Intention of the article is to provide debugging steps to check when IBGP neighborship is not getting established.
show bgp summary
Threading mode: BGP I/O
Default eBGP mode: advertise - accept, receive - accept
Groups: 2 Peers: 4 Down peers: 4
Table Tot Paths Act Paths Suppressed History Damp State Pending
bgp.rtarget.0
0 0 0 0 0 0
inet.0
inet.3
bgp.l3vpn.0
bgp.l3vpn-inet6.0
bgp.l2vpn.0
bgp.evpn.0
inet6.0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
192.168.1.2 1***7 0 0 0 0 13:21:34 Active
192.168.2.2 1***7 0 0 0 0 13:21:34 Active
Customer in a MW were migrating their network during which RR configurations were changed and they reported that bgp configurations were not getting established .
Upon checking the configurations noticed that ISIS adjacency were not established and ISIS was configured under the routing-instance
show isis adjacency instance MX_L1
IS-IS instance is not running
Perform the following checks to debug the issue.
show interfaces terse ae1
Interface Admin Link Proto Local Remote
ae1 up up
ae1 up up inet 172.16.1.1
iso 49.0001.0000.0000.0001
ping 172.16.1.2
PING 172.16.1.1 (172.16.1.1): 56 data bytes
64 bytes from 172.16.1.2: icmp_seq=0 ttl=64 time=0.072 ms
64 bytes from 172.16.1.2: icmp_seq=1 ttl=64 time=0.066 ms
^C
--- 172.16.1.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.066/0.069/0.072/0.003 ms
Next check if ISIS configuration is activated or not under the routing-instance . Upon checking the configuration ISIS protocol was deactivated . Activate the configuration . BGP came up after that.
show configuration routing-instances MX_L1
instance-type no-forwarding;
protocols {
inactive: isis {
apply-groups ISIS_L1;
interface ae1.0 {
level 1 {
metric 10;
}
show | compare
[edit routing-instances MX_L1 protocols]
! active: isis { ... }
Dec 13 03:12:13
Interface System L State Hold (secs) SNPA
ae1.0 MX_L2 1 Up 29
192.168.1.2 1***7 0 0 0 0 27 Establ
192.168.2.2 1***7 0 0 0 0 23 Establ