From: ccie2be (ccie2be@nyc.rr.com)
Date: Wed Dec 15 2004 - 21:46:40 GMT-3
Hi Brian,
Knowing how to use the police command to drop traffic if the drop command
isn't supported is a good thing to know. But, I think the answers in this
thread are focused on something a bit different than the issue raised by the
original question.
Restating the question more broadly, what restrictions, if any, are there on
what commands can be used in the policy-map portion when match protocol is
used in the class-map portion?
Depending on the direction of the service-policy, can any of the policy-map
commands be used (obviously using shape or set fr-de on inbound packets
doesn't make sense) or are there still some combo's of match protocol and
policy-map commands that can't be used and require setting the ip prec on
an inbound interface and then matching and taking the desired action on the
outbound interface?
If there were restrictions in previous IOS releases, have any of those
restrictions been removed in the current version of IOS?
Thanks, Tim
----- Original Message -----
From: "Brian McGahan" <bmcgahan@internetworkexpert.com>
To: "Lord, Chris" <chris.lord@lorien.co.uk>; <swm@emanon.com>; "Group Study"
<ccielab@groupstudy.com>; "marvin greenlee" <marvin@ccbootcamp.com>
Sent: Wednesday, December 15, 2004 6:28 PM
Subject: RE: NBAR for Security Filtering
> Chris,
>
> Even without a version that supports unconditional packet
> discard you can still use policing to accomplish this. If both the
> conform and exceed actions are drop, the effect is the same as just
> using the "drop" keyword. For example:
>
> class-map SOMETHING
> match protocol SOMETHING
> !
> policy-map DROP_IT
> class SOMETHING
> police cir 8000 confrom-action drop exceed-action drop
> !
> Interface serial0
> Service-policy input DROP_IT
>
>
> HTH,
>
> Brian McGahan, CCIE #8593
> bmcgahan@internetworkexpert.com
>
> Internetwork Expert, Inc.
> http://www.InternetworkExpert.com
> Toll Free: 877-224-8987 x 705
> Outside US: 775-826-4344 x 705
> 24/7 Support: http://forum.internetworkexpert.com
> Live Chat: http://www.internetworkexpert.com/chat/
>
>
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of
> > Lord, Chris
> > Sent: Wednesday, December 15, 2004 1:38 PM
> > To: swm@emanon.com; Group Study; marvin greenlee
> > Subject: RE: NBAR for Security Filtering
> >
> > Many thanks for the replies. I had wondered about feature-set timing
> but
> > since the book makes several references to 12.3(4)T I'd just about
> ruled
> > that one out. Hadn't thought about performance issues though!
> >
> > Regards,
> >
> > Chris.
> >
> > -----Original Message-----
> > From: Scott Morris [mailto:swm@emanon.com]
> > Sent: 15 December 2004 18:54
> > To: Lord, Chris; 'Group Study'
> > Subject: RE: NBAR for Security Filtering
> >
> > When this book and the whitepapers were first written, 'drop' was
> likely
> > not
> > a valid entry for the policy.
> >
> > Plus there is some argument about which parts of code take more
> > processing
> > power to execute (which nobody will likely have a true answer that
> could
> > be
> > released publically anyway!).
> >
> > But mostly a timing thing.
> >
> > Scott
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of
> > Lord, Chris
> > Sent: Wednesday, December 15, 2004 1:48 PM
> > To: Group Study
> > Subject: NBAR for Security Filtering
> >
> > I was wondering whether anybody has read Deal's "Cisco Router Firewall
> > Security" book - section on using NBAR to filter attacks.
> >
> >
> >
> > The method prescribed is to craft a policy map on the inbound
> interface
> > using NBAR to detect dangerous traffic (e.g. Code Red urls), mark
> > matching
> > packets with a dscp value and then use an acl on the outbound
> interface
> > to
> > detect the dscp value and deny the traffic.
> >
> >
> >
> > Why not just drop the packets in the first place using the inbound
> > policy-map instead of letting it traverse the router first??
> >
> >
> >
> > Any views out there on this??
> >
> >
> >
> > TIA
> >
> >
> >
> > Chris.
> >
> >
> >
> > **********************************************************************
> > The information contained in this email is confidential and is
> intended
> > for
> > the recipient only. If you have received it in error, please notify us
> > immediately by reply email and then delete it from your system. Please
> > do
> > not copy it or use it for any purposes, or disclose its contents to
> any
> > other person or store or copy this information in any medium. The
> views
> > contained in this email are those of the author and not necessarily
> > those of
> > Lorien plc.
> >
> > Thank you for your co-operation.
> > **********************************************************************
> >
> >
> _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Mon Jan 03 2005 - 10:31:27 GMT-3