From: Guyler, Rik (rguyler@shp-dayton.org)
Date: Thu Jul 28 2005 - 10:26:17 GMT-3
I thought about that too but I couldn't think of a viable application of MQC
to filter traffic that way. Maybe I'll dig into it a little deeper...I'm
probably not looking at it from a creative enough perspective. Did you have
something specifically in mind?
Rik
-----Original Message-----
From: ccie2be [mailto:ccie2be@nyc.rr.com]
Sent: Wednesday, July 27, 2005 4:29 PM
To: 'Guyler, Rik'; ccielab@groupstudy.com
Subject: RE: Nesting ACLs
I don't know if this would meet all your requirements but you can nest with
MQC.
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Guyler, Rik
Sent: Wednesday, July 27, 2005 12:06 PM
To: 'ccielab@groupstudy.com'
Subject: Nesting ACLs
I'm coming up blank on this so I'll post it to the collective:
I'm looking at our primary VPN router and the ACL for inbound traffic is
getting out of control plus it's not modular enough for when I have to make
additions. Im using the "ip access-list extended" syntax so I can go in and
modify to my heart's content but still, after many hundreds of entries it's
getting ugly. If I have to make an addition to the list, I like to keep all
the entries for the same vendor together but that requires getting creative
with the sequnce numbers at times, espcially if I have to add many entries
for the same vendor.
My question is this: is there any way to nest ACLs without using reflexive
ACLs? For example, on a PIX it's possible to create object groups so your
modifications are much more modular. If you need to modify the ACL for a
specific tunnel you could just modify the object group without worrying
about how it affects the entire ACL. If I could setup individual ACLs (or
objects) for each VPN peer then call those within another all-inclusive ACL
that gets applied to the interface, it would be much easier to manage. Any
ideas how to do this?
Thanks
Rik
This archive was generated by hypermail 2.1.4 : Sun Sep 04 2005 - 17:00:31 GMT-3