RE: Routing protocols with Reflexive Acls

From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Wed Oct 10 2007 - 17:33:45 ART


        Locally generated traffic is not affected by outbound access-lists.
This means that the local BGP traffic going out will not be subject to the
reflection of the ACL, hence when evaluation occurs inbound the return BGP
session will be denied. The normal fix for this is to statically permit the
session back inbound. The longwinded solution is local policy routing, as
this forces the traffic to be treated as transit traffic and it is reflected
by the outbound access-list.

HTH,

Brian McGahan, CCIE #8593 (R&S/SP/Security)
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
> Usankin, Andrew
> Sent: Wednesday, October 10, 2007 12:44 PM
> To: Joseph Brunner; Cisco certification
> Subject: RE: Routing protocols with Reflexive Acls
>
> Why would you go through so much problems?
> You know you have BGP over this link, you know that BGP works over
> TCP:179. So just use simple reflective access list for it. Yes, session
> won't ever get established from BB1 to R6, but that's not a big dial. As
> soon as R6 tries to establish session to BB1 reflective ACL will let
> everything pass through.
> Do I miss something?
>
> Andrew
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Joseph Brunner
> Sent: Wednesday, October 10, 2007 4:12 AM
> To: 'Cisco certification'
> Subject: Routing protocols with Reflexive Acls
>
> Task 5.1 Configure a BGP peering session between R6 and BB1 using their
> directly connected address
>
>
>
>
>
> Task 7.2 Configure a traffic inspection policy on R6's G0/1 interface
> that only permits return traffic that was originated within the network
>
> Any routing protocols previously configured must work
> after this policy is applied
>
> If access-lists are used do not explicitly permit any
> routing protocol
>
>
>
>
>
> This deals with a reflexive acl (I guess cbac can do this too) and how
> we normally permit routing protocols inbound before the EVAULATE part of
> the acl which evaluates the reflexive acl. I figured a way to permit bgp
> to run without configuring a permit statement in the inbound acl.
>
>
>
> -routing protocol traffic is local policy routed to the loopback
> interface
>
> -bgp traffic is then "reflected" as it leaves R6 towards BB1
>
> -R6's bgp peering session required "ebgp-multihop" or the peering
> session would get stuck in "OpenConfirm"
>
> -I permitted telnet also as I like to telnet to the BB's from R6 in my
> rack
>
> -I wanted to start a discussion regarding handling routing protocols
> when using reflexive acl's and CBAC
>
>
>
>
>
> R6 Config
>
>
>
> access-list 101 permit tcp any any eq telnet
>
> access-list 101 permit udp any any eq rip
>
> access-list 101 permit tcp any eq bgp any
>
> access-list 101 permit tcp any any eq bgp
>
>
>
> ip access-list extended INBOUND
>
> evaluate REFLECT
>
> ip access-list extended OUTBOUND
>
> permit icmp any any reflect REFLECT
>
> permit tcp any any reflect REFLECT
>
> permit udp any any reflect REFLECT
>
>
>
>
>
> route-map POLICY permit 10
>
> match ip address 101
>
> set interface Loopback0
>
>
>
>
>
> ip local policy route-map POLICY
>
>
>
> interface GigabitEthernet0/1
>
> ip address 150.1.1.6 255.255.255.0
>
> ip access-group INBOUND in
>
> ip access-group OUTBOUND out
>
>
>
> router bgp 100
>
> no synchronization
>
> bgp log-neighbor-changes
>
> network 1.1.6.6 mask 255.255.255.255
>
> neighbor 150.1.1.254 remote-as 54
>
> neighbor 150.1.1.254 ebgp-multihop 255
>
>
>
>
>
>
>
> rack1r6#sh route-map
>
> route-map LOCAL, permit, sequence 10
>
> Match clauses:
>
> ip address (access-lists): 101
>
> Set clauses:
>
> interface Loopback0
>
> Policy routing matches: 286 packets, 31464 bytes
>
>
>
> rack1r6#sh ip bgp summ
>
> BGP router identifier 160.1.6.6, local AS number 100
>
> BGP table version is 27, main routing table version 27
>
> 21 network entries using 2457 bytes of memory
>
> 28 path entries using 1456 bytes of memory
>
> 14/10 BGP path/bestpath attribute entries using 1736 bytes of memory
>
> 1 BGP rrinfo entries using 24 bytes of memory
>
> 7 BGP AS-PATH entries using 168 bytes of memory
>
> 0 BGP route-map cache entries using 0 bytes of memory
>
> 0 BGP filter-list cache entries using 0 bytes of memory
>
> BGP using 5841 total bytes of memory
>
> BGP activity 316/295 prefixes, 551/523 paths, scan interval 60 secs
>
>
>
> Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down
> State/PfxRcd
>
> 150.1.1.254 4 54 2210 2266 27 0 0 00:13:33
> 18
>
> 160.1.7.7 4 100 2265 2711 27 0 0 00:13:34
> 7
>
>
>
> rack1r6#sh ip access
>
> Extended IP access list 101
>
> 5 permit tcp any any eq telnet (62 matches)
>
> 10 permit udp any any eq rip (2 matches)
>
> 20 permit tcp any eq bgp any (79 matches)
>
> 30 permit tcp any any eq bgp (486 matches)
>
> Extended IP access list INBOUND
>
> 40 evaluate REFLECT
>
> Extended IP access list OUTBOUND
>
> 10 permit icmp any any reflect REFLECT (17 matches)
>
> 20 permit tcp any any reflect REFLECT (5382 matches)
>
> 30 permit udp any any reflect REFLECT (10893 matches)
>
> Reflexive IP access list REFLECT
>
> permit tcp host 150.1.1.254 eq bgp host 150.1.1.6 eq 25558 (58
> matches) (time left 263)
>
> rack1r6#
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
> The content contained in this electronic message is not intended to
> constitute formation of a contract binding TWTC. TWTC will be
> contractually bound only upon execution, by an authorized officer, of
> a contract including agreed terms and conditions or by express
> application of its tariffs.
>
> This message is intended only for the use of the individual or entity
> to which it is addressed. If the reader of this message is not the
> intended recipient, or the employee or agent responsible for
> delivering the message to the intended recipient, you are hereby
> notified that any dissemination, distribution or copying of this
> message is strictly prohibited. If you have received this
> communication in error, please notify us immediately by replying to
> the sender of this E-Mail or by telephone.
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html



This archive was generated by hypermail 2.1.4 : Fri Nov 16 2007 - 13:11:13 ART