BGP & EIGRP Routing Issue

All,

Hi, any assistance on this would be great, we're all out of ideas at the moment.

I have 2 x central L3 switches (3560's - Primary & Secondary) running BGP to a private MPLS cloud. I redistribute BGP (WAN) into EIGRP (LAN), there is no iBGP.

The above switches are connected to the internal LAN and to each other via one of their Gig Interfaces.

A number of remote branches connect to the same MPLS cloud and back to the central site.

At the central site routes to these remote locations are learned via eBGP with a metric of 20. However, routes to 3-4 branches are learned in EIGRP by the Primary via the Secondary (AD 170). If I bounce the Gig link between them everything is OK for a while, then a few days later, the EIGRP route pops up again.

There is no inbound route filtering on the 3560's as we wanted to see all routes.

The routes concerned do show in the BGP table with the next hop as the eBGP peer. For some reason this route is ignored and the EIGRP path is followed.

Any ideas ?

Regards

Darren

Reply to
Darren Green
Loading thread data ...

Darren,

Turn on "Route Change Log" on both protocols, or turn on debugging for the redistribution, and see when it happens.

Good luck,

Mike CCNP, CCDP, CCSP, Cisco Voice, MCSE W2K, MCSE+I, Security+, etc. CCIE R&S (in progress), CCIE Voice (in progress)

------ Headset Adapters for Cisco IP Phones

formatting link
formatting link

Reply to
headsetadapter.com

Setup IBGP to eliminate redistribution in EIGRP; use loopbacks if there is multiple paths between the two 3560's.

When you redistirbute you lose the the details carried with the BGP route which can be important for multipath BGP bestpatch route slection and for other reasons.

Default can atrtact traffic to central MPLS-connected routers so should not have to redistribute BGP into EIGRP

If redistribution is left in place, lower the IBGP admin distance so that it is under external EIGRP - ie set to 150

Reply to
Merv

I'm not sure why this is a problem. So core 1 routes to core 2 for some of the branches, which to me is completely healthy unless you are talking about having backup ISDN links terminating on Core 2 and therefore want to avoid it. Else you are distributing the bandwidth and utilization across the cores, which actually makes sense. And if one fails, the other should pickup the heat. The issue I'm having, is that if it is true e-bgp peering on both cores to all branches, then how is eigrp being selected when e-bgp's admin distance is 20. Something is not quite right.

Reply to
Trendkill

This may be an IOS bug.

If OP posts his configs then reponders could assess whether there are any config-related issues.

Personally, I would ditch the redistribution and implement IBGP

Reply to
Merv

I agree, but that only solves this issue, and then you still most likely have to redistribute bgp into eigrp elsewhere (perhaps at the next layer of routers). And if he is having some kind of bug issue, I'm also not sure that would solve it. Regardless, I get the impression he has to advertise these subnetworks back into his core. I would consider turning up eigrp all the way through if you can get away with it, but given that it is mpls, probably not an option.

Reply to
Trendkill

Assuming that the two routers running EBGP are the only exit points, then I would think that advertising default via EIGRP would suffice.

Reply to
Merv

Its not exit points, its to branches. If we were talking internet, this would be much easier. I think this is a retail network of some kind, and therefore it can get difficult. Although, you may be onto something. You could use ip summary statements on your routing vlans to advertise the branch/store networks presuming they are subnetted nicely and can be summarized. This would allow you to advertise the bgp networks into eigrp without redistributing, and all you would need to ensure is that the routers have at least one interface in eigrp in the summarized range. This could work nicely.

Reply to
Trendkill

Exit points meaning to the MPLS PE routers.

The OP clearly stated that this issue was occuring on the two central site routers.

All the other sites have to be reached via those two rCE routers so any traffic behind i.e. LABNS at the central site. etc) can be drawn to these routers with default.

Reply to
Merv

Gotta be careful here, what about the internet? We can assume these cores are the default route for anything downstream, but the OP did not specifically say this, and who knows how they are routing for DMZs or out to the internet. It probably is a safe bet that the cores know about the default through the proper way, but once you turn that up, just need to be aware of what else is where. I worked for a very large retail organization, and we had separate retail routers (for stores) than for our WAN, and from our core. Additionally, we had multiple internet connections in various datacenters, and turning up a summary for 0.0.0.0 if it is not already there may cause issues if the local internet pipe drops. Default should be redistributed from the proper protocol, so perhaps he can redistribute that from bgp (presuming it is there) and nothing else.

Reply to
Trendkill

Clearly if there are other exit points then the more specific routes need to be propogated.

BTW I did not say to point default at the MPLS PE routers but just advertise (i.e. originate) default (i.e. points it to null0 on teh BGP routers

More specific routes are held by CE routers that are running BGP. So once traffic arrive at these routers it will be handled as it is today.

Reply to
Merv

Yes, I agree. Just didn't want to assume too much without the data. Never can gauge the knowledge of everyone on here, some take everything verbatim. Either way, appreciate the help, and congrats on your #2 post status now :-).

Reply to
Trendkill

Hi Merv,

Thanks to you & Trendkill for the follow up posts.

I see the value in iBGP, however, I inherited the network from another engineer who is no longer with my company. The roll out is approx 90% complete and downtime is a real issue.

The BGP routes are redistributed into EIGRP by our L3 switches and then handed off on the internal side to some customer 6509's that run EIGRP (the customers original routing protocol of choice). When I do the re-distribution I add prefix lists to ensure the client doesn't accidentally advertise these routes back to me.

For the 3-4 x routes I learn in EIGRP from the backup 3560 I still have a valid next hop when I do a show ip bgp XXXXX for the same network. The route is in the BGP table but not in the routing table. Bounce the interface between the 3560's (Gig 0/3) and the routes come back in BGP.

I followed a Cisco BGP troubleshooting guide and it's suggestion is that I raise a TAC case which I aim to do tomorrow.

The reason this is an issue is that the customer sees the traffic on the link coming into the Secondary 3560. From here it's re-distributed and pushed to the primary 3560 in EIGRP. Whilst this is OK this link is supposed to be a failover link.

Remote Site | cloud | | primary---secondary | | Transit Lan | Customer Lan

Regards

Darren

Reply to
Darren Green

Same mask on both routes (the one from eigrp, and the one in bgp after you bounce the backbone)? Can you not redistro into eigrp but filter it back to just 0.0.0.0, or do you have other ingress/egress on other routers further back? You don't want to put in a filter list in eigrp (between the two cores) to avoid problems if one of the wan links really does go down, but you may have other options to keep eigrp clean. Both 3560s are the same AS I would presume? What code are you running? I'm also assuming you do not have any peering in between the two 3560s per Merv's questions, which means that core1 must either have a better match (via mask) to router 2 via eigrp, or something is up with code if I am understanding the architecture right. Also, is the peer/next hop address the same for both 3560s in bgp?

If you open a case, let us know what you find.

Reply to
Trendkill

The actual Internet breakout isn't in yet but will be shortly.

The plan is to deliver a resillient Internet connection split across 2 x Co-Lo cation facilities from the MPLS cloud.

The issue here is with a seperate Data Centre where the BGP is re- distributed into EIGRP for the client core. This data centre connects back to the client HQ via a couple of Ethernet circuits. The client wants to be able to see all the routes in EIGRP so they know what's up /down.

Remote Site | MPLS cloud--------------internet | | primary---secondary | | Data Centre LAN | | customer LAN

I believe this is an IOS bug and aim to open a TAC case with Cisco tomorrow.

Regards

Darren

Reply to
Darren Green

Same mask for both EIGRP and BGP. Originally I thought that this could have been the problem but no so.

Unfortunately I can't filter EIGRP down to 0.0.0.0 at the back end as the customer wants to see the routes being handed over to them.

Originally, the customer's network consisted of leased lines running EIGRP from their HQ to all their sites. We came along and moved the sites to MPLS, when doing this we applied router filtering to make sure that the customer did not advertise the LAN's on the MPLS back to us on the transit network.

In BGP we don't filter the inbound BGP in the datacenter but we do filter the re-distributed routes into EIGRP.

As an example, an old site on Leased Line say 192.168.1.1 /24 moves to MPLS. When this advertisement come in via the 3560's in BGP, we ensure via a route-map that this LAN is allowed to be re-distributed into EIGRP. Then on the transit side of the 3560'we ensue that it is not re- advertised back to us by the client in their EIGRP process.

Both 3560's are in the same AS but I would need to check the IOS versions. There is no iBGP between the 3560's only EIGRP.

Each 3560 talks to a different Telco eBGP peer in the MPLS cloud. The Telco eBGP peers for both routers are in the same AS (just separate datacenters for resiliency)

When I find out what the problem was, I will e-mail an update.

Thanks for the help, really appreciated.

Regadrs

Darren

Reply to
Darren Green

I'm no expert in this area (by any means) but when I was reading around the subject (for another issue by the way), I came across:

formatting link
which seems to indicate in some circumstances that routes learned via EIGRP are automatically preferred to those learned through BGP. Now I have no idea if this applies in this situation, and I have probably missed something critical, but thought it worth tossing out there for someone to shoot down...?! Would be interested to hear what anyone has to say on this.

Cheers,

Al

Reply to
Al

Guys,

I have the same problem related by Darren. Look the show ip bgp and show ip route.

SPOPA302#sh ip bgp vpnv4 vrf bfe 10.171.28.0 BGP routing table entry for 8167:10401:10.171.28.0/24, version 6254804 Paths: (2 available, best #1, table bfe) Not advertised to any peer 7738 65001, imported path from 8167:10398:10.171.28.0/24 201.10.208.209 (metric 32) from 201.10.208.8 (201.10.208.8) Origin incomplete, metric 310, localpref 100, valid, internal, best Extended Community: RT:8167:10398 Originator: 201.41.107.252, Cluster list: 0.0.0.14 Local 10.249.2.26 from 0.0.0.0 (201.10.240.4) Origin incomplete, metric 249344, localpref 95, valid, sourced Extended Community: RT:8167:10401 Cost:pre-bestpath:129:249344 0x8800:0:7738 0x8801:10:36096 0x8802:65285:213248

0x8803:65285:1500 0x8804:8167:184091589 0x8805:9:310

The first route learned from MP-BGP(MPLS) and it is the best, but, the other route from EIGRP is installed on routing table:

SPOPA302#sh ip route vrf bfe 10.171.28.0 Routing entry for 10.171.28.0/24 Known via "eigrp 10401", distance 170, metric 249344 Tag 7738, type external Redistributing via eigrp 10401, bgp 8167 Advertised by bgp 8167 route-map WEIGHT_0 Last update from 10.249.2.26 on FastEthernet11/37, 03:42:12 ago Routing Descriptor Blocks: * 10.249.2.26, from 10.249.2.26, 03:42:12 ago, via FastEthernet11/37 Route metric is 249344, traffic share count is 1 Total delay is 1410 microseconds, minimum bandwidth is 12004 Kbit Reliability 255/255, minimum MTU 1500 bytes Loading 5/255, Hops 5 Route tag 7738

I tried to influence de pre-bestpath on the first route, but it did not resolve.

Anyone knows how to solve this.

Regards,

Christianno snipped-for-privacy@gmail.com

Reply to
christiannomarcenes

Best is learned via IBGP which has AD=200

EIGRP external has AD=170, thus EIGRP wins

you could lower the Admin Distance of IBGP from 200 to 150

make sure your are NOT doing mutual redistribution without proper route riltering useing route maps

Reply to
Merv

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.