[nsp] RE: cisco-nsp Digest, Vol 5, Issue 19
Jim Dueltgen
jimd at lmi.net
Tue Apr 8 12:09:08 EDT 2003
Thanks Mark,
I'll try the OS upgrade and see if that helps. I'm a little
chagrined that I let my more colorful map and policy names slip
through...twice. So much for manual search and replace when one is
exhausted. So, yes, in the actual config the class-map and
policy-map names all match and flow through to the appropriate places
and traffic is being identified and throttled, but still the T1 is
filling up and it's all now classified as "unknown." What's strange
is that before applying the policy map the T1 was being filled with
recognized kazaa2 traffic. I'll try the OS upgrade. Thanks again.
- Jim
At 7:18 PM +0200 4/8/03, Mark Pace Balzan wrote:
>Jim,
>
>I did some playing around with nbar and 12.2(13)T, and here follows my
>feedback.
>As always, this is my opinon and experience, and I stand to be corrected:
>
>- You applied an input service policy 'operation-packet-freedom' to your
>ethernet interface.
>I liked the descriptive name, but should that not be your policy map name
>'p2p-map' ?
>
>- When I tried to match and police kazaa2 traffic, I too was left with alot
>of unknown traffic. I have via other products determined that the unknown
>traffic is indeed mainly kazaa2, which was not identified by NBAR.
>
>- The release notes for 12.2(13)T mention some issues related to nbar and
>kazaa2 traffic classification. some of these issues seem to be addressed in
>12.2(13)T2 or T3, but I havent had time to try these.
>
>
>just my two cents worth. anyone else been working in this direction, and
>care to share experiences ?
>
>
>cheers
>
>
>Mark
>
>
>
>
>> Message: 1
>> Date: Mon, 7 Apr 2003 19:32:23 -0700
>> From: Jim Dueltgen <jimd at lmi.net>
>> Subject: [nsp] NBAR unclassified traffic up as rate limiting is put
>> in place?
>> To: cisco-nsp at puck.nether.net
>> Message-ID: <p05200f0fbab7e07b90c1@[66.117.131.84]>
>> Content-Type: text/plain; charset="us-ascii" ; format="flowed"
>>
>> I'm playing around with NBAR on a 2620 running 12.2(13)T. I'm
>> looking to bandwidth limit the use of those pesky P2P apps across
>> that T1. I think I've got it implemented correctly as "sho ip nbar
>> protocol-discovery" clearly shows the kazaa2 and fasttrack (the two
>> targets of my class map) 5 minute bit rate fitting down into my
>> policy limits. However, at the same time the 5 minute bit rate of
>> all of the "unknown" traffic has grown to fill all of the bandwidth
>> made available by policy limits. The line is as saturated as ever.
>> Am I doing something wrong or are these programs getting around the
>> limits by being more clever than the PDLMs and NBAR? Here's the
>> config (only the IP addresses have been changed to protect the
>> guilty):
>>
>> class-map match-any p2p-class
>> match protocol kazaa2
>> match protocol fasttrack
>> !
>> policy-map p2p-map
>> class piggies
>> police cir 256000 bc 64000 be 128000
>> conform-action transmit
>> exceed-action drop
>> !
>> interface FastEthernet0/0
>> ip address 192.168.1.1 255.255.255.0
>> ip nbar protocol-discovery
>> speed 100
>> full-duplex
>> service-policy input operation-packet-freedom
>> !
>> interface Serial0/0
>> ip address 10.1.1.1 255.255.255.0
>> ip nbar protocol-discovery
>> no ip mroute-cache
>> service-policy input operation-packet-freedom
>>
>> Here's the current nbar info:
>>
>> FastEthernet0/0
>> Input Output
>> Protocol Packet Count Packet Count
>> Byte Count Byte Count
>> 5 minute bit rate (bps) 5 minute
>> bit rate (bps)
>> ------------------------ ------------------------
>> ------------------------
>> kazaa2 176182858 86919702
>> 146964916583 28358892324
>> 245000 67000
>> fasttrack 37788209 31714535
>> 33414399197 20906754867
> > 88000 189000
>> [...]
>> unknown 92213883 164490587
>> 54345142378 167135533630
>> 1221000 624000
>> Total 353962553 343978552
>> 246496757983 274991876201
>> 1667000 999000
>>
>> Serial0/0
>> Input Output
>> Protocol Packet Count Packet Count
>> Byte Count Byte Count
>> 5 minute bit rate (bps) 5 minute
>> bit rate (bps)
>> ------------------------ ------------------------
>> ------------------------
>> fasttrack 246486 206601
>> 253777388 106718162
>> 207000 65000
>> kazaa2 170480 383364
>> 42349405 230400940
>> 66000 185000
>> [...]
>> unknown 852688 748976
>> 516781526 692594208
>> 612000 1206000
>> Total 1391021 1463846
>> 879547644 1092559828
>> 997000 1561000
>>
>> Anyone have any experience with this they can share?
>>
>> Regards,
>>
>> Jim Dueltgen
>> LMi.net
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Mon, 7 Apr 2003 20:57:31 -0700
>> From: Jim Dueltgen <jimd at lmi.net>
>> Subject: [nsp] NBAR unclassified traffic [follow up]
>> To: cisco-nsp at puck.nether.net
>> Message-ID: <p05200f10bab7f8753328@[66.117.131.84]>
>> Content-Type: text/plain; charset="us-ascii" ; format="flowed"
>>
>> Typo in my config example under policy-map fixed here:
>>
>> class-map match-any p2p-class
>> match protocol kazaa2
>> match protocol fasttrack
>> !
>> policy-map p2p-map
>> class p2p-class
>> police cir 256000 bc 64000 be 128000
>> conform-action transmit
>> exceed-action drop
>> !
>> interface FastEthernet0/0
>> ip address 192.168.1.1 255.255.255.0
>> ip nbar protocol-discovery
>> speed 100
>> full-duplex
>> service-policy input operation-packet-freedom
>> !
>> interface Serial0/0
>> ip address 10.1.1.1 255.255.255.0
>> ip nbar protocol-discovery
>> no ip mroute-cache
>> service-policy input operation-packet-freedom
>>
>> Tried to make the config more generic looking and wound up making it
>> look like I didn't know what the heck I'm doing. That may still be
>> the case but at least it's due to something other than a typo now.
>>
>> - Jim
>
>_______________________________________________
>cisco-nsp mailing list cisco-nsp at puck.nether.net
>http://puck.nether.net/mailman/listinfo/cisco-nsp
>archive at http://puck.nether.net/pipermail/cisco-nsp/
More information about the cisco-nsp
mailing list