Multiple Redistributions - BGP, OSPF, Static - Design Validation

dmarekatc · ‎02-02-2016

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

Philip D'Ath · ‎02-03-2016

My head hurts.

I think if it was me I would ditch BGP and the provider routing. I would treat them as a transit provider. I would make HE1 and HE2 DMVPN head ends (you don't need to use encryption).

I would then run OSPF over the multipoint GRE tunnels between all routers. Now you are back to one main routing protocol, and life is much easier.

If it was me, I would ditch OSPF and use EIGRP, because I'm not into sadistic pain. But that is just me, and you have said being sadistic is non-negotiable.

dmarekatc · ‎02-03-2016

Hello Philip,

LOL - I can appreciate your first comment... my head feels the same at times pondering & debating the various ways this could all be handled.

And I've certainly thought about using an overlay - though if I did, I'd kind of want to use the newer FlexVPN, to take advantage of things like IKEv2... only problem is that I haven't tried it yet, and I'm not certain my timeline would allow.

As for OSPF vs. EIGRP - I've considered that too... but (and dare I say this here) not everything may be Cisco, so having things open & universally supported is ideal.

Thanks for your comments.

Regards.

Philip D'Ath · ‎02-03-2016

We mostly used FlexVPN now, and it works great. However FlexVPN makes you assign a crypto policy, while DMVPN does not.

If you have everything with crytpo licences then FlexVPN stands out as a nice option.

The other nice thing about using the overlay is it will make it much easier doing routing maintenance or investigating faults.

dmarekatc · ‎02-03-2016

Good to know - thanks!

(We purchase the security feature set/license with everything so we should be good to go.)

I don't suppose you have a multi-hub and spoke environment, and would have sample configs portions for the FlexVPN for each? (each hub and a spoke/remote) Or know of some good resources that have examples.

Cheers!

Philip D'Ath · ‎02-03-2016

Actually we have several we look after. It is our first choice of deployment if the customer is running 15.2(4)M7 or better on all routers.

Here is a nice simple example:

http://www.cisco.com/c/en/us/support/docs/security/flexvpn/116412-configure-flexvpn-00.html

Giuseppe Larosa · ‎02-03-2016

Hello Marek,

a) about default route

in Cisco routers you cannot redistribute a default static route into an OSPF domain, you have to use the

default-information originate

command in OSPF router mode.

The command accepts as a parameter a route-map where you can check the existance of a static default route. But in your case you don't need it.

You can also play with the hierarchy of OSPF external routes types because:

O > O IA > O E1 > O E2

regardless of metric.

your area 2 is totally NSSA allowing for redistribution using LSA type 7.

However, still O N1 is preferred over O N2 regardless of the metric value.

I don't understand what is a.a.a.a the IP next-hop of static route for 10/8 RFC 1918 private address.

b) multiple mutual redistribution points = Danger you need filters or route tags

In a case like yours you can use an aggregate address on BGP to advertise only the 10/8 via BGP and you can avoid mutual redistribution between OSPF and BGP that is dangerouos.

The network is quite complex and multiple points of mutual redistribution should be used only when really needed.

If you really want to go on with mutual redistribution between OSPF and BGP in different points of your network I recommend you to use route tags in order to mark what comes from OSPF into BGP, what comes from BGP into OSPF and so on.

You will need route-maps based on matching route tags values in order to build a robust solution.

For example you can tag with route tags ospf.learned with route tag 100.

A route tag is an unsigned integer 32 bit value number for most protocols.

route-map OSPF-to-BGP deny 10

match tag 65000

route-map OSPF-to-BGP permit 20

set tag 100

set metric 115

route-map BGP-into-OSPF deny 10

match tag 100

route-map BGP-into-OSPF permit 20

set tag 65000

set metric 1000

The logic is to avoid to have prefixes to go into BGP and then back in OSPF somewhere in the network.And viceversa a route coming from BGP with tag 65000 should not be accepted by BGP when redistributing into BGP.

Hope to help

Giuseppe

dmarekatc · ‎02-03-2016

Hello Giuseppe,

Thanks for taking the time to reply and all the information - much appreciated.

So at the Remote sites/routers, the default originate would handle things (or if I used a 10.0.0.0/8 static, I'd have similar acceptable results) - and I like that approach.

To clarify regarding the a.a.a.a & z.z.z.z those would just be other routers at the Head-Ends that didn't really play a role in any of this so I didn't put ip addresses on them. Just like R5's x.x.x.x - that peer address doesn't matter per se, just needs to have one.

Regarding the route tags - I seem to encounter an error with a set tag & redistributing OSPF into BGP (% "<route-map name" used as redistribute ospf into bgp route-map, set tag not supported ), and I need to use a community instead. Have you encountered this?

I guess I'm also still a little confused on the need for the maps - Obviously I see the potential for a loop in the design, but since higher metrics are being used in both R5 & HE1/HE2, shouldn't that keep them from even getting into the routing tables?

From what Jon put in his reply, I'm hoping he can show & explain how the mutual redistribution can be avoided.

Thanks for your help.

Cheers,

-Marek

Giuseppe Larosa · ‎02-04-2016

Hello Marek,

the best approach is to avoid mutual redistribution as Jon has noted.

About creating an aggregate address in BGP this means simply using the command aggregate-address in BGP with the option summary-only to avoid to advertise component routes.

router bgp 65000

aggregate-address 10.0.0.0 255.0.0.0 summary-only

This makes the head end to send out only the aggregate 10/8 and to be used only in case of need. You eliminate in this way the need to redistribute OSPF into BGP.

>> Regarding the route tags - I seem to encounter an error with a set tag & redistributing OSPF into BGP (% "<route-map name" used as redistribute ospf into bgp route-map, set tag not supported ), and I need to use a community instead. Have you encountered this?

You are right I remember the use of route tags in case of mutual redistribution between multiple OSPF processes or between OSPF and EIGRP.

I had a case many years ago of mutual redistribution between EIGRP and BGP and probably we ended to use the BGP community as you have noted.

I apologize for the mistake.

>> I guess I'm also still a little confused on the need for the maps - Obviously I see the potential for a loop in the design, but since higher metrics are being used in both R5 & HE1/HE2, shouldn't that keep them from even getting into the routing tables?

No, the higher metric is not a protection from unwanted re-injection of routes in cases of multiple points of mutual redistribution. I cannot easily describe a scenario that illustrates this, but generally books about routing at CCNP level or above have these examples.

The BGP community can be used in the same way as a route tag to classify routes coming from OSPF and to avoid to inject them again in the OSPF domain in another point of mutual redistribution.

In any case consider carefully the use of aggregate-address in BGP instead of mutual redistribution as this carries a lot of complexity and difficulty in case of troubleshooting the network.

Hope to help

Giuseppe

dmarekatc · ‎02-08-2016

Thanks Giuseppe (and all others) for your help and input.

I think I have a good direction to go from here.

Cheers!,

-Marek

Jon Marshall · ‎02-03-2016

You do not need to worry about the metric of the default route.

The HE devices will be injecting a default route of type 3 LSA into each area.

As Giuseppe says you need to use the default-information originate command on R5, for example, and this will inject a default route of type N2 by default.

So your default pointing to the HE devices will always be preferred unless you lose the link.

Giuseppe also makes a good point about advertising out an aggregate address with BGP from the HE devices because any more specific routes will be advertised by each site.

And that would mean no mutual redistribution anywhere.

Jon

dmarekatc · ‎02-03-2016

Hello Jon,

Good to hear from you again - Since our previous discussion got rather lengthy, I opted to focus on this area to ask for input & ideas, and appreciate your comments as always.

Good point on what will be favored due to LSA type - makes things simple there. When I was describing using a static, I had contemplated using a 10.0.0.0/8 instead of a default but a default/default originate seems the easier way to go.

Could you provide a config sample of what you're describing with the aggregate address? And being that there are multiple occurrences of the situation depicted, I trust that this shouldn't cause issue / would still apply?

Cheers,

-Marek

Jon Marshall · ‎02-03-2016

Hi Marek

The suggestion of an aggregate address is pretty much the same as Milan's default route from the HE devices ie. you simply catch any traffic for which there is not a more specific route.

The issue with it is that traffic could go to either HE device and if I remember your last diagram there are sites that are only connected to one HE device for example.

This would mean traffic could come in for that site to either HE device and if it was the wrong one it would have to go across the HE links.

It really depends on how specific you want to be in terms of traffic paths and if you also want to account for a failure of all links between the HE devices or not.

Jon