Show from a working router the results of /system syslog export.

Show from a non-working router the results of /system syslog export.

Ensure the IP addresses from both routers are permitted to talk to the Kiwi server on the syslog port.

Same configuration in non working syslog also.

Ensure the IP addresses from both routers are permitted to talk to the Kiwi server on the syslog port.

Actually, he didn't follow instructions at all... I asked for exports in case there is something which set or unset which is one of the many RouterOS configuration parameters which do not show in the results of a print command.

Also, I guess we are supposed to take his word for it that the non-working router's results are exactly the same. The whole point is to show the "equal" results to others so that they can see what you have been staring at for too long to see for yourself.

If you don't want to show me the configs at least show me the results of "diff -u configA configB". All other claims are suspect. That is often the only way I see the mistakes in my configs.

Yes, i am able to ping from both routers and kiwi syslog to routers also , even i tried to upgrade and downgrade the versions but same issue repeated.
check out the images and .rsc of non working and working

 diff -u syslogworking.rsc syslognotworking.rsc            14:19:58
--- syslogworking.rsc   2014-11-21 01:42:04.000000000 -0600
+++ syslognotworking.rsc        2014-11-21 01:23:14.000000000 -0600
@@ -1,11 +1,10 @@
 #
 /system logging action
-set 0 memory-lines=100
-set 1 disk-lines-per-file=100
-set 3 remote=202.133.57.80
+set 1 disk-file-name=""
+set 2 remember=yes
+set 3 remote=202.133.57.80 syslog-facility=syslog
 /system logging
 set 0 action=disk topics=info,!firewall
 add action=remote topics=firewall
-add topics=e-mail

Yes, i am able to ping from both routers and kiwi syslog to routers also , even i tried to upgrade and downgrade the versions but same issue repeated.
check out the images and .rsc of non working and working

Please, do not make gratuitous changes such as changing the version of RouterOS. Let us debug this using scientific methods.

The working and non-working devices' remote "system logging action" settings are not identical PLUS they apparently source their syslog traffic from completely different /8s.

You actually have a lot of gratuitous differences between the working and non-working routers. However, only the remote syslog logging action is likely to have a chance of being the culprit.

Code: Select all

 diff -u syslogworking.rsc syslognotworking.rsc            14:19:58
--- syslogworking.rsc   2014-11-21 01:42:04.000000000 -0600
+++ syslognotworking.rsc        2014-11-21 01:23:14.000000000 -0600
@@ -1,11 +1,10 @@
 #
 /system logging action
-set 0 memory-lines=100
-set 1 disk-lines-per-file=100
-set 3 remote=202.133.57.80
+set 1 disk-file-name=""
+set 2 remember=yes
+set 3 remote=202.133.57.80 syslog-facility=syslog
 /system logging
 set 0 action=disk topics=info,!firewall
 add action=remote topics=firewall
-add topics=e-mail

On the not working version, you have specified "syslog-facility=syslog". The working version is using the default "syslog-facility=daemon".

I do not know if the syslog facility takes effect when you have not checked the "bsd-syslog" box. I log to a BSD syslog server rather than Kiwi, so I enable the BSD syslog option on my devices.

Based on that, I would say the first step is to set your non-working system's syslog-facility to "daemon". Whether or not that is a problem may depend on your Kiwi config. Kiwi could, theoretically, be set to ignore the "syslog" facility tagged log entries.

The second step is to make certain that Kiwi and the Windows firewall, and any other firewalls between the non-working device and the syslog server, are configured to allow UDP traffic on port 514 from your non-working system, 175.101.X.X. Are there any working devices in the 175.101.X.X network?

You are apparently permitting UDP traffic on port 514 from your working system, 202.133.Y.Y, in Kiwi and the Windows firewall and all other firewalls between the working device and the syslog server. Are there any non-working devices in the 202.133.Y.Y network?

You may want to set your syslog source address on the non-working system so that you will know that it is not accidentally sourcing the traffic from a different non-allowed IP on the non-working system. MikroTik's syslog client will choose to use the "closest" IP to the syslog server, if you do not explicitly set the source address.