Re: BGP, TCP server-client

My conclusion is here after applying all the scenarios on the dynamics :)

R1#sh ip bgp neighbors | inc port
Local host: 192.168.1.2, Local port: 179
Foreign host: 192.168.1.1, Foreign port: 30434

Above output means R1 is the 'Server'. R0 (192.168.1.1) initiates the
connection (which is client)

There are two ways I found to restrict the Server/Client.

1- By using ACL on the interface:
You can restrict who will be the server and the client. (Active/passive)

2 - By giving this command on the R1:
    neighbor 192.168.1.1 transport connection-mode passive

R1 always be the server now means never initiate the TCP
connection(Only receive the connection from R0)

Another point as mentioned in the RFC that higher BGP ID will be match
when collision occurs only otherwise any one can be the server/client
by default.

Regards,
Anser

On Wed, Oct 14, 2009 at 10:11 AM, Marcel Lammerse <m.lammerse_at_mac.com> wrote:
> Hey Marco,
>
> you're spot on. Thanks for clarifying that, I learnt another thing about BGP
> today :) The only way to set the client and server is through either the
> neighbor transport command, or an inbound acl, as you already pointed out.
>
> Cheers,
> Marcel
>
>
>
> On 14/10/2009, at 01:39 , Marko Milivojevic wrote:
>
>> 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
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>
>
> 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 Wed Oct 14 2009 - 20:33:18 ART