Re: BGP, TCP server-client

I dont think so, update-source just change your BGP ID and This will
help you when collision occurs only(higher ID will be the winner). You
can check it by clear ip bgp * on both the routers one by one after
applying this command.It will change the server and client
simultaneously.

Otherwise any one can be server/client by default.

Regards,
Anser

On Thu, Oct 15, 2009 at 10:45 PM, Narbik Kocharians <narbikk_at_gmail.com> wrote:
> Have you tried the update-source? that is another way to control the
> client/server role. I am not infront of a rack, but when you think about it
> you should be able to manipulate that on one end to do this.
>
> On Wed, Oct 14, 2009 at 10:33 AM, Muhammad Anser Khan <manserkhan_at_gmail.com>
> wrote:
>>
>> 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
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>>
>>
>>
>>
>>
>
>
>
> --
> Narbik Kocharians
> CCSI#30832, CCIE# 12410 (R&S, SP, Security)
> www.MicronicsTraining.com
> Sr. Technical Instructor
> YES! We take Cisco Learning Credits!
> Training And Remote Racks available

Blogs and organic groups at http://www.ccie.net
Received on Fri Oct 16 2009 - 01:32:42 ART