How does OSPF pick its concept of a default route in a line of
tiks, in particular when every interface has two or more subnets on it, both connecting to the
tik next door.
For example
internet → tik1 ↔ tik2
209.150.1.1 209.150.1.2
10.150.1.1 10.150.1.2
The default route of tik2 can be 209.150.1.1 or 10.150.1.1.
Packets originating from the tik tend to have a source address of the default route subnet,
I believe.
Thus if a OSPF has chosen 10.150.1.1 as the default route for tik2 , and a ping is issued from tik2 to the internet, It’s src will be 10.150.1.2 which will fail if there is no NAT.
Is the question about actual “default routes” or more about which route will be active when there are multiple possible routes between devices?
If you have multiple subnets on the same interfaces of adjacent routers then you may well end up with an ECMP route installed - you can see the multiple gateways if you look closely at the route.
My question would be why do you need multiple default routes? Do you have more than one Internet exit point? If not, then one default is probably all you need and specifically advertise the other subnets and networks.
But to get to the radios which are bridges, they put a second subnet on the link.
tik1 → radio1 → radio2 → tik2
tik1 is 10.150.1.1/29
radio1 is 10.150.1.2/29
radio2 is 10.150.1.3/29
tik2 is 10.150.1.4/29
rebootbox is 10.150.1.5/29
Since no default route is statically declared, OSPF shows that data going from tik2
to tik1 can go out BOTH, 209.150.1.1 or 10.150.1.1 and shows this in the routes line at
routing → OSPF → routes
Further if the default route is not specified, OSPF seems to pick the route from the
two IP randomly, or by some means I am missing.
I wish to control this behavior so that the public IP’s are ALWAYS used, and the
private one’s never used, unless one is talking to the radio’s directly.
There are 3 situations in which this is important.
1.) tracerouting in from the outside world, if the 10s are used, I get * * *, I hate that
2.) If end users are NATTED through the tik using simple masquerading with no further
specification of the SNAT IP, their packets can go out with 10’s as the src IP and they
die eventually.
3.) When using the tik as a hotspot, when the hotspot originates communications to the outside world such as during authentication, it can pick the 10. as the source address and thus the hotspot fails.
I am apologize if I am so confused I don’t know what I am talking about, OSPF is very new
to me. All the tiks on our system use OSPF, with hundreds of routes in the routing table, and on some of the tiks all the routes are directed to a 10 gateway rather than a 209 gateway even though both addresses are on the ether net the packets are being directed out over.
Gotcha…your problem is management vs traffic segregation. Most ISPs use a routing mark (or VRF) to segregate management networks and public traffic. Once you have that separation, all you need to do is manage the routes and routing tables on your core router.
This is a security issue as well - public should never see private in a carrier network - this is a golden rule of Service Provider networking.
My suggestion would be to explore this section of the Wiki:
Also, Scott Hammersley, a Network Architect and Mikrotik Consultant for IP ArchiTechs is doing a presentation on segregating your network using VRF/Routing Marks at the 2013 MUM - St Louis.
So OSPF has indeed installed an ECMP route. The RouterOS OSPF implementation doesn’t have a lot of controls in that area so this situation is simply best avoided if (as in this case) ECMP routes are undesirable.
Your options for avoiding it depend in part on what management options the radios support and what traffic isolation options they support. e.g. if the supported VLANs for both you could have a fairly easy way of isolating traffic groups and removing the management addresses from customer data path.
If you can share more info the options might be clearer. If you are sharing public IP information feel free to use the email address in my sig rather than publicly posting.
