From: Sidalo (sidalo@gmail.com)
Date: Thu May 25 2006 - 12:53:42 ART
12.4
router bgp 100
neighbor 1.1.1.1 transport connection-mode passive
Rack1R3(config-router)#do sh ip bgp neig
<output omitted>
TCP session must be opened passively
That will keep one side from initiating the BGP session. There is also an
active keyword on the command to force that operation
On 5/25/06, Ivan <ivan@iip.net> wrote:
>
> You can see local and foreigh port "sh ip bgp nei | i port"
> In BGP tcp-session one side is server other is client. You can't predict
> wich
> one will server. But you can to force one side be a client (deny tcp to
> local
> 179-port).
>
> > The good part if that one source fails to establish connection then the
> > other party would initiate to destination 179
> >
> >
> >
> > -----Mensaje original-----
> > De: nobody@groupstudy.com [mailto:nobody@groupstudy.com] En nombre de
> > Plank, Jason
> > Enviado el: Jueves, 25 de Mayo de 2006 12:04 a.m.
> > Para: Nick Griffin; Tony Paterra
> > CC: GroupStudy CCIE
> > Asunto: RE: RACLs and BGP sessions...
> >
> > BGP uses TCP. It uses a random source port.
> >
> > 2w2d: TCP src=179, dst=12790, seq=0, ack=4117655611, win=0 ACK RST
> >
> > -------------------
> > J. Marshall Plank
> > Network Engineer
> > 101 Bellevue Parkway
> > Wilmington, DE 19809
> > E-mail: JPlank@concordefs.com
> > Phone: 302-793-5913
> >
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> > Nick Griffin
> > Sent: Wednesday, May 24, 2006 11:48 PM
> > To: Tony Paterra
> > Cc: GroupStudy CCIE
> > Subject: Re: RACLs and BGP sessions...
> >
> > Based on my understanding your correct, BGP does use a random source
> > port, there is a range, but right off hand I can't recall( appears to be
> > 11000-11002 ). It's not sourced from port 179. So I believe "permit tcp
> > any any eq bgp" Inbound would work. And your right on with RIP, udp
> > source/destination 520, I think what you have for RIP would work as
> well.
> >
> > My .02
> >
> > Tony Paterra wrote:
> > > All quick question regarding reflexive ACLs and BGP... If we have a
> > > router with an "outside" ethernet interface and we want to allow BGP
> > > routing updates I have seen it configured like this statically in a
> > > RACL...
> > >
> > > ip access-list extended OUT_ACL
> > > permit tcp any any reflect REFLECTED
> > > permit icmp any any reflect REFLECTED
> > > permit udp any any reflect REFLECTED
> > >
> > > ip access-list extended IN_ACL
> > > permit tcp any any eq bgp
> > > permit tcp any eq bgp any
> > > permit udp any any eq rip
> > > eval REFLECTED
> > >
> > > int e0/0
> > > description Outside interface
> > > ip access-group IN_ACL in
> > > ip access-group OUT_ACL out
> > >
> > >
> > > My natural reaction is to say "permit tcp any any eq bgp" and leave it
> > > at that instead of saying "permit tcp any eq bgp any" as well. My
> > > guess is that my router sources BGP updates from a random available
> > > port to port 179 (i.e. local port = random, dst port = neighbor's port
> > > 179) and expects to receive from the neighbor's random port destined
> > > to my local port 179 (neighbor's local port = random dst port = my
> > > port 179, is my mind on the right track? If this is the case,
> > > shouldn't RIP updates be configured like so...
> > >
> > > permit udp any eq rip any eq rip
> > >
> > > I'm seeing all the RIP communication come SRC/DST from port 520 which
> > > leads me to believe this...
> > >
> > >
> > > As always, I appreciate the help.
> > >
> > > Tony Paterra
> > > apaterra@gmail.com
> > >
> > >
> _______________________________________________________________________
> > > Subscription information may be found
> > > at:http://www.groupstudy.com/list/CCIELab.html
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> > -----------------------------------------
> > The information in this message may be proprietary and/or
> > confidential, and protected from disclosure. If the reader of this
> > message is not the intended recipient, or an employee or agent
> > responsible for delivering this message to the intended recipient,
> > you are hereby notified that any dissemination, distribution or
> > copying of this communication is strictly prohibited. If you have
> > received this communication in error, please notify First Data
> > immediately by replying to this message and deleting it from your
> > computer.
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
> --
> Ivan
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Thu Jun 01 2006 - 06:33:22 ART