v7.1.3 CHR ping with routing-mark

Hello,

I have a failover system based on pinging with specific routing-marks to check the status of multiple WAN interfaces.
Everything is handled with a custom script, no netwatch or whatever.

This works fine in rOS6 but I’m trying to redesign to conform with changes in rOS7.

As ping command does not support routing-table option, I’ve setup VRF for each WAN, without adding any interface.
Related configuration :

/ip vrf
add interfaces=none name=testing-ether3
add interfaces=none name=testing-ether2

/ip route
add dst-address=0.0.0.0/0 gateway=192.168.20.254 routing-table=testing-ether2
add dst-address=0.0.0.0/0 gateway=192.168.21.254 routing-table=testing-ether3
add distance=1 dst-address=0.0.0.0/0 gateway=192.168.20.254
add distance=2 dst-address=0.0.0.0/0 gateway=192.168.21.254

This “works”.
The issue is that it stops working randomly and will not work unless I ping out of the main routing table.

example :

[admin@sini7] > ping count=4 8.8.8.8 vrf=testing-ether2
  SEQ HOST                                     SIZE TTL TIME       STATUS                        
    0 8.8.8.8                                                      timeout                       
    1 8.8.8.8                                                      timeout                       
    2 8.8.8.8                                                      timeout                       
    3 8.8.8.8                                                      timeout                       
    sent=4 received=0 packet-loss=100% 

[admin@sini7] > ping count=4 8.8.8.8 vrf=testing-ether3
  SEQ HOST                                     SIZE TTL TIME       STATUS                        
    0 8.8.8.8                                                      timeout                       
    1 8.8.8.8                                                      timeout                       
    2 8.8.8.8                                                      timeout                       
    3 8.8.8.8                                                      timeout                       
    sent=4 received=0 packet-loss=100% 

[admin@sini7] > ping count=4 8.8.8.8
  SEQ HOST                                     SIZE TTL TIME       STATUS                        
    0 8.8.8.8                                    56  55 43ms173us 
    1 8.8.8.8                                    56  55 43ms28us  
    2 8.8.8.8                                    56  55 43ms171us 
    3 8.8.8.8                                    56  55 43ms371us 
    sent=4 received=4 packet-loss=0% min-rtt=43ms28us avg-rtt=43ms185us max-rtt=43ms371us 

[admin@sini7] > ping count=4 8.8.8.8 vrf=testing-ether2
  SEQ HOST                                     SIZE TTL TIME       STATUS                        
    0 8.8.8.8                                    56  55 42ms916us 
    1 8.8.8.8                                    56  55 43ms205us 
    2 8.8.8.8                                    56  55 43ms46us  
    3 8.8.8.8                                    56  55 43ms726us 
    sent=4 received=4 packet-loss=0% min-rtt=42ms916us avg-rtt=43ms223us max-rtt=43ms726us 

[admin@sini7] > ping count=4 8.8.8.8 vrf=testing-ether3
  SEQ HOST                                     SIZE TTL TIME       STATUS                        
    0 8.8.8.8                                    56  55 43ms288us 
    1 8.8.8.8                                    56  55 44ms400us 
    2 8.8.8.8                                    56  55 43ms599us 
    3 8.8.8.8                                    56  55 42ms993us 
    sent=4 received=4 packet-loss=0% min-rtt=42ms993us avg-rtt=43ms570us max-rtt=44ms400us

However, what’s even more weird is that packets are actually being sent and received.

example and attached pcap file

[admin@sini7] > do { tool sniffer start ip-address=8.8.8.8
{... ping count=4 8.8.8.8 vrf=testing-ether2
{... ping count=4 8.8.8.8 vrf=testing-ether3
{... ping count=4 8.8.8.8
{... ping count=4 8.8.8.8 vrf=testing-ether2
{... ping count=4 8.8.8.8 vrf=testing-ether3
{... delay 20s
{... ping count=4 8.8.8.8 vrf=testing-ether2
{... ping count=4 8.8.8.8 vrf=testing-ether3
{... tool sniffer stop
{... tool sniffer save file=test.pcap
{... }
  SEQ HOST                                     SIZE TTL TIME       STATUS                        
    0 8.8.8.8                                                      timeout                       
    1 8.8.8.8                                                      timeout                       
    2 8.8.8.8                                                      timeout                       
    3 8.8.8.8                                                      timeout                       
    sent=4 received=0 packet-loss=100% 

  SEQ HOST                                     SIZE TTL TIME       STATUS                        
    0 8.8.8.8                                                      timeout                       
    1 8.8.8.8                                                      timeout                       
    2 8.8.8.8                                                      timeout                       
    3 8.8.8.8                                                      timeout                       
    sent=4 received=0 packet-loss=100% 

  SEQ HOST                                     SIZE TTL TIME       STATUS                        
    0 8.8.8.8                                    56  55 43ms57us  
    1 8.8.8.8                                    56  55 42ms751us 
    2 8.8.8.8                                    56  55 42ms621us 
    3 8.8.8.8                                    56  55 43ms370us 
    sent=4 received=4 packet-loss=0% min-rtt=42ms621us avg-rtt=42ms949us max-rtt=43ms370us 

  SEQ HOST                                     SIZE TTL TIME       STATUS                        
    0 8.8.8.8                                    56  55 43ms117us 
    1 8.8.8.8                                    56  55 42ms120us 
    2 8.8.8.8                                    56  55 43ms64us  
    3 8.8.8.8                                    56  55 43ms616us 
    sent=4 received=4 packet-loss=0% min-rtt=42ms120us avg-rtt=42ms979us max-rtt=43ms616us 

  SEQ HOST                                     SIZE TTL TIME       STATUS                        
    0 8.8.8.8                                    56  55 42ms984us 
    1 8.8.8.8                                    56  55 42ms933us 
    2 8.8.8.8                                    56  55 42ms746us 
    3 8.8.8.8                                    56  55 42ms630us 
    sent=4 received=4 packet-loss=0% min-rtt=42ms630us avg-rtt=42ms823us max-rtt=42ms984us 

  SEQ HOST                                     SIZE TTL TIME       STATUS                        
    0 8.8.8.8                                                      timeout                       
    1 8.8.8.8                                                      timeout                       
    2 8.8.8.8                                                      timeout                       
    3 8.8.8.8                                                      timeout                       
    sent=4 received=0 packet-loss=100% 

  SEQ HOST                                     SIZE TTL TIME       STATUS                        
    0 8.8.8.8                                                      timeout                       
    1 8.8.8.8                                                      timeout                       
    2 8.8.8.8                                                      timeout                       
    3 8.8.8.8                                                      timeout                       
    sent=4 received=0 packet-loss=100%

bug.pcap.zip (1.57 KB)
Can anyone shed some light here?

Shamelessly bumping this.

I have the same problem with RouterOS 7.2
Is this a bug? Is there a workaround? I had to downgrade to RouterOS 6.x because I can’t find a working solution to replace the missing ping routing-table parameter.

I believe I found a workaround. It seems to work, if you add

check-gateway=ping

or

check-gateway=arp

to the routes.

Same problem here with 7.2
There is no possibility to specify a routing mark in ping, it’s a problem for the scripting

Dont understand why are you using pinging other than check-gateway=ping
No need to mark anything???

Basic Multi-WAN Failover
/ip route
add check-gateway=ping comment=Primary ISP distance=5 dst-address=0.0.0.0/0 gateway=Primary-gatewayIP scope=30 target-scope=11
add comment=SecondaryISP distance=10 dst-address=0.0.0.0/0 gateway=Secondary-gatewayIP scope=30 target-scope=11

MultiWAN with Recursive
/ip route
add check-gateway=ping distance=3 dst-address=0.0.0.0/0 gateway=1.0.0.1 scope=30 target-scope=12
add comment=Recursive-A distance=3 dst-address=1.0.0.1/32 gateway=PrimaryISP-gatewayIP scope=10 target-scope=11
add comment=SecondaryISP distance=10 dst-address=0.0.0.0/0 gateway=SecondaryISP-gatewayIP scope=30 target-scope=11

The use of ping with a routing mark is not only for wan failover

Yes, and the workaround using vrf instead of routing-table is described in the first post + my additional workaround. This works with 7.2.

can confirm this is happening to me too.
http://forum.mikrotik.com/t/mikrotik-7-x-ccr1072-1036-ping-issue/157418/1



Cause It’s not my gateway that’s going down.
I ping towards the intenet, through that gateway.
Like, what’s a realistic scenario where a gateway goes off? If your WAN connection is an ADSL modem-router and the DSL connection drops, does the modem-router, your gateway, stop replying to ping requests and becomes in-accessible?

The OP doesn’t work. It describes a potential workaround using the tools available in v7 but does not work properly, as described in the OP.

Do we have any update here whether the issue is resolved with a latest ROS7 update ?

Same problem here.
We don’t use the Check-Gateway option anymore, because we needed a more extensive testing methode to prevent to much switching when the connection is instable.
Therefore we are using the same methode @sin3vil.

We first want to check if the primary WAN is stable, but is not the default route.
Only after a few minutes make the switch back to the primary.

In ROS7.3 I even can’t get it to work at al anymore.
I some has an alternative solution

N1bble we are all here stuck with the same problem in implementation and as there is not easy workaround we are more interested to know if this is something Deprecated on ROS or we should hold our horses as it is getting fixed

If your ISP is that bad find another one…

useless post is useless…

And yours then, do you think it is of any use?