Re: BGP, TCP server-client

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