04-01-2010 08:45 AM - edited 03-04-2019 08:00 AM
How can I best configure this network to be reliable and recoverable?
This is a simplified view of what I have in place. At the central HQ site I have a primary T3 to my MPLS cloud with AS 1. I have another backup router on the same ethernet subnet with a T1 to the same MPLS cloud with AS 10. At the Main HQ site I redistribute EIGRP and BGP pretty much completely. This is probably a bad idea. At the backup router I have no redistribution between EIGRP and BGP. I had lots of loops when I redistributed the backup sites EIGRP and BGP. My BGP skills are pretty new and I lack real-world experience. Oddly enough I've tried to setup a GNS3 environment and it fails to function on XP and Win7 for me.
To add to it, I have VPN/GRE tunnels coming in to the backup router in case the main MPLS or router fails. The GRE tunnels run EIGRP currently. I think I should be able to have the backup router configured to do both but I can't seem to hit upon the right mix of options.
At present, I don't think it is very resilent or easily managed. I've been reading case studies and route map examples for the last week or so but it all starts to make my head hurt.
What are some directions I should investigate? I can post router snippets if it is helpful though they are pretty ugly right now with futile attempts to make them work.
Thanks for any help you might offer.
04-01-2010 09:55 AM
Can you change your Backup router to AS # 1 and iBGP with your main router?
With an iBGP configuraton, you can use 'local-pref' to influence traffic leaving AS #1
towards the MPLS.
On the backup router connection, you can 'AS_prepend' the HQ routes towards the MPLS cloud.
Do you redistribute from EIGRP to BGP or from BGP to EIGRP without a route-map?
You must a create a route-map that matches the HQ EIGRP routes while being brought into
BGP. This would avoid potential loops on routes brought by the other ASBR router.
You should do the same on the BGP to EIGRP process. Bring routes that belong to the remote
offices into EIGRP, not all BGP routes.
As far as the GRE tunnel, the HQ router will have EIGRP end-to-end based on the diagram
and this connection will be preferred.
I don't see in the diagram a connection to the primary router from site 2.
Site 2 connected to the MPLS Cloud as well?
Regards
Edison
______
Each time you rate a CSC discussion we'll donate $1 to the American Red Cross Haiti fund up to a maximum donation of $10,000 USD.
04-01-2010 11:07 AM
The backup link has a separate AS number as determined by the provider. Had I known more, I would have exerted a little more force in making things differently. It may take a while but I may be able to get it changed. I'm also tempted to put another router in that only does EIGRP for the VPN/GRE tunnels to get that out of the mix even though I think it is possible in a single router.
When you say match the HQ EIGRP, do you mean line for line? For instance, the 10.18.0.0/16 is actually quite a few /24 and /23 VLANs visible to both HQ main and HQ backup that I've lumped together rather than having to key up the dozens of individual entries.
Site 2 currently is VPN/GRE only but Site 1 and Site 3 will have VPN/GRE tunnels for backup if I ever get this cleaned up.
I had some prepending on at one time but it didn't seem to work as I intended. I've also tried some prefix lists and route maps and I'm afraid I'm just kludging it up with stuff I don't understand fully to try to get something to work. My worst fear is I make it unstable and unreliable.
Here's how it looked when I thought I was close to achieving the desired goal but still had issues with the GRE sites not being able to reach the MPLS only sites. This is the HQ backup router, the HQ main router look similar with the transposing of AS numbers.
router eigrp 1
redistribute bgp 10 route-map to-EIGRP
passive-interface Serial0/0/0:1
network 10.0.0.0
no auto-summary
!
router bgp 10
no synchronization
bgp log-neighbor-changes
network 10.0.0.0
aggregate-address 10.18.0.0 255.255.0.0 summary-only
redistribute eigrp 1 route-map from-EIGRP
neighbor 10.26.10.46 remote-as 100
neighbor 10.26.10.46 prefix-list from-BGP in
neighbor 10.26.10.46 prefix-list to-BGP out
neighbor 10.26.10.46 route-map set-as-path out
neighbor 10.26.10.46 filter-list 1 in
no auto-summary
!
ip as-path access-list 1 deny _1$
ip as-path access-list 1 permit .*
!
ip prefix-list from-BGP seq 10 deny 10.10.0.0/13 le 32
ip prefix-list from-BGP seq 20 deny 10.18.0.0/16 le 32
ip prefix-list from-BGP seq 30 deny 10.55.255.0/24 le 32
ip prefix-list from-BGP seq 40 deny 10.26.254.0/24 le 32
ip prefix-list from-BGP seq 50 deny 10.26.255.0/24 le 32
ip prefix-list from-BGP seq 999 permit 0.0.0.0/0 le 32
!
ip prefix-list to-BGP seq 10 permit 10.10.0.0/13 le 32
ip prefix-list to-BGP seq 20 permit 10.18.0.0/16 le 32
ip prefix-list to-BGP seq 30 permit 10.55.255.0/24 le 32
ip prefix-list to-BGP seq 40 permit 10.26.254.0/24 le 32
ip prefix-list to-BGP seq 50 permit 10.26.255.0/24 le 32
ip prefix-list to-BGP seq 999 deny 0.0.0.0/0 le 32
!
access-list 1 permit any
!
route-map from-EIGRP permit 10
match ip address prefix-list to-BGP
!
route-map set-as-path permit 10
match ip address 1
set as-path prepend 65511
!
route-map to-EIGRP permit 10
match ip address prefix-list from-BGP
!
04-01-2010 11:31 AM
If you are unable to change the AS number on the backup router, you can eBGP between the backup and primary router.
On the backup router, you can use local-pref for routes coming from the primary router so this can be preferred over the MPLS incoming routes.
On the same backup router, you can 'as_prepend' routes announced to the MPLS so the primary router has the best routes from your HQ environment within the MPLS cloud.
You don't have to match the routes line by line. If you are able to match on an aggregate of all routes, the redistribution with a route-map will be easier to manage.
Are the remote locations part of a major subnet that also belongs to the HQ?
In your case, 10.18.0.0/16 is also part of the remote location subnet?
You mentioned you are afraid of dealing with changes you don't understand. I understand your concerns, have you considered hiring a consulting firm to do this design for you?
04-01-2010 02:06 PM
The prefix list in my previous post is all at HQ. That was my attempt to keep the routes from coming in BGP and looping back out in EIGRP between the two HQ routers. The subnets out in the world do not share any common subnet with anything at HQ, such that 10.18.0.0/16 is only known via EIGRP to the local routers.
Another problem I have is even though I'm a sending out an aggregate of 10.18.0.0/16, my VPN/GRE tunnels are learning all the smaller subnets via EIGRP and populating them back out to the BGP if I allow them both up at the same time. Is there a good way to summarize the EIGRP routes like I can with the BGP?
As for help, I have asked for some help and we even received statements of work and quotes a few years back but they would never pull the trigger on it. I've recently asked for help again and have gotten no where. I guess the powers that be have undue faith in my ability to muddle through. Frankly, I'm tired of learning the hard way after I've taken down the network and my phone won't stop ringing. I think I have a Phd in dialing 1 800 553 2447 for TAC.
04-02-2010 05:10 AM
Yes, your as-prepending looks ok but that's 50% of the requirement.
While your as-prepending will influence traffic from the MPLS to your location, it will not influence traffic from your location to the MPLS.
At the moment, your backup router will only receive BGP routes from the MPLS.
We need to introduce BGP routes from your primary router and make those routes preferred so any traffic entering the backup router will use your primary router as the exit point towards the MPLS network.
That's the reason I'm suggesting to create an eBGP between them and use the local-pref to influence traffic towards the primary router instead of the MPLS.
Regards
Edison
04-05-2010 03:43 PM
I'm setting up a test scenario to see if I can work out the specifics of your suggestions. I finally got GNS3 to run on a machine.
I'm also toying with the idea of ONLY using BGP to connect routers to the cloud and using an mGRE/NHRP tunnel to run EIGRP on top of the MPLS cloud.
I see this as having several benefits. One, it gets me out of redistributing, prefixing and filtering routes between EIGRP and BGP and vice versa. Two, it reduces the complexity (to me) of the configurations. Third, it makes my IPSEC/GRE VPN recovery less prone to problems since I run EIGRP on the backup tunnels.
The down side is my traffic is tunneled and that has to add some overhead plus slightly smaller packets.
Am I crazy to consider that as an alternative? My other alternate idea was to run BGP on the IPSEC/GRE VPN tunnels but I don't know if that is a good solution or not.
Thanks for your help so far, it has been very informative.
05-02-2017 08:52 AM
what if the MPLS networks are different providers and run eBGP between your two mpls routers, you run into the issue of being a transit network. So how would you approach that situation?
05-02-2017 09:36 AM
You don't advertise one MPLS network to the other. Then neither should send you transit traffic.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide