I just noticed the following problem with RouterOS 6.30/6.31 that wasn’t happening with 6.18:
I have routers with both a private IP and a public IP addresses on the same interface. All the routing is done on the public IPs and only the public IP networks are configured in OSPF:
When doing a traceroute from PC1 to PC2, router2 will be listed as “192.168.1.2” instead of 194.xxx.xxx.3
But the routes in router1 are correctly set to 194.xxx.xxx.3 and not to 192.168.1.2
If I disable the 192.168.1.2 address, the router2 will correctly answers with 194.xxx.xxx.3 address. If I enable again the private IP, it will continue to answer correctly with 194.xxx.xxx.3. At least until the next reboot of the router.
I never saw something like that with RouterOS 6.18 or earlier.
This is not something that is broken... it is just something that needs to be managed via setting the pref-src attribute, when you have a interface with multiple IP's.
pref-src (IP; Default: "") Which of the local IP addresses to use for locally originated packets that are sent via this route. Value of this property has no effect on forwarded packets. If value of this property is set to IP address that is not local address of this router then the route will be inactive. If pref-src value is not set, then for locally originated packets that are sent using this route router will choose one of local addresses attached to the output interface that match destination prefix of the route (an example).
If that was the case, then why did the behavior changed from version 6.18 (and earlier)? Such things never happened before.
If pref-src value is not set, then for locally originated packets that are sent using this route router will choose one of local addresses attached to the output interface > that match destination prefix of the route
That’s obviously not the case…
Packets are returned with a source address that isn’t the one they were sent at… If I have an interface with IP 192.168.0.1 and 192.168.100.1 and I ping 192.168.100.1, packets should come back from that IP. And not from 192.168.0.1
Also, please note that this happen after booting the router. If you disable and enable back the IP address, then the router correctly answer with the right IP. A traceroute to 192.168.0.1 will show 192.168.0.1 and a traceroute to 192.168.100.1 will show 192.168.100.1 (and not 192.168.0.1)
traceroute to http://www.google.com (173.194.67.103), 30 hops max, 60 byte packets
1 193.247.238.17 0.171 ms 0.157 ms 0.173 ms
2 192.168.252.2 0.367 ms 0.363 ms 0.420 ms
3 193.247.238.11 3.423 ms 5.080 ms 5.073 ms
The first router (193.247.238.17) doesn’t even have an IP address on the 192.168.252.0/24 network and that address isn’t routed in anyway.
Now, if I disable and enable back the 192.168.252.2 IP address on the router then I get the expected result:
traceroute to http://www.google.com (173.194.116.84), 30 hops max, 60 byte packets
1 193.247.238.17 0.164 ms 0.157 ms 0.177 ms
2 193.247.238.39 0.371 ms 0.402 ms 0.437 ms
3 193.247.238.11 1.839 ms 2.008 ms 2.761 ms
Even if that was “normal behavior”, why disabling and enabling back the IP would be enough to change the result? And why did it never happened with previous versions of RouterOS?
and if I disable and enable back the 193.247.238.39 IP address on the router, I again get the wrong result:
traceroute to http://www.google.com (173.194.116.82), 30 hops max, 60 byte packets
1 193.247.238.17 0.159 ms 0.147 ms 0.166 ms
2 192.168.252.2 0.356 ms 0.348 ms 0.372 ms
3 193.247.238.11 1.765 ms 3.137 ms 4.581 ms
So it looks like the order in which the address are defined matter. That doesn’t make any sense. It shouldn’t matter that I configure one address or another first. Or that the router enable one address or the other first.
I was not offering you an explanation on why it happens … I was offering you the way to solve it..
I often have to remind myself and others, in our business, when standards are not followed (or proper configuration not done) the net result is not something broken but more realistically something not working consistently…
Mind to elaborate how I can change the pref-source value of an interface route using filters? I wouldn’t mind giving it a try even if I doubt it would change anything: The pref-source value displayed for the routes are already the same as the ones shown in earlier version of RouterOS…
For static routes, you have the option pref-source option that you can set
For OSPF routes, you have ospf-in filters where you can set the pref-source option.
I had to deal with a specific situation with BGP (Peering) where I had to set the pref-source for incoming routes …
I have not played much with OSPF filters.. have not had the need to.
I am speaking of “interface route”. They are automaticaly added by the system and, to my knowledge, there is no possibility to modify their parameters.
As a side note, the behavior is correct up to RouterOS 6.29. I just downgraded to it (I am not trusting that it’s just “cosmetic” and won’t have some other nastly little effects hidden somewhere)
