05-01-2019 05:13 AM
I have an ISR 4430 advertising over a WAN via BGP to a 3925. The 3925 talks EIGRP to its local networks. The routes i'm advertising to the 3925 via BGP are listed with an AD of 20. The EIGRP routes seen by the 3925 have an AD of 170. Yet the EIGRP routes are being preferred and the report on rib-failure is as below. Any idea why the EIGRP routes would be preferred even though they have a higher distance?
show ip bgp rib-failure
Network Next Hop RIB-failure RIB-NH Matches
0.0.0.0 10.38.240.2 Higher admin distance n/a
10.5.44.0/27 10.38.240.2 Higher admin distance n/a
10.24.1.2/32 10.38.240.2 Higher admin distance n/a
10.35.0.0/16 10.38.240.2 Higher admin distance n/a
Solved! Go to Solution.
05-01-2019 08:36 AM
I agree that seeing what is in the config might be helpful (and might want to see more than just the bgp section). It would also be helpful if we could see the output of these commands
show ip route
show ip bgp neighbor
show ip bgp sum
HTH
Rick
05-02-2019 05:03 PM
As a test, i placed an inbound distribute-list on the eigrp config of C & D such that only subnets local to C & D would be received. Then, when i checked the route table on C, those routes (from A) which previously reported as EIGRP (170) now appeared as iBGP (200) from D. And they were still overriding eBGP.
Next, on C, i did a 'clear ip bgp <AS of D>'. After that, the routing table correctly showed routes from A as eBGP (20) and the RIB-Failures disappeared. I dont see why clearing the neighbor would change the table so much.
05-02-2019 06:27 PM - edited 05-02-2019 06:31 PM
Hi @jmcgrady1
This is exactly what I said its a race condition in my previous post. To understand it further, think about the order of operation.
There are 3 different source of Routes.
1. eBGP
2. iBGP
3. redistributed EIGRP route
In the first instance, when EIGRP route was selected due to highest redistributed weight and it being the best route in BGP then was also announced to EBGP neighbor unless there is some filtering. In such situations it is possible that upstream may not announce the eBGP route if it considers the route from D to be better. BGP only advertises best route to all peers but does not advertises route back to peer if it receives the best route from it already.
When your kill the redistribution through prefix-list you need to clear the BGP so that it can send the withdraw for that redistributed route to its ebgp peer. Again the race condition, before you could withdraw the route, iBGP got installed. Only after you cleared the BGP which then withdrew the route you could see the correct eBGP.
Like I mentioned in first post this is expected behavior and not really an anomaly. And the trick here is to modify the weights on the eBGP neighbors to be higher than the default 32768. This should be done on both eBGP routers and vice-versa on the other end of your topology.
Technically, you should only announce the local prefixes over eBGP and this should be done using AS-path access-list.
On both C&D, you should do this
ip as-path acess-list 1 permit ^$ ! route-map AS-PATH-LOCAL match as-path 1 ! router bgp <> neighbor x.x.x.x route-map AS-PATH-LOCAL out !
That regular expression selects only site-local routes.
Please rate this post and others if your find them helpful.
Regards,
Sebastian
05-05-2019 06:44 PM
Thanks all for contributing to this discussion. As a test, in my scenario, i removed EIGRP. I then saw the local iBGP advertisement (AD 200) from C to D appearing in D's routing table and the same route advertised from B to D (eBGP 20) listed as rib-failure. If i 'clear ip bgp <C AS>' on D, the rib failure clears and i see routes from B to D correctly listed.
I tried assigning weights in the BGP neighbor config on D for its neighbors B and C. With B set to 35000 and C set to 1000 it didnt seem to help. I'm not sure how to make it such that B's advertisements are always preferred over C's
05-05-2019 08:46 PM
Can you paste 'show ip bgp x.x.x.x' showing both eBGP and iBGP route in that scenario you mentioned with the BGP preferring iBGP over eBGP. That should not be the case if you eBGP is received and as long as there are no pain points that should be always preferred.
-
Sebastian
05-07-2019 10:53 PM
Below are some specifics from my environment. As described, A (AS 65065) & B (AS 65066) are at one site with C (AS 65042 10.42.240.1) & D (AS 65042 10.42.250.1, 10.42.240.2) at the other. Between B and D is a Telco (AS 65530 10.42.250.2).
Here is the routing table on D. Note the appearance of 0.0.0.0 via iBGP from C. This overrides 0.0.0.0 via eBGP from B.
You can see some successful routes from B, eg; 10.36.0.0
(on D) Gateway of last resort is 10.42.240.2 to network 0.0.0.0
B* 0.0.0.0/0 [200/0] via 10.42.240.2, 21:07:07
10.0.0.0/8 is variably subnetted, 45 subnets, 10 masks
B 10.5.44.0/27 [200/0] via 10.42.240.2, 21:07:07
B 10.24.250.0/29 [20/0] via 10.42.250.2, 2d06h
B 10.36.0.0/16 [20/0] via 10.42.250.2, 1d10h
B 10.38.0.0/16 [200/0] via 10.42.240.2, 21:07:07
(on D) sh ip bgp summ
BGP router identifier 10.42.240.1, local AS number 65042
BGP table version is 21596, main routing table version 21596
60 network entries using 8640 bytes of memory
77 path entries using 6160 bytes of memory
23/17 BGP path/bestpath attribute entries using 3680 bytes of memory
12 BGP AS-PATH entries using 288 bytes of memory
3 BGP community entries using 72 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 18840 total bytes of memory
Dampening enabled. 0 history paths, 0 dampened paths
4 received paths for inbound soft reconfiguration
BGP activity 2445/2385 prefixes, 9016/8939 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.42.240.2 4 65042 1415 1444 21596 0 0 21:14:03 22
10.42.250.2 4 65530 6746 7148 21596 0 0 2d06h 47
Curiously, since removing EIGRP from this equation, i'm not seeing RIB failures. However i cant see why D is receiving an advertisement for 0.0.0.0 via eBGP, yet choosing the iBGP advertisement to place into its routing table
sh ip bgp nei 10.42.250.2 received-routes
BGP table version is 21596, local router ID is 10.42.240.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
* 0.0.0.0 10.42.250.2 0 65530 65066 i
*> 10.24.250.0/29 10.42.250.2 0 65530 i
* 10.36.0.0/16 10.42.250.2 0 65530 i
* 10.38.0.0/16 10.42.250.2 0 65530 65024 i
sh ip bgp nei 10.42.240.2 received-routes
BGP table version is 21597, local router ID is 10.42.240.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
*>i 0.0.0.0 10.42.240.2 0 100 0 65065 i
*>i 10.5.44.0/27 10.42.240.2 0 100 0 65065 65048 i
* i 10.36.0.0/16 10.42.240.2 0 100 0 65065 65036 i
*>i 10.38.0.0/16 10.42.240.2 0 100 0 65065 65024 i
05-08-2019 12:06 AM
The reason D is choosing the IBGP default is because there is another AS (65530) between B and D which adds another AS to the AS path and that seems to be the deciding factor here.
When you applied the configuration to modify the weights did you do a soft reset ?
Jon
05-08-2019 03:00 AM
I'll arrange to do a soft reset. I haven't done that yet.
(on D) sh run | sec bgp
router bgp 65042
bgp log-neighbor-changes
bgp dampening
network 10.35.0.0
network 10.42.0.0 mask 255.255.0.0
network 10.43.0.0 mask 255.255.0.0
neighbor 10.42.240.2 remote-as 65042
neighbor 10.42.240.2 update-source Loopback1
neighbor 10.42.240.2 next-hop-self
neighbor 10.42.240.2 soft-reconfiguration inbound
neighbor 10.42.250.2 remote-as 65530
neighbor 10.42.250.2 soft-reconfiguration inbound
neighbor 10.42.250.2 weight 35000
sh ip bgp 0.0.0.0
BGP routing table entry for 0.0.0.0/0, version 21617
Paths: (2 available, best #1, table default)
Flag: 0x820
Not advertised to any peer
Refresh Epoch 1
65065, (received & used)
10.42.240.2 (metric 10880) from 10.42.240.2 (10.42.240.2)
Origin IGP, metric 0, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0
Refresh Epoch 1
65530 65066, (received & used)
10.42.250.2 from 10.42.250.2 (10.42.250.2)
Origin IGP, localpref 100, valid, external
rx pathid: 0, tx pathid: 0
sh ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
Known via "bgp 65042", distance 200, metric 0, candidate default path
Tag 65065, type internal
Last update from 10.42.240.2 00:06:30 ago
Routing Descriptor Blocks:
* 10.42.240.2, from 10.42.240.2, 00:06:30 ago
Route metric is 0, traffic share count is 1
AS Hops 1
Route tag 65065
MPLS label: none
05-08-2019 02:05 AM
Hello
Can you post the following:
RTR D
sh ip bgp 0.0.0.0
sh run | sec router bgp
05-08-2019 07:48 AM - edited 05-08-2019 07:50 AM
Hello
Even you say you've applied the weight metric we don't see them applied to the rib , maybe you do need to soft clear the bgp sessions as it is at present looks like shortest as-path is taking precedence has @Jon Marshall stated
BGP routing table entry for 0.0.0.0/0, version 21617
Paths: (2 available, best #1, table default)
Flag: 0x820
Not advertised to any peer
Refresh Epoch 1
65065, (received & used)
10.42.240.2 (metric 10880) from 10.42.240.2 (10.42.240.2)
Origin IGP, metric 0, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0
Refresh Epoch 1
65530 65066, (received & used)
10.42.250.2 from 10.42.250.2 (10.42.250.2)
Origin IGP, localpref 100, valid, external
rx pathid: 0, tx pathid: 0
05-08-2019 05:15 PM
On D i've now applied a soft reset for both peers. This corrected the routing table. Its now listing routes as per what i would expect
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: