[c-nsp] control plane policing feature
Francisco Rivas
frivas at lanparty.cl
Wed Dec 21 12:45:11 EST 2005
Thanks Rodney, I didn't realize that the control-policy was configured
as OUTPUT on the example. Changed it to INPUT and that did the trick.
But I have another doubt: the "drop" policy doesn't exist on 12.2
train??? I've found it only on IOS 12.4 train..... I've tried 12.0
(31)S2, 12.2(25)S7 and 12.3(14)T5, and the drop policy doesn't exist.
I'm missing something else here?? is the "drop" policy exclusive of the
12.4 train???
Besides that, there are some bugs on the example on that URL. There is a
defined policy map like this:
Router(config)# policy-map control-plane-out-policy
! Drop all traffic that matches the class "icmp-class."
But after this, the example tries to apply this to the control-plane:
Router(config)# control-plane
! Define aggregate control plane service for the active route processor.
Router(config-cp)# service-policy output control-plane-policy
Router(config-cp)# exit
On the policy-map, the name is "control-plane-out-policy", but on the
control-plane the service policy is configured as "control-plane-
policy"... it should be "control-plane-out-policy", right??
Another thing: when I tried to copy/paste the example directly, I've got
this on the access-list:
router7206(config)#access-list 141 deny icmp host 3.3.3.0 0.0.0.255 any
port-unreachable ?
% Unrecognized command
The "host" there is wrong, it should be
router7206(config)#access-list 141 deny icmp 3.3.3.0 0.0.0.255 any port-
unreachable
Well, I've configured this on my lab router (running 12.4(3b):
!
class-map match-all icmp-class
match access-group 141
!
!
policy-map control-plane-out-policy
class icmp-class
drop
!
access-list 141 deny icmp 192.168.1.0 0.0.0.255 any echo
access-list 141 deny icmp 192.168.1.0 0.0.0.255 any echo-reply
access-list 141 permit icmp any any echo
access-list 141 permit icmp any any echo-reply
!
control-plane
service-policy output control-plane-out-policy
!
This should permit the echo and echo-reply directed to any IP on any
interface on the router, from 192.168.1.0/24, right???? Well, this isn't
working here. All the packets are being dropped, from any source to any
destination on the router. When I look at the ACL 141, I can see that
all the packets are being matched with the last permit:
router7206#sh ip access-lists 141
Extended IP access list 141
10 deny icmp 192.168.1.0 0.0.0.255 any echo
20 deny icmp 192.168.1.0 0.0.0.255 any echo-reply
30 permit icmp any any echo
40 permit icmp any any echo-reply (1076 matches)
router7206#
Then, when I added to the ACL the net 192.168.2.0/24 (the net used on
the router's interface), the ACL matched this:
router7206#sh ip access-lists 141
Extended IP access list 141
10 deny icmp 192.168.1.0 0.0.0.255 any echo
20 deny icmp 192.168.1.0 0.0.0.255 any echo-reply
30 deny icmp 192.168.2.0 0.0.0.255 any echo
40 deny icmp 192.168.2.0 0.0.0.255 any echo-reply (323 matches)
50 permit icmp any any echo
60 permit icmp any any echo-reply
router7206#
This works because, as you said, the policy is working as OUTPUT (on
this particular example), so the ACL is filtering the packet generated
by the control-plane (the router itself) in response to the packets
being send by the nets configured on the ACL. If I put the service
policy on the control-plane as INPUT, it works as expected (I've tested
this myself). If I'm right, the docs (particulary this example on that
URL) is wrong...
To stay according to the explanation of the example, "The following
example shows how to configure trusted networks with source addresses
3.3.3.0 and 4.4.4.0 to receive Internet Control Message Protocol (ICMP)
port-unreachable responses without constraint, while allowing all
remaining ICMP port-unreachable to be dropped", the example should be
something like this (notice that the ACL source-dest is reversed,
because we need to match the outgoing traffic, not the incoming -
because we are using an OUTPUT policy from the router to the nets):
! Allow 3.3.3.0 trusted network traffic.
Router(config)# access-list 141 deny icmp any 3.3.3.0 0.0.0.255 port-
unreachable
! Allow 4.4.4.0 trusted network traffic.
Router(config)# access-list 141 deny icmp any 4.4.4.0 0.0.0.255 port-
unreachable
! Rate limit all other ICMP traffic.
Router(config)# access-list 141 permit icmp any any port-unreachable
Router(config)# class-map icmp-class
Router(config-cmap)# match access-group 141
Router(config-cmap)# exit
Router(config)# policy-map control-plane-policy
! Drop all traffic that matches the class "icmp-class."
Router(config-pmap)# class icmp-class
Router(config-pmap-c)# drop
Router(config-pmap-c)# exit
Router(config-pmap)# exit
Router(config)# control-plane
! Define aggregate control plane service for the active route processor.
Router(config-cp)# service-policy output control-plane-policy
Router(config-cp)# exit
I'm right, or not??? :)
regards,
Francisco Rivas C.
On Wed, 2005-12-21 at 08:52 -0500, Rodney Dunn wrote:
> I can't read your email because it didn't line wrap.
>
> But from what I can gather is you want to allow icmp
> from certain networks and drop the rest.
>
> So you ACL should deny icmp coming from the particular
> networks and then permit all other icmp traffic.
>
> Then you reference the class-map *inbound* and set
> the policy to drop.
>
> That makes it such that all traffic that is *permitted* will
> be dropped which is sorta reverse logic in that you denied
> the traffic you wanted to allow through in the ACL.
>
> Rodney
>
> On Tue, Dec 20, 2005 at 03:23:47PM -0300, Francisco Rivas wrote:
> > Hi all,
> >
> > I'm testing the control plane policing on a Cisco 7206
> > (http://www.cisco.com/en/US/customer/products/sw/iosswrel/ps1838/products_feature_guide09186a008052446b.html)
> > and I've found certain things that don't fit, and I hope that someone
> > here can give me a hand here. In the URL, there is an example that shows
> > how to configure a couple of trusted networks to reach the router thru
> > ICMP, and all the remaining ICMP traffic should be dropped. The example
> > goes like this:
> >
> > ! Allow 3.3.3.0 trusted network traffic.
> > Router(config)# access-list 141 deny icmp host 3.3.3.0 0.0.0.255 any
> > port-unreachable ! Allow 4.4.4.0 trusted network traffic.
> > Router(config)# access-list 141 deny icmp host 4.4.4.0 0.0.0.255 any
> > port-unreachable ! Rate limit all other ICMP traffic. Router(config)#
> > access-list 141 permit icmp any any port-unreachable Router(config)#
> > class-map icmp-class Router(config-cmap)# match access-group 141
> > Router(config-cmap)# exit Router(config)# policy-map
> > control-plane-out-policy ! Drop all traffic that matches the class
> > "icmp-class." Router(config-pmap)# class icmp-class
> > Router(config-pmap-c)# drop Router(config-pmap-c)# exit
> > Router(config-pmap)# exit Router(config)# control-plane ! Define
> > aggregate control plane service for the active route processor.
> > Router(config-cp)# service-policy output control-plane-policy
> > Router(config-cp)# exit
> >
> >
> > First of all, I've tried some IOS versions, and the only one that I've found
> > with the "drop" feature inside the class (in this case, "class icmp-class")
> > is 12.4(3b) (service provider). I've tried 12.0(31)S2, 12.2(25)S7 and
> > 12.3(14)T5, and they didn't have the "drop" command. I'm running
> > 12.2(18)S4 on a 7206vxr with NPE-G1, and I want to stay on the 12.2
> > train for now (by the way, 12.2(18)S4 is giving me some memory issues
> > right now.. soon I'll write another mail about that). Is the "drop" command exclusive
> > to the 12.4 train???
> > Another thing, in the example, they want to ALLOW the ICMP traffic from both networks,
> > so why they are DENIED on the config???? (access-list 141 deny icmp ...)
> > I've tried this exact example (changing the ip addresses only), and
> > obviously they didn't work. I've reversed the access-list (permit for
> > the networks, then DENY any), and it worked as I expected. Is this a bug
> > on the example, or something changed on 12.4 train??
> >
> > And, for last, anyone has real-world experience with this control plane policing feature??
> > does it works as expected???? any word about this will be very appreciated :)
> >
> > Thanks a lot for your help!!!
> >
> >
> > Regards,
> >
> >
> > --
> > Francisco Rivas Catalan
> > Senior Network Engineer
> > IFX Networks
> > (56) 2 3744574
> > francisco.rivas at ifxnw.cl
> >
> >
> > _______________________________________________
> > cisco-nsp mailing list cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
>
More information about the cisco-nsp
mailing list