Monday, December 13, 2010

BGP Client-Server Communication - How Does It Work ?

I am sure these days most of CCNP or CCNP+ people knows that BGP is technically an APPLICATION not a routing protocol which runs on top of TCP. As an application it can carry many sorts of information inside with IPv4 prefixes being one among them.


Also in past we discussed here about another important fact that BGP is a CLIENT-SERVER designed based application. Now important question comes in mind is - How do we determine which side is SERVER and which side is CLIENT.


Lets try to figure it out and see how things work:


Here is the quick topology we are going to use:






So lets do the basic configuration before we dig deeper. In first case we will establish EBGP Peering Between R1 & R2 over Serial0/0 interface on both sides.


===========================================


^^^ R1 ^^^
#########



R1(config)#int lo0
R1(config-if)#ip add 11.11.11.11 255.255.255.255
R1(config-if)#exit
R1(config)#int s0/0
R1(config-if)#ip add 12.12.12.1 255.255.255.0
R1(config-if)#no sh
R1(config-if)#exit
R1(config)#int s0/1
R1(config-if)#ip add 112.112.112.1 255.255.255.0
R1(config-if)#no sh
R1(config-if)#exit
R1(config)#router bgp 1
R1(config-router)#no au
R1(config-router)#no sync
R1(config-router)#nei 12.12.12.2 remote-as 2
R1(config-router)#net 11.11.11.11 mask 255.255.255.255
R1(config-router)#exit



^^^ R2 ^^^
#########

R2(config)#int lo0
R2(config-if)#ip add 22.22.22.22 255.255.255.255
R2(config-if)#exit
R2(config)#int s0/0
R2(config-if)#ip add 12.12.12.2 255.255.255.0
R2(config-if)#no sh
R2(config-if)#exit
R2(config)#int s0/1
R2(config-if)#ip add 112.112.112.2 255.255.255.0
R2(config-if)#no sh
R2(config-if)#exit
R2(config)#router bgp 2
R2(config-router)#no au
R2(config-router)#no sync
R2(config-router)#nei 12.12.12.1 remote-as 1
R2(config-router)#net 22.22.22.22 mask 255.255.255.255
R2(config-router)#exit
===========================================



$$$ <- Verification -> $$$
####################





R1#sh ip bgp summ | b N 
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
12.12.12.2      4     2       8       8        3    0    0 00:01:08                                1


R2#sh ip bgp summary | b N
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
12.12.12.1      4     1       5       5        3    0    0 00:01:30                                 1


R1#ping 22.22.22.22 so lo0


Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 22.22.22.22, timeout is 2 seconds:
Packet sent with a source address of 11.11.11.11 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/11/20 ms

So far everything looks good. Our peering is up and we are able to exchange prefixes just fine.
===========================================
Now next step is to verify which side is server and which side is client and does being SERVER vs being CLIENT affects something.


From the RFC point of view, the side with higher RID will be "CLIENT" and router with lower RID (Router ID) will be chosen as "SERVER". It's going to be the CLIENT which will initiate connection towards SERVER from some random source port towards destination TCP port 179.

This is a very important piece of information in case there is any device in middle of two BGP speakers blocking traffic like firewall, proxy etc. In such case you know now in which direction you need to open which ports.

But as far real world is concerned :-)



things might behave little different. Actually the fact I explained above only comes into play when both BGP speaker start talking to each other at same time in first place. If one BGP speaker is already up and you bring another BGP speaker up in later, in such case things may be seen as opposite.

So It's important to figure out which side is SERVER & which one is CLIENT.

Ummm.... Actually it's simple. There are many IOS command to figure it out but one being my favorite one is " show tcp brief ". What are the other ones ? .... hehehe :-) go figure

R1#sh tcp brief   
TCB                Local Address                  Foreign Address              (state)
64AF469C      12.12.12.1.51473               12.12.12.2.179              ESTAB

R2#sh tcp brief
TCB                Local Address           Foreign Address        (state)
64AF406C      12.12.12.2.179          12.12.12.1.51473       ESTAB

So looking at the output for R1 you can see that R1 is initiating a TCP session with source IP as 12.12.12.1 with source port as 51473 with destination IP as 12.12.12.2 with destination port as 179.

This very much tells us that R1 is the CLIENT here and R2 is the SERVER. It also support the other fact I mentioned above that it's not always necessary that the device with higher RID will be client and initiator of the connection.

R1#sh ip bgp | i ID
BGP table version is 3, local router ID is 11.11.11.11

R2#sh ip bgp | i ID
BGP table version is 7, local router ID is 22.22.22.22

Also one more important piece of information I would like to mention here is that in BGP it's only the SERVER side which need to receive BGP connection from the valid source matching it's local NEIGHBOR statement. For CLIENT side it is not necessary.

Lets try to verify if this is true:

R1config)#no router bgp 1 
R1(config)#router bgp 1 
R1(config-router)#no au
R1(config-router)#no sync
R1(config-router)#nei 112.112.112.2 remote 2
R1(config-router)#nei 112.112.112.2 update s0/0
R1(config-router)#net 11.11.11.11 mask 255.255.255.255
R1(config-router)#exit

R2(config)#no router bgp 2
R2(config)#router bgp 2
R2(config-router)#nei 12.12.12.1 remote 1
R2(config-router)#no au
R2(config-router)#no sync
R2(config-router)#net 22.22.22.22 mask 255.255.255.255
R2(config-router)#exit

So though local neighbor statement has been changed, but R2 (Server) still sees the BGP communication coming out from valid source IP of 12.12.12.2 which is same as mentioned in it's local BGP communication. But that's not the case for R1 which has neighbor statement for 
112.112.112.112 though the BGP connection it sees is coming from 12.12.12.1 with update source address not modified over R2 for it.

*Mar  1 02:07:14.203: %BGP-5-ADJCHANGE: neighbor 12.12.12.1 Up 

R1#sh tcp brief
TCB                 Local Address           Foreign Address        (state)
64B379E4      12.12.12.1.58558        112.112.112.2.179      ESTAB

R1#sh ip bgp summ | b N
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
112.112.112.2   4     2       6       6        3    0    0 00:02:23                              1

R1#sh ip bgp | b N
   Network          Next Hop            Metric LocPrf Weight   Path
*> 11.11.11.11/32   0.0.0.0                  0              32768     i
*> 22.22.22.22/32   112.112.112.2            0             0      2 i

R1#ping 22.22.22.22 so lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 22.22.22.22, timeout is 2 seconds:
Packet sent with a source address of 11.11.11.11 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/8/16 ms

HTH...
Deepak Arora
CCIE - 0::0/0 Null0

2 comments:

luis said...

Very interesting article. Keep going like this!

Anonymous said...

Quoting:
From the RFC point of view,
the side with higher RID will
be "CLIENT" and router with
lower RID (Router ID) will be
chosen as "SERVER".

Can you cite a source for this information? I've looked through a couple of BGP RFCs, and the only references remotely related to this topic were
1) concerned with IP address, not router-id
2) only worked to resolve session establishment collisions - this is a rare circumstance

I've certainly seen lots of sources that make the claim about high/low client/server, but never seen an authoritative source, and my lab testing shows otherwise.