Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
Step-by-Step Configuration and Troubleshooting Best Practices for the NGFW, NGIPS and AMP Technologies A Visual Guide to the Cisco Firepower Threat Defense (FTD)
Community Member

NBAR bug suspected in 12.4(20)T

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


class class-default


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).

CreatePlease to create content