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
Deepak Arora
CCIE - 0::0/0 Null0
2 comments:
Very interesting article. Keep going like this!
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.
Post a Comment