Re: BGP, TCP server-client

From: Marko Milivojevic <markom_at_markom.info>
Date: Tue, 13 Oct 2009 14:39:19 +0000

I think you are misunderstanding something from that RFC. It is very
clear in section 8.2.x.y that every peer is both active and passive,
unless otherwise configured. It also explicitly states that peer
configured as active, can become either active or passive. Here is the
exact quote:

8.2.1.1. Terms "active" and "passive"

   The terms active and passive have been in the Internet operator's
   vocabulary for almost a decade and have proven useful. The words
   active and passive have slightly different meanings when applied to a
   TCP connection or a peer. There is only one active side and one
   passive side to any one TCP connection, per the definition above and
   the state machine below. When a BGP speaker is configured as active,
   it may end up on either the active or passive side of the connection
   that eventually gets established. Once the TCP connection is
   completed, it doesn't matter which end was active and which was
   passive. The only difference is in which side of the TCP connection
   has port number 179.

It takes some experience and practice to actually understand this, but
let me try in a brief message.

As you all have correctly observed, operation when both peers are
active is pretty random. It's hard to determine which peer will be
passive which will be active - and that's perfectly fine. Rare are
occasions in which this even remotely matters. In fact, this helps
speed things up somewhat. Given that routers will not be trying at the
same time to establish connection (be active) and they both listen, as
soon as one opens connection, the other will stop trying to be active
and session is established. THERE IS NO COLLISION!

In those rare cases when both try at the same time, connection
collision occurs and section 6.8 of the RFC applies, as it was clearly
written in the first paragraph of it.

Kind regards,
Marko.

--
Marko
CCIE #18427 (SP)
My network blog: http://cisco.markom.info/
On Tue, Oct 13, 2009 at 09:17, Marcel Lammerse <m.lammerse_at_mac.com> wrote:
> I just labbed this up and, to my surprise, I got the same results. According
> to rfc 4271, the bgp router-id should determine which side becomes the
> server and which becomes the client during a connection collision. This
> should be a deterministic process. But in my lab it made no difference and I
> got random results. Why?
>
> The neighbor transport command seems to lock the client/server role down.
> The passive side is the server, the active side is the client.
>
> On 13/10/2009, at 15:57 , Marko Milivojevic wrote:
>
>> Have you tried:
>>
>> neighbor X.X.X.X transport connection-mode active
>>
>> Out of curiosity - is this a lab requirement, or are you trying to do
>> something weird in real life? :-)
>>
>> --
>> Marko
>> CCIE #18427 (SP)
>> My network blog: http://cisco.markom.info/
>>
>> On Tue, Oct 13, 2009 at 03:49, ospfv2 <ospfv2_at_gmail.com> wrote:
>>>
>>> Hi Experts
>>>
>>> afaik to make bgp router as tcp client, we can set the router-id
>>> higher or put update-source command. is that correct ?
>>>
>>> but i found out if we reload each of the router,sometime the client
>>> become the server.
>>> how to make the assigment permanent ?
>>>
>>> any comments ?
>>>
>>> thx
>>>
>>>
>>>
>>> R1# sh run
>>> interface FastEthernet0/0
>>> B ip address 192.168.1.1 255.255.255.0
>>>
>>> router bgp 100
>>> B no synchronization
>>> B neighbor 192.168.1.2 remote-as 200
>>> B no auto-summary
>>>
>>> R1#sh ip bgp nei | in port
>>> Local host: 192.168.1.1, Local port: 179
>>> Foreign host: 192.168.1.2, Foreign port: 11001
>>>
>>>
>>>
>>>
>>> R2#sh run
>>> interface FastEthernet0/0
>>> B ip address 192.168.1.2 255.255.255.0
>>>
>>> router bgp 200
>>> B no synchronization
>>> B neighbor 192.168.1.1 remote-as 100
>>> B neighbor 192.168.1.1 update-source FastEthernet0/0
>>> B no auto-summary
>>>
>>>
>>> R2# sh ip bgp nei | in port
>>> Local host: 192.168.1.2, Local port: 11001
>>> Foreign host: 192.168.1.1, Foreign port: 179
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net
Received on Tue Oct 13 2009 - 14:39:19 ART

This archive was generated by hypermail 2.2.0 : Sun Nov 01 2009 - 07:50:59 ART