From: Robert Rech (rjrech@xxxxxxxxxxxx)
Date: Mon Jul 22 2002 - 10:40:10 GMT-3
You are correct if the peer on one side can't establish the connection
the other peer will so an inbound access list like this will work.
access-list 101 deny tcp host 1.1.1.1 eq 179 host 2.2.2.2
access-list 101 deny tcp host 1.1.1.1 host 2.2.2.2 eq 179
The first line will stop a sessoin initiated by the inside host, the
second line will stop a session initiated by the outside host.
Robert Rech
Senior Network Engineer
Cap Gemini Ernst & Young
Kansas City Service Center
rjrech@cgeykcsc.com
phone (816) 459-4767
fax (816) 459-6767
>>> "Anthony Pace" <anthonypace@fastmail.fm> 07/19/02 05:46PM >>>
Since there is no way to determine which router will be the
server(179)
and which will be the client, would you need to block tcp-179 in both
directions on the BRI to stop the BGP peering. Wouldn't there be a
50/50 chance of it being 179 in either direction?
Anthony Pace
On Fri, 19 Jul 2002 14:07:42 +1000, "Jason Sinclair"
<sinclairj@powertel.com.au> said:
> Dave,
>
> Let's think about this logically. You cannot block the outbound
> connection
> attempt because the connection (and hence the traffic) originates
from
> the
> local router.
>
> Let's then think about the inverse of this. The following is a show
tcp
> from
> a BGP speaking router:
>
> Stand-alone TCP connection from host 202.92.64.251
> Connection state is ESTAB, I/O status: 1, unread input bytes: 0
> Local host: 202.92.64.254, Local port: 179
> Foreign host: 202.92.64.251, Foreign port: 11005
>
> See the local port connection on port 179? You can use an ACL to
block
> this
> as this originates from a foreign router.
>
> So to sum it all up - try blocking the tcp port 179 connection
INBOUND
> to
> your router via an ACL.
>
> PS - this does work.
>
> Regards,
>
> Jason Sinclair CCIE #9100
> Manager, Network Control Centre
> POWERTEL
> 55 Clarence Street,
> SYDNEY NSW 2000
> AUSTRALIA
> office: + 61 2 8264 3820
> mobile: + 61 416 105 858
> email: sinclairj@powertel.com.au
>
> -----Original Message-----
> From: Ng, Kim Seng David (David) [mailto:ksng@avaya.com]
> Sent: Friday, 19 July 2002 13:15
> To: Omer Ansari
> Cc: ccielab@groupstudy.com
> Subject: RE: Passive interface command for BGP peering?
>
> It is an IBGP peering using loopback as source. This is not a
scenario
> that
> I came across but something I just thought of.
>
> Rgds
> David
>
> -----Original Message-----
> From: Omer Ansari [mailto:omer@ansari.com]
> Sent: Thursday, July 18, 2002 8:15 PM
> To: Ng, Kim Seng David (David)
> Cc: ccielab@groupstudy.com
> Subject: Re: Passive interface command for BGP peering?
>
>
> Dave,
>
> i see that you're using the loopback to peer.
> is is prohibited to use the physical (primary) interface's IP
address
> for
> peering?
>
> On Thu, 18 Jul 2002, Ng, Kim Seng David (David) wrote:
>
> > Hi group,
> >
> > Is there an equivalent "passive interface" command to stop BGP
> peering over a specific interface. In a case when I have the backup
BRI
> interface activated and the floating static default route in place,
I
> want
> to prevent the BGP peering from happening over the BRI interface.
> Dialer
> list can prevent peering from activating the BRI link but that will
not
> stop
> BGP peering when some other interesting traffic activates the link.
I
> tried
> access-list extended out blocking tcp port 179 at the BRI interface
but
> the
> IBGP peering (thru loopback interface) still occurs. I think it is
> because
> the access-list cannot block locally generated traffic. Hope someone
> can
> advice.
> >
> > Thanks
> > David
This archive was generated by hypermail 2.1.4 : Sat Sep 07 2002 - 19:36:39 GMT-3