Hello,
I’m hoping I might get some validation on a network design that involves multiple redistributions and interconnections (for redundancy). Attached is a mock-up environment to help depict things. Essentially I’m looking for input on if you would think there’d be a problem with the redistributions or design in general, of if it could be a clever way to avoid potential problems with mutual / bi-directional redistribution.
Facts / Assumptions (Treat as Unchangeable):
-
OSPF is to be favored over BGP, hence the administrative distance is being set to 115 for BGP.
-
OSPF Areas are Totally NSSA.
-
The Provider MPLS circuits using BGP (at R3 & R5) are for redundancy purposes only.
-
While a small daisy-chain of routers is depicted here, there could be up to 20 routers involved with a total of 200-300 network routes.
General Design Concept:
The OSPF connections will be utilized under normal circumstances, and Area 2 is Totally NSSA to reduce the routing tables – As a result, a default route is pushed out, along with some other static routes via static redistribution into OSPF. The Provider-based MPLS circuits (running BGP) need to make available to the Head-Ends all the remote networks in the event of a device/link failure, hence the redistribution of OSPF into BGP at the Remote routers and redistribution of BGP into OSPF at the Head-End routers. Because a device/link failure would remove the default OSPF route being generated from the Head-End(s), redistribution of a static route on the Remote routers with MPLS/BGP connections into OSPF would seem necessary to let other remote sites know how to get back to the Head-Ends. In all these cases, a higher metric is used to prevent a loop and ensure that these alternate routes only get put into the routing tables for use when there is no other path available, and once the failed device/link is restored they would cease and OSPF routes would again take over.
Example Situation:
Per the attached diagram, use the scenario that the link between R1 & R2 goes down. R1’s local traffic would be unaffected by this and get back to HE1 via OSPF. R2 would now need to know how to get back to the Head-Ends, via R3 – This is where the redistribution of a static in OSPF on R3 comes in; and the Head-Ends need to know how to get to R2 – which is where the OSPF into BGP at R3 comes in, along with BGP into OSPF on HE1 & HE2. R3 and R5 would similarly have their traffic/networks able to be known and get to/back, and R4 would be able to use either R3 or R5 depending on what OSPF says is more favorable.
Does that sound about right?
Possible issues with this? Am I missing anything? Is there a simpler way to address this that is stable? (I’m hoping to avoid hundreds of network statements in BGP and mutual redistribution between BGP & OSPF on any single router.)
So you don't have to stare at the small config snippets in the diagram, here is the sample config for R5 and HE1.
R5 routing config: (R3 would be similar)
router ospf 100
area 2 nssa
network 10.0.0.0 0.255.255.255 area 2
redistribute static metric 2000 subnets
!
router bgp 65005
bgp log-neighbor-changes
redistribute connected metric 115
no synchronization
no auto-summary
distance 115 0.0.0.0 255.255.255.255
neighbor x.x.x.x remote-as 12345
neighbor x.x.x.x soft-reconfiguration inbound
redistribute ospf 100 metric 1115 match internal external 1 external 2
!
ip route 0.0.0.0 0.0.0.0 x.x.x.x
HE1 routing config: (HE2 would be similar)
router ospf 100
area 2 nssa no-redistribution no-summary
network 10.1.1.2 0.0.0.0 area 0
network 10.2.2.2 0.0.0.0 area 2
redistribute bgp 65001 metric 1150 subnets
redistribute static metric 200 subnets
!
router bgp 65001
bgp log-neighbor-changes
redistribute static metric 1150
no synchronization
no auto-summary
distance 115 0.0.0.0 255.255.255.255
neighbor y.y.y.y remote-as 12345
neighbor y.y.y.y default-originate
neighbor y.y.y.y soft-reconfiguration inbound
!
ip route 0.0.0.0 0.0.0.0 z.z.z.z
ip route 10.0.0.0 255.0.0.0 a.a.a.a
I appreciate any feedback.
Thank you,
-Marek
