NBAR bug suspected in 12.4(20)T

Unanswered Question
Apr 6th, 2009

Hi guys,

I have the following config on two different routers:

class-map match-any P2P

match protocol gnutella

match protocol edonkey

match protocol kazaa2

match protocol fasttrack

match protocol bittorrent

match protocol vdolive

match protocol winmx

match protocol http url "*.torrent"

!

policy-map TrafficPolicy-OUT

class P2P

drop

class class-default

fair-queue

random-detect dscp-based

random-detect ecn

!

interface F0/0

description WAN

service-policy output TrafficPolicy-OUT

The first one is 2811 with 12.4(20)T, the second one is 1812 with 12.4(15)T1. Both routers in medium-size production networks (about 100 users, 2 servers). The second one causes little to no problems with HTTP traffic (slight slowdown felt by the users but no big pain). The first one though almost completely kills HTTP traffic - the few HTTP requests that get through are damn slowly responded (and websites almost never load completely). DNS works fine in both places. When I remove the match protocol http url command from the 2811 HTTP starts flying. Checked out the IOS Bug Toolkit for a similar problem related to 2811, nothing came up. Anyone facing a similar issue? I'm pretty sure it's an undiscovered bug but the last time I submitted bug reports to Cisco didn't have a problem finding the way to do that. Is it now done only via TAC requests? Kinda missing my partner access right now so I'm unable to open a TAC request. Besides that, as a side question, what's the process with opening TAC cases now? The last time I worked for a partner (about 2 years ago) I remember that a new Cisco policy took place and TAC cases were (highly) paid - about $2500 or something (maybe I was misinformed by the management for a purpose but that's what I remember).

Kind Regards,

Stefan Stefanov

P.S. Before someone asks why I used both match protocol bittorrent and match protocol http url "*.torrent" - the reason is that users can still connect to BitTorrent clients supporting encryption as NBAR can't catch this traffic. I wanted to mitigate the problem by filtering .torrent files from HTTP GET requests (I know some trackers support SSL or downloading the .torrent as .txt but that's the best I could do with a Cisco router).

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.

Actions

This Discussion