Expedited Forwarding (EF) Denial of Service Attack

Unanswered Question
Jan 7th, 2008
User Badges:

Hi Guys,


A Quickie for you :)


If you enable QoS and classifying voice (RTP) for EF. what happens if someone tries to saturate the network with say 100Mb of EF, and how would this have affect say an uplink from an access to a distribution?


Lets say the tx-q on a 6500 (1p2q1t) with the command "set qos txq-ratio 1p2q1t 30 40 30"


and


someone sending 100Mb EF traffic, and the uplink was 1g trunk, would the SP always get serviced and starve other traffic in this particular scenario?


Many thx for you help.


Regards,

Ken

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Jon Marshall Mon, 01/07/2008 - 12:20
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Ken


The recommended design is to police the EF queue. So you allocate the bandwidth you need for EF traffic but you then police any badnwidth above that to ensure you do not starve all the other queues.


With CBWFQ that is what happens with the prioriy command using LLQ - the traffic is policed.


If you do not police the traffic then yes you could well end up starvng the other queues.


HTH


Jon

dominic.caron Mon, 01/07/2008 - 12:33
User Badges:
  • Silver, 250 points or more

You can re-mark on the access (and 6500) switch the packets.


mls qos map policed-dscp 0 24 to 8

class-map match all vlan-voice

match access group ...

class-map match all vlan-any

match access group ...


policy-map EFpolicing

class vlan-voice

set ip dscp 46

police 128000 8000 exceed-action policed-dscp-transmit


class vlan-any

set ip dscp 0

police 5000000 8000 exceed-action policed-dscp-transmit


and... you apply this to you access port. Same thing can be done on the 6500. Excess trafic will be re-mark to CS1.


please rate helpful post



chschroe Mon, 01/07/2008 - 20:22
User Badges:

You can't just trust everyone is the issue.


If you're worried about from your access ports out to the rest of the network, you have to define the trust boundary to only trust the phones, and not the users.


With a cisco phone, you would define that as mls qos trust cisco-phone.


Otherwise, you have to classify using access lists and more tangible data, then trust just the devices that need be and don't trust the others.


You have to be very careful how you classify at the edge.


NS

kfarrington Tue, 01/08/2008 - 00:28
User Badges:

All,


This is excellent stuff and some brillian posts.


Many thx,


So in essense, policing and trust to the IP phones only is the way to go.


With the trust point, if we are not trusting and using VLAN ACLs to classify, this means that the only possible way is to use policing. Correct? Also, this is under CatOS and would need to configure policing on this. Would I do this on a per vlan or per port basis?


I am just about to read up on policing on CatOS to understand.


Really, great replies guys :))))


Many thx

Ken

Jon Marshall Tue, 01/08/2008 - 00:34
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Ken


I will need to lookup CatOS too :).


As for the policing and trusting, it really depends. I have seen recommendations to trust the phone if it marks and others where it says not to.


The key thing about it is that you trust packets when you can guarantee that they have been marked correctly. You CAN guarantee theyy have been marked correctly on your edge switches because you control those and users do not have access to them.


The same cannot be said of the phone/PC so if you want to be really sure classify and mark the packets on your edge switches and then trust from there.


Jon

kfarrington Tue, 01/08/2008 - 00:37
User Badges:

Jon, That seems like the sensible solution to me. Dont trust phone/PC and to classify and trust from then on in. Im sure there will be other people that have a difference of opinon, and would love to hear the other side to this :))


Great stuff man :)


Ken

Actions

This Discussion