Re: BGP, TCP server-client

I was referring to setting up client and server ONLY. Update-source does NOT
change the BGP-ID, it changes the source ip address, therefore, if you have
two routers let's say R1 and R2, and R1 is configured to establish the BGP
session using the IP address of R2's link and R2 establishes the BGP session
with the loopback Ip address of R1. You would need update-source lo0 on R1
and that will make R1 the client and R2 the server.

Once again i am NOT infront of a rack but this would be the config:

*On R1*
int lo0
ip addr 1.1.1.1 255.0.0.0
int f0/0
ip addr 10.1.1.1 255.255.255.0

router bgp 100
neighbor 10.1.1.2 remot 200
neighbor 10.1.1.2 update-source lo0
neighbor 10.1.1.2 ebgp-multi

*On R2*

ip route 1.1.1.1 255.255.255.255 10.1.1.1

int f0/0
ip addr 10.1.1.2 255.255.255.0

router bgp 200
neighbor 1.1.1.1 remot 100
neighbor 1.1.1.1 ebgp-multi

This should make R1 the client and R2 the server, if you lab it up it should
work. If i was infront of a rack i would have sent you the actual config.

On Thu, Oct 15, 2009 at 3:32 PM, Muhammad Anser Khan
<manserkhan_at_gmail.com>wrote:

> 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 <http://www.micronicstraining.com/>
> > Sr. Technical Instructor
> > YES! We take Cisco Learning Credits!
> > Training And Remote Racks available
> >
>

-- 
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