[c-nsp] Access-list application

Rodney Dunn rodunn at cisco.com
Wed Sep 22 11:46:36 EDT 2004


Yes that does make sense in that scenario.

I didn't think of it that way.

Rodney

On Wed, Sep 22, 2004 at 08:29:53PM +0530, Amol Sapkal wrote:
> On Wed, 22 Sep 2004 07:37:38 -0400, Rodney Dunn <rodunn at cisco.com> wrote:
> > On Wed, Sep 22, 2004 at 07:12:55AM +0530, Amol Sapkal wrote:
> > > Yes,
> > >
> > > I checked it yesterday for ICMP, traffic generated within the router
> > > does actually pass outbound. So the access-list did not stop the
> > > traffic outbound.
> > > I know about ip local policy, but thought it comes in play only for
> > > taking routing decisions and not access-list application.
> > 
> > Well, for a policy to work you have to do two things.
> > a) match
> > b) set
> > 
> > meaning you have to first classify the traffic and then decide
> > what you want to do with the traffic that matches.
> > The point was if you want to prevent traffic from originating
> > from the router for a certain reason you can leverage PBR
> > to either permit or deny by the set clause.
> > 
> > It wasn't originally designed to do that but it so happened
> > to solve this problem too.
> > 
> > >
> > > Like, if my router's default is interface X, and there is source based
> > > routing for traffic from subnet A.B.C.D to go out via interface Y -
> > > 1. with ip local policy enabled, an extended trace on the router (with
> > > a loopback as source, which is in the subnet ABCD), will take
> > > interface Y.
> > > 2. with ip local policy disabled, the trace would still take the
> > > default interface X.
> > 
> > Well, I'm not sure why you would ever want to do that.
> > "ip local policy" *only* applies to traffic that is originated
> > by the router going out.  If you want to redirect that traffic
> > to a different path than the routing table says you do it.
> > Otherwise you shouldn't use local policy.
> > 
> > The only reason your above example does anything different is
> > because the ICMP response built by the router is evaluated
> > against the local policy.  That doesn't make much sense to me
> > because one of the purposes of traceroute/ping is to verify
> > path connectivity.  If you force just that traffic to reroute
> > then your data path and ICMP paths diverge and one can work
> > and the other not.
> > 
> > Rodney
> > 
> 
> 
> This was required so that my trace and ping traffic follows the same
> path as my actual data. this could help my team do a proper
> troubleshoot on Internet paths.
> 
> 
> > 
> > 
> > >
> > >
> > >
> > >
> > > On Wed, 22 Sep 2004 02:27:29 +0300, Volodymyr Yakovenko
> > > <vovik at dumpty.org> wrote:
> > > > On Tue, Sep 21, 2004 at 05:36:10PM -0400, Rodney Dunn wrote:
> > > > >Never tried it with a loopback.
> > > > >
> > > > >Is that packet matches for in or out?
> > > >
> > > > Only inbound ACL actualy matches packets.
> > > >
> > > > So your statement about outbound ACLs is right.
> > > >
> > > > >You have the ACL configured in both directions
> > > > >with the same src/dst.
> > > > >
> > > > >On Tue, Sep 21, 2004 at 10:33:03PM +0300, Volodymyr Yakovenko wrote:
> > > > >> On Tue, Sep 21, 2004 at 02:02:39PM -0400, Rodney Dunn wrote:
> > > > >> >On Tue, Sep 21, 2004 at 11:15:39PM +0530, Amol Sapkal wrote:
> > > > >> >> Quick question: Does an interface access-list apply to traffic
> > > > >> >> generated from a router? Say a ping, if icmp is blocked, or a telnet
> > > > >> >> to a site on port 80, if port 80 is blocked.
> > > > >> >
> > > > >> >On egress from the router no.
> > > > >>
> > > > >> It does work for Loopbacks:
> > > > >>
> > > > >> interface Loopback1
> > > > >>  ip address 172.21.255.2 255.255.255.255
> > > > >>  ip access-group NOME in
> > > > >>  ip access-group NOME out
> > > > >>  h323-gateway voip interface
> > > > >>  h323-gateway voip id dp-gk1 ipaddr 172.21.255.1 1719
> > > > >>  h323-gateway voip h323-id dp-msc-cis2
> > > > >>  h323-gateway voip tech-prefix 1#
> > > > >> ip access-list extended NOME
> > > > >>  deny   tcp host 172.21.255.2 host 172.21.255.2 eq 1720
> > > > >>  permit ip any any
> > > > >>
> > > > >> dp-msc-cis2#sh ip access-lists NOME
> > > > >> Extended IP access list NOME
> > > > >>     deny tcp host 172.21.255.2 host 172.21.255.2 eq 1720 (36 matches)
> > > > >>     permit ip any any (36 matches)
> > > > >>
> > > > >> >Why?  Because it's assumed the the router sending a packet
> > > > >> >out is always a valid one.
> > > > >> >
> > > > >> >We considered an option for them to match on the traffic
> > > > >> >but since the below workaround does the job it never
> > > > >> >went further.
> > > > >> >
> > > > >> >You can force it to do by defining a route-map, match
> > > > >> >the traffic, configure "ip local policy <route-map".
> > > > >> >
> > > > >> >Rodney
> > > > >> >
> > > > >> >
> > > > >> >>
> > > > >> >> Detailed: If no, why?
> > > >
> > > > --
> > > > Regards,
> > > > Volodymyr.
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Warm Regds,
> > >
> > > Amol Sapkal
> > >
> > > --------------------------------------------------------------------
> > > An eye for an eye makes the whole world blind
> > > - Mahatma Gandhi
> > > --------------------------------------------------------------------
> > 
> 
> 
> 
> -- 
> Warm Regds,
> 
> Amol Sapkal
> 
> --------------------------------------------------------------------
> An eye for an eye makes the whole world blind 
> - Mahatma Gandhi
> --------------------------------------------------------------------


More information about the cisco-nsp mailing list