EBGP Neighborship

[Manu Shankar]

Hi All, this is sample config done in GNS3 with 2 routers.

R1 & R2 are connected each others by their Ser 1/0 interface. R1 is in AS 100 and R2 is in AS 200.

****** R1 Config ******

interface Serial1/0

ip address 100.1.1.1 255.255.255.252

serial restart-delay 0

!

!

router bgp 100

no synchronization

bgp log-neighbor-changes

neighbor 2.2.2.2 remote-as 200

neighbor 2.2.2.2 ebgp-multihop 255

no auto-summary

!

!

ip route 2.2.2.2 255.255.255.255 100.1.1.2

****** R2 Config ******

interface Serial1/0

ip address 100.1.1.2 255.255.255.252

serial restart-delay 0

!

!

router bgp 200

no synchronization

bgp log-neighbor-changes

neighbor 1.1.1.1 remote-as 100

neighbor 1.1.1.1 ebgp-multihop 2

no auto-summary

!

!

ip route 1.1.1.1 255.255.255.255 100.1.1.1

With the above config both the neigbhors were in "active" state.

As Soon as I entered the command "neighbor 1.1.1.1 update-source Loopback0" on R2 the nieghbors are established.

I am not configured R1 with "update-source" command. Here my doubt is without configuring the above command on R1, how the neighborship established ?

Thanks,

Manu

[smitesh kharecha · Accepted solution]

Hi Manu,

Remember BGP works on underlying TCP.

When you added update-source on any one of the routers, it send another router TCP packets with Source IP, inn your case Lo0.

When another routers gets that packet (Hello), It replies to the same packet, but with SIP and DIP changes to DIP and SIP; and hence neighbourship gets established.

But remember, in your particular case, it will be always initiated by R2 and not by R1.

HTH,

Smitesh

[cadet alain · Accepted solution]

Hi,

BGP is TCP based client/server application and it won't form a peering with a neighbour IP which it hasn't got in its config.

you were doing the eBGP peering with Loopbacks so the server side is waiting for a BGP  SYN packet with with a src IP of the loopback and if you enable the update-source command then it will and the server side will accept the packets and establish a peering.

Regards.

Alain

[Manu Shankar]

Hi,

Thanks Smitesh & Cadet for the prompt reply. I am cleared now. Yes Smitesh you are correct it was initiated by R2 .

Thanks again..Manu

[panditvinayak]

Hi All,

Smitesh here was Right.

A small summary on how it actually works.

There is a BGP Collision Detect Mechanism, which says if  " When Two BGP peers try to establish an EBGP session with each other at the same time, then the BGP router with lower BGP router ID will tear down its session and the BGP router with the Higher BGP router ID will again initiate the connection"

The BGP router with Higher router ID is called the Client and The BGP router with lower BGP router ID is called the server.

So the client will initiate an EBGP session with the server on port (destination) 179 with a SYN packet, the server will approve the connection and then send an ACK for the SYN packet to the client on some HIGHER port no. other than 179.

Hence when R2 sends a SYN packet to R1, R1 sees the source and destination of the packet, verifies it and then reply accordingly.

If R2 DOES NOT use update-source Loopback 0 :

then it will take the source as its exit interface IP (100.1.1.2) and destination as what is configured on the neighbor command (1.1.1.1).

When it comes to R1, R1 now needs to send an ACK to R2, however it FIRST checks the SIP and DIP of the connection, verifies it and then sends an ACK. When the SYN packet is received on R1 the SIP is 100.1.1.2 and DIP is 1.1.1.1 hence now the ACK will have a DIP as 100.1.1.2 and SIP as 1.1.1.1 but the DESTINATION that is configured on R1 in the BGP neighbor command is 2.2.2.2 Hence the verification fails and the server R1 does not authorize the connection.

If R2 uses update-source Loopback 0 :

then it will take the source as its Loopback 0 IP (2.2.2.2) and destination as what is configured on the neighbor command (1.1.1.1).

When it comes to R1, R1 now needs to send an ACK to R2, however it FIRST checks the SIP and DIP of the connection, verifies it and then sends an ACK. When the SYN packet is received on R1 the SIP is 2.2.2.2 and DIP is 1.1.1.1 hence now the ACK will have a DIP as 2.2.2.2 and SIP as 1.1.1.1, Here the DESTINATION that is configured on R1 in the neighbor command is 2.2.2.2 which matches the DIP of the ACK to be sent (2.2.2.2), verification is SUCCESSFUL and the ACK is sent to R2 with DIP as 2.2.2.2 and SIP as 1.1.1.1

Server (lower router ID) always verifies the BGP TCP connection and Client (higher router ID) always initiates the connection hence the update-source command is needed only on CLIENT when we use IP address in BGP Neighbor command other than connecting interface to form an EBGP connection.

Hope I did not Bug you all

Regards,

Vinayak Pandit

[Manu Shankar]

Hi Vinayak & All,

When I configured R2 with the command "neighbor 1.1.1.1 update-source lo 0"

R1#sh tcp brief

TCB       Local Address               Foreign Address             (state)

65071534  1.1.1.1.179                 2.2.2.2.61334               ESTAB

R2#sh tcp brief

TCB       Local Address               Foreign Address             (state)

65078A58  2.2.2.2.61334               1.1.1.1.179                 ESTAB

The BGP router with Higher router ID is called the Client and with lower BGP router ID is called the server.

So, R2 (2.2.2.2) is the client and R1 (1.1.1.1) is the server. As you said client will always initaite the EBGP session with server on port 179.

So R2 should initiate the EBGP session with R1 on port 179. as per the above result R1 is initiating the EBGP session. Please correct me if i am wrong.

**************************************************************************

When I configured R1 with the command "neighbor 2.2.2.2 update-source lo 0"  and removed the command

"neighbor 1.1.1.1 update-source lo 0"  from R2 and cleared the BGP session. The result shows below..

R1#sh tcp brie

TCB       Local Address               Foreign Address             (state)

66661914  1.1.1.1.62207               2.2.2.2.179                 ESTAB

R2#sh tcp brief

TCB       Local Address               Foreign Address             (state)

65078A58  2.2.2.2.179                 1.1.1.1.62207               ESTAB

**************************************************************************

I thinks peers are not tearing down the connection when it recieving a SYN. And is there benefit for a router to become a server ?

Thanks you all for your participation in this discussion... Manu

[smitesh kharecha]

Manu Shankar wrote:
Hi Vinayak & All, 
When I configured R2 with the command "neighbor 1.1.1.1 update-source lo 0" 
R1#sh tcp brief
TCB       Local Address               Foreign Address             (state)
65071534  1.1.1.1.179                 2.2.2.2.61334               ESTAB
R2#sh tcp brief
TCB       Local Address               Foreign Address             (state)
65078A58  2.2.2.2.61334               1.1.1.1.179                 ESTAB
The BGP router with Higher router ID is called the Client and with lower BGP router ID is called the server.
So, R2 (2.2.2.2) is the client and R1 (1.1.1.1) is the server. As you said client will always initaite the EBGP session with server on port 179. 
So R2 should initiate the EBGP session with R1 on port 179. as per the above result R1 is initiating the EBGP session. Please correct me if i am wrong. 

Hi Manu,

You are misreading the output.

Here R1 is Server, as can be seen from the port number 179 and also R2 has got some random port number.

In Client/Server model, when Client initiates the connection, it initiates the service on particular port pertaining to that service ( in our case 179).

In other words, Like SIP and DIP, It also set Source Port and Destination Port.

Here, when Client initiates the session, it sends request to DIP on Destination Port 179 and for himself he take any random port.

HTH,

Smitesh

[Manu Shankar]

Hi Smitesh,

As always thanks for the prompt reply. What I understand is R2 (client) sending the request on port 179 of R1 (server). Am I correct ?

Thanks,

Manu

[smitesh kharecha]

Hi Manu,

yes, your are correct.

But for better explaination, I will go a bit more forward.

When you have confirured update-source on R2, Both R1 and R2 will try to initiate the session; however When TCP packet from R1 comes to R2 (Which does have IP address of exist interface) it doesn't matches with neighbour IP address configured on R2, and hence it drops the session.

However, the TCP packet sent by R2 has got IP address of loopback interface in its TCP packet, which matches with the neighbour IP address configured on R1, it initiates the session.

Since, request was sent by R2; it becomes client and R1 becomes the server.

So, TCP packet sent by R2 will be have  SIP of R2's loopback and DIP as configured on R2 of neigbour IP address. Only it would sent packet to neighbour IP address on port 179 and for its source port will select any random port.

When R1 replies to th packet, it will sent to R2's IP address as configured on R1's BGP config with Destination Port 179  and will select it own Source port as any random port.

HTH,

Smitesh

[Manu Shankar]

Hi Smitesh,

Thank you for time, patience and detailed explanation. If you don't mind one last question.

As you said, "Since, request was sent by R2; it becomes client and R1 becomes the server." Serevr client election is based on highest ip address or based on who have initiated the session ?

Thanks,

Manu

[panditvinayak]

Hi Manu and Smitesh,

BGP TCP connection will always be initiated by the Router with highest Router ID in your case it is R2 and thus become the CLIENT

The Router with lower BGP router ID will become the Server and will authorize the connection coming in and send an ACK in response to the SYN sent by CLient (R2).

Hence it is MANDATORY to use update-source Loopback x Only on the CLIENT if the BGP connection is sourced from an IP which is other than the exit interface and the Loopback x has to be the IP which is configured as Neighbor x on the server for the Server to authrorize the connection.

Even if WE have update-source command configured on R1 still the BGP TCP connection will be initiated by R2 as it has the Higher BGP router ID.

Regards,

Vinayak

[Manu Shankar]

Hi Smitesh & Vinayak,

When I configured R1 with the command "neighbor 2.2.2.2 update-source lo 0"  and removed the command

"neighbor 1.1.1.1 update-source lo 0"  from R2 and cleared the BGP session. The result shows below..

R1#sh tcp brie

TCB       Local Address               Foreign Address             (state)

66661914  1.1.1.1.62207               2.2.2.2.179                 ESTAB

R2#sh tcp brief

TCB       Local Address               Foreign Address             (state)

65078A58  2.2.2.2.179                 1.1.1.1.62207               ESTAB

Here is the output of debug command on both routers.

R1(config-router)#neighbor 2.2.2.2 update-source loopback 0

R1(config-router)#

*Dec 23 12:43:16.531: BGP: 2.2.2.2 open active, local address 1.1.1.1

*Dec 23 12:43:16.611: BGP: 2.2.2.2 read request no-op

*Dec 23 12:43:16.619: BGP: 2.2.2.2 went from Active to OpenSent

*Dec 23 12:43:16.623: BGP: 2.2.2.2 sending OPEN, version 4, my as: 100, holdtime 180 seconds

*Dec 23 12:43:16.631: BGP: 2.2.2.2 send message type 1, length (incl. header) 45

*Dec 23 12:43:16.699: BGP: 2.2.2.2 rcv message type 1, length (excl. header) 26

*Dec 23 12:43:16.703: BGP: 2.2.2.2 rcv OPEN, version 4, holdtime 180 seconds

*Dec 23 12:43:16.703: BGP: 2.2.2.2 rcv OPEN w/ OPTION parameter len: 16

*Dec 23 12:43:16.703: BGP: 2.2.2.2 rcvd OPEN w/ optional parameter type 2 (Capability) len 6

*Dec 23 12:43:16.707: BGP: 2.2.2.2 OPEN has CAPABILITY code: 1, length 4

*Dec 23 12:43:16.707: BGP: 2.2.2.2 OPEN has MP_EXT CAP for afi/safi: 1/1

*Dec 23 12:43:16.707: BGP: 2.2.2.2 rcvd OPEN w/ optional parameter type 2 (Capability) len 2

*Dec 23 12:43:16.707: BGP: 2.2.2.2 OPEN has CAPABILITY code: 128, length 0

*Dec 23 12:43:16.707: BGP: 2.2.2.2 OPEN has ROUTE-REFRESH capability(old) for all address-families

*Dec 23 12:43:16.707: BGP: 2.2.2.2 rcvd OPEN w/ optional parameter type 2 (Capability) len 2

*Dec 23 12:43:16.707: BGP: 2.2.2.2 OPEN has CAPABILITY code: 2, length 0

*Dec 23 12:43:16.707: 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 200

*Dec 23 12:43:16.707: BGP: 2.2.2.2 went from OpenSent to OpenConfirm

*Dec 23 12:43:16.707: BGP: 2.2.2.2 went from OpenConfirm to Established

*Dec 23 12:43:16.707: %BGP-5-ADJCHANGE: neighbor 2.2.2.2 Up

**********************************************************************************************************************

R2#debug ip bgp all

BGP debugging is on for all address families

*Dec 23 12:42:49.359: BGP: 1.1.1.1 went from Idle to Active

*Dec 23 12:42:49.367: BGP: 1.1.1.1 open active, local address 100.1.1.2

*Dec 23 12:42:49.471: BGP: 1.1.1.1 read request no-op

*Dec 23 12:42:49.479: BGP: 1.1.1.1 open failed: Connection refused by remote host, open active delayed 2981ms (5000ms max, 90% jitter)

*Dec 23 12:42:52.463: BGP: 1.1.1.1 open active, local address 100.1.1.2

*Dec 23 12:42:52.599: BGP: 1.1.1.1 read request no-op

*Dec 23 12:42:52.607: BGP: 1.1.1.1 open failed: Connection refused by remote host, open active delayed 7371ms (10000ms max, 60% jitter)

*Dec 23 12:42:59.979: BGP: 1.1.1.1 open active, local address 100.1.1.2

*Dec 23 12:43:00.047: BGP: 1.1.1.1 read request no-op

*Dec 23 12:43:00.059: BGP: 1.1.1.1 open failed: Connection refused by remote host, open active delayed 18068ms (20000ms max, 60% jitter)

*Dec 23 12:43:16.995: BGP: 1.1.1.1 passive open to 2.2.2.2

*Dec 23 12:43:16.999: BGP: 1.1.1.1 went from Active to Idle

*Dec 23 12:43:17.003: BGP: 1.1.1.1 went from Idle to Connect

*Dec 23 12:43:17.031: BGP: 1.1.1.1 rcv message type 1, length (excl. header) 26

*Dec 23 12:43:17.035: BGP: 1.1.1.1 rcv OPEN, version 4, holdtime 180 seconds

*Dec 23 12:43:17.039: BGP: 1.1.1.1 went from Connect to OpenSent

*Dec 23 12:43:17.039: BGP: 1.1.1.1 sending OPEN, version 4, my as: 200, holdtime 180 seconds

*Dec 23 12:43:17.043: BGP: 1.1.1.1 rcv OPEN w/ OPTION parameter len: 16

*Dec 23 12:43:17.043: BGP: 1.1.1.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 6

*Dec 23 12:43:17.047: BGP: 1.1.1.1 OPEN has CAPABILITY code: 1, length 4

*Dec 23 12:43:17.047: BGP: 1.1.1.1 OPEN has MP_EXT CAP for afi/safi: 1/1

*Dec 23 12:43:17.047: BGP: 1.1.1.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 2

*Dec 23 12:43:17.047: BGP: 1.1.1.1 OPEN has CAPABILITY code: 128, length 0

*Dec 23 12:43:17.047: BGP: 1.1.1.1 OPEN has ROUTE-REFRESH capability(old) for all address-families

*Dec 23 12:43:17.047: BGP: 1.1.1.1 rcvd OPEN w/ optional parameter type 2 (Capability) len 2

*Dec 23 12:43:17.047: BGP: 1.1.1.1 OPEN has CAPABILITY code: 2, length 0

*Dec 23 12:43:17.047: 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

*Dec 23 12:43:17.047: BGP: 1.1.1.1 went from OpenSent to OpenConfirm

*Dec 23 12:43:17.047: BGP: 1.1.1.1 send message type 1, length (incl. header) 45

*Dec 23 12:43:17.075: BGP: 1.1.1.1 went from OpenConfirm to Established

*Dec 23 12:43:17.079: %BGP-5-ADJCHANGE: neighbor 1.1.1.1 Up

As per the above output R1 initited the session at "Dec 23 12:43:16.619" and R2 recieved it at "Dec 23 12:43:17.031" on port 179.  And R1 becomes the client and R2 becomes the server. 

As Vinayak said, "The Router with lower BGP router ID will become the Server". Here the rule got changed. Please correct me if I am wrong.

Thanks,

Manu

[smitesh kharecha]

Hi Manu & Vinu,

If Highest router-id will come into the picture onl when both are configured correctly, i.e Update-source on both end.

As also said by Vinayak, If both tries to initiate the session, Router with lowest IP will drop the session and with the highest will start the session.

However, In our scenario, it is bit different. R2 becomes the Client not only of the fact that it has got the higher router-id, but also because it has got update-source configured which matches with neighbour IP configured on R1.

Even, if for the moment if we forget that Higher Router-ID becomes clien; imagine this If R1 tries to initiate the session; its TCP packet will reach R2 with DIP of 2.2.2.2; however SIP of that will be of R1's exit interface. Which will not match the neighbour IP configured on R2 and hence neighbourship will not be formed.

At the same time if the TCP packet sent by R2 will be having DIP of 1.1.1.1 and SIP of loopback configured on R2; which will match neighbour IP configured on R1. Hence session initiation starts.

Since, R2 has sent the request, it will be client and R1 will be the Server.

PS: Vinayak, I beg to differ on your input where you quoted that it is MANDATORY to use update-source loopback x only on client. If if you use update-source on R1 (Server in this case); session will be established and it will be R1 who would have initiated the session.

Try it and let me know

HTH,

Smitesh

[panditvinayak]

Hi Smitesh,

I might be wrong here, but the fact that update-source decides who the client will be is also not correct.

I have been into CISCO DOCS and other IETF docs for BGP and they had mentioned that ONE OF THE REASONS for BGP client to be selected is based on HIGHER BGP Router ID and thus it sources the BGP TCP connection from any higher port no. to the port no 179 on the server.

I did not say that the ROUTER with higher Router BGP ID should have "mandatory" update-source command, rather I MEANT TO SAY " BGP Router who is the client and initiates a BGP TCP connection" is mandatory to have update-source command and the server will thus authorize the connection.

"NOW" Which router will become the CLIENT and the Server has many indepth reasons one of which I mentioned to be the Higher router ID. Update-source does not determine who the client will be, rather, we should decide to put this command on the CLIENT and as said which router will become the client needs an indepth inspection... there is also a condition where we tear down a BGP session by issuing the command "clear ip bgp soft in out" and thus the client and server election changes, thus we always use update-source on both BGP routers to avoid this HAVOC.

Again, I maintain my words, that " update-source command is mandatory for the CLIENT when we source TCP session other than the exit interface, which Router becomes the client in the neighborship is still a suspense and requires in depth investigation with higher router ID being one of the election criteria as per BGP COLLISION DETECTION mechanism.

Thanks,

Vinayak

[panditvinayak]

Some Highlight on The RFC for BGP // Does not give any reference to Update-source Usage and Decision //

RFC 4271 – A Border Gateway Protocol 4 (BGP-4)

6.8.  BGP Connection Collision Detection
   If a pair of BGP speakers try to establish a BGP connection with each
   other simultaneously, then two parallel connections well be formed.
   If the source IP address used by one of these connections is the same
   as the destination IP address used by the other, and the destination
   IP address used by the first connection is the same as the source IP
   address used by the other, connection collision has occurred.  In the
   event of connection collision, one of the connections MUST be closed.
   Based on the value of the BGP Identifier, a convention is established
   for detecting which BGP connection is to be preserved when a
   collision occurs.  The convention is to compare the BGP Identifiers
   of the peers involved in the collision and to retain only the
   connection initiated by the BGP speaker with the higher-valued BGP
   Identifier.
   Upon receipt of an OPEN message, the local system MUST examine all of
   its connections that are in the OpenConfirm state.  A BGP speaker MAY
   also examine connections in an OpenSent state if it knows the BGP
   Identifier of the peer by means outside of the protocol.  If, among
   these connections, there is a connection to a remote BGP speaker whose BGP Identifier equals the one in the OPEN message, and this
   connection collides with the connection over which the OPEN message
   is received, then the local system performs the following collision
   resolution procedure:
      1) The BGP Identifier of the local system is compared to the BGP
         Identifier of the remote system (as specified in the OPEN
         message).  Comparing BGP Identifiers is done by converting them
         to host byte order and treating them as 4-octet unsigned
         integers.
      2) If the value of the local BGP Identifier is less than the
         remote one, the local system closes the BGP connection that
         already exists (the one that is already in the OpenConfirm
         state), and accepts the BGP connection initiated by the remote
         system.
      3) Otherwise, the local system closes the newly created BGP
         connection (the one associated with the newly received OPEN
         message), and continues to use the existing one (the one that
         is already in the OpenConfirm state).
   Unless allowed via configuration, a connection collision with an
   existing BGP connection that is in the Established state causes
   closing of the newly created connection.
   Note that a connection collision cannot be detected with connections
   that are in Idle, Connect, or Active states.
   Closing the BGP connection (that results from the collision
   resolution procedure) is accomplished by sending the NOTIFICATION
   message with the Error Code Cease.