[c-nsp] Cisco nbar - How to detect media streamings

[Diego Castro]

Jaime

1.- What is the result from the following command:

show ip nbar protocol-discovery stat bit-rate top-n 20

2.- In what interface had you configured this command:

ip nbar protocol-discovery

--- Velasquez Venegas Jaime Omar <jaime at ulima.edu.pe>
wrote:

> Brian,
> 
> You are absolutely right about this and in fact this
> is the approach
> I've been proposing for this problem until I might
> get a packeteer box
> :)
> I tried the configuration you suggest with a
> bandwith command in the
> policy-map , something like this:
> 
> Facingmylan0/0--------(router)-----facinginternet0/1
> 
> Congestion: From Internet to Lan
> 
> Class match-any goodapps
> Match access-group <acl with the good traffic>
> !
> Policy-map guaranteed-bandwith
> Class goodapps
> Bandwidth 1000
> !
> Interface facingmylan0/0
> Service-policy output guaranteed-bandwidth
> !
> Interface facinginternet0/1
> 
> I applied the guaranteed-bandwdth policy in the
> router interface
> connected to my lan because Cisco IOS won't accept
> the same policy
> applied in input direction:
> 
> Interface facinginternet0/1 
> Service-policy input guaranteed-bandwidth
> 
> Thank you for your time,
> 
> 
>  
> 
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf
> Of Brian McMahon
> Sent: Viernes, 23 de Junio de 2006 05:25 p.m.
> To: cisco-nsp
> Subject: Re: [c-nsp] Cisco nbar - How to detect
> media streamings
> 
> 
> On Jun 23, 2006, at 14:51, Matt Stevens wrote:
> 
> > Yeah, that might be a tough one. Since Cisco has
> never opened up the 
> > protocol description language they use, it's
> pretty much impossible to
> 
> > do a custom PDLM. And custom.pdlm doesn't count
> :-)
> >
> > The only solution I can think of would be use a
> web cache.
> 
> Ayup.  Or -- the best we could come up with is to
> carve out a chunk of
> bandwidth guaranteed to known-GOOD traffic (e.g.,
> http to specific
> servers on campus, microsoft cruft, etc.), corral
> all the known-BAD
> traffic (the parts we can categorize reliably) into
> its own
> (restricted) slice of bandwidth, and then let the
> remaining {good|bad|
> ugly} duke it out for whatever bits are left.
> 
> At least that way, when some Kl0wn sets up Kazaa on
> some open-access PC
> at our remote campus on the other end of 2xT1, we
> don't start getting
> authentication failures in the labs there because
> the poor dumb boxes
> can't talk to the domain controllers any more.
> 
> When it comes to our own internal infrastructure, we
> are far from "net
> neutral"!
> 
> --
> Brian McMahon <brian dot mcmahon at cabrillo dot
> edu> Computer
> Networking and System Administration Instructor
> Cabrillo College, Aptos,
> California
> 
> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://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
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at
> http://puck.nether.net/pipermail/cisco-nsp/
>