[nsp] NBAR, Gnutella and 'match protocol http url'

[Jim Dueltgen]

Since the 12.2.(15)T1 release we've been getting excellent, reliable 
results using NBAR to manage T1 (single and multilink) utilization on 
2620s that serve multi-tenant unit buildings.  These apartments 
mostly house college students and they hammer the circuit with every 
p2p and broadband app in existence.  The built-in PDLMs don't handle 
everything but with some careful packet analysis, the custom PDLMs 
we've added have done a great job.  No, I'm not implementing this on 
my main upstream connected router, but using NBAR at the customer end 
works perfectly well, and the 2620s don't break a CPU sweat at all.

Regards,

Jim Dueltgen
LMi.net

At 11:42 PM +0200 7/2/03, mac wrote:
>Until now nbar has proven to be non re-able feature. Avoid using it 
>on main router or switchs.
>
>Mac
>
>On Mercoledì, lug 2, 2003, at 21:32 Europe/Rome, Benjamin Setnick wrote:
>
>>Matt,
>>
>>Be very careful using the new Kazaa2 PDLM.  It is very broken.  Take a look
>>at bug CSCea26074.  We have this problem even with the "fixed" PDLM
>>installed.  It is based on some type of heuristics that can potentially
>>match any type of traffic that is not otherwise classified.  If you are
>>going to use this PDLM you MUST have ip nbar protocol-discovery turned on
>>for the interface where you are matching the traffic or you will find
>>yourself blocking all kinds of stuff you don't mean to.  You can still get
>>bitten by blocking traffic that NBAR doesn't have a built in definition for
>>(in my case ISAKMP).  To get an idea of how much traffic this would endanger
>>just look at the amount NBAR reports as unknown.
>>
>>Ben
>>
>>-----Original Message-----
>>From: cisco-nsp-bounces at puck.nether.net
>>[mailto:cisco-nsp-bounces at puck.nether.net]On Behalf Of Matt Stevens
>>Sent: Wednesday, June 25, 2003 2:52 PM
>>To: cisco-nsp at puck.nether.net
>>Subject: [nsp] NBAR, Gnutella and 'match protocol http url'
>>
>>
>>I'm doing some testing with NBAR - with the main goal of policing Fasttrack
>>and
>>Gnutella based P2P traffic.
>>
>>It seems that the Kazaa2 PDLM does a pretty good job of recognizing
>>Kazaa/Fasttrack and allowing it to be controlled. The Gnutella based traffic
>>on
>>the other hand seems to be relatively unaffected. The gnutella PDLM seems to
>>be
>>port-based and not able to track the connections when they use non-standard
>>ports.
>>
>>In the same vein trying to match gnutella traffic using 'match protocol http
>>url' statements seems to have no effect, since matching url's also seems
>>confined to traffic on port 80.
>>
>>Is this what others have experienced as well?
>>
>>The testing I'm doing is on a 2621 running 12.2(11)T8 with the kazaa2 pdlm
>>added
>>- since that's all that will fit in 64M RAM/16M Flash. Eventually this will
>>be
>>deployed on 7206VXR's. Have the PDLM's been improved any in newer releases -
>>or
>>am I seeing pretty much what one would expect?
>>
>>Thanks for any insight you all can lend.
>>--
>>matt
>>
>>
>>_______________________________________________
>>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/
>>
>>_______________________________________________
>>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/
>>
>
>
>_______________________________________________
>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/