eigrp to bgp redistribution

[DARYLE DIANIS]

I have a layer 3 switch running EIGRP and a router that is redistributing EIGRP into BGP.
If any of the neighbor relationships on the layer3 switch goes down, then comes back up, 
does that event trigger an update in BGP?  The reason I ask is that the router seems to be
reacting to something and the bgp routing table is getting updated.

many thanks,

[Bilal Nawaz · Accepted solution]

Yes if you are redistributing EIGRP in to BGP, any prefix's in the routing table that are EIGRP that are taken away or added (to the routing table) will be reflected in what BGP advertises [or not advertised]

Example: On your layer 3 switch, you have a prefix that is EIGRP begin advertised, subsequently advertised to the router doing the redistribution. If this prefix was to stop being advertised in EIGRP or the EIGRP neighborship was to go down, then this would trigger updates or routes would become invalid to the router, router would then withdraw the route from its routing table, since it no longer exists in its routing table, bgp update messages to be sent about the relevant prefix(s) being redistributed. Vice versa for EIGRP routes being learnt/neighborship coming back up.

The below is equivalent to the router doing the redistribution.

R2# WHEN NEIGHBORSHIP COMES UP.

*Mar  1 00:15:26.183: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 1.1.1.1 (FastEthernet0/1) is up: new adjacency

*Mar  1 00:15:26.607: BGP: Regular scanner event timer

*Mar  1 00:15:26.607: BGP: Performing BGP general scanning

*Mar  1 00:15:26.607: BGP(0): scanning IPv4 Unicast routing tables

*Mar  1 00:15:26.607: BGP(IPv4 Unicast): Performing BGP Nexthop scanning for general scan

*Mar  1 00:15:28.243: RT: SET_LAST_RDB for 10.10.10.10/32

  NEW rdb: via 1.1.1.1

*Mar  1 00:15:28.243: RT: add 10.10.10.10/32 via 1.1.1.1, eigrp metric [90/409600]

*Mar  1 00:15:28.247: RT: NET-RED 10.10.10.10/32

*Mar  1 00:15:28.247: BGP(0): route 10.10.10.10/32 up

*Mar  1 00:15:28.247: BGP: Applying map to find origin for 10.10.10.10/32

*Mar  1 00:15:28.247: BGP(0): nettable_walker 10.10.10.10/32 route sourced locally

*Mar  1 00:15:28.247: BGP(0): 2.2.2.3 send UPDATE (format) 10.10.10.10/32, next 2.2.2.2, metric 409600, path Local

*Mar  1 00:15:41.635: BGP: Regular scanner event timer

*Mar  1 00:15:41.635: BGP: Import timer expired. Walking from 1 to 1

*Mar  1 00:15:56.635: BGP: Regular scanner event timer

*Mar  1 00:15:56.635: BGP: Import timer expired. Walking from 1 to 1

R2#WHEN BGP NEIGBORSHIP GOES DOWN

*Mar  1 00:15:59.775: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 1.1.1.1 (FastEthernet0/1) is down: holding time expired

*Mar  1 00:15:59.775: RT: delete route to 10.10.10.10 via 1.1.1.1, eigrp metric [90/409600]

*Mar  1 00:15:59.779: RT: SET_LAST_RDB for 10.10.10.10/32

  OLD rdb: via 1.1.1.1, FastEthernet0/1

*Mar  1 00:15:59.779: RT: no routes to 10.10.10.10

*Mar  1 00:15:59.779: RT: NET-RED 10.10.10.10/32

*Mar  1 00:15:59.783: RT: delete subnet route to 10.10.10.10/32

*Mar  1 00:15:59.783: RT: NET-RED 10.10.10.10/32

*Mar  1 00:15:59.783: RT: delete network route to 10.0.0.0

*Mar  1 00:15:59.787: RT: NET-RED 10.0.0.0/8

*Mar  1 00:15:59.803: BGP(0): route 10.10.10.10/32 down

*Mar  1 00:15:59.803: BGP(0): no valid path for 10.10.10.10/32

*Mar  1 00:15:59.803: BGP(0): route 10.10.10.10/32 down

*Mar  1 00:15:59.803: BGP(0): nettable_walker 10.10.10.10/32 no best path

*Mar  1 00:15:59.807: BGP(0): 2.2.2.3 send unreachable 10.10.10.10/32

*Mar  1 00:15:59.807: BGP(0): 2.2.2.3 send UPDATE 10.10.10.10/32 -- unreachable

hth

[DARYLE DIANIS]

thanks, now I have another question, does the change to bgp affect only the 1 subnet that went down and then up or does the entire bgp table get refreshed?

thanks again,

[Bilal Nawaz]

This will only have effect on the prefix's that were lost or gained in the routing table. Dependant on timers (advertisement-interval), BGP does send updates every so often - eBGP neighborships i believe is 30secs by default.

From what i've seen, the router doing the redistribution - it's BGP table should be updated as soon as relevant routes are in the routing table.

But its BGP peers will have to wait for the advertisement interval before they receive the update of the new routes or perished routes. The updates only contain the new prefix's with relevant information about the prefix e.g. AS path etc... or routes that are no longer reachable (unfeasible route) i.e. to be withdrawn.

[DARYLE DIANIS]

thanks for clarifying for me.