EIGRP internal routes to WAN MPLS/BGP router

Amafsha1 · ‎05-07-2018

Hello, with the help of great people here at the community forums I've gotten farther with our MPLS router failover project to connect all our branches.

In this project, I am trying to get a second router to connect to the same ISP AS# to provide redundancy to all our branches in case the first circuit or Router goes down. All branches have to come to the main hub (here main office) via MPLS to use the internet, we use this MPLS circuit only for connecting our branches (internet router is somewhere else). But aside from that, my question is a little different and is regards to getting the internal EIGRP routes to choose which Router to use when exiting our network to go out the MPLS circuit(s). The 2 files attached show the story. 1 is the current design of how we are now; the other is what we would like for the future design. I'm not worried about the inbound/outbound BGP configs because those are happening by someone else, but I did need to work on the configs for how the internal routes in the network choose whether they want to use Router 1 or Router 2. From my understanding, we need to tweak the EIGRP metrics in the Route-map that specifies all routes that are being redistrbiuted from BGP to EIGRP. As you can see in the configs I've posted below that everything from EIGRP is allowed to BGP and everything from BGP is allowed to EIGRP. I've tweaked the reliability on the CE2 router because I would like that to be the backup router in case CE1 fails. Does this config look correct? I've bolded the changes.

If anyone suggests any other changes or sees anything else wrong, please, I am all ears :)

Thank you in advance

-----------------------------------------------------------------------------------
hostname CE1
!
!
!
interface Loopback0
ip address 10.0.0.1 255.255.255.255
!
!
interface GigabitEthernet0/0/1
description // MPLS to ISP
ip address 63.63.140.154 255.255.255.252
no negotiation auto
!
interface GigabitEthernet0/0/2
description to Core1
ip address 172.31.255.1 255.255.255.252
negotiation auto
!
interface GigabitEthernet0/0/3
description to Core2
ip address 172.31.255.5 255.255.255.252
negotiation auto
!
!
router eigrp 200
network 172.31.255.0 0.0.0.3
network 172.31.255.4 0.0.0.3
redistribute bgp 65000 route-map bgp-to-eigrp
!
router bgp 65000
bgp log-neighbor-changes
neighbor 63.63.140.153 remote-as 200
neighbor 10.0.0.2 remote-as 65000
neighbor 10.0.0.2 update-source Loopback0
neighbor 10.0.0.2 soft-reconfiguration inbound
!
address-family ipv4
redistribute connected
redistribute static
redistribute eigrp 1 route-map eigrp-to-bgp
neighbor 63.63.140.153 activate
neighbor 63.63.140.153 soft-reconfiguration inbound
default-information originate
exit-address-family
!
ip route 0.0.0.0 0.0.0.0 172.31.255.2 name to Core1
ip route 0.0.0.0 0.0.0.0 172.31.255.6 name to Core2
!
!
ip prefix-list bgp-to-eigrp seq 100 permit 0.0.0.0/0 le 32
!
!
ip prefix-list eigrp-to-bgp seq 100 permit 0.0.0.0/0
ip prefix-list eigrp-to-bgp seq 320 permit 0.0.0.0/0 le 32
!
!
!
route-map bgp-to-eigrp permit 100
match ip address prefix-list bgp-to-eigrp
set metric 100 1 255 1 1500
!
route-map eigrp-to-bgp permit 100
match ip address prefix-list eigrp-to-bgp
!

--------------------------------------------------------------------------------
hostname CE2
!
!
!
!
interface Loopback0
ip address 10.0.0.2 255.255.255.255
!
!
interface GigabitEthernet0/0/1
description // MPLS to ISP
ip address 64.64.140.154 255.255.255.252
no negotiation auto
!
interface GigabitEthernet0/0/2
description to Core1
ip address 172.31.255.10 255.255.255.252
negotiation auto
!
interface GigabitEthernet0/0/3
description to Core2
ip address 172.31.255.14 255.255.255.252
negotiation auto
!
!
router eigrp 200
network 172.31.255.9 0.0.0.3
network 172.31.255.13 0.0.0.3
redistribute bgp 6500 route-map bgp-to-eigrp
!
router bgp 65000
bgp log-neighbor-changes
neighbor 64.64.140.153 remote-as 200
neighbor 10.0.0.1 remote-as 65000
neighbor 10.0.0.1 update-source Loopback0
neighbor 10.0.0.1 soft-reconfiguration inbound
!
address-family ipv4
redistribute connected
redistribute static
redistribute eigrp 1 route-map eigrp-to-bgp
neighbor 64.64.140.153 activate
neighbor 64.64.140.153 soft-reconfiguration inbound
default-information originate
exit-address-family
!
ip route 0.0.0.0 0.0.0.0 172.31.255.9 name to Core1
ip route 0.0.0.0 0.0.0.0 172.31.255.13 name to Core2
!
!
ip prefix-list bgp-to-eigrp seq 100 permit 0.0.0.0/0 le 32
!
!
ip prefix-list eigrp-to-bgp seq 100 permit 0.0.0.0/0
ip prefix-list eigrp-to-bgp seq 320 permit 0.0.0.0/0 le 32
!
!
!
route-map bgp-to-eigrp permit 100
match ip address prefix-list bgp-to-eigrp
set metric 100 1 155 1 1500
!
route-map eigrp-to-bgp permit 100
match ip address prefix-list eigrp-to-bgp
!

Georg Pauwen · ‎05-07-2018

Hello,

looking at your topology, influencing EIGRP metric is tedious at the very least. You have redundant links, and even with offset lists, delay metrics or administrative distance tweaking, there is always the risk of introducing a routing loop. Why not use HSRP or iBGP with AS prepend load sharing ? Have a look at the link below (scroll down to topology 5, which resembles your setup)...

http://showipbgp.com/bgp-configurations/cisco.html

Amafsha1 · ‎05-07-2018

we can't use path-prepend because we are sending communities to our ISP with Local pref configured within them, and they have route-maps that automatically adjust to that and that takes care of the inbound/outbound BGP, I'm talking about getting my internal routes to choose our CE1 Router over our CE2 Router. If you look at the configs, I will have iBGP configured between CE1 and CE2; the sending of communities with local pref won't work if I don't have iBGP configured on the 2 CE routers. I don't think we have to worry about loops, because all the interfaces from the core to the CE1 and CE2 router are EIGRP.

Georg Pauwen · ‎05-08-2018

Hello,

set the delay on the links between Core 1 and CE2 and Core 2 and CE2 to 20, that way, all traffic will flow through CE1.

Core1

interface GigabitEthernet0/0

description Link to CE2

delay 20

Core2

interface GigabitEthernet0/0

description Link to CE2

delay 20

cofee · ‎05-08-2018

Hi,

What Georg is suggesting will work, you can simply decrease delay on the link that you want to be preferred route/link and that would take care of eigrp internal routes.

Keep in mind, if the eigrp metrics are not in sync for the internal eigrp routes with external routes (redistributed bgp routes into eigrp) then you will end up in a situation where you internal eigrp traffic is flowing over CE2, but external eigrp traffic is going through CE1.However, configuration you shared appears to be in sync.

I would also suggest to advertise the loopback interfaces, that you are using for iBGP peering, of CE1 and CE2 in eigrp because if the directly connected interface between CE1 and CE2 is down then it will affect the traffic flow and you will lose iBGP peering. Not sure if you are already doing that, but I didn't see loopback interfaces being advertised in eigrp and neither I saw static routes for loopbacks reachability, so can't tell which method you are using for iBGP peering. If you are using eigrp to advertise loopback addresses for iBGP peering then you can block them from being advertised to eBGP neighbors.

I also didn't see "next-hop-self" command between iBGP neighbors, may be you have removed it from the configuration that you posted for simplicity, but I just wanted to bring it up.

Amafsha1 · ‎05-08-2018

Thanks both of you. I was actually just replying to George. As far as the loopback, my drawing is misleading. I am not connecting iBGP via a direct connection between CE1 and CE2, I am connecting them via through the core routers. Do you think that's a bad idea? Also, about advertising loopback, if you look at my prefix-list and route-map, I am advertising everything from BGP-to-EIGRP and vice versa, so I don't think I need to worry about that.

Amafsha1 · ‎05-08-2018

oh ok, I see what you're saying. You're saying to advertise 10.0.0.0 under router eigrp 200.

cofee · ‎05-08-2018

Right, but preferably specific routes:

router eigrp xx

10.0.0.2 0.0.0.0

or

But if you want to avoid blocking loopbacks from being advertised to Ebgp neighbors then you can use static routes for loopback interfaces and still have redundancy by creating static routes for loopbacks on Core routers because I see you have default routes on CE1 and CE2 pointing to core routers.

Amafsha1 · ‎05-09-2018

I was finally able to get my hands on VIRL. boy this is a tough one to make work. What I did is not create an interface connection between CE1 and CE2 and just tried to use 1 of the eigrp links to the Cores to form the iBGP neighborship. I can get the iBGP neighborship to come up and I do that by advertising the loopbacks into eigrp on both CE1 and CE2 and I also put 2 static routes to CE1 from CE2 and vice versa. I make the static routes point to the interfaces of the 2 cores such as

ip route CE1 172.31.255.x

that way I have enough routes to get to and from the CE's to eachother. However, when the interface from CE1 to Core 1 dies, the iBGP neighborship goes down even though it has another route to CE 2 from Core 2, but does not display it with the "show ip route". I can ping from CE1 to CE2, but not the other way around. When debugging ICMP, it says something like "time exceed rcvd". I guess it maybe causes a loop or something since if CE2 wants to talk to CE1, it now cannot go to Core 1 anymore, but has to go to Core 2, then CE1. I would think the static routes on both the CE's to eachother and both the Cores to the CE's would do the trick...and I'm advertising them on EIGRP. I guess I have no choice but to create the interface and connect CE1 directly to CE2.

cofee · ‎05-10-2018

Yeah static routes would give you trouble because your CE routers have default routes pointing towards Core 1 and 2 and both core routers are pointing towards CE routers to reach loopback addresses, that would potentially cause a routing loop.

You can advertise loopbacks in eigrp and you should be fine, once a link (depending which link) between CE and Core routers go down, at worst there will be few ping drops, but iBGP peering won't be affected. I tested it in a lab with shutting down all links 1 at a time and iBGP peering was stable.

If you don't want to do this then your other option will be to run a cable between CE routers and use static routes for loopbacks, but in this case you lose redundancy unless your router has a switch module because then you can use more than 1 physical link and bundle it with etherchannel.

Amafsha1 · ‎05-11-2018

Ok, now I'm really curious how you got that to work. i did exactly that where I advertised

Wan1#

router eigrp 200

network 10.0.0.1 0.0.0.0 (loopback of Wan 1 router)

Wan2#

router eigrp 200

network 10.0.0.2 0.0.0.0 (loopback of Wan 2 router)

did the same on the other Wan 2 router. I could get the neighborship to come up, but if I took the link between core 1 to Wan 1 router down, I would lose the neighborship and the wan router would not think to use the other link that goes to core 2. Can you possible share your syntax if you can? or core 2 would not think to send it through the other link.

cofee · ‎05-13-2018

Configuration of eigrp is straight forward. You just need to enable eigrp on all links that connect CE1 and CE2 to Core routers, also advertise loopback interfaces of CE 1 and CE 2 for iBGP peering. You have redundant links so there is no reason why iBGP peering would be affected if one of links between CE and Core routers is down.

Please make sure you don't have any static routes configured for loopbacks on core routers. If you are still having issues then please share eigrp configuration from CE and Core routers.

Amafsha1 · ‎05-13-2018

Sorry, I shouldve responded back. I had left a left-over static route on the core that was interfering with EIGRP. The second I removed it, it worked and both WAN routers had 2 routes to eachother.

cofee · ‎05-13-2018

No worries. Good to hear that it's working for you now.

Amafsha1 · ‎05-13-2018

Thanks for all your help btw. I have 1 more question. If you look at the picture I attached, I setup a sample topolgy of what our config will look like hopefully. I am able to get the iBGP neighborships to come up through routing through the cores. The NX cores are on the way right, left of that is WAN2 router and WAN4 router which is us, left of that is PE1 and PE3 which is ISP and left of that is supposed to be 1 of our branches(router 7) which is only connected to the PE1 isp router, but there is an iBGP neighborship between the two PE routers so they can both get to the branch. I have configured BGP so that both of our WAN2/4 routers can route to the branch(I can ping from both WAN2/4 routers to the branch). So now that both of our routers can get to the branch, how do I get it so that the cores see both of Routers as an option to get there. right now, only WAN2 works, and if it fails the cores loose their ability to touch the branch routers because they're not learning it from WAN4 router...Idk how to get them to work because I have redistrubted everything bgp from both WAN routers to eigrp, so both cores should know that there is a route to the branch through any of the 2 WAN routers.. Is their something fundemental I'm missing here? I understand that BGP can't load-balance, but I wonder if that's why..