I am not understanding this route table

Steven Williams · ‎06-12-2019

what would cause an issue with seeing a route in the show ip bgp table but not in the show ip route table?

CORE-9500-01#show ip bgp neighbors 10.53.100.1 received-routes
BGP table version is 64, local router ID is 10.10.10.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,
t secondary path, L long-lived-stale,
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 10.20.40.0/24 10.53.100.18 0 100 0 i
* i 10.53.100.0/30 10.53.100.1 100 0 ?
* i 10.53.100.8/30 10.53.100.1 100 0 ?
*>i 10.53.100.12/30 10.53.100.10 0 100 0 i
* i 10.53.100.16/30 10.53.100.1 100 0 ?
*>i 10.53.100.20/30 10.53.100.18 0 100 0 i

Total number of prefixes 6
CORE-9500-01#show ip bgp neighbors 10.53.100.5 received-routes
BGP table version is 64, local router ID is 10.10.10.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,
t secondary path, L long-lived-stale,
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 10.20.40.0/24 10.53.100.22 0 100 0 i
* i 10.53.100.4/30 10.53.100.5 100 0 ?
*>i 10.53.100.8/30 10.53.100.14 0 100 0 i
* i 10.53.100.12/30 10.53.100.5 100 0 ?
*>i 10.53.100.16/30 10.53.100.22 0 100 0 i
* i 10.53.100.20/30 10.53.100.5 100 0 ?

Total number of prefixes 6
CORE-9500-01#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 8 subnets, 2 masks
C 10.53.100.0/30 is directly connected, FortyGigabitEthernet1/0/29
L 10.53.100.2/32 is directly connected, FortyGigabitEthernet1/0/29
C 10.53.100.4/30 is directly connected, FortyGigabitEthernet1/0/30
L 10.53.100.6/32 is directly connected, FortyGigabitEthernet1/0/30
B 10.53.100.8/30 [200/0] via 10.53.100.14, 00:36:11
B 10.53.100.12/30 [200/0] via 10.53.100.10, 00:36:11
B 10.53.100.16/30 [200/0] via 10.53.100.22, 00:36:11
B 10.53.100.20/30 [200/0] via 10.53.100.18, 00:36:11
CORE-9500-01#

!

CORE-9500-01#show run | sec router
router bgp 65001
bgp router-id 10.10.10.1
bgp log-neighbor-changes
neighbor 10.53.100.1 remote-as 65001
neighbor 10.53.100.5 remote-as 65001
!
address-family ipv4
network 10.53.100.0 mask 255.255.255.252
network 10.53.100.4 mask 255.255.255.252
neighbor 10.53.100.1 activate
neighbor 10.53.100.1 soft-reconfiguration inbound
neighbor 10.53.100.5 activate
neighbor 10.53.100.5 soft-reconfiguration inbound
maximum-paths ibgp 2
exit-address-family

!

Dim16 · ‎06-12-2019

Hi Steven,

which route is in BGP table and not in IP routing table?

All 4 best routes are in ( if I understood your question)

Hector Gustavo Serrano Gutierrez · ‎06-12-2019

You should have the Next Hop IP addresses shown in the BGP table learned via any IGP (EIGRP, OSPF, ISIS) instead of learned via the same iBGP adjacency.

For testing purposes, create a valid Static Route pointing to those Next Hops.

CORE-9500-01#show ip bgp neighbors 10.53.100.1 received-routes
BGP table version is 64, local router ID is 10.10.10.1

    Network 	    Next Hop	 Metric LocPrf Weight Path
* i 10.20.40.0/24   10.53.100.18      0    100      0 i
* i 10.53.100.0/30  10.53.100.1            100      0 ?
* i 10.53.100.8/30  10.53.100.1            100      0 ?
*>i 10.53.100.12/30 10.53.100.10      0    100      0 i
* i 10.53.100.16/30 10.53.100.1            100      0 ?
*>i 10.53.100.20/30 10.53.100.18      0    100      0 i


CORE-9500-01#show ip bgp neighbors 10.53.100.5 received-routes
BGP table version is 64, local router ID is 10.10.10.1

    Network         Next Hop       Metric LocPrf Weight Path
* i 10.20.40.0/24   10.53.100.22        0    100      0 i
* i 10.53.100.4/30  10.53.100.5              100      0 ?
*>i 10.53.100.8/30  10.53.100.14        0    100      0 i
* i 10.53.100.12/30 10.53.100.5              100      0 ?
*>i 10.53.100.16/30 10.53.100.22 	0    100      0 i
* i 10.53.100.20/30 10.53.100.5              100      0 ?

Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 8 subnets, 2 masks
C 10.53.100.0/30 is directly connected, FortyGigabitEthernet1/0/29
L 10.53.100.2/32 is directly connected, FortyGigabitEthernet1/0/29
C 10.53.100.4/30 is directly connected, FortyGigabitEthernet1/0/30
L 10.53.100.6/32 is directly connected, FortyGigabitEthernet1/0/30
B 10.53.100.8/30 [200/0] via 10.53.100.14, 00:36:11
B 10.53.100.12/30 [200/0] via 10.53.100.10, 00:36:11
B 10.53.100.16/30 [200/0] via 10.53.100.22, 00:36:11
B 10.53.100.20/30 [200/0] via 10.53.100.18, 00:36:11
CORE-9500-01#

Steven Williams · ‎06-12-2019

So I am not using an IGP. but there is a default route to physical next hop so shouldnt it use that when it cant get somewhere?

Steven Williams · ‎06-12-2019

CORE-9500-01#
Jun 12 20:50:38.903: %BGP-3-NOTIFICATION_MANY: sent to 2 sessions 6/4 (Administrative Reset) for all peers with AS: 65001 AFI: all VRF: global
Jun 12 20:50:38.903: %BGP-5-ADJCHANGE: neighbor 10.53.100.1 Down User reset
Jun 12 20:50:38.903: %BGP_SESSION-5-ADJCHANGE: neighbor 10.53.100.1 IPv4 Unicast topology base removed from session User reset
Jun 12 20:50:38.903: %BGP-5-ADJCHANGE: neighbor 10.53.100.5 Down User reset
Jun 12 20:50:38.903: %BGP_SESSION-5-ADJCHANGE: neighbor 10.53.100.5 IPv4 Unicast topology base removed from session User reset
Jun 12 20:50:38.903: RT: del 10.53.100.8 via 10.53.100.14, bgp metric [200/0]
Jun 12 20:50:38.903: RT: delete subnet route to 10.53.100.8/30
Jun 12 20:50:38.903: RT: del 10.53.100.12 via 10.53.100.10, bgp metric [200/0]
Jun 12 20:50:38.903: RT: delete subnet route to 10.53.100.12/30
Jun 12 20:50:38.903: RT: del 10.53.100.16 via 10.53.100.22, bgp metric [200/0]
Jun 12 20:50:38.903: RT: delete subnet route to 10.53.100.16/30
Jun 12 20:50:38.903: RT: del 10.53.100.20 via 10.53.100.18, bgp metric [200/0]
Jun 12 20:50:38.904: RT: delete subnet route to 10.53.100.20/30
Jun 12 20:50:39.039: %BGP-5-NBR_RESET: Neighbor 10.53.100.1 active reset (Peer closed the session)
Jun 12 20:50:39.039: %BGP-5-NBR_RESET: Neighbor 10.53.100.5 active reset (Peer closed the session)
Jun 12 20:50:39.039: %BGP_SESSION-5-ADJCHANGE: neighbor 10.53.100.1 IPv4 Unicast topology base removed from session Peer closed the session
Jun 12 20:50:39.039: %BGP_SESSION-5-ADJCHANGE: neighbor 10.53.100.5 IPv4 Unicast topology base removed from session Peer closed the session
Jun 12 20:50:48.257: %BGP-5-NBR_RESET: Neighbor 10.53.100.5 active reset (Peer closed the session)
Jun 12 20:50:48.257: %BGP_SESSION-5-ADJCHANGE: neighbor 10.53.100.5 IPv4 Unicast topology base removed from session Peer closed the session
Jun 12 20:50:50.304: %BGP-5-NBR_RESET: Neighbor 10.53.100.1 active reset (Peer closed the session)
Jun 12 20:50:50.304: %BGP_SESSION-5-ADJCHANGE: neighbor 10.53.100.1 IPv4 Unicast topology base removed from session Peer closed the session
Jun 12 20:50:53.907: %BGP-5-ADJCHANGE: neighbor 10.53.100.5 Up
Jun 12 20:50:53.908: %BGP-5-ADJCHANGE: neighbor 10.53.100.1 Up
Jun 12 20:50:53.909: RT: updating bgp 10.20.40.0/24 (0x0) [local lbl/ctx:1048577/0x0] :
via 10.53.100.22 0 1048577 0x100001

Jun 12 20:50:53.909: RT: add 10.20.40.0/24 via 10.53.100.22, bgp metric [200/0]
Jun 12 20:50:53.909: RT: updating bgp 10.53.100.8/30 (0x0) [local lbl/ctx:1048577/0x0] :
via 10.53.100.14 0 1048577 0x100001

Jun 12 20:50:53.909: RT: add 10.53.100.8/30 via 10.53.100.14, bgp metric [200/0]
Jun 12 20:50:53.909: RT: updating bgp 10.53.100.12/30 (0x0) [local lbl/ctx:1048577/0x0] :
via 10.53.100.5 0 1048577 0x100001

Jun 12 20:50:53.909: RT: add 10.53.100.12/30 via 10.53.100.5, bgp metric [200/0]
Jun 12 20:50:53.909: RT: updating bgp 10.53.100.16/30 (0x0) [local lbl/ctx:1048577/0x0] :
via 10.53.100.22 0 1048577 0x100001

Jun 12 20:50:53.909: RT: add 10.53.100.16/30 via 10.53.100.22, bgp metric [200/0]
Jun 12 20:50:53.909: RT: updating bgp 10.53.100.20/30 (0x0) [local lbl/ctx:1048577/0x0] :
via 10.53.100.5 0 1048577 0x100001

Jun 12 20:50:53.909: RT: add 10.53.100.20/30 via 10.53.100.5, bgp metric [200/0]
Jun 12 20:50:53.911: RT: updating bgp 10.20.40.0/24 (0x0) [local lbl/ctx:1048577/0x0] :
via 10.53.100.18 0 1048577 0x100001
via 10.53.100.22 0 1048577 0x100001

Jun 12 20:50:53.911: RT: closer admin distance for 10.20.40.0, flushing 1 routes
Jun 12 20:50:53.911: RT: add 10.20.40.0/24 via 10.53.100.18, bgp metric [200/0]
Jun 12 20:50:53.911: RT: add 10.20.40.0/24 via 10.53.100.22, bgp metric [200/0]
Jun 12 20:50:53.911: RT: updating bgp 10.53.100.12/30 (0x0) [local lbl/ctx:1048577/0x0] :
via 10.53.100.10 0 1048577 0x100001

Jun 12 20:50:53.911: RT: closer admin distance for 10.53.100.12, flushing 1 routes
Jun 12 20:50:53.912: RT: add 10.53.100.12/30 via 10.53.100.10, bgp metric [200/0]
Jun 12 20:50:53.912: RT: updating bgp 10.53.100.20/30 (0x0) [local lbl/ctx:1048577/0x0] :
via 10.53.100.18 0 1048577 0x100001

Jun 12 20:50:53.912: RT: closer admin distance for 10.53.100.20, flushing 1 routes
Jun 12 20:50:53.912: RT: add 10.53.100.20/30 via 10.53.100.18, bgp metric [200/0]
Jun 12 20:51:23.909: RT: del 10.20.40.0 via 10.53.100.22, bgp metric [200/0]
Jun 12 20:51:23.909: RT: del 10.20.40.0 via 10.53.100.18, bgp metric [200/0]
Jun 12 20:51:23.909: RT: delete subnet route to 10.20.40.0/24

Steven Williams · ‎06-12-2019

why is it deleting 10.20.40.0/24?

Giuseppe Larosa · ‎06-12-2019

Hello Steven,

from the debug output that you have provided you can see that you have race conditions:

without using an IGP your iBGP routes have BGP next-hops learned over other iBGP routes.

This can cause some prefixes to be installed with an iBGP next-hop and later they are deleted, because BGP choices a different BGP next-hop for the next-hop of the affected /deleted prefix.

You understand that there is ambiguity caused by excessive recursion in resolving BGP next hops.

Also some prefixes that contain BGP next hops are advertised by multiple iBGP peers.

I would recommend you to consider again the use of an IGP and iBGP sessions over loopbacks to achieve a stable and deterministic routing environment.

Hope to help

Giuseppe

Steven Williams · ‎06-12-2019

I thought we could use RR for some of these issues? I have read people not using an IGP so what are they doing? Static?

Hector Gustavo Serrano Gutierrez · ‎06-12-2019

It usually depends on the network environment.
You can often find BGP running on the “WAN Routers” to peer with the ISP where it does redistribution to exchange routes between the ISP and the IGP running on the LAN side.
BGP also has an important role inside ISP networks when using MPLS L3 VPN or L2 VPN where all their PEs (Provider Edge Routers) usually peer with the BGP Route Reflectors to avoid the “full mesh” of iBGP sessions requirement.
Also, Data Centers nowadays use BGP EVPN in VXLAN environments to exchange IP & MAC reachability.
In any of those cases, an IGP is usually present and BGP is “on top” of it.
Perhaps you can share more about your use case for this.
I’ve personally never really seen a “BGP-only Core” and I see lots of networks.
Cheers

Steven Williams · ‎06-12-2019

I am basically tired of redistribution and my SDWAN provider only supports BGP or static so saves once again redistributing. I think i will just move to ospf and peer to loopbacks that seems cleaner than statics.

Giuseppe Larosa · ‎06-12-2019

Hello Steven,

once you deploy iBGP with loopbacks and OSPF you don't need anymore to redistribute from eBGP on border routers into OSPF.

Also the reason why an iBGP only environment like the one in your lab is not stable is related to the BGP scanning process.

BGP to achieve the very high scalability it has does not wait for a topology change to occur, it uses a scheduled process called BGP scanning to evaluate every 60 seconds (this is the default timer for address family IPv4 unicast) each BGP prefix and its BGP next-hop.

In your tests some BGP next-hops were resolved by other BGP routes and multiple BGP advertisements could provide the BGP next hop prefix.

So in the process of periodic re-evalution of the BGP table competition for the BGP route can occur and your tests show that this can lead some prefixes to be deleted for excessive recursion.

Hope to help

Giuseppe

Martin L · ‎06-12-2019

so, you have left CLN and came over here ? ...... switched teams?
hehehehehehe

Steven Williams · ‎06-12-2019

I haven't really been active on CLN in a few years. I find the responses here more helpful and to the point.