From: Martin, David (Contractor) (David.Martin@eu.dodea.edu)
Date: Thu Dec 16 2004 - 09:23:11 GMT-3
Hi Brian,
I need to drop p2p at my distribution layer which has a LAN, 6 E1's to the
remotes and a 34MB circuit to the core.
Should I use 'input' on the LAN and E1's and 'output' drop on the 34Meg ? Or
can I just put one drop statement on the 34meg ?
Interface Fastethenet0/0
Desc LAN
service-policy input drop_p2p
!
interface Serial2/2
Desc drop to remote site A
service-policy input drop_p2p
!
Interface serial 6/0
Desc 34MB to Core
service-policy output drop_p2p
!
policy-map drop_p2p
class p2p
police 1000000 31250 31250 conform-action drop exceed-action drop
violate-action drop
!
class-map match-any p2p
match protocol fasttrack
match protocol gnutella
match protocol edonkey
match protocol kazaa2
match protocol napster
!
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Brian McGahan
Sent: Thursday, December 16, 2004 12:28 AM
To: Lord, Chris; swm@emanon.com; Group Study; marvin greenlee
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.
> **********************************************************************
>
>
This archive was generated by hypermail 2.1.4 : Mon Jan 03 2005 - 10:31:27 GMT-3