I'm working from my phone so I apologize for a short response. With DMVPN, the packets are already tunnel via gre. So with IPSec tunnel mode, there is a third set of ip headers. Thus IPSec transport mode is more efficient.
GETVPN is a totally different animal. It uses header presevation so it copies the header. That is the reason it works only in a fully routed environment unless DMVPN is overlayed upon it. I think in recent ios, getvpn can also work in transport mode. I've never seen tunnel vs transport as a "best practice" but as a way to route rfc1918 over a public address space. On Apr 19, 2010, at 10:46 AM, "Terry Little (terlittl)" <[email protected] > wrote: > 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
