Ingress QoS Marking - Policy Precedence

[pdavapark]

Quick question to anyone that knows the answer off the top of their head before I go checking with live captures.

Let's say I want to mark my ingress packets as follows at the access layer...

- Voice (SIP or SCCP) EF

- Video AF41

- Signaling AF31/CS3

- Anything else 0'd out (dscp default)

If I have the following relevant commands set on my interfaces...

interface GigabitEthernet x/x

 mls qos trust device cisco-phone

 service-policy input INGRESS_MARK

 And my class and policy maps look something like this (I realize this only marks SIP related packets)...

ip access-list extended signaling

 permit tcp any any eq 5060 5061

 permit udp any any eq 5060 5061

 permit tcp any any eq 2748

 permit tcp any any eq 5222 5223

 permit tcp any any eq 5222 5269

ip access-list extended video

 permit udp any eq 24575 32766 any

ip access-list extended voice

 permit udp any eq 16384 24574 any

!

class-map match-any signaling

 match access-group name signaling

class-map match-any video

 match access-group name video

class-map match-any voice

 match access-group name voice

!

policy-map INGRESS_MARK

 class C_voice-data

  set dscp EF

class C_video-data

   set dscp AF41

class C_signaling

   set dscp CS3

class class-default

  set dscp default

How will SCCP phone originated traffic end up getting marked?

I realize this should correctly mark all traffic from a Jabber client (SIP), which I do need to cover, BUT, what will happen to voice and video from SCCP phones - will the "mls qos trust device cisco-phone" keep those packets correctly marked as they were from the device (Desk phone) anyway, or will the input service-policy override that and potentially have some marked as the class-default and receive a dscp default marking?

I guess my question is this: Who will win the marking process - the input service policy or the mls qos trusted device setting on the same port?

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Believe ingress policy will override port trust statement.

[pdavapark]

Good to know, I was thinking that might be the case, but wasn't sure.

Now, the thing I can't find for the life of me - How can I differentiate between voice and video RTP streams coming from a SCCP physical phone? Markings seem to be correctly marking everything with the CDP trust, but if I put my own ingress policy on, I need to make sure that continues to happen.

 Will it follow the same rules as Jabber where it splits the available port range in half and uses one side for audio and the other for video?

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

If you trust the phone, you need an ingress policy for?

Believe you could also structure your ingress policy to trust certain markings, i.e. those expected from the phone, and analyze further other traffic.

However, if you truly want to verify all the ingress traffic, unfortunately I'm not current on how that might be done.  It might be "impossible" on most Cisco switch, assuming you need deeper packet inspection (e.g. -PISA).

[pdavapark]

The ingress policy is to cover Jabber clients, which are on just about all the same ports as we have physical phones. Some users prefer their desk phone while others prefer Jabber, so I'd like an all inclusive policy to cover all bases.

Trusting incoming DSCP has been working for the time being (Windows GPO marks Jabber packets accordingly) , just not ideal given the potential risks of rogue apps tagging packets incorrectly. 

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Regarding the issue of other traffic abuse, although ideally you may want to completely verify the "special" traffic is as expected, you can do some basic sanity checks, such as no TCP traffic should have a DSCP EF marking, etc.  And/or, you can rate limit "special traffic", so even if there's abuse, it's limited.  E.g. DSCP EF traffic is limited to 150 Kbps, ingress, on an edge port.