cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5575
Views
0
Helpful
16
Replies

DSCP markings are being lost when traffic leaves switch?

andy roles
Level 1
Level 1

Hi,

I've just added the following commands to my 6509 switch -

mls qos

interface GigabitEthernet3/24

description *** DATA VLAN 35 - VOICE VLAN 34 ***

switchport

switchport trunk native vlan 33

switchport trunk allowed vlan 32,33

switchport mode trunk

mls qos trust dscp

no cdp enable

spanning-tree portfast trunk

!

I have a phone connected to this port and when I make calls the wireshark output (sniffing on same VLAN) show the markings as being present (e.g. DSCP = 46)

The upstream router (a Cisco 3845) has the following configuration:

!

class-map match-all IPVoice-Priority

match ip dscp ef

!

!

policy-map WAN_QoS

class IPVoice-Priority

    priority 30000

class class-default

    fair-queue

!

interface FastEthernet2/1

service-policy output WAN_QoS

when I make a VoIP call (that I know is traversing the WAN link connected to fa2/1) and run the command

show policy-map interface fastEthernet 2/0

The packet count isn't incrementing i.e. the traffic is not being identified and prioritised.  (I believe the DSCP markings are being set back to zero by the switch before the traffic leaves for the router)

The interesting thing is that if i remove the mls qos configuration from the 6509 switch the markings are left in tact and are making it to the upstream router and onwards on the WAN link.

My theory is that the switch is resetting the CoS or DSCP values before sending the traffic onwards to the router.

Can anybody tell me where I am going wrong?  i.e. how can I get the switch to trust CoS/DSCP markings as they leave the local VLAN on the 6509 switch?

16 Replies 16

andy roles
Level 1
Level 1

And... thank you!

I don't know if this could be playing a part but the 6509 switches are set up as a redundant pair with a port-channel connecting them.

I'm just wondering - if the traffic on the VLAN was leaving switch A to go via switch B if the port the traffic left switch A on could be setting the DSCP markings to zero?

Please let me know if the problem isn't clear!?

Many thanks,

Andy

Andy

I'm just wondering - if the traffic on the VLAN was leaving switch A to go via switch B if the port the traffic left switch A on could be setting the DSCP markings to zero?

Do you have mls qos trust dscp on the port channel config on switch B. Because that is an ingress port so it could be resetting it.

Jon

Hi Jon,

Thanks for your response.

I don't think the traffic is going via the other switch (B) but the other switch hasn't got the 'mls qos' command configured so it shouldn't be doing anything to the traffic.

I need to do some more granular troubleshooting I guess to figure out exactly where the markings are being reset to zero.

Do you know any debug command that will show the exact point where the makrings are being removed?  or anybody on the forum!?

Thank you,

Andy

Andy

Don't know of any debugs that can be used but i'll have a quick check.

Which module is this trunk connected to ?

Which supervisor ?

Which IOS ?

Perhaps you can post the entire config of the 6500 ?

Jon

Hi Jon/all,

Sorry for the delay.  I've been away from the office.

The trunk is connected to module 3. 

6509E-DIST-01#show module 3
Mod Ports Card Type                              Model              Serial No.
--- ----- -------------------------------------- ------------------ -----------
  3   48  SFM-capable 48 port 10/100/1000mb RJ45 WS-X6548-GE-TX     SAL09496X50

Mod MAC addresses                       Hw    Fw           Sw           Status
--- ---------------------------------- ------ ------------ ------------ -------
  3  0016.47d6.7680 to 0016.47d6.76af  10.2   7.2(1)       8.7(0.22)BUB Ok

Mod  Sub-Module                  Model              Serial       Hw     Status
---- --------------------------- ------------------ ----------- ------- -------
  3  IEEE Voice Daughter Card    WS-F6K-GE48-AF     SAL09518EAA  1.2    Ok

Mod  Online Diag Status
---- -------------------
  3  Pass

6509E-DIST-02#show module 3
Mod Ports Card Type                              Model              Serial No.
--- ----- -------------------------------------- ------------------ -----------
  3   48  SFM-capable 48 port 10/100/1000mb RJ45 WS-X6548-GE-TX     SAL1003APZF

Mod MAC addresses                       Hw    Fw           Sw           Status
--- ---------------------------------- ------ ------------ ------------ -------
  3  0016.9de0.eb78 to 0016.9de0.eba7  10.2   7.2(1)       8.7(0.22)BUB Ok

Mod  Sub-Module                  Model              Serial       Hw     Status
---- --------------------------- ------------------ ----------- ------- -------
  3  IEEE Voice Daughter Card    WS-F6K-GE48-AF     SAL1003AR3J  1.2    Ok

Mod  Online Diag Status
---- -------------------
  3  Pass

6509E-DIST-01#show module 5
Mod Ports Card Type                              Model              Serial No.
--- ----- -------------------------------------- ------------------ -----------
  5    2  Supervisor Engine 720 (Active)         WS-SUP720-3B       SAL09232SMZ

Mod MAC addresses                       Hw    Fw           Sw           Status
--- ---------------------------------- ------ ------------ ------------ -------
  5  0013.7f0d.3c1c to 0013.7f0d.3c1f   4.4   8.1(3)       12.2(33)SXH4 Ok

Mod  Sub-Module                  Model              Serial       Hw     Status
---- --------------------------- ------------------ ----------- ------- -------
  5  Policy Feature Card 3       WS-F6K-PFC3B       SAL09232N80  2.1    Ok
  5  MSFC3 Daughterboard         WS-SUP720          SAL09211PZ8  2.3    Ok

6509E-DIST-02#show module 5
Mod Ports Card Type                              Model              Serial No.
--- ----- -------------------------------------- ------------------ -----------
  5    2  Supervisor Engine 720 (Active)         WS-SUP720-3B       SAL09222278

Mod MAC addresses                       Hw    Fw           Sw           Status
--- ---------------------------------- ------ ------------ ------------ -------
  5  0013.7f0d.3020 to 0013.7f0d.3023   4.4   8.1(3)       12.2(33)SXH4 Ok

Mod  Sub-Module                  Model              Serial       Hw     Status
---- --------------------------- ------------------ ----------- ------- -------
  5  Policy Feature Card 3       WS-F6K-PFC3B       SAL0922281C  2.1    Ok
  5  MSFC3 Daughterboard         WS-SUP720          SAL09222DPX  2.3    Ok

Mod  Online Diag Status
---- -------------------
  5  Pass

6509E-DIST-01#show version

Cisco IOS Software, s72033_rp Software (s72033_rp-IPSERVICES_WAN-M), Version 12.2(33)SXH4, RELEASE SOFTWARE (fc1)

6509E-DIST-02#show version
Cisco IOS Software, s72033_rp Software (s72033_rp-IPSERVICES_WAN-M), Version 12.2(33)SXH4, RELEASE SOFTWARE (fc1)

I can send the config over to you Jon..  My email is casabas at hotmail.co.uk

Thank you.

Andy

Andy

Sorry to keep asking for outputs but can you post output of -

"sh queueing int gi3/24"

Note also that a way to guarantee the DSCP markings are preserved is to disable the DSCP rewrite command ie.

"no mls qos dscp rewrite ip dscp"

which tells the switch to leave any DSCP marking in the packet untouched. However as far as i am aware if you use the "mls qos trust dscp" command on an interface you should not need to do this as the internal DSCP value is simply the one that was received on the port and then is written into the TOS header on egress. 

Is there any other QOS config on the switch  in terms of policy maps or have you modfied any of the QOS maps on the 6500 ?

Jon

Hi Jon.

Thank you.  Whatever helps -  It's very kind of you to take your time out to assist.

The only mls config that shows up when searching for it is as follows:

RS03-6509E-DIST-ML-01#show mls qo

RS03-6509E-DIST-ML-01#show run | inc mls

mls netflow interface

no mls flow ip

mls qos map cos-dscp 0 8 16 24 32 46 48 56

mls qos

mls cef error action reset

mls qos trust dscp

mls qos trust dscp

mls qos trust dscp

RS03-6509E-DIST-ML-01#

And the output for 'sho queueing interface gig 3/24' -

RS03-6509E-DIST-ML-01#sho queueing interface gig 3/24

Interface GigabitEthernet3/24 queueing strategy:  Weighted Round-Robin

  Port QoS is enabled

  Trust state: trust DSCP

  Extend trust state: not trusted [COS = 0]

  Default COS is 0

    Queueing Mode In Tx direction: mode-cos

    Transmit queues [type = 1p2q2t]:

    Queue Id    Scheduling  Num of thresholds

    -----------------------------------------

       1         WRR low             2

       2         WRR high            2

       3         Priority            1

    WRR bandwidth ratios:  100[queue 1] 255[queue 2]

    queue-limit ratios:     70[queue 1]  15[queue 2]  15[Pri Queue]*same as Q2

    queue random-detect-min-thresholds

    ----------------------------------

      1    40[1] 70[2]

      2    40[1] 70[2]

    queue random-detect-max-thresholds

    ----------------------------------

      1    70[1] 100[2]

      2    70[1] 100[2]

    queue thresh cos-map

    ---------------------------------------

    1     1      0 1

    1     2      2 3

    2     1      4 6

    2     2      7

    3     1      5

    Queueing Mode In Rx direction: mode-cos

    Receive queues [type = 1q2t]:

    Queue Id    Scheduling  Num of thresholds

    -----------------------------------------

       1         Standard            2

    queue tail-drop-thresholds

    --------------------------

    1     100[1] 100[2]

    queue thresh cos-map

    ---------------------------------------

    1     1      0 1 2 3 4 5 6 7

    1     2     

  Packets dropped on Transmit:

    BPDU packets:  0

    queue thresh             dropped  [cos-map]

    ---------------------------------------------------

    1     1                       0  [0 1 ]

    1     2                       0  [2 3 ]

    2     1                       0  [4 6 ]

    2     2                       0* [7 ]

    3     1                       0* [5 ]

                                  * - shared transmit counter

  Packets dropped on Receive:

    BPDU packets:  0

    queue thresh              dropped  [cos-map]

    ---------------------------------------------------

    1     1                       0  [0 1 2 3 4 5 6 7 ]

RS03-6509E-DIST-ML-01#

Thank you.

Kind regards,

Andy

Andy

Can you post complete list of modules in your chassis ?  Do you have any service modules in there ?

Your last output shows that the port is showing as trusted so i can't see anything wrong there.

Jon

HI Jon,

Please see below.

Thanks again,

Andy

6509E-DIST-01#show module
Mod Ports Card Type                              Model              Serial No.
--- ----- -------------------------------------- ------------------ -----------
  1   48  48-port 10/100/1000 RJ45 EtherModule   WS-X6148A-GE-45AF  SAL1031WYF9
  2   48  48 port 10/100/1000mb EtherModule      WS-X6148-GE-45AF   SAL1022PYEH
  3   48  SFM-capable 48 port 10/100/1000mb RJ45 WS-X6548-GE-TX     SAL09496X50
  4   48  48-port 10/100/1000 RJ45 EtherModule   WS-X6148A-GE-45AF  SAL1032XC3H
  5    2  Supervisor Engine 720 (Active)         WS-SUP720-3B       SAL09232SMZ
  6    2  Supervisor Engine 720 (Hot)            WS-SUP720-3B       SAL09232SQ5
  7   48  SFM-capable 48 port 10/100/1000mb RJ45 WS-X6548-GE-TX     SAL09169GN4
  8   48  SFM-capable 48 port 10/100/1000mb RJ45 WS-X6548-GE-TX     SAL09169GG9
  9   48  SFM-capable 48 port 10/100/1000mb RJ45 WS-X6548-GE-TX     SAL09232VBT

Mod MAC addresses                       Hw    Fw           Sw           Status
--- ---------------------------------- ------ ------------ ------------ -------
  1  0018.b973.2f10 to 0018.b973.2f3f   2.0   8.4(1)       8.7(0.22)BUB Ok
  2  0018.1856.2ae8 to 0018.1856.2b17   7.0   7.2(1)       8.7(0.22)BUB Ok
  3  0016.47d6.7680 to 0016.47d6.76af  10.2   7.2(1)       8.7(0.22)BUB Ok
  4  0019.0684.1dc0 to 0019.0684.1def   2.1   8.4(1)       8.7(0.22)BUB Ok
  5  0013.7f0d.3c1c to 0013.7f0d.3c1f   4.4   8.1(3)       12.2(33)SXH4 Ok
  6  0012.dae4.5f94 to 0012.dae4.5f97   4.4   8.1(3)       12.2(33)SXH4 Ok
  7  0013.c37a.6178 to 0013.c37a.61a7  10.1   7.2(1)       8.7(0.22)BUB Ok
  8  0013.c312.6e60 to 0013.c312.6e8f  10.1   7.2(1)       8.7(0.22)BUB Ok
  9  0009.125c.704c to 0009.125c.707b  10.1   7.2(1)       8.7(0.22)BUB Ok

Mod  Sub-Module                  Model              Serial       Hw     Status
---- --------------------------- ------------------ ----------- ------- -------
  1  IEEE Voice Daughter Card    WS-F6K-48-AF       SAL1030WC3F  2.0    Ok
  2  IEEE Voice Daughter Card    WS-F6K-GE48-AF     SAL1022PVC8  1.3    Ok
  3  IEEE Voice Daughter Card    WS-F6K-GE48-AF     SAL09518EAA  1.2    Ok
  4  IEEE Voice Daughter Card    WS-F6K-48-AF       SAL1032XH3U  2.1    Ok
  5  Policy Feature Card 3       WS-F6K-PFC3B       SAL09232N80  2.1    Ok
  5  MSFC3 Daughterboard         WS-SUP720          SAL09211PZ8  2.3    Ok
  6  Policy Feature Card 3       WS-F6K-PFC3B       SAL09232N7J  2.1    Ok
  6  MSFC3 Daughterboard         WS-SUP720          SAL09232QUS  2.3    Ok
  7  Cisco Voice Daughter Card   WS-F6K-VPWR-GE     SAL091594AR  1.1    Ok
  8  Cisco Voice Daughter Card   WS-F6K-VPWR-GE     SAL09127A2H  1.1    Ok
  9  Cisco Voice Daughter Card   WS-F6K-VPWR-GE     SAL09232SWH  1.1    Ok

Mod  Online Diag Status
---- -------------------
  1  Pass
  2  Pass
  3  Pass
  4  Pass
  5  Pass
  6  Pass
  7  Pass
  8  Pass
  9  Pass
6509E-DIST-01#

edited

Jon Marshall
Hall of Fame
Hall of Fame

Andy

No, nothing there. I did find some bugs related to service modules (FWSM, IDSM) removing the DSCP marking but you don't have any of those.

Possible workarounds for you -

1) "no mls qos rewrite ip dscp"  - this will ensure the switch does not rewrite the DSCP value, assuming you are not actually wanting to change any DCSP markings on your switch ?

The problem with this command though is that it applies to all ports. So if someone connected a laptop to a port on your switch and marked all their traffic as DSCP 46 then the switch would simply pass on those packets to the router unchanged. So it removes the trust boundary if you see what i mean. The likelihood of someone doing this is probably very slim but it is worthbearing in mind.

2) remark the packets on the ingress interface of the router. The general rule with QOS is to mark as close to the source as possible so this is not ideal. In addition if you want the voice packets to go to a specific queue on the egress interface of the switch then the marking may have already been lost by then. You would also need to know the ports used by the VoIP phones to match them in a policy map.

Couple of quick questions -

1) are you sure that traffic is going from switch A direct to the router ?

2) how is the router connected to the switch ie. is it just a routed port connection between the two ?

Jon

Jon Marshall
Hall of Fame
Hall of Fame

Andy

Is the packet from the phone being marked with a CoS value as well ?

If so which value is it, presumably CoS 5.

Jon

Review Cisco Networking products for a $25 gift card