From: Wade Edwards (wade.edwards@xxxxxxxxxxxxxxxxxxx)
Date: Fri Feb 15 2002 - 16:25:55 GMT-3
I would check the CPU utilization on the router and if it looks ok, like
15 to 20 percent then I would try NBAR. If it is more than that you
might want to hold off. I don't have any hard evidence on the load NBAR
has on a router but it will not hurt to try it IMHO.
Take a look at the nimda stuff on CCO on how to get this to work.
L8r.
-----Original Message-----
From: Sam Munzani [mailto:sam@munzani.com]
Sent: Friday, February 15, 2002 12:53 PM
To: Wade Edwards; Parrish, Ben
Cc: ccielab@groupstudy.com
Subject: Re: OT: Any way to block streaming audio/video?
How much processing overhead are we taking about with NBAR? If I have
dual
T1 line with 2611 router, I don't think the router can handle NBAR on
top of
it.
Sam
> If they start streaming over 80 then you can use NBAR to look that the
> packet contents and filter based upon the HTTP information.
>
> L8r.
>
> -----Original Message-----
> From: Parrish, Ben [mailto:parrisb@netsolve.net]
> Sent: Friday, February 15, 2002 11:50 AM
> To: 'Sam Munzani'; Jason Gardiner; Church, Chuck;
> ccielab@groupstudy.com
> Subject: RE: OT: Any way to block streaming audio/video?
>
> All,
> The buggers are getting smart and have started putting streaming
traffic
> over port 80. This solution may not work all the time.
>
> Benjamin Parrish
> Customer Engineering
> Austin Network Management Center
> NetSolve, Inc
>
> -----Original Message-----
> From: Sam Munzani [mailto:sam@munzani.com]
> Sent: Friday, February 15, 2002 11:24 AM
> To: Jason Gardiner; Church, Chuck; ccielab@groupstudy.com
> Subject: Re: OT: Any way to block streaming audio/video?
>
>
> I came across same situation and did it cheap way. I applied an
> access-list
> to inside interface and only permitted required traffic to go out.
e.g.
> 80,
> 443, 20, 21 etc.
>
> If there is any better way, I would definately like to know about it.
>
> Thanks,
> Sam
>
>
> > I believe that the inbound is multicast/UDP on upper ports and would
> be
> > fairly hard to block. The initial request, however, is sent
> differently,
> I
> > believe through TCP. You should be able to sniff the session setup
> and
> block
> > that packet, thus preventing the session.
> >
> >
> > On Friday 15 February 2002 10:53, Church, Chuck wrote:
> > > Anyone,
> > >
> > > Has anyone had luck blocking Windows Media Player from streaming
> > > audio sites? I've been looking at Sniffer traces this morning,
but
> don't
> > > see anything that NBAR could block. The first packet after the
> connection
> > > is established looks like this:
> > >
> > > GET /jazzfmstation HTTP/1.0
> > > Accept: */*
> > > User-Agent: NSPlayer/7.1.0.3055
> > > Host: mediaservices1.webpage-marketing.com
> > > Pragma:
> > >
>
no-cache,rate=1.000000,stream-time=0,stream-offset=0:0,request-context=1
> 285
> > >6 9540
> > > ....
> > >
> > >
> > > After that, every packet coming from the server is interpreted as
> > > 'Graphics Data' by Sniffer, but is actually the compressed audio.
> Any
> > > ideas?
> > >
> > > Thanks,
> > >
> > > Chuck Church
> > > Sr. Network Engineer
> > > CCIE #8776, MCNE, MCSE
> > > US Tennis Association
> > > 70 W. Red Oak Lane
> > > White Plains, NY 10604
> > > 914-696-7199
This archive was generated by hypermail 2.1.4 : Thu Jun 20 2002 - 13:46:24 GMT-3