Router not respecting AD rules between EBGP and EIGRP

[RClaros]

Hello,

I have a setup where a router learns a subnet from both EIGRP process and a BGP process (EBGP peer). In the network's normal state, the EBGP path is preffered path (Primary Path). When the route to the subnet is lost in EBGP, then the router will install the EIGRP learn route into the routing table and use that as its path to get to subnet now (Backup path). This works as expected.

The problem is when the EBGP learn route comes back, the Router still holds on the EIGRP learned route in its routing table. I would think that since the Admin Distance (AD) of EIGRP (90) is higher then the EBGP AD (20) that once the EBGP route is learned again, that it would re-install itself back into the routing table (replacing the EIGRP learned route). But this is not happening.

Im not sure what Im missing here since I thought AD was highest considered attribute the routing table consider when install a route learned from 2 routing process.

The setup Im running is an Cisco 7206VXR (NPE-G2) processor (revision A) running IOS c7200p-spservicesk9-mz.124-15.T12.bin.

Thanks for any help on this.

[Dennis Mink]

Robin,

are the routes exacltly the same? i.e. do both routing processes advertise the same network and mask? Because admin distance will only be a decider when there is an exct match between 2 different routing protocols.

[nkarpysh]

Can you please also paste "sh ip route" and "show ip bgp" for this router after eBGP route le-reant to start with.

Nik

[RClaros]

Nikolay Karpyshev wrote:
Can you please also paste "sh ip route" and "show ip bgp" for this router after eBGP route le-reant to start with.
Nik

Hello Nikolay, I am sorry but since router is in live enviroment, I cannot paste this capture at the moment. However I can tell you after the BGP route was re-learned, the "show ip bgp" output would show the subnet in the BGP table with no errors (for example no RIB failure) and the "show ip route" would show EIRGP learned router of the same subnet. It would also show it with Admin distance of 90.

Once I cleared the EIGRP route (by turning off the device that advertises the network in the EIGRP domain), then the EBGP route is again installed in the routing table, and a show IP route would show the admin distance as 20. This I can paste beow. But note that we again have turn up the device in eigrp so routes are learned from both process and EBGP route still remians in routing table. It is like the routing table will not update itself unitl we completely remove the route from either BGP or EIGRP completely for a short time.

This is the current snapshot of "show Ip route",show bgp" and show eigrp topology" in its current and normal state:

routername# sh ip bgp 10.xxx.0.0/16
BGP routing table entry for 10.xxx.0.0/16, version 13279
Paths: (1 available, best #1, table Default-IP-Routing-Table)
  Not advertised to any peer
  yyyyy yyyyy
    bbb.bbb.bbb.bbb from bbb.bbb.bbb.bbb (ccc.ccc.ccc.ccc)
      Origin IGP, localpref 100, weight 300, valid, external, best

routername# sh ip route 10.xxx.0.0
Routing entry for 10.xxx.0.0/16
  Known via "bgp 65000", distance 20, metric 0
  Tag yyyyy , type external
  Redistributing via eigrp 3
  Advertised by eigrp 3 metric 10000000 1 255 1 1500 route-map BGP-TO-EIGRP
  Last update from bbb.bbb.bbb.bbb 1w3d ago
  Routing Descriptor Blocks:
  * bbb.bbb.bbb.bbb, from bbb.bbb.bbb.bbb, 1w3d ago
      Route metric is 0, traffic share count is 1
      AS Hops 2
      Route tag yyyyy

routername# sh ip eigrp topology 10.xxx.0.0/16
IP-EIGRP (AS 3): Topology entry for 10.xxx.0.0/16
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 512
  Routing Descriptor Blocks:
  bbb.bbb.bbb.bbb, from Redistributed, Send flag is 0x0
      Composite metric is (512/0), Route is External
      Vector metric:
        Minimum bandwidth is 10000000 Kbit
        Total delay is 10 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 0
      External data:
        Originating router is ddd.ddd.ddd.ddd (this system)
        AS number of route is 65000
        External protocol is BGP, external metric is 0
        Administrator tag is yyyyy (0x00003637)

[milan.kulik]

Hi,

I see you are redistributin BGP to EIGRP on your router.

Aren't you also redistributing EIGRP to BGP?

In that case, I could imagine following scenario:

EIGRP learns the prefix. I gets to the RIB with AD 90.

Your router redistributes it to BGP table (with the weight attribute 32768 by default).

Then the same prefix is received by eBGP. But with a default weight attribute 0. So it's not the best route from the BGP process point of view, so the "old" prefix with weight 32768 remains as the best in the BGP table. And there is no reason to change the RIB.

(This way the AD plays only a secondary role, as from the BGP process point of view the eBGP prefix is the worse one.)

Then you remove the prefix from EIGRP by turning off the device that advertises the network in the EIGRP domain.

The redistributed prefix is removed from BGP table and the same prefix received by eBGP becomes the best (as the only one) from the BGP process point of view. So it gets to the RIB with AD 20.

When the same prefix is received from EIGRP again (AD 90), it does not get to to RIB as it contains the eBGP prefix with AD 20 already.

To fix the problem, you'd need to tune BGP attributes when redistributing.

Using a route-map for EIGRP to BGP redistriution decreasing the weight to 0, e.g.

If you are running a mutual EIRGP/BGP redistribution on your router, I'd recommend you to build a lab and test "what happens when the prefix is received from EIGRP first and from BGP then" and vice versa.

HTH,

Milan

[RClaros]

minkdennis wrote:
Robin,
are the routes exacltly the same? i.e. do both routing processes advertise the same network and mask? Because admin distance will only be a decider when there is an exct match between 2 different routing protocols.

Hello minkdennis,

I can confirm that network learned by both EIGRP and BGP is the same subnet and that mask is exactly the same.

Beside "longest mask match rule" what else can supercede Adminstrative Distance?

[nkarpysh]

BGP may consider route as not valid - e.g. next hop not reachable, etc

Thus I asked for show commands to see how the route is showing up in the BGP table while both routes learnt and EIGRP installed in GRT.

Nik

[RClaros]

Nikolay Karpyshev wrote:
BGP may consider route as not valid - e.g. next hop not reachable, etc
Thus I asked for show commands to see how the route is showing up in the BGP table while both routes learnt and EIGRP installed in GRT.
Nik

Hello Nikolay,

Please see previous post that I replied to yours, the show ip bgp output I pasted is basically the same as what I see after the BGP route is relearned. Also I did verify that the prefix was not in a "rib failure" status. This is what I see also by just doing "show ip bgp" without the prefix aurgument afterwards:

routername# sh ip bgp | i 10.xxx.0.0/16

*> 10.xxx.0.0/16    bbb.bbb.bbb.bbb                        300 yyyyy yyyyy i

routername#

[nkarpysh]

SOrry Robin,

Did not notice outputs above. As I see from sh ip route  - right now problem is not there. And as it is production netwrok we will not be able simulate it. Right?

Basically it would e interesting to look at BGP table during the problem as now all showing correct - BGP path showing as best:

*> 10.xxx.0.0/16    bbb.bbb.bbb.bbb                        300 yyyyy yyyyy i

and that is in GRT:

routername# sh ip route 10.xxx.0.0

Routing entry for 10.xxx.0.0/16

  Known via "bgp 65000", distance 20, metric 0

it would be interesting also to see "debug ip routing" to see what happening to this route.

Anyway may be someone else met this before and aware of any defect for same.

Nik