From: Hafizur Rahman \(UK\) (hafizur.rahman@uk.didata.com)
Date: Thu Aug 03 2006 - 04:57:11 ART
But BGP on the local router will still work with out using following line
permit tcp any eq bgp any
Could any one pls confirm this?
Thanks
hafi
-----Original Message-----
From: nobody@groupstudy.com on behalf of Brian McGahan
Sent: Thu 03/08/2006 00:32
To: Sami; Magmax
Cc: David Redfern (AU); ccielab@groupstudy.com
Subject: RE: reflexive acl's and bgp orf
If the local device is running BGP then yes. Outbound
access-lists do not affect locally generated traffic, so BGP will not be
reflected. You can trick the router into reflecting it by using local
policy routing, but this is going out of the way to solve a problem that
shouldn't be that complex. Simply use the two statements you listed,
TCP source 179 and TCP destination 179, and BGP will be permitted. This
hold true for any other locally generated traffic as well, OSPF, RIP,
GRE, etc.
HTH,
Brian McGahan, CCIE #8593
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987 x 705
Outside US: 775-826-4344 x 705
24/7 Support: http://forum.internetworkexpert.com
Live Chat: http://www.internetworkexpert.com/chat/
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> Sami
> Sent: Wednesday, August 02, 2006 5:23 PM
> To: Magmax
> Cc: David Redfern (AU); ccielab@groupstudy.com
> Subject: Re: reflexive acl's and bgp orf
>
> Another question .about reflexive access list
>
> permit tcp any any reflect MYREFLECT --> this line allow all the tcp
> traffic , bgp is also running . Do we need to permit explictly bgp in
> outbound direction or not ?
>
> permit tcp any any eq bgp
> permit tcp any eq bgp any
>
> Thanks
> ..
>
>
> On 7/23/06, Magmax <magmax@bigpond.net.au> wrote:
> >
> > David,
> >
> > It is same thing mate but you will be permitting traffic other than
TCP,
> > UDP, and ICMP like EIGRP or ESP
> >
> > Please feel free to correct my concept
> >
> >
> > Regards,
> >
> > Ubaid
> >
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> > David Redfern (AU)
> > Sent: Sunday, 23 July 2006 7:38 PM
> > To: ccielab@groupstudy.com
> > Subject: reflexive acl's and bgp orf
> >
> > Hi Guys,
> >
> > Just working IEWB lab 15 and just want to brainstorm everyones
thoughts.
> >
> > Couple of questions
> >
> >
> > REFLEXIVE ACCESS LISTS
> >
> >
> > A lot of practice labs which ask for reflexive access-lists have the
> > following outbound
> >
> >
> > ip access-list extended OUTBOUND
> > permit tcp any any reflect MYREFLECT
> > permit udp any any reflect MYREFLECT
> > permit icmp any any reflect MYREFLECT
> >
> >
> >
> > Does anyone know if you must use all 3 entries for any reason or
simply
> > one statement below can be used in its place when using Reflexive
access
> > lists.
> >
> > ip access-list extended OUTBOUND
> > permit ip any any reflect MYREFLECT
> >
> >
> > When i use the above and i seem to achieve the same result. Any
ideas?
> >
> >
> >
> >
> > BGP OUTBOUND ROUTE FILTERING
> >
> > All documenation suggests the below command must be entered under
> > address family configuration and not directly under the routing
process.
> > When i do this directly under it works. But on some IOS it is not
> > showing up in the running config.
> > Verification of sh ip bgp nei shows the route-filter applied.
> >
> > Is ipv4 unicast the default and is that why it works?
> >
> > Any ideas of best practice?
> >
> >
> > neighbor x.x.x.x capability orf prefix-list send/receive/bot
> >
> >
> >
> >
> >
> >
>
************************************************************************
**
> **
> > *
> > *
> > - NOTICE FROM DIMENSION DATA AUSTRALIA
> > This message is confidential, and may contain proprietary or legally
> > privileged information. If you have received this email in error,
> please
> > notify the sender and delete it immediately.
> >
> > Internet communications are not secure. You should scan this message
and
> > any
> > attachments for viruses. Under no circumstances do we accept
liability
> > for
> > any loss or damage which may result from your receipt of this
message or
> > any
> > attachments.
> >
> >
>
************************************************************************
**
> **
> > *
> > *
> >
> >
_______________________________________________________________________
> > 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
>
>
_______________________________________________________________________
> 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
-----------------------------------------
Dimension Data - providing global IP based solutions and services
for over 20 years supported locally from a single point of contact
This email is confidential. If you are not the intended recipient
then you must not copy it, forward it, use it for any purpose, or
disclose it to another person.
Please also note that the author of this email is not authorised
to; make any offers capable of acceptance unless expressly stated
in a validly dated and attached document which shall be subject to
the terms and conditions stated therein or, conclude any contract
on behalf of Dimension Data by email.
Although Dimension Data has taken reasonable precautions to ensure
no viruses are present in this email, the company cannot accept
responsibility for any loss or damage arising from the use of this
email or attachments.
This archive was generated by hypermail 2.1.4 : Fri Sep 01 2006 - 15:41:55 ART