Static routing problem

RouterOS General
1

Hi, I’m new to Mikrotik and I’ll try to make this as brief as possible. We are replacing pfSense with Mikrotik and I encountered a single problem that is preventing me to accomplish my task. It’s a single static route that is making my head ache.

Topology:

Internet GW <—> pfSense <—> Wireless (Tropos) GW <— mesh —> AP7 <— subinterface —> Webcam

Internet GW: 172.16.6.1
pfSense: 172.16.6.10/24 (eth0), 10.14.4.1/23 (eth1)
Wireless GW: 10.14.4.14 (eth0), 10.14.4.16 (wlan0)
AP7: 10.14.4.18 (wlan0)
Mesh (APs): 10.14.4.10 → 10.14.4.30
AP Sub-interface: 10.14.7.1/24 (eth0)
Webcam: 10.14.7.3 (eth0)

To be able to access the Webcam, you must add a static route to pfSense as:

10.14.7.0/24 → GW 10.14.4.18 (or any other AP, since a routing table is distributed throughout the entire mesh by Tropos itself

With pfSense, everything works well. If you remove the static route, you cannot access the Webcam. Webcam can however be accessed within the Wireless network since the routing table is automatically distributed among all the APs within the mesh.

When I switch pfSense with Mikrotik RB1100ah (RouterOS 5.16), a strange problem arises.

First the configuration:

2 interfaces:

2 R WAN
6 R Wifi

IP Addresses:

1 172.16.6.10/24 172.16.6.0 WAN
2 10.14.4.1/23 10.14.4.0 Wifi

NAT is enabled on both interfaces (add action=masquerade chain=srcnat)

Hotspot is enabled, and just to be sure, ip-binding is enabled for 10.14.7.0/24 and for all AP IPs.

This is routing table:

 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 A S  0.0.0.0/0                          172.16.6.1                1
 1 ADC  10.14.4.0/23       10.14.4.1       Wifi                 0
 2 A S  10.14.7.0/24       10.14.4.1       10.14.4.18                1
 3 ADC  172.16.6.0/24      172.16.6.10     WAN                       0

Now, the funny part:

  1. Static route enabled (as shown above):
[admin@MikroTik] /ip route> /ping 10.14.7.3
HOST                                     SIZE TTL TIME  STATUS                                                                                                                         
10.14.7.3                                  56  61 10ms 
10.14.7.3                                  56  61 6ms




[admin@MikroTik] /ip route> /ping 10.14.4.14
HOST                                     SIZE TTL TIME  STATUS
10.14.4.14                                              timeout




[admin@MikroTik] /ip route> /ping 10.14.4.16
HOST                                     SIZE TTL TIME  STATUS                                                                                                                         
10.14.4.16                                 56  64 0ms  
10.14.4.16                                 56  64 0ms  
10.14.4.16                                 56  64 0ms
  1. Static route disabled:
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 A S  0.0.0.0/0                          172.16.6.1                1
 1 ADC  10.14.4.0/23       10.14.4.1       Wifi                 0
 2 X S  10.14.7.0/24       10.14.4.1       10.14.4.18                1
 3 ADC  172.16.6.0/24      172.16.6.10     WAN                       0




[admin@MikroTik] /ip route> /ping 10.14.4.14
HOST                                     SIZE TTL TIME  STATUS                                                                                                                         
10.14.4.14                                              timeout                                                                                                                        
10.14.4.14                                 56  64 8ms  
10.14.4.14                                              timeout                                                                                                                        
10.14.4.14                                 56  64 8ms  
10.14.4.14                                 56  64 0ms  
10.14.4.14                                 56  64 0ms  
10.14.4.14                                              timeout                                                                                                                        
10.14.4.14                                 56  64 8ms  
10.14.4.14                                 56  64 0ms  
10.14.4.14                                 56  64 0ms  
10.14.4.14                                 56  64 1ms  
10.14.4.14                                 56  64 0ms  
10.14.4.14                                 56  64 0ms  
10.14.4.14                                 56  64 0ms  
10.14.4.14                                 56  64 0ms  
10.14.4.14                                 56  64 0ms  
10.14.4.14                                 56  64 0ms  
10.14.4.14                                 56  64 0ms

And no more timeouts after secondary ping and forth…

My question is, why is the static route, which has a different subnet from Wifi, preventing a successful ping of 10.14.4.14, which is the eth0 interface of Tropos GW AP? And why would there be ping losses to begin with, since it’s a physical cable connection?

Any idea would be highly appreciated. I might be doing something wrong with the routing as well.

Edited to add:
May I just add that debugging eth0 interface on Tropos GW does not show up any ICMP requests while static route is enabled. By this fact I assume that it’s not a routing problem on Tropos GW of any kind.

And I also tried adding the static route for 10.14.4.14/32 for WifiLasko interface and still no luck.

Thanks,
Gorazd,
Slovenia

2

I solved this by moving the 10.14.7.0/24 subnet to 10.15.1.0/24. This change seems to solve the issue.

Edited to add:

Incorrect. First few pings went through, but no more. The problem remains.

3

I believed changing the subnet would solve the problem but it really didn’t. It worked for a short while but started failing right after.

Current routing table is:

[admin@MikroTik] /ip route> print
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit 
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 A S  0.0.0.0/0                          172.16.6.1                1
 1 ADC  10.14.4.0/23       10.14.4.1       WifiLasko                 0
 2 A S  10.15.1.2/32                       WifiLasko                 1
 3 ADC  172.16.6.0/24      172.16.6.10     WAN                       0

What I don’t understand is this → tracking down the packets using /tool sniffer shown different results when interface filter is in use. If I user interface=all, I get this result when pinging the problematic interface:

Wifi    3.553      6 ->                                             10.14.4.1                           10.14.4.14                          ip:icmp      56
Wifi    4.551      7 ->                                             10.14.4.1                           10.14.4.14                          ip:icmp      56
Wifi    5.553      8 ->                                             10.14.4.1                           10.14.4.14                          ip:icmp      56
Wifi    6.551      9 ->                                             10.14.4.1                           10.14.4.14                          ip:icmp      56
.
.

But if I set the filter to interface=Wifi, I only see the packet which acually go through the Wifi interface and reach the destination (which can be also confirmed in the Tropos’ debug view.

So, sniffer is showing that “lost” packets are actually going through Wifi interface (when interface=all is used), but is not showing the same “lost” packets when filter interface=Wifi is used. Why?

I still have no clue what could be the cause of 95% ping loss and why do some icmp packets actually go through.

Cheers,
G.

4

ARP-Ping does work, but it returns duplicated results:

[admin@MikroTik] /ip route> /ping arp-ping=yes 10.14.4.14 interface=Wifi 
HOST                                     SIZE TTL TIME  STATUS                                                                                                                         
00:0D:97:00:E2:7E                                 0ms  
00:0D:97:00:E2:7E                                 0ms  
.
.
.

Whereas ARP-Ping to Webcam returns single reply, with the same MAC as eth0 of the Tropos GW:

[admin@MikroTik] /ip route> /ping arp-ping=yes 10.15.1.2 interface=Wifi       
HOST                                     SIZE TTL TIME  STATUS                                                                                                                         
00:0D:97:00:E2:7E                                 0ms

I’m lost.

Cheers,G.

5

I changed the IP address for the subnet in the meantime. I reported the issue with Mikrotik support. It might be related to the Tropos devices.