As OSPF recent design issue discussed here can possibly turn into obnoxious CCIEv5 R&S troubleshooting scenario, I got one email from another friend who also ran into interesting OSPF design issue recently around OSPF default information originate too.
Here is a quick topology of his network design:
At high level the design looks pretty simple. R1 & R2 are peering with WAN cloud using E-BGP. Between R1-R2-R3-R4-R5 we are running OSPF Area 0. To ensure R3-R4-R5 have reachability to external prefixes (Since it's always good to avoid BGP to IGP Redistribution), R1 & R2 are injecting default route into the network using "default-information originate always metric-type 1" option.
Also R1 & R2 are connected to each other over a link running OSPF.
Now let's talk about problem...which is the fun part :)
If R1's WAN connection goes down, R4 can't reach any external prefixes using default route any longer. Whereas at the same time both R3 & R5 don't lose their connectivity to same external prefixes.
Now ideally once R1 find it's WAN interface down, it should get default route from R2 and should be able to route R4's traffic in that direction.
Let me show you same behaviour using CLI :
Here is a quick topology of his network design:
At high level the design looks pretty simple. R1 & R2 are peering with WAN cloud using E-BGP. Between R1-R2-R3-R4-R5 we are running OSPF Area 0. To ensure R3-R4-R5 have reachability to external prefixes (Since it's always good to avoid BGP to IGP Redistribution), R1 & R2 are injecting default route into the network using "default-information originate always metric-type 1" option.
Also R1 & R2 are connected to each other over a link running OSPF.
Now let's talk about problem...which is the fun part :)
If R1's WAN connection goes down, R4 can't reach any external prefixes using default route any longer. Whereas at the same time both R3 & R5 don't lose their connectivity to same external prefixes.
Now ideally once R1 find it's WAN interface down, it should get default route from R2 and should be able to route R4's traffic in that direction.
Let me show you same behaviour using CLI :
Before R1's WAN Link goes down
After R1's WAN Link goes down
No ICMP Packets Received Any Longer on R6
R1 is not installing default route from R2
See if you can figure out " WHY " behind this and offer different ways we can fix this design issue. Feel Free to post you solution, recommendation and findings under comments section. I'll update the post around next weekend with my findings and solutions to the design.
HTH...
Deepak Arora
Evil CCIE
Update
In SPF Debug
12 comments:
Default route not exchange between R1 and R2 because they both are using default-information originate command in OSPF, it's avoid the loop.
it's better if we are using IBGP between R1 AND R2.
like if WAN like goes down on router 1 then it take the default route from router 2 from IBGP and R2 already have default route from ISP.
Default route not exchage between when both are using default-information oringinate command under OSPF , because its a loop avoid feature.
it's better if R1 and R2 using IBGP between them .
like if wan link goes down on ROUTER 1 , it take the default route from router 2 and router 2 has already default route froM ISP by EBGP
Instead of using "always" with the default-info command you can use a route-map to match the wan interface prefix 16.0.0.0/24. If the wan interface goes down, then R1 will stop generating the default and install the one from R2.
My guess is that internally when you generate the default, the router is creating a blackhole to 0.0.0.0/0 which then prevents the router from installing another router's external default which would create a routing loop.
How about establish iBGP adjacency between R1 and R2 ? This session would carry info about default routing
Hi Deepak,
This is an interesting issue for sure :)
If we added a network statement of
network 0.0.0.0 0.0.0.0 area 0
into R1 and R2 OSPF process, would it have allowed R4 to then go through R2 when R1's wan connection went down?
Thanks,
Camitech
Hi Deepak,
This is an interesting issue for sure :)
If we added a network statement of
network 0.0.0.0 0.0.0.0 area 0
into R1 and R2 OSPF process, would it have allowed R4 to then go through R2 when R1's wan connection went down?
Thanks,
Camitech
Set up a bgp peering between both edge routers
Set up an ibgp peering between the 2 egde routers
Hi,
I believe this issue can be sorted out in couple of ways –
1 . If there is no limitation for running iBGP between the WAN edge, I will be going for the iBGP peering.
2. A metric value can be used along with the default-information originate command and R1 can have a lower metric value and R2 can have a higher metric value. If R1 loses its 0/0 router because of a WAN failure, then a default router will be installed at R1 with a higer metric value from R2.
Eg –
R1 - default-information originate always metric 5 metric-type 1
R2 - default-information originate always metric 15 metric-type 1
Thanks
Rajesh
Hi Deepak,
Would appreciate if you could explain why redistribution from BGP to IGP should be avoided?
Thanks.
Hi Deepak,
my solution would be to setup a static route which tracks an IP SLA probe on R1 and R2, and then redistribute static route into the OSPF process.
The IP SLA probe would ping the remote end of its WAN link to confirm the up status. If the ping fails the track object goes down and the static route is stripped from the RIB and not distributed by OSPF. OSPF will pick up the other static route and traffic will continue to be routed.
We can even improve upon this by using a different IP SLA probe to determine link quality and drop the default route if jitter / delay or packet loss falls below the threshold.
My guess is same as Brian.
'Always' makes R1 originate default route independent of whether or nor it has a default route in the RIB or it has any connectivity to the given eBGP peer. Making it dependent on some external factor - like IP connectivity with the eBGP peer - would mean as soon as it loses eBGP peering, it will remove default route. Then it can accept External from R2 and will not blackhole traffic from R4 destined to 6.6.6.6
Post a Comment