dynamic failover for certain networks

cdobler95842 · ‎08-04-2011

Network:

Core_RTR-(2)- 172.16.2.x-(1)----C65K---(254)--172.16.1.X--(253)--WAN RTR#1-(5)--192.168.3.0-(6)-{AS 65001}---MPLS#1-{AS 4182}--(AS65001)--Stub Sites
| EIGRP EIGRP/BGP BGP

172.16.253.2/30
| EIGRP

MPLS #2 <-------This cloud is injecting 4 prefixs into EIGRP*****
| EIGRP

172.16..253.10/30

|
| EIGRP/BGP BGP
WAN_RTR#2---192.168.7.8------{AS 65002}-(5)----------------------------------------MPLS#1-{AS 4182}---------------------------(AS65001)--Stub Sites(same as above)

***The goal is to enable dynamic failover for the following networks if the connection from MPLS#2 fails on Core_RTR to transverse via WAN_RTR#2

Network 10.4.32.0/24

Network 10.1.128.0/24

Network 192.168.50.0/24

WAN_RTR1 and WAN_RTR2 are connected to the same ISP and provide connectivity to the stub sites incase of failure. The prefixes from MPLS#2 need to be redundant via either WAN_RTR#1 or WAN_RTR#2

As these networks need to be reachable from the stub sites if the connection from MPLS#2 is lost on the Core_RTR. The question is do I redistribute these prefixes from EIGRP {which they currently are as we are receiving them MPLS#2 as type EX with a AD 170} into BGP or do I originate them via the network command in BGP and pre-pend the paths from each AS?

Any suggestions?

Thanks

Jon Marshall · ‎08-04-2011

Christian

Any chance of a jpg showing the network layout. The above is somewhat difficult to read

Jon

cdobler95842 · ‎08-04-2011

Jon Marshall · ‎08-04-2011

Thanks for the jpg.

Just to clarify, where exactly are these networks that you want redundancy for ?

What is the preferred path from the stub sites to these networks fail ?

And if the preferred path fails what path do you want them to take ?

Jon

cdobler95842 · ‎08-04-2011

John,

Thank you for your assistance...

where exactly are these networks that you want redundancy for ?

These networks are accessed by the stub sites and core for certain applications provided through aother serivce provider. They are not controlled by me specifically as they are injected into my EIGRP by the service provider for accessing the applications and tools.

What is the preferred path from the stub sites to these networks fail ?

The preferred path when all is status quo is to route through WAN RTR #1 for these specific networks and thus would trasnferse from the WAN_RTR #1 through the core to the MPLS #2

And if the preferred path fails what path do you want them to take ?

If the preferred path fails from the core to the MPLS#2 then have them take the path through WAN_RTR#2 to the MPLS#2 cloud.

I hope it is explained clearly. looking to provide a dynamic failover for these specific prefixes if a failure for MPLS#2 fails so that the applications can be reached.

cdobler95842 · ‎08-04-2011

Thee networks are injected via redistribution into EIGRP through the service provider in the MPLS #2 cloud.

Network 10.4.32.0/24

Network 10.1.128.0/24

Network 192.168.50.0/24

The Core and WAN_RTR#2 receive them from their EIGRP neighbor from the MPLS#2 cloud as type EX AD 170 -

Jon Marshall · ‎08-04-2011

Christian

No problem with the help

Thanks for above, that clarifies the path. Just a few more questions -

1) So where are these networks injected by the SP ? is it via the core router ? It's important to know to work out what happens when the link fails between WAN-RTR2 and the core router. If this link does fail would the EIGRP routes disappear ?

Because if they do disappear then how you would advertise them via WAN-RTR2 ?

2) i'm assuming you are not redistributing these networks into BGP on WAN-RTR2 or else the remote sites would be going straight via WAN-RTR2 ?

3) on WAN-RTR1 are you redisributing the EIGRP routes into BGP or do you have network statements ?

Apologies for all the questions but need to clarify before suggesting a solution.

Jon

cdobler95842 · ‎08-04-2011

1) So where are these networks injected by the SP ? is it via the core router ? It's important to know to work out what happens when the link fails between WAN-RTR2 and the core router. If this link does fail would the EIGRP routes disappear ?

So to clarify their is a cloud/SP between CORE-RTR and WAN_RTR#2 -Between the Core and the WAN_Router#2 -

The service provider for MPLS#2 is injecting the routes into EIGRP.

Because if they do disappear then how you would advertise them via WAN-RTR2 ?

I am hopeful that they would not disappear from both sides at the same time.The idea is to have the routes available via BGP through WAN-RTR1 and WAN-RTR2, with the path through WAN-RTR1 preferred. If their is a failure between the CORE-RTR and MPLS#2 Cloud, then have the preferred path be routed through WAN-RTR2 to MPLS#2.

The question is how do I advertise these to MPLS#1 so that when core-RTR loses the EIGRP route that it causes WAN_RTR#1 to re-direct these prefixes or route these through to WAN-RTR2

2) i'm assuming you are not redistributing these networks into BGP on WAN-RTR2 or else the remote sites would be going straight via WAN-RTR2 ?

This is what I am trying to determine as the best case solution on how to advertise these prefixes from WAN-RTR1 and WAN-RTR2. There has been modifcation to the configuration prior to my engagement and I have a window to make changes to correct and modify the previous tweaks.

3) on WAN-RTR1 are you redisributing the EIGRP routes into BGP or do you have network statements ?

This is part of my question as how and when should I redistribute and/or use the network states? And in using the network statements, then I rely on EIGRP to remove those routes from the routing table and push to WAN-RTR2?

If I use the network statements, would I run into a convergance issue between EIGRP and BGP? As both WAN-RTR1 and WAN-RTR2 would be receiving a EIGRP EX Route with a AD of 170, if BGP Originates it then it would be placed at AD 20 - right?

Apologies for all the questions but need to clarify before suggesting a solution.

Ask away as it helps me clarify as well. I

Jon Marshall · ‎08-04-2011

Christian

It's starting to make more sense now thanks.

You can use network statements on both WAN-RTR1 and RTR2 or you can redistribute EIGRP into BGP. If you are redistributing EIGRP into BGP on RTR1 and RTR2 for the remote sites it may be better to simply use network statements as we are only talking about 4 subnets.

AS path prepending would be an easy solution to this. What should then happen is -

1) if the link between MPLS2 and core 2 goes down then WAN-RTR1 will no longer receive the EIGRP routes. Once it stops receiving the routes then BGP will stop advertising the routes to the remote sites because for a network to be advertised it must be found in the IGP routing table.

2) So the remote sites stop receiving the BGP routes from RTR1 but RTR2 should still be receiving the EIGRP routes and so will still be advertising the routes to the remote sites.

This is about the simplest setup i can think of.

Alternatively you can redistribute EIGRP into BGP at both RTR1 and RTR2 and play with the metrics but the above does seem the easiest approach.

Thoughts ?

Jon

Jon Marshall · ‎08-04-2011

Christian

A quick followup. You have the same AS on RTR1/RTR2 and the remote sites. I'm not sure what your existing BGP config is but you may well be using the "bgp neighbor x.x.x.x allowas-in 1" config command to allow routes with the same AS to be accepted.

If you are using prepending obviously you will need to increase the number in the allowas-in to allow for the number of times you enter the same AS in the AS PATH.

If you aren't happy doing this the alternative is to redistribute EIGRP into BGP on RTR1/RTR2 and then on the remote site routers you could use the BGP weight attribute to prefer RTR1 over RTR2 routes.

Jon

cdobler95842 · ‎08-04-2011

Jon

RTR1 AS 65001

Remote Locations AS 65001

RTR2 AS65002

======================

I assume that I should redistribute the EIGRP into BGP and use the Network command for the following prefixes that I wish to use for the "failover"

With the weight it can only be set on inbound and not outbound? What would that look like in the config?

Jon Marshall · ‎08-04-2011

Christian

If RTR2 is not using the same AS then you could simply add multiple instances of the same AS PATH.

If you use the network command you are not redistributing EIGRP into BGP. It is one or the other. Using the network command gives you strict control over what is advertised whereas if you redistribute EIGRP into BGP it will redistribute all EIGRP routes (unless you filter it) so you may end with the sites getting a lot more routes than they need.

The same goes for weight and AS path prepending, it is one or the other. I am simply giving you some options in case you try to implement one solution and there are problems as you are working within a window.

AS path prepending would be done on RTR2 only. Using weight you would need to do it on each site router. With weight the higher value wins and by default the weight will be 0 for BGP received routes.

So your config on a remote site router would be -

router bgp 65100

neighbor 0>

Jon

ranjit123 · ‎08-05-2011

Hi,

Can we advertise more specific prefixes from the primary path and summary from the secondary if possible

Happy to help

Ranjit.

cdobler95842 · ‎08-05-2011

I reviewed the configurations of this implementation and it appears that the end user has tried some modifications.

I do not think this is correct and going to modify it and want your input on this before I modify.

Here is the RTR2 config and routing table

router eigrp 100

redistribute bgp 65002 metric 5120 20 255 1 1500

network 172.16.253.8 0.0.0.3

no auto-summary

!

router bgp 65002

no synchronization

bgp router-id 12.4.47.8

bgp default local-preference 90

bgp cluster-id 3232235777

bgp log-neighbor-changes

network 10.4.32.0 mask 255.255.254.0

network 172.16.253.8 mask 255.255.255.252

network 172.16.255.0 mask 255.255.255.0

network 192.168.255.0

neighbor 12.4.47.7 remote-as 4182

neighbor 12.4.47.7 timers 60 180

neighbor 12.4.47.7 soft-reconfiguration inbound

neighbor 12.4.47.7 route-map prepend out

no auto-summary

!

ip forward-protocol nd

ip route 0.0.0.0 0.0.0.0 172.16.253.9

ip route 10.2.4.0 255.255.255.0 172.16.253.9

ip route 10.5.2.0 255.255.255.0 172.16.253.9

ip route 172.40.255.0 255.255.255.0 172.16.253.9

!

no ip http server

no ip http secure-server

!

access-list 5 permit 10.15.128.0 0.0.0.255

!

route-map mpls2-tompls1 permit 10

match ip address 5

!

route-map prepend permit 10

set as-path prepend 65002 65002 65002

!

===========

WAN_Router2#show ip bgp 10.4.32.0 255.255.254.0 longer-prefixes
BGP table version is 289, local router ID is 12.4.47.8
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
* 10.204.32.0/23   12.4.47.7                           0 7018 65001 i
*>                  172.16.253.9       1671936         32768

WAN_Router#show ip bgp 10.5.128.0 255.255.255.0 longer-prefixes
BGP table version is 289, local router ID is 12.4.47.8
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 10.5.128.0/24   12.4.47.7                           0 7018 65001 ?
*> 10.5.128.10/32 12.4.47.7                           0 7018 65001 ?