Overriding Default routes with BGP
I have a customer with 2 carriers. They have their own ASN, and are running BGP to the carriers. Unfortunately, they are using HSRP on their carrier facing routers. Without explaining all of that and the problems they run into, I thought okay simple solution we will run iBGP from their border routers back to the WG. I have that all set up with no problems.
However, no matter what I try I cannot override the built in default routes in the WG. If I disable Multi-Wan it forces me to enter a default route. I do not want a statically defined default route. I want BGP to do its thing.
If there is a default route learned from the carriers I want to pass that on from the border routers to the WG. I have multi-path (BGP config) set up in BGP. If both routes to the carriers are up, those default routes should flow down to the WG and the routing table should do its thing. This all works great. I see the learned default routes in BGP and the RIB. However, if an upstream link goes down and my WG facing router no longer advertises a default route to the WG, the WG still leaves a default route in place, obvious bad things to happen.
I've spent many hours trying everything I can think of. Custom interfaces, setting the default route to different things. Anything to try to over-ride the default route so iBGP and the RIB can take over. No matter what I do, both external interfaces have a route in the RIB, even though they shouldn't. The problem is if the outage is upstream the WG will still send traffic out that direction.
The best solution I've come up is setting up multi-wan with link monitor. I really did not want to do that. Dynamic routing protocols were invented to handle these situations.
So, my question is how can I set up a WG to prevent an external (whether it is set to that or not) interface from putting a default route into the RIB?
Comments
Hi @Mury
I don´t know much about bgp or ffr, but maybe a deny rule preventing importing the default route, if it is possible to do this in fireware?
https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-stop-default-route-inject-into-routing/ta-p/232185
/Robert
Hi Robert,
Thats the opposite of what I want to do. I was trying to find the right verbiage to explain I want to have those imported default routes get ahead of the built in default routes in the WG. Maybe that should have been my first question. Is what is the process that takes an external interface and turns it into a default route in the RIB?
I want the iBGP default routes to control the traffic. Not the WG default routes that I can't wrap my head around... or seem to get around.
Ahh,sorry.
What if you change the bgp destince default route to a lower value or the same as the static route? Maybe this overrride the static routing.
/Robert
Yup, that is the problem. Apparently whatever mix of attempts I was trying was not working. For whatever reason, not saying it's wrong, but the default route in WGs is apparently an AD of 5. Getting Quagga (which I am not super familiar with) to change the BGP AD to less than 5 was sure making me feel dumb.
Anyway, I think I finally have it.
WG#diagnose dynroute "show ip route"
Codes: K - kernel route, C - connected, S - static, R - RIP,
O - OSPF, I - IS-IS, B - BGP, P - PIM, A - Babel, N - NHRP,
B>* 0.0.0.0/0 [2/0] via 10.6.6.1, eth6, 00:02:43 <----Yay
O 0.0.0.0/0 [110/1] via 10.6.6.1, eth6, 16:58:06
S 0.0.0.0/0 [5/0] is directly connected, Null0
I haven't tested it with the end goal in mind, but this is the progress I needed. I have a relatively complicated BGP config, so I'm not going to paste it here, but in the end it was the line "distance bgp 2 2 2" under the address-family ipv4 section that finally resulted in the AD change I needed. I still have a lot of fine-tuning to do, but in case anyone else runs into the same issue I figured I'd drop a quick note in here.
Note under status report it shows up as:
IPv4 Routes
Destination Gateway Genmask Flags Metric Interface
0.0.0.0 10.6.6.1 0.0.0.0 UG 0 eth6
0.0.0.0 10.6.6.1 0.0.0.0 UG 5 eth6
0.0.0.0 10.7.7.1 0.0.0.0 UG 5 eth7
Which leads to a feature request to show more information in the FSM status report. Having to bounce back and forth between an ssh session and policy manager is not ideal since you can't save your changes while ssh'ed in.
Now hopefully it all works as it should in my mind... Have a good day.