From: Andy Cole (Andy.Cole@foremostfarms.com)
Date: Tue Mar 11 2008 - 17:50:52 ARST
Recently started dropping Napster in our network. We found that our
Kronos Time Clocks have been hard coded to use port 8888, which is a
Napster Port. We shut down the communication of our Time Clocks back to
our Server. We then tried to do a Custom Map and the IOS would not let
me omit the 8888 from the other ports because, 'it is a Napster Port'.
Kronos doesn't care that it is using a Napster Port, and has no
intention of making any changes.
So, be careful when you start dropping 'junk traffic' somebody out there
might be using that port for legitimate traffic.
Andy
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Tony Schaffran (GS)
Sent: Tuesday, March 11, 2008 2:33 PM
To: 'Joseph Brunner'; 'Edward Balow'; 'groupstudy'
Subject: RE: real world QOS issue
Actually, I just caught a fundamental problem with your sample config.
If you do not specify match-any or match-all in your class-map, the
default is match-all which means that a packet would need to match
kazaa, bittirent and access-list 101 to be in class junk. No packet
would match that criteria.
You need to configure a class-map match-any junk with your criteria and
then the packet that matches any one of them would be flagged for drop
in your policy-map.
Tony Schaffran
Network Analyst
CCIE #11071
CCNP, CCNA, CCDA,
NNCDS, NNCSS, CNE, MCSE
www.cconlinelabs.com
Your #1 choice for online Cisco rack rentals.
_____
From: Joseph Brunner [mailto:joe@affirmedsystems.com]
Sent: Tuesday, March 11, 2008 1:04 PM
To: 'Edward Balow'; groupstudy@cconlinelabs.com; 'groupstudy'
Subject: RE: real world QOS issue
I have had issues (perhaps someone can elaborate)
Where say you are doing this.
access-list 101 remark edonkey
access-list 101 permit tcp 10.1.1.0 0.0.0.255 any eq 4672
Class-map junk
Match protocol kazaa
Match protocol bittorent
Match access-group 101
Policy-map inbound
Class junk
Drop
Int F0/0
Service-policy input drop
Dropping TCP 4672 DOESN'T WORK. but if you do this.
Class-map junk_mark
Match protocol kazaa
Match protocol bittorent
Match access-group 101
Policy-map inbound
Class junk_mark
Set dscp cs1
Int F0/0
Service-policy input inbound
Then (now I marked it with dscp, cause it's going to be natted to
different
ip's outbound.. and we cant match ip source so easily,
But we can match dscp)
Class-map junk
Match dscp cs1
Policy-map outbound
Class junk
Drop
Interface s0/0/0
Service-policy output junk
IT WORKS!
ALL TCP to 4672 and the other stuff that was MARKED CS1 inbound on F0/0
is
DROPPED.
It was another policy dropping CS1 out of F0/0 that killed my clients
sites.
So my question is.
What causes the DROP option to ONLY work when traffic is LEAVING an
interface????
(I had this happen a lot last year with my policies to "drop all images
from
a url, but permit the site itself) the traffic had to be dropped on
router
egress to work!!!
Thanks,
Joe
_____
From: Edward Balow [mailto:ebalow@hotmail.com]
Sent: Tuesday, March 11, 2008 1:55 PM
To: Joseph Brunner; groupstudy@cconlinelabs.com; 'groupstudy'
Subject: RE: real world QOS issue
Why bother to mark stuff you want to drop? You're marking at the edge.
Why
would you want traffic you're eventually going to drop to eat up
internal
resources before being dropped at distribution? Don't mark it as
anything,
just drop it.
> From: joe@affirmedsystems.com
> To: groupstudy@cconlinelabs.com; ccielab@groupstudy.com
> Subject: RE: real world QOS issue
> Date: Tue, 11 Mar 2008 14:41:47 -0500
>
> Yeah, duh, I'm dumb...
>
> (no wonder I'm going for 3 more stars, so I can learn something)
>
> What I did in my little qos world was use CS1/Scavenger as a place to
put
> stuff I wanted to drop anyway (like kazaa, bittorrent, etc)
>
> So what is the recommended dscp for stuff you REALLY do want to drop,
even
> if there is NO congestion...
>
> Thanks,
>
> Joe
>
> -----Original Message-----
> From: Tony Schaffran (GS) [mailto:groupstudy@cconlinelabs.com]
> Sent: Tuesday, March 11, 2008 1:24 PM
> To: 'Joseph Brunner'; 'groupstudy'
> Subject: RE: real world QOS issue
>
> You would normally not drop scavenger class unless you are
experiencing
> congestion.
>
>
> Tony Schaffran
> Network Analyst
> CCIE #11071
> CCNP, CCNA, CCDA,
> NNCDS, NNCSS, CNE, MCSE
>
> www.cconlinelabs.com
> Your #1 choice for online Cisco rack rentals.
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> Joseph Brunner
> Sent: Tuesday, March 11, 2008 9:45 AM
> To: 'groupstudy'
> Subject: real world QOS issue
>
> Can anyone tell me why Sungard (and I know several of you guys work
for
> them) would mark data from their websites with CS1 ???!?!?!?!?
>
>
>
> What are you thinking? That is the scavenger class in many books and
it's
> frequently used in the real world to mark JUNK (to be dropped later).
>
>
>
> Just today I solved an issue where a client couldn't get to a few big
firm's
> website. Turns out they are all hosted on Sungard.
>
> I had to temporarily disabled the scavenger class's drop setting
>
>
>
> policy-map somepolicy
>
> class scavenger
>
> drop
>
>
>
> interface f0/0
>
> service-policy output somepolicy
>
>
>
> Take this capture image from example law firm, www.shearman.com
> <http://www.shearman.com/>
>
>
>
> http://img364.imageshack.us/my.php?image=shearmanyo5.jpg
>
>
>
>
>
> Can anyone explain this!!!
>
>
>
> Thanks,
>
>
>
> Joe
>
>
This archive was generated by hypermail 2.1.4 : Tue Apr 01 2008 - 07:53:53 ART
