I'm broadcasting a /24 through one upstream and am working on adding our second. This is my first time doing this with Linux/BIRD. I have two routers speaking eBGP to each ISP, one is giving me a default route only (0.0.0.0/0) and the other is giving me a default route along with a partial routing table.
I have the network on our side segmented into /28s, which will have each /28 on its own router and talk to the two eBGP routers via OSPF. Right now all the /28s are on one router while I set this up.
When I bring up one or the other upstream, everything works perfect, but when I bring up both, we have problems. OSPF will choose 0.0.0.0/0 as the best path for whichever eBGP router comes up first. If eBGP A comes up first, 0.0.0.0/0 will point to eBGP A. In this case, any traffic from eBGP B will be dropped, even though the /28 is still in eBGP B router's table and "ip route show to/from/etc" shows the correct path. If I take down eBGP A, eBGP B will automatically be installed as the default router via OSPF in the /28 router and all will be fine.
is my /28 router rejecting traffic from eBGP B in this case because it isn't seen as a valid upstream path to originate this traffic by iproute2? Do I need to add a second routing table to the kernel to mitigate this? Does anyone else have experience multi-homing with BIRD eBGP/OSPF in this way?
I've tried all sorts of other things, and really think it's related to the 0.0.0.0/0 route, and perhaps it taking precedence and creating a routing loop with the eBGP routers, or it rejecting routes on the /28 because of the origin of the traffic not matching the "default" gateway. My main goal is high availability and not load balancing, so not having the routing table to pick routes isn't a high priority for me.
net.ipv4.ip_forward is set to 1, and rp_filter is disabled while I test.
No comments:
Post a Comment