BGP-EIGRP mutual redistribution problem

[smith.dean]

I have a problem I'm struggling to understand from a design point of view and would be grateful for any help that could put me on the right track here.  I have attached a diagram depicting the topology I will explain now, as well as my logic (flawed or not!).

I have a WAN with 2 CPE routers that advertise an aggregate (LAN supernet) to the carrier PE via an eBGP peering.  Both CPE routers have their own eBGP peers with 2 separate PE routers and advertise the same aggregate; the primary CPE issues a better metric than the backup CPE to influence the path for traffic back inbound.  The CPE nodes do not have any BGP peering relationship but use EIGRP to redistribute routes back in to the LAN with CPE 1 redistributing the BGP routes using a better eigrp metric than the redistributed routes CPE2 advertises.  They are both redistributing these routes back in to BGP (along with redistribution of static routes as well).

The problem I am getting is when another WAN site advertises an aggregate address range into the BGP cloud (for example 10.38.0.0/18) this BGP route is received by both the CPE1 and CPE2 nodes.  CPE2 however is redistributing this into EIGRP and CPE1 is getting this as an EIGRP external route (AD 170); which is all well and good.  It is using this route over the BGP (AD 20) route though.  The intention is that CPE1 should redistribute this route into the EIGRP process as well (with a better metric than CPE2 does) but this is not happening.  CPE1 is merely retaining the EIGRP EX route for 10.38.0.0/18 with the next hop being the CPE2 inside interface.  This causes asymetrical routing as traffic from a 10.38.0.0/18 address enters the site via CPE1 but returns back to the WAN via CPE2. 

I'm a bit perplexed as to what I've done wrong here.  I assume its a design flaw but am unsure as to how to go about it.  Why doesn't CPE1 use the 20/0 BGP route from PE1 instead of the external EIGRP 170 router from CPE2? And how do I go about fixing it?  Anyone?  Thanks

[Varun Uniyal]

Well eBGP over iBGP is only the 7th criteria in BGP path selection algo. From what you've summarized it seems that the route is being learnt via CPE2 and redistributed in BGP which causes CPE1 to learn that route through EIGRP (170)., now you are redistributing EIGRP into BGP, right ? coz if you are this EIGRP learnt route might get installed in BGP on CPE2 as a local route (200), since BGP will advertise whatever appears best in it's BGP table it could be that this route now starts getting advertised to PE2 and since BGP is ultimately a path vector protocol , PE2 will never advertise the same route back to CPE2.

if you do on CPE2sh ip bgp x.x.x.x     you will see the next-hop as 0.0.0.0 and weight as 32768A solution is to increae the weight of the routes learnt from PE2 on CPE2on CPE2:neighbor weight 32769

[smith.dean]

Hi Varun.  Thanks heaps for the reply and your feedback.  Below is an output of the BGP route from CPE2's perspective:

CPE2

#show ip bgp 10.38.0.0/18

BGP routing table entry for 10.38.0.0/18, version 10329

Paths: (1 available, best #1, table Default-IP-Routing-Table)

  Not advertised to any peer

  65530 130, (aggregated by 130 10.38.63.255)

    10.32.63.97 from 10.32.63.97 (10.32.63.65)

      Origin IGP, localpref 100, valid, external, atomic-aggregate, best

#show ip bgp

*> 10.38.0.0/18     10.32.63.97                            0 65530 130 i

You can see that it is clearly getting the BGP route from PE2 (10.32.63.97) and it is redistributing in to EIGRP at which point CPE1 is picking up that route.  For comparison, here is what I am seeing on CPE1.  It is getting the route from both PE1 and via EIGRP from CPE2, but preferring the EIGRP route.

CPE1

#show ip bgp 10.38.0.0/18

BGP routing table entry for 10.38.0.0/18, version 9219

Paths: (2 available, best #2, table default)

  Not advertised to any peer

  65530 130, (aggregated by 130 10.38.63.255)

    10.32.63.9 from 10.32.63.9 (10.32.63.9)

      Origin IGP, localpref 100, valid, external, atomic-aggregate

  Local

    10.33.63.34 from 0.0.0.0 (10.32.63.11)

      Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best

*  10.38.0.0/18     10.32.63.9                             0 65530 130 i

*>                  10.33.63.34              0         32768 ?

#show ip route 10.38.0.0  

Routing entry for 10.38.0.0/18

  Known via "eigrp 100", distance 170, metric 284160

  Tag 65530, type external

  Redistributing via eigrp 100, bgp 110

  Advertised by bgp 110 metric 0

  Last update from 10.33.63.34 on GigabitEthernet0/0, 4d22h ago

  Routing Descriptor Blocks:

  * 10.33.63.34, from 10.33.63.34, 4d22h ago, via GigabitEthernet0/0

      Route metric is 284160, traffic share count is 1

      Total delay is 1100 microseconds, minimum bandwidth is 10000 Kbit

      Reliability 255/255, minimum MTU 1500 bytes

      Loading 3/255, Hops 1

      Route tag 65530

Are you able to explain to me how changing the weight on CPE2 will rectify this?  I'm a bit confused by that.  Thanks again for your help.

[milan.kulik · Accepted solution]

Hi,

it looks strange, as you are not running iBGP between your routers, are you?

And also not redistributing EIGRP to BGP.

Are yu sure you are receiving 10.38.0.0/18 via BGP from PE1?

Can you provide

sh ip bgp  10.38.0.0/18

sh ip eigrp topo 10.38.0.0/18

sh ip route 10.38.0.0

from both your routers?

BR,

Milan

[Varun Uniyal · Accepted solution]

Exactly what i thought..just got the device mixed. It's happening the other way round :

Look at CPE1 entry :

CPE1

#show ip bgp 10.38.0.0/18
BGP routing table entry for 10.38.0.0/18, version 9219
Paths: (2 available, best #2, table default)
  Not advertised to any peer
  65530 130, (aggregated by 130 10.38.63.255)
    10.32.63.9 from 10.32.63.9 (10.32.63.9)
      Origin IGP, localpref 100, valid, external, atomic-aggregate
  Local
    10.33.63.34 from 0.0.0.0 (10.32.63.11)
      Origin incomplete, metric 0, localpref 100, weight 32768, valid, sourced, best

*  10.38.0.0/18     10.32.63.9                             0 65530 130 i

*>                  10.33.63.34               0        32768

?

The 0.0.0.0 means it's a locally originated route ( the one that is redistributed from EIGRP in BGP on CPE1) and locally originated route has a weight of 32768. Now in BGP route selection criteria weight is the most preferred attribute, higher the weight more preferred the route.

You need to tweek the weight on CPE1 so that it prefers route from 10.32.63.9   intead of EIGRP learnt (and redistributed)

Try this and let me know how it goes :

on CPE1 :

neighbor 10.32.63.9  weight 32769

[Varun Uniyal]

or rather configure on both CPE1 and CPE2

neighbor weight 32769

so that they do not prefer the local route(redistributed from EIGRP) with weight 32768 but each prefers the route learnt from their respective PEs

[smith.dean]

Varun, that makes total sense to me now!  Thank you so much for the clarification.  I will try that and let you know how it goes.  Will take me a week or so though unfortunately to get required change approvals (you know how it is...).

One thing I'm not sure on though is that if CPE1 then installs the route based on the better weight of 32769 from PE, will that then redistribute that route back into the EIGRP process again (with a better metric than that coming from CPE2, as per the original intent) so that the downstream (LAN interfacing) EIGRP neighbour will then prefer the routes from CPE1 again instead of CPE2?  I presume this is the case as currently CPE1 is preferring the CPE2 route and split horizon would be stopping it from advertising back out the same interface with its own EIGRP redistributed route? 

Thanks so much again Varun.

Regards

[smith.dean]

Hi Milan.  Thanks for your response, it's much appreciated.  As per the reply above, you can see that CPE1 is getting the route from PE1.  I did however forget to include the EIGRP topology output as you suggested, so here is that:

CPE1

show ip eigrp topology

P 10.38.0.0/18, 1 successors, FD is 284160, tag is 65530

        via 10.33.63.34 (284160/281600), GigabitEthernet0/0

show ip route

D EX     10.38.0.0/18 [170/284160] via 10.33.63.34, 4d22h, GigabitEthernet0/0

show ip bgp

*  10.38.0.0/18     10.32.63.9                             0 65530 130 i

*>                  10.33.63.34              0         32768 ?

CPE2

show ip eigrp topology

P 10.38.0.0/18, 1 successors, FD is 281600, tag is 65530

        via Redistributed (281600/0)

show ip route

B       10.38.0.0/18 [20/0] via 10.32.63.97, 4d22h

show ip bgp

*> 10.38.0.0/18     10.32.63.97                            0 65530 130 i

Also, no, there is no iBGP peering between CPE1 & CPE2; only the EIGRP and the redistribution between that and BGP.

Thanks again.

[milan.kulik · Accepted solution]

Hi,

so it means you ARE redistributing the same prefixes from BGP to EIGRP on CP2 and from EIGRP to BGP again on CPE1.

(It was not visible form your original diagram.)

Is it really what you want?

IMHO, what happend:

CPE2 had received the 10.38.0.0/18 prefix from PE2 first. It redistrubuted that prefix to EIGRP.

CPE1 received the prefix from EIGRP.

As there was not the same prefix received from PE1 yet, CE1 took the EIGRP prefix as the best one and redistributed it to BGP.

Later on, when the same prefix came from PE1, CE1 did not take it as the best one, as there was the same prefix in the BGP table already originated by CE1 (redistributed from EIGRP) with weight 32768.

IMHO, it's not a good practice to redistribute EIGRP  external prefixes (received from BGP originally) back to BGP.

You should use some tagging to prevent that, e.g.

Example:

Use a route-map when redistributing BGP to EIGRP which would tag all the redistributed prefixes with some unique value - 2000, e.g.

And when redistributing from EIGRP to BGP, use another route-map preventing prefixes tagged with 2000 from redistributing to BGP.

That's easy and will fix your problem, I hope.

BR,

Milan

[smith.dean]

Thanks Milan.  I take your point and agree its valid.  I'm going to look at redesigning that setup so I'm not redistributing the BGP routes through EIGRP and back out BGP again.  You guys have been great.  I at least understand now why it is behaving the way it is and that will help me in better re-engineering it and knowing how to test it as well.

Cheers