BGP Peering Explored

I had an opportunity to play around with GNS3 briefly today; configured eBGP.  I know a few things about the rules of an eBGP peering relationship from my past reading.  So today I was aiming to validate what I thought I understood.

I configured the following scenario:

Before starting up the BGP protocol and configuring the BGP peers, I configured a default gateway (Gateway of last resort on both sides of this WAN) in the end R1’s loopback 1.1.1.1 was able to ping 2.2.2.2 and vice-versa, all is perfect and well.

I configured everything else above ensuring that my update-source and multihop commands were not forgotten, asserting my self that this would be an easy breezy practice exercise.  When I was finished I went to check the neighbor peering state here is what i got:

R1#show ip bgp summary
BGP router identifier 1.1.1.1, local AS number 100
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   200       0       0        0    0    0 never    Active
R2#show ip bgp summary
BGP router identifier 2.2.2.2, local AS number 200
BGP table version is 1, main routing table version 1

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
1.1.1.1         4   100       0       0        0    0    0 never    Active

Nooo! No cigar… there is IP connectivity, so what are we missing? Well… I know that an exact route must be in place for a route to be advertised, so I inferred that adding specific routes on both sides should do the trick.  So i went to add a static route for 2.2.2.2 on R1 first… to my surprise, setting up one side did the trick.  Here is what I saw:

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.1.1.2
R1(config)#
*Mar  1 00:20:36.119: %BGP-5-ADJCHANGE: neighbor 2.2.2.2 Up
R1(config)#end
R1#show ip bgp
*Mar  1 00:20:43.955: %SYS-5-CONFIG_I: Configured from console by console
R1#show ip bgp summ
R1#show ip bgp summary
BGP router identifier 1.1.1.1, local AS number 100
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   200       4       4        1    0    0 00:00:10        0

The bgp debugs on the other side confirm the handshake was successful:

R2#debug ip bgp

BGP debugging is on for address family: IPv4 Unicast
R2#
*Mar  1 00:20:35.803: BGP: 1.1.1.1 passive open to 2.2.2.2
*Mar  1 00:20:35.807: BGP: 1.1.1.1 went from Active to Idle
*Mar  1 00:20:35.807: BGP: 1.1.1.1 went from Idle to Connect
*Mar  1 00:20:35.819: BGP: 1.1.1.1 rcv message type 1, length (excl. header) 26
*Mar  1 00:20:35.819: BGP: 1.1.1.1 rcv OPEN, version 4, holdtime 180 seconds
*Mar  1 00:20:35.819: BGP: 1.1.1.1 went from Connect to OpenSent
*Mar  1 00:20:35.819: BGP: 1.1.1.1 sending OPEN, version 4, my as: 200, holdtime 180 seconds
*Mar  1 00:20:35.823: BGP: 1.1.1.1 rcv OPEN w/ OPTION parameter len: 16
*Mar  1 00:20:35.823: BGP: 1.1.1.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 6
*Mar  1 00:20:35.823: BGP: 1.1.1.1 OPEN has CAPABILITY code: 1, length 4
*Mar  1 00:20:35.823: BGP: 1.1.1.1 OPEN has MP_EXT CAP for afi/safi: 1/1
*Mar  1 00:20:35.823: BGP: 1.1.1.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Mar  1 00:20:35.827: BGP: 1.1.1.1 OPEN has CAPABILITY code: 128, length 0
*Mar  1 00:20:35.827: BGP: 1.1.1.1 OPEN has ROUTE-REFRESH capability(old) for all address-families
*Mar  1 00:20:35.827: BGP: 1.1.1.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 2
*Mar  1 00:20:35.827: BGP: 1.1.1.1 OPEN has CAPABILITY code: 2, length 0
*Mar  1 00:20:35.827: BGP: 1.1.1.1 OPEN has ROUTE-REFRESH capability(new) for all address-families
BGP: 1.1.1.1 rcvd OPEN w/ remote AS 100
*Mar  1 00:20:35.831: BGP: 1.1.1.1 went from OpenSent to OpenConfirm
*Mar  1 00:20:35.831: BGP: 1.1.1.1 send message type 1, length (incl. header) 45
*Mar  1 00:20:35.867: BGP: 1.1.1.1 went from OpenConfirm to Established
*Mar  1 00:20:35.867: %BGP-5-ADJCHANGE: neighbor 1.1.1.1 Up

Interesting.  So you do not need to have exact routes in the routing table on both sides.  Oddly enough, you don’t even need to have the static routes in place after the TCP handshake is completed and the session is established.

R1(config)#no ip route 2.2.2.2 255.255.255.255 10.1.1.2
R1(config)#show ip route
             ^
% Invalid input detected at '^' marker.

R1(config)#do show ip route
Codes: 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

Gateway of last resort is 10.1.1.2 to network 0.0.0.0

     1.0.0.0/32 is subnetted, 1 subnets
C       1.1.1.1 is directly connected, Loopback0
     10.0.0.0/30 is subnetted, 1 subnets
C       10.1.1.0 is directly connected, Serial0/0
S*   0.0.0.0/0 [1/0] via 10.1.1.2

R1(config)#do show tcp brief
TCB       Local Address               Foreign Address             (state)
64C9C5B0  1.1.1.1.26251               2.2.2.2.179                 ESTAB

I set the the protocol to 2 second keepalives just to be double sure – and sure enough it stayed up.

R1(config-router)#timers bgp 2 20
R1(config-router)#end
R1#
*Mar  1 00:28:30.899: %SYS-5-CONFIG_I: Configured from console by console
R1#show ip bgp summ
R1#show ip bgp summary
BGP router identifier 1.1.1.1, local AS number 100
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   200      12      12        1    0    0 00:08:01        0

R1#show ip bgp neighbors
BGP neighbor is 2.2.2.2,  remote AS 200, external link
  BGP version 4, remote router ID 2.2.2.2
  BGP state = Established, up for 00:08:22
  Last read 00:00:21, last write 00:00:21, hold time is 180, keepalive interval is 60 seconds
  Configured hold time is 20,keepalive interval is 2 seconds, Minimum holdtime from neighbor is 0 seconds
  Neighbor capabilities:
    Route refresh: advertised and received(old & new)
    Address family IPv4 Unicast: advertised and received
  Message statistics:
    InQ depth is 0
    OutQ depth is 0
                         Sent       Rcvd
    Opens:                  1          1
    Notifications:          0          0
    Updates:                0          0
    Keepalives:            11         11
    Route Refresh:          0          0
    Total:                 12         12

Lessons learned:
Lesson learned #1 – BGP peering requires a specific route (from the specific source initiating the TCP handshake) simply having IP connectivity or a gateway of  last resort is not sufficient for the neighbor peering to establish.  It only requires it on the side initiating the handshake, the replying device can have only a default route.
Lesson learned #2 – BGP peering does not require a specific route once the TCP session is established, that means the requirement for a specific route in the table doesn’t exist so long as the TCP session is established.
Lesson learned #3 – BGP bite you in the rear if you’re not patient and careful!

That’s all for today peeps.  Good fight and good nite!

Gabe @ networkdojo.net

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s