Sorry for the long delay in this response, I was pushing for my CCIE lab on the 16th and then trying to get caught up at work. (Nope, didn't make it this time)
First, I agree that DMVPN works fine with either transport or tunnel mode. Other issues in the network may affect that, such as what I ran into with the NAT in the ASA that was in the data path. Generally, my experience has been because transport mode exposes the IP header it is less preferred on public networks. This is the same reason that GETVPN is generally not recommended on public networks, although it will work just fine. Terry Little (425) 894-4109 (m) (425) 468-1057 (o) -----Original Message----- From: Paul Stewart [mailto:[email protected]] Sent: Monday, April 05, 2010 6:52 AM To: [email protected] Cc: Terry Little (terlittl) Subject: Re: DMVPN Phase 1 Why have you avoided transport mode in the real world? Generally, DMVPN works fine in transport mode over the public internet. The tunnelling happens for the actual data payload in GRE. I didn't re-read lab four, but it very well may not have required transport mode. However, most examples show DMVPN in transport mode and is generally the recommended approach from what I recall. I can see possible issues if the DMVPN spoke is behind nat. As I recall ESP in transport mode has issues with that (but maybe only with hmac, I'll have to think about that scenario). I wouldn't say whether or not that would cost points on the real lab. My opinion is that if you meet each criteria for each task, you will get the points. On Mon, Apr 5, 2010 at 9:33 AM, <[email protected]> wrote: > Send CCIE_Security mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://onlinestudylist.com/mailman/listinfo/ccie_security > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of CCIE_Security digest..." > > > Today's Topics: > > 1. Re: FPM Examples (Paul Stewart) > 2. Re: FPM Examples (Paul Stewart) > 3. DMVPN Phase 1 (Terry Little (terlittl)) > 4. Re: FPM Examples (Kingsley Charles) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 5 Apr 2010 08:39:23 -0400 > From: Paul Stewart <[email protected]> > Subject: Re: [OSL | CCIE_Security] FPM Examples > To: Michael Davis <[email protected]> > Cc: Kingsley Charles <[email protected]>, > "[email protected]" > <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=windows-1252 > > I had the protocols loaded. This works with stack or access-control. > Stack is always a match-all where access-control can be match-any or > match all. You could explicitly match all attributes with an > access-control in a single map, or you could define a stack to a type > of protocol, then use access-control to only block a subset. For > example, I think the following would successfully block fragmented > ICMP or fragmented telnet. > > > //create a class-map subclass that can be reused > class-map type access-control match-any FRAGMENTS > //IP Flags = 3 bits (abc) > //a=unused > //b=dont fragmet > //c=more fragments > //this matches the first packet (but not the last) > match field IP flags eq 0x1 mask 0x6 > //this would not match the first fragment > //of a chain > match field IP fragment-offset gt 0 > > //create the sub-class policy > policy-map type access-control FRAGMENTS > class FRAGMENTS > drop > > //class-map for calling FRAGMENTS for TELNET > class-map type stack match-all TELNET > match field IP protocol eq 6 next TCP > match field TCP dest-port eq 23 > > //policy-map calling FRAGMENTS > policy-map type access-control MYFPM > class TCP > service-policy FRAGMENTS > > //class-map for ICMP > class-map type stack match-all ICMP > match field IP protocol eq 1 next ICMP > > //policy-map calling FRAGMENTS for ICMP traffic > policy-map type access-control ICMP > service-policy FRAGMENTS > drop > > interface > service-policy type access-control input TCP > > STACK is just a little different way of looking at the packet. You > can certainly create a single access-control that has all of the > information for each item and do the same. That might look like this. > (please note I've not tested this) > > //Match the first TELNET FRAGMENT > class-map type access-control match-all FIRSTTNFRAGMENTS > //more fragments doesn't work on the > //last fragment of a chain > match field IP flags eq 0x1 mask 0x6 > match field IP protocol eq 6 next TCP > match field TCP dest-port eq 23 > > class-map type access-control match-all LASTTNFRAGMENTS > //fragment offset does not match the > //initial fragment in a chain, but does > //match the last fragment > match field IP fragment-offset gt 0 > match field IP protocol eq 6 next TCP > match field TCP dest-port eq 23 > > //now we do the same for ICMP > class-map type access-control match-all FIRSTICMPFRAGMENTS > match field IP flags eq 0x1 mask 0x6 > match field IP protocol eq 1 next ICMP > > class-map type access-control match-all LASTSTICMPFRAGMENTS > match field IP fragment-offset gt 0 > match field IP protocol eq 1 next ICMP > > > policy-map type access-control MYFPM > class FIRSTTNFRAGMENTS > drop > class LASTTNFRAGMENTS > drop > class FIRSTICMPFRAGMENTS > drop > class LASTICMPFRAGMENTS > drop > > > So while it could be done this way as well, there is more duplicated work. > > > > On Mon, Apr 5, 2010 at 3:05 AM, Michael Davis > <[email protected]> wrote: >> I thought the stack class-map was to tie the protocol stack to the phdf.? If >> you ?load protocol? you need to create a stack class-map.? I think you lose >> a lot of the functionality without loading phdf and specifying the stack >> class-map first, ie you may not be able to match on as many fields.? Correct >> me if I am wrong. >> >> >> >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Kingsley >> Charles >> Sent: Monday, April 05, 2010 4:59 PM >> To: Paul Stewart >> Cc: [email protected] >> Subject: Re: [OSL | CCIE_Security] FPM Examples >> >> >> >> Great Paul... >> >> >> >> The following one that you have mentioned is Yusuf's Practice lab 1?task. >> >> >> >> >> >> I just tried this and observed a behavior. >> >> >> >> >> >> class-map type access-control match-all TNTOHOST >> ?match field IP dest-addr eq 192.168.30.2 >> ?match field TCP dest-port eq 23 >> policy-map type access-control TNTOHOST >> ?class TNTOHOST >> ? drop >> >> class-map type stack match-all TCP >> ?match field IP protocol eq 6 next TCP >> policy-map type access-control TCP >> ?class TCP >> ?service-policy TNTOHOST >> >> interface >> ?service-policy type access-control input TCP >> >> >> >> >> >> This can be done without?a stack class-map as following but it didn't work >> for me. >> >> >> >> >> >> class-map type access-control match-all TNTOHOST >> ?match field IP dest-addr eq 192.168.30.2 >> ?match field TCP dest-port eq 23 >> policy-map type access-control TNTOHOST >> ?class TNTOHOST >> ? drop >> >> >> >> interface >> ?service-policy type access-control TNTOHOST >> >> >> >> ok why do we need stack class map? access-control?class-map has?also?the >> "match field" option. Instead of using a stack class-map, we can use an >> "access-control" class-map alone?with "match-all". >> >> >> >> >> >> For your example "drop icmp over 1000", see the following solution: >> >> >> >> class-map type access-control match-all BIGIP >> >> ?match field IP protocol eq 1 >> ?match field IP length gt 1000 >> policy-map type access-control BIGIP >> ?class BIGIP >> ? drop >> >> interface >> ?service-policy type access-control input BIGIP >> >> >> >> Most of the cases, I think, we don't need stack class-map. But the think, I >> am not able to verify as FPM doesn't work as expected. >> >> >> >> ?Do we need stack class-map? Is it like putting L7 policy map under L4 >> policy of ZBF? >> >> >> >> >> >> With regards >> >> Kings >> >> On Mon, Apr 5, 2010 at 12:39 AM, Paul Stewart <[email protected]> wrote: >> >> I don't know about you, but every time I think I know something about >> FPM, something happens to cause me to have to humble myself. ?Bottom >> line, I still think it is buggy and possibly even more so on dot1q >> trunks. ?I have put together a few examples that you might find >> helpful. ?Of particular interest, the total length is only the length >> of each fragment in the chain. ?However, there are some examples that >> will filter all fragments (including the first by using the "more >> fragments" ip flag, and the last by using the fragment offset). >> Anyway. ?if anyone is interested. >> >> >> FPM examples >> >> >> //block all fragments >> //could be a service policy inside something that matches just ICMP >> >> class-map type access-control match-any FRAGMENTS >> ?//IP Flags ?= 3 bits (abc) >> ?//a=unused >> ?//b=dont fragmet >> ?//c=more fragments >> ?//this matches the first packet (but not the last) >> ?match field IP flags eq 0x1 mask 0x6 >> ?//this would not match the first fragment >> ?//of a chain >> ?match field IP fragment-offset gt 0 >> policy-map type access-control FRAGMENTS >> ?class FRAGMENTS >> ? drop >> >> interface >> ?service-policy type access-control input FRAGMENTS >> >> >> >> //drop telnet to a single IP >> >> class-map type access-control match-all TNTOHOST >> ?match field IP dest-addr eq 192.168.30.2 >> ?match field TCP dest-port eq 23 >> policy-map type access-control TNTOHOST >> ?class TNTOHOST >> ? drop >> >> class-map type stack match-all TCP >> ?match field IP protocol eq 6 next TCP >> policy-map type access-control TCP >> ?class TCP >> ?service-policy TNTOHOST >> >> interface >> ?service-policy type access-control input TCP >> >> >> //block all ICMP >> >> class-map type stack match-all ICMP >> ?match field IP protocol eq 1 next ICMP >> policy-map type access-control ICMP >> ?class ICMP >> ? drop >> >> interface >> ?service-policy type access-control input ICMP >> >> >> //just drop ICMPECHO >> >> class-map type access-control match-all ICMPECHO >> ?match field ICMP type eq 8 >> policy-map type access-control ICMPECHO >> ?class ICMPECHO >> ? drop >> >> class-map type stack match-all ICMP >> ?match field IP protocol eq 1 next ICMP >> policy-map type access-control ICMP >> ?class ICMP >> ?service-policy ICMPECHO >> >> interface >> ?service-policy type access-control input ICMP >> >> //drop icmp over 1000 >> >> >> class-map type access-control match-all BIGIP >> ?match field IP length gt 1000 >> policy-map type access-control BIGIP >> ?class BIGIP >> ? drop >> >> class-map type stack match-all ICMP >> ?match field IP protocol eq 1 next IP >> policy-map type access-control ICMP >> ?class ICMP >> ?service-policy BIGIP >> >> interface >> ?service-policy type access-control input ICMP >> >> >> //this works as long as no fragment >> >> >> class-map type access-control match-all BIGIP >> ?match field IP length gt 1499 >> policy-map type access-control BIGIP >> ?class BIGIP >> ? drop >> >> class-map type stack match-all ICMP >> ?match field IP protocol eq 1 next IP >> policy-map type access-control ICMP >> ?class ICMP >> ?service-policy BIGIP >> >> interface >> ?service-policy type access-control input ICMP >> >> >> //this never works on ethernet >> >> >> class-map type access-control match-all BIGIP >> ?match field IP length gt 1500 >> policy-map type access-control BIGIP >> ?class BIGIP >> ? drop >> >> class-map type stack match-all ICMP >> ?match field IP protocol eq 1 next IP >> policy-map type access-control ICMP >> ?class ICMP >> ?service-policy BIGIP >> >> interface >> ?service-policy type access-control input ICMP >> _______________________________________________ >> For more information regarding industry leading CCIE Lab training, please >> visit www.ipexpert.com >> >> > > > ------------------------------ > > Message: 2 > Date: Mon, 5 Apr 2010 09:01:49 -0400 > From: Paul Stewart <[email protected]> > Subject: Re: [OSL | CCIE_Security] FPM Examples > To: Kingsley Charles <[email protected]> > Cc: [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > Okay, I have done a bit more experimenting. The examples I gave > putting everything into a single access-control class might not work. > It seems that I can use access-control class maps alone and apply them > directly to the interface, but it does not work for me if I span > different layers of the OSI model. I'm curious if that hypothesis is > correct and we must stay in a single layer, or stay on layer 3. For > example-- > > > //this works > class-map type access-control match-all TESTTNTOHOST > match field IP dest-addr eq 192.168.30.1 > match field IP protoco eq 6 > > policy-map type access-control TESTTNTOHOST > class TESTTNTOHOST > drop > > int fa0/1 > service-policy typ access-control input TESTTNTOHOST > > //this doesn't > class-map type access-control match-all TESTTNTOHOST > match field IP dest-addr eq 192.168.30.1 > match field IP protoco eq 6 > //add some layer 4 infor > match field TCP dest-p eq 23 > > policy-map type access-control TESTTNTOHOST > class TESTTNTOHOST > drop > > int fa0/1 > service-policy typ access-control input TESTTNTOHOST > > > > > > > > > > On Mon, Apr 5, 2010 at 8:21 AM, Kingsley Charles > <[email protected]> wrote: >> I worked on my testbed and found that access-control class-maps are >> in-effective without stacks. >> >> Only the "policy-map" with stack class-map is effective and can be applied >> to an interface or control plane. The access-control class maps can be used >> only as child policy and is not effective directly under interface or >> control plane. >> >> >> >> >> With regards >> Kings >> >> On Mon, Apr 5, 2010 at 12:28 PM, Kingsley Charles >> <[email protected]> wrote: >>> >>> Great Paul... >>> >>> The following one that you have mentioned is Yusuf's Practice lab 1?task. >>> >>> >>> I just tried this and observed a behavior. >>> >>> >>> class-map type access-control match-all TNTOHOST >>> ?match field IP dest-addr eq 192.168.30.2 >>> ?match field TCP dest-port eq 23 >>> policy-map type access-control TNTOHOST >>> ?class TNTOHOST >>> ? drop >>> class-map type stack match-all TCP >>> ?match field IP protocol eq 6 next TCP >>> policy-map type access-control TCP >>> ?class TCP >>> ?service-policy TNTOHOST >>> interface >>> ?service-policy type access-control input TCP >>> >>> >>> This can be done without?a stack class-map as following but it didn't work >>> for me. >>> >>> >>> class-map type access-control match-all TNTOHOST >>> ?match field IP dest-addr eq 192.168.30.2 >>> ?match field TCP dest-port eq 23 >>> policy-map type access-control TNTOHOST >>> ?class TNTOHOST >>> ? drop >>> >>> interface >>> ?service-policy type access-control TNTOHOST >>> >>> ok why do we need stack class map? access-control?class-map has?also?the >>> "match field" option. Instead of using a stack class-map, we can use an >>> "access-control" class-map alone?with "match-all". >>> >>> >>> For your example "drop icmp over 1000", see the following solution: >>> >>> class-map type access-control match-all BIGIP >>> ?match field IP protocol eq 1 >>> ?match field IP length gt 1000 >>> policy-map type access-control BIGIP >>> ?class BIGIP >>> ? drop >>> interface >>> ?service-policy type access-control input BIGIP >>> >>> Most of the cases, I think, we don't need stack class-map. But the think, >>> I am not able to verify as FPM doesn't work as expected. >>> >>> ?Do we need stack class-map? Is it like putting L7 policy map under L4 >>> policy of ZBF? >>> >>> >>> With regards >>> Kings >>> >>> On Mon, Apr 5, 2010 at 12:39 AM, Paul Stewart <[email protected]> wrote: >>>> >>>> I don't know about you, but every time I think I know something about >>>> FPM, something happens to cause me to have to humble myself. ?Bottom >>>> line, I still think it is buggy and possibly even more so on dot1q >>>> trunks. ?I have put together a few examples that you might find >>>> helpful. ?Of particular interest, the total length is only the length >>>> of each fragment in the chain. ?However, there are some examples that >>>> will filter all fragments (including the first by using the "more >>>> fragments" ip flag, and the last by using the fragment offset). >>>> Anyway. ?if anyone is interested. >>>> >>>> >>>> FPM examples >>>> >>>> >>>> //block all fragments >>>> //could be a service policy inside something that matches just ICMP >>>> >>>> class-map type access-control match-any FRAGMENTS >>>> ?//IP Flags ?= 3 bits (abc) >>>> ?//a=unused >>>> ?//b=dont fragmet >>>> ?//c=more fragments >>>> ?//this matches the first packet (but not the last) >>>> ?match field IP flags eq 0x1 mask 0x6 >>>> ?//this would not match the first fragment >>>> ?//of a chain >>>> ?match field IP fragment-offset gt 0 >>>> policy-map type access-control FRAGMENTS >>>> ?class FRAGMENTS >>>> ? drop >>>> >>>> interface >>>> ?service-policy type access-control input FRAGMENTS >>>> >>>> >>>> >>>> //drop telnet to a single IP >>>> >>>> class-map type access-control match-all TNTOHOST >>>> ?match field IP dest-addr eq 192.168.30.2 >>>> ?match field TCP dest-port eq 23 >>>> policy-map type access-control TNTOHOST >>>> ?class TNTOHOST >>>> ? drop >>>> >>>> class-map type stack match-all TCP >>>> ?match field IP protocol eq 6 next TCP >>>> policy-map type access-control TCP >>>> ?class TCP >>>> ?service-policy TNTOHOST >>>> >>>> interface >>>> ?service-policy type access-control input TCP >>>> >>>> >>>> //block all ICMP >>>> >>>> class-map type stack match-all ICMP >>>> ?match field IP protocol eq 1 next ICMP >>>> policy-map type access-control ICMP >>>> ?class ICMP >>>> ? drop >>>> >>>> interface >>>> ?service-policy type access-control input ICMP >>>> >>>> >>>> //just drop ICMPECHO >>>> >>>> class-map type access-control match-all ICMPECHO >>>> ?match field ICMP type eq 8 >>>> policy-map type access-control ICMPECHO >>>> ?class ICMPECHO >>>> ? drop >>>> >>>> class-map type stack match-all ICMP >>>> ?match field IP protocol eq 1 next ICMP >>>> policy-map type access-control ICMP >>>> ?class ICMP >>>> ?service-policy ICMPECHO >>>> >>>> interface >>>> ?service-policy type access-control input ICMP >>>> >>>> //drop icmp over 1000 >>>> >>>> >>>> class-map type access-control match-all BIGIP >>>> ?match field IP length gt 1000 >>>> policy-map type access-control BIGIP >>>> ?class BIGIP >>>> ? drop >>>> >>>> class-map type stack match-all ICMP >>>> ?match field IP protocol eq 1 next IP >>>> policy-map type access-control ICMP >>>> ?class ICMP >>>> ?service-policy BIGIP >>>> >>>> interface >>>> ?service-policy type access-control input ICMP >>>> >>>> >>>> //this works as long as no fragment >>>> >>>> >>>> class-map type access-control match-all BIGIP >>>> ?match field IP length gt 1499 >>>> policy-map type access-control BIGIP >>>> ?class BIGIP >>>> ? drop >>>> >>>> class-map type stack match-all ICMP >>>> ?match field IP protocol eq 1 next IP >>>> policy-map type access-control ICMP >>>> ?class ICMP >>>> ?service-policy BIGIP >>>> >>>> interface >>>> ?service-policy type access-control input ICMP >>>> >>>> >>>> //this never works on ethernet >>>> >>>> >>>> class-map type access-control match-all BIGIP >>>> ?match field IP length gt 1500 >>>> policy-map type access-control BIGIP >>>> ?class BIGIP >>>> ? drop >>>> >>>> class-map type stack match-all ICMP >>>> ?match field IP protocol eq 1 next IP >>>> policy-map type access-control ICMP >>>> ?class ICMP >>>> ?service-policy BIGIP >>>> >>>> interface >>>> ?service-policy type access-control input ICMP >>>> _______________________________________________ >>>> For more information regarding industry leading CCIE Lab training, please >>>> visit www.ipexpert.com >>> >> >> > > > ------------------------------ > > Message: 3 > Date: Mon, 5 Apr 2010 06:33:43 -0700 > From: "Terry Little (terlittl)" <[email protected]> > Subject: [OSL | CCIE_Security] DMVPN Phase 1 > To: "CCIE Sec" <[email protected]> > Message-ID: > <52e903a38f544f46a2a6632ac66103ee0a485...@xmb-sjc-221.amer.cisco.com> > Content-Type: text/plain; charset="us-ascii" > > Quick question. In the DMVPN phase 1 lab (vol 1, lab 4, part 2, sec 12) > It doesn't work with tunnel mode. I don't see what in this config > requires transport mode, and generally have avoided transport mode for > DMVPN in the real world since it has always been over public networks. > > > > Looking for insight...... > > > > Terry Little > > [email protected] > Phone: +1 425 468 1057 > > Mobile: +1 425 894 4109 > > > > Cisco Systems, Inc. > > Network Consulting Engineer > World Wide Security Services Practice > Cisco.com - http://www.cisco.com > > > > This email may contain confidential and privileged material for the sole > use of the intended recipient. Any review, use, distribution or > disclosure by others is strictly prohibited. If you are not the intended > recipient (or authorized to receive for the recipient), please contact > the sender by reply email and delete all copies of this message. > > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://onlinestudylist.com/pipermail/ccie_security/attachments/20100405/ad589620/attachment-0001.htm > > ------------------------------ > > Message: 4 > Date: Mon, 5 Apr 2010 19:03:52 +0530 > From: Kingsley Charles <[email protected]> > Subject: Re: [OSL | CCIE_Security] FPM Examples > To: Paul Stewart <[email protected]> > Cc: [email protected] > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > Yes, I too see the same behavior. > > I think, this is the place where stack map class comes into picture. I > think, it tells the IOS which layer it should look next. Without stack, it > doesn't understand "match field TCP dest-p eq 23" for your case. > > > > > > With regards > Kings > > On Mon, Apr 5, 2010 at 6:31 PM, Paul Stewart <[email protected]> wrote: > >> Okay, I have done a bit more experimenting. The examples I gave >> putting everything into a single access-control class might not work. >> It seems that I can use access-control class maps alone and apply them >> directly to the interface, but it does not work for me if I span >> different layers of the OSI model. I'm curious if that hypothesis is >> correct and we must stay in a single layer, or stay on layer 3. For >> example-- >> >> >> //this works >> class-map type access-control match-all TESTTNTOHOST >> match field IP dest-addr eq 192.168.30.1 >> match field IP protoco eq 6 >> >> policy-map type access-control TESTTNTOHOST >> class TESTTNTOHOST >> drop >> >> int fa0/1 >> service-policy typ access-control input TESTTNTOHOST >> >> //this doesn't >> class-map type access-control match-all TESTTNTOHOST >> match field IP dest-addr eq 192.168.30.1 >> match field IP protoco eq 6 >> //add some layer 4 infor >> match field TCP dest-p eq 23 >> >> policy-map type access-control TESTTNTOHOST >> class TESTTNTOHOST >> drop >> >> int fa0/1 >> service-policy typ access-control input TESTTNTOHOST >> >> >> >> >> >> >> >> >> >> On Mon, Apr 5, 2010 at 8:21 AM, Kingsley Charles >> <[email protected]> wrote: >> > I worked on my testbed and found that access-control class-maps are >> > in-effective without stacks. >> > >> > Only the "policy-map" with stack class-map is effective and can be >> applied >> > to an interface or control plane. The access-control class maps can be >> used >> > only as child policy and is not effective directly under interface or >> > control plane. >> > >> > >> > >> > >> > With regards >> > Kings >> > >> > On Mon, Apr 5, 2010 at 12:28 PM, Kingsley Charles >> > <[email protected]> wrote: >> >> >> >> Great Paul... >> >> >> >> The following one that you have mentioned is Yusuf's Practice lab >> 1 task. >> >> >> >> >> >> I just tried this and observed a behavior. >> >> >> >> >> >> class-map type access-control match-all TNTOHOST >> >> match field IP dest-addr eq 192.168.30.2 >> >> match field TCP dest-port eq 23 >> >> policy-map type access-control TNTOHOST >> >> class TNTOHOST >> >> drop >> >> class-map type stack match-all TCP >> >> match field IP protocol eq 6 next TCP >> >> policy-map type access-control TCP >> >> class TCP >> >> service-policy TNTOHOST >> >> interface >> >> service-policy type access-control input TCP >> >> >> >> >> >> This can be done without a stack class-map as following but it didn't >> work >> >> for me. >> >> >> >> >> >> class-map type access-control match-all TNTOHOST >> >> match field IP dest-addr eq 192.168.30.2 >> >> match field TCP dest-port eq 23 >> >> policy-map type access-control TNTOHOST >> >> class TNTOHOST >> >> drop >> >> >> >> interface >> >> service-policy type access-control TNTOHOST >> >> >> >> ok why do we need stack class map? access-control class-map has also the >> >> "match field" option. Instead of using a stack class-map, we can use an >> >> "access-control" class-map alone with "match-all". >> >> >> >> >> >> For your example "drop icmp over 1000", see the following solution: >> >> >> >> class-map type access-control match-all BIGIP >> >> match field IP protocol eq 1 >> >> match field IP length gt 1000 >> >> policy-map type access-control BIGIP >> >> class BIGIP >> >> drop >> >> interface >> >> service-policy type access-control input BIGIP >> >> >> >> Most of the cases, I think, we don't need stack class-map. But the >> think, >> >> I am not able to verify as FPM doesn't work as expected. >> >> >> >> Do we need stack class-map? Is it like putting L7 policy map under L4 >> >> policy of ZBF? >> >> >> >> >> >> With regards >> >> Kings >> >> >> >> On Mon, Apr 5, 2010 at 12:39 AM, Paul Stewart <[email protected]> >> wrote: >> >>> >> >>> I don't know about you, but every time I think I know something about >> >>> FPM, something happens to cause me to have to humble myself. Bottom >> >>> line, I still think it is buggy and possibly even more so on dot1q >> >>> trunks. I have put together a few examples that you might find >> >>> helpful. Of particular interest, the total length is only the length >> >>> of each fragment in the chain. However, there are some examples that >> >>> will filter all fragments (including the first by using the "more >> >>> fragments" ip flag, and the last by using the fragment offset). >> >>> Anyway. if anyone is interested. >> >>> >> >>> >> >>> FPM examples >> >>> >> >>> >> >>> //block all fragments >> >>> //could be a service policy inside something that matches just ICMP >> >>> >> >>> class-map type access-control match-any FRAGMENTS >> >>> //IP Flags = 3 bits (abc) >> >>> //a=unused >> >>> //b=dont fragmet >> >>> //c=more fragments >> >>> //this matches the first packet (but not the last) >> >>> match field IP flags eq 0x1 mask 0x6 >> >>> //this would not match the first fragment >> >>> //of a chain >> >>> match field IP fragment-offset gt 0 >> >>> policy-map type access-control FRAGMENTS >> >>> class FRAGMENTS >> >>> drop >> >>> >> >>> interface >> >>> service-policy type access-control input FRAGMENTS >> >>> >> >>> >> >>> >> >>> //drop telnet to a single IP >> >>> >> >>> class-map type access-control match-all TNTOHOST >> >>> match field IP dest-addr eq 192.168.30.2 >> >>> match field TCP dest-port eq 23 >> >>> policy-map type access-control TNTOHOST >> >>> class TNTOHOST >> >>> drop >> >>> >> >>> class-map type stack match-all TCP >> >>> match field IP protocol eq 6 next TCP >> >>> policy-map type access-control TCP >> >>> class TCP >> >>> service-policy TNTOHOST >> >>> >> >>> interface >> >>> service-policy type access-control input TCP >> >>> >> >>> >> >>> //block all ICMP >> >>> >> >>> class-map type stack match-all ICMP >> >>> match field IP protocol eq 1 next ICMP >> >>> policy-map type access-control ICMP >> >>> class ICMP >> >>> drop >> >>> >> >>> interface >> >>> service-policy type access-control input ICMP >> >>> >> >>> >> >>> //just drop ICMPECHO >> >>> >> >>> class-map type access-control match-all ICMPECHO >> >>> match field ICMP type eq 8 >> >>> policy-map type access-control ICMPECHO >> >>> class ICMPECHO >> >>> drop >> >>> >> >>> class-map type stack match-all ICMP >> >>> match field IP protocol eq 1 next ICMP >> >>> policy-map type access-control ICMP >> >>> class ICMP >> >>> service-policy ICMPECHO >> >>> >> >>> interface >> >>> service-policy type access-control input ICMP >> >>> >> >>> //drop icmp over 1000 >> >>> >> >>> >> >>> class-map type access-control match-all BIGIP >> >>> match field IP length gt 1000 >> >>> policy-map type access-control BIGIP >> >>> class BIGIP >> >>> drop >> >>> >> >>> class-map type stack match-all ICMP >> >>> match field IP protocol eq 1 next IP >> >>> policy-map type access-control ICMP >> >>> class ICMP >> >>> service-policy BIGIP >> >>> >> >>> interface >> >>> service-policy type access-control input ICMP >> >>> >> >>> >> >>> //this works as long as no fragment >> >>> >> >>> >> >>> class-map type access-control match-all BIGIP >> >>> match field IP length gt 1499 >> >>> policy-map type access-control BIGIP >> >>> class BIGIP >> >>> drop >> >>> >> >>> class-map type stack match-all ICMP >> >>> match field IP protocol eq 1 next IP >> >>> policy-map type access-control ICMP >> >>> class ICMP >> >>> service-policy BIGIP >> >>> >> >>> interface >> >>> service-policy type access-control input ICMP >> >>> >> >>> >> >>> //this never works on ethernet >> >>> >> >>> >> >>> class-map type access-control match-all BIGIP >> >>> match field IP length gt 1500 >> >>> policy-map type access-control BIGIP >> >>> class BIGIP >> >>> drop >> >>> >> >>> class-map type stack match-all ICMP >> >>> match field IP protocol eq 1 next IP >> >>> policy-map type access-control ICMP >> >>> class ICMP >> >>> service-policy BIGIP >> >>> >> >>> interface >> >>> service-policy type access-control input ICMP >> >>> _______________________________________________ >> >>> For more information regarding industry leading CCIE Lab training, >> please >> >>> visit www.ipexpert.com >> >> >> > >> > >> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://onlinestudylist.com/pipermail/ccie_security/attachments/20100405/65954a66/attachment.htm > > End of CCIE_Security Digest, Vol 46, Issue 21 > ********************************************* > _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
