Van a BGP-nek egy kevésbé ismert tulajdonsága amely “Peter Palúch – Troubleshooting BGP” Ciscolive! előadásában jött velem szembe.
A topológia végtelenül egyszerű: két router egy linken összekötve, mindkettőn egy-egy Loopback interface és alap BGP konfiguráció.
---- R1 ---- conf t hostname R1 no ip domain-lookup int f0/0 ip add 10.0.12.1 255.255.255.0 no shut int Lo0 ip add 1.1.1.1 255.255.255.255 router bgp 12 neighbor 2.2.2.2 remote-as 21 neighbor 2.2.2.2 up lo0 neighbor 2.2.2.2 ebgp-multihop exit ip route 0.0.0.0 0.0.0.0 10.0.12.2 end
---- R2 ---- conf t hostname R2 no ip domain-lookup int f0/0 ip add 10.0.12.2 255.255.255.0 no shut int Lo0 ip add 2.2.2.2 255.255.255.255 router bgp 21 neighbor 1.1.1.1 remote-as 12 neighbor 1.1.1.1 up lo0 neighbor 1.1.1.1 ebgp-multihop exit ip route 0.0.0.0 0.0.0.0 10.0.12.1 end
A kapcsolat a két router között rendben működik, a Loopback interface-k is elérik egymást (a default route miatt).
A Wireshark logban mégis az látszik hogy nincs BGP OPEN Sent üzenet, azaz nem is próbálja kiépíteni a neighborship-et, mindkét oldal “Active” státuszban marad.
R1#ping 10.0.12.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.12.2, timeout is 2 seconds: .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 4/30/56 ms R1# R1# R1#ping 2.2.2.2 so lo0 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds: Packet sent with a source address of 1.1.1.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 12/17/20 ms R1# R1#sh ip bgp s BGP router identifier 1.1.1.1, local AS number 12 BGP table version is 1, main routing table version 1 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 2.2.2.2 4 21 0 0 0 0 0 never Active R1#
Ha bekapcsoljuk a BGP debug-ot akkor már sejthető a probléma oka:
R1#debug ip bgp
BGP debugging is on for address family: IPv4 Unicast
R1#
*Mar 1 00:09:10.843: BGP: 2.2.2.2 active open failed - no route to peer, open active delayed 28326ms (35000ms max, 28% jitter)
R1#
A dokumentációban az alábbi megjegyzést találjuk:
To prevent the creation of loops through oscillating routes, the multihop will not be established if the only route to the multihop peer is the default route (0.0.0.0).
Nézzük mi történik ha more specific route-t ütök be R1-en:
R1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R1(config)#ip route 2.2.2.2 255.255.255.255 10.0.12.2
R1(config)#
Hopp…
R1(config)# *Mar 1 00:11:27.695: BGP: 2.2.2.2 open active, local address 1.1.1.1 *Mar 1 00:11:27.719: BGP: 2.2.2.2 went from Active to OpenSent *Mar 1 00:11:27.723: BGP: 2.2.2.2 sending OPEN, version 4, my as: 12, holdtime 180 seconds *Mar 1 00:11:27.723: BGP: 2.2.2.2 send message type 1, length (incl. header) 45 *Mar 1 00:11:27.751: BGP: 2.2.2.2 rcv message type 1, length (excl. header) 26 *Mar 1 00:11:27.755: BGP: 2.2.2.2 rcv OPEN, version 4, holdtime 180 seconds *Mar 1 00:11:27.755: BGP: 2.2.2.2 rcv OPEN w/ OPTION parameter len: 16 *Mar 1 00:11:27.755: BGP: 2.2.2.2 rcvd OPEN w/ optional parameter type 2 (Capability) len 6 *Mar 1 00:11:27.755: BGP: 2.2.2.2 OPEN has CAPABILITY code: 1, length 4 *Mar 1 00:11:27.755: BGP: 2.2.2.2 OPEN has MP_EXT CAP for afi/safi: 1/1 *Mar 1 00:11:27.759: BGP: 2.2.2.2 rcvd OPEN w/ optional parameter type 2 (Capability) len 2 *Mar 1 00:11:27.759: BGP: 2.2.2.2 OPEN has CAPABILITY code: 128, length 0 *Mar 1 00:11:27.759: BGP: 2.2.2.2 OPEN has ROUTE-REFRESH capability(old) for all address-families *Mar 1 00:11:27.759: BGP: 2.2.2.2 rcvd OPEN w/ optional parameter type 2 (Capability) len 2 *Mar 1 00:11:27.759: BGP: 2.2.2.2 OPEN has CAPABILITY code: 2, length 0 *Mar 1 00:11:27.759: BGP: 2.2.2.2 OPEN has ROUTE-REFRESH capability(new) for all address-families BGP: 2.2.2.2 rcvd OPEN w/ remote AS 21 *Mar 1 00:11:27.759: BGP: 2.2.2.2 went from OpenSent to OpenConfirm *Mar 1 00:11:27.767: BGP: 2.2.2.2 went from OpenConfirm to Established *Mar 1 00:11:27.767: %BGP-5-ADJCHANGE: neighbor 2.2.2.2 Up
R1#sh ip bgp s
BGP router identifier 1.1.1.1, local AS number 12
BGP table version is 1, main routing table version 1
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
2.2.2.2 4 21 11 11 1 0 0 00:05:47 0
R1#
Nem gyakran találkozik szembe az ember ilyen esettel, de most már mindannyian megjegyeztük hogy az eBGP neighborship nem épül ki default route felett. Ez egyébként igaz iBGP-re is: ha R1-R2 egy AS-be kerül és a Loopback címek csak a default route miatt érhetőek el, akkor szintén nem áll össze a BGP.
