Re: BGP, TCP server-client

Here is the configuration with the output:

Router R1

interface Loopback0
 ip address 1.1.1.1 255.0.0.0
!
interface FastEthernet0/0
 ip address 10.1.1.1 255.255.255.0
 duplex auto
 speed auto
!
interface FastEthernet0/1
 no ip address
 shutdown
 duplex auto
 speed auto
!
router bgp 100
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.1.1.2 remote-as 200
 neighbor 10.1.1.2 ebgp-multihop 255
 neighbor 10.1.1.2 update-source Loopback0
 no auto-summary

Router R2:
!
interface FastEthernet0/0
 ip address 10.1.1.2 255.255.255.0
 duplex auto
 speed auto
!
interface FastEthernet0/1
 no ip address
 shutdown
 duplex auto
 speed auto
!
router bgp 200
 no synchronization
 bgp log-neighbor-changes
 neighbor 1.1.1.1 remote-as 100
 neighbor 1.1.1.1 ebgp-multihop 255
 no auto-summary
!
ip http server
no ip http secure-server
ip route 1.1.1.1 255.255.255.255 10.1.1.1

OUTPUT R1:

R1#show ip bgp neighbors | inc port
Local host: 1.1.1.1, Local port: 179
Foreign host: 10.1.1.2, Foreign port: 45023
(Server)

R1#clear ip bgp *

R1#show ip bgp neighbors | inc port
Local host: 1.1.1.1, Local port: 24572
Foreign host: 10.1.1.2, Foreign port: 179
(Client)
R2#sh ip bgp nei | inc port
Local host: 10.1.1.2, Local port: 179
Foreign host: 1.1.1.1, Foreign port: 25330
(Server)
Initial OUTPUT R2:

R2#sh ip bgp nei | inc port
Local host: 10.1.1.2, Local port: 45023
Foreign host: 1.1.1.1, Foreign port: 179
(Client)

It changes their relationship simultaneously

Regards,
Anser

On Fri, Oct 16, 2009 at 3:38 AM, Narbik Kocharians <narbikk_at_gmail.com> wrote:
> 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
>> > 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
Received on Fri Oct 16 2009 - 13:41:08 ART