with ROS version 6 it was easy to use the ping command with routing-marks:
ping x.x.x.x routing-table=myRoutingMark
ROS Version 7 lacks the option routing-table.
How do I use the ping command to test/use the routes, that are marked with different routing marks?
I read the docs, but can’t find anything useful. VRFs are not useable, because every VRF instance need their own interface. In my setup, there is one interface, that faces to a couple of gateways, that are used by routing-marks. Routing rules can’t be applied, because the source and destination of the ping command is evertime the same. Only the routing-mark is changed, to take another “way” through the network.
Without knowing what you are trying to accomplish with your traffic, its not feasible to answer.
What traffic are you trying to support.
mangles, routing routes, vpns in the mix ???
If it helps ¯_(ツ)_/¯:
n clients are routet via n routers to the internet, using mangle rules, PCC and routing marks. The Mikrotik router sits between the clients and internet routers. It has a LAN interface (Client traffic enters here) and a WAN interface (Traffic to the internet leaves here). There is no NAT involved on the MT. Only routing. Only the internet router use NAT to masquerade the LAN IPs to their public IP.
This setup supports all IP traffic. Including VPN. And it works fine.
Right know there is a default route to each internet router. Seperated by routing marks. Any router is a backup with higher scope for the ohter routing marks. Every LAN IP address is marked in the pre-routing chain with a routing mark, that is used in the routing table. At this point the client and internet connection is coupled.
There are scripts for each internet router, to find out wich one is online/offline, because the direct connected networks could be online, but the internet connection is offline. These scripts use the ping command with the routing mark to test the particular default route. For example “if ping 8.8.8.8 routing-table=router1 fails, all routes to this router are disabled”.
This last step won’t work with ROS v7, because the ping command can’t use marked routes any more.
Any further questions? or suggestions to solve the problem: “connect n clients to n internet routers”?
Thanks for the link. Sounds exactly like my issue. Wonder why I didn’t found it before
I will look into it. On first quick look I missed the option to create a VRF with interface “none”, because it is not possible to create a vrf without an interface (error notice). It is necessary to explizitly choose the “none” option for the interface field. Very confusing
Fyi: The MT support states, that the routing-table option is currently not implemented. It’s on a todo list and may come back in some unspecified time.
Ok. Thank you all. I figured out what has to be changed to make it work again
FYI:
Backup all configuration parts, where routing marks are used (e.g. /ip/route, /ip/firewall/mangle)
Delete all old routing marks in /routing/tables
Create all old routing marks in /ip/vrf (with interface “none” )
Set all routing marks in /ip/routes, because they were deleted (I deleted all affected routes and imported them from the backup)
If you use /ip/firewall/mangle with routing marks, set the marks here as well
In my case, I had to adjust all scripts to use vrf, and the option in the routing table has changed as well from “routing-mark” to “routing-table”
Fun fact: It is possible to have entries with the same name in /ip/vrf and /routing/tables. And it is possible to choose both of this entries as routing mark for a route in /ip/routes
There’s a bug in ROS 7:
Using VRF as replacement will not work properly. The MT support confirmed that today. In fact they say “You cannot use VRFs as a pure routing marks in v7”.
Here is a quote of my support request. Described for a lab setup (see attachement). You can simplify the setup by deleting the eth2, vrrp, vlan600 parts. I tought, that it could be something with this features, but the issue is more basic.
The issue:
The ping command fails if used with VRFs/Routing marks and gateways in the main routing table. e.g. ping 1.1.1.1 vrf=mark1.
The lab setup:
There are two routers in the lab setup (network scheme is attached). Each of them has two interfaces (eth2 and eth3) that are connected to each other and simulate the multiple gateway setup. eth3 is “directly” connected (no vlans or vrrp). eth2 is more sophisticated with a vrrp session and vlan on top of the vrrp session. The second router has a “internet address” (1.1.1.1) on its loopback interface to simulate a far away device. In short: the second router is only the counterpart station to router one.
The first router is the one, where the issue can be observed. Besides its two described devices, it has two VRFs (mark1 and mark2) with interface “none”. These marks are used in the routing table with two default routes. Everything else is direcly connected.
The observations:
After bootup the ping command “ping 1.1.1.1 vrf=mark1” results in timeouts. Same for mark2. If the packets are sniffed on that devices (vlan600 or eth3) the echo reply is received.
If one of the gateways are pinged (e.g. ping 192.168.1.2) and short after that, the “ping 1.1.1.1 vrf=mark1” command is executed, the ping command succeeds. It will continue to succeed, as long as it is not canceled.
If you execute the gateway ping command and wait for 12-15 seconds (I can’t figure it out exacly), before executing the ping vrf command, the ping with vrf option will time out.
Connection tracking will show nothing - as expected in this setup.
The workaround is to create a script, that performs a ping on any IP address you like (it can even fail) and a scheduler event, that runs this script any 8 or 10 seconds. Because every 12 to 15 seconds something happens in router OS, that make the ping via vrf time out again. With this script in place, the other scripts (that use the vrf) work again.
I hope MT brings back the routing-table option soon
You can (using v7.22) state the interface you want to ping out on from the ping command/window.
Not the same as routing table but resolves most of my problems.
I have multiple PPPoE interfaces named PPPoE_1..57
/ping 8.8.8.8%PPPoE_1
/ping 8.8.8.8%PPPoE_34
Or just plain
/ping 8.8.8.8%ether2
This does not use any routing table, so does not allow for checking if you have bad routes, but at least you can check if interfaces / destinations are operational.
