QoS: Locally sourced SSH/Telnet/...

[Tymofii Dmytrenko]

Doing some packet sniffing at the moment. I noticed that SSH/Telnet packets that are returning from Cisco Catalyst 3750 switches and Cisco 2800 routers are being marked with CS6. I was aware about Control Plane protocols that mark traffic with CS6/CS7, like IP Routing Protocols, STP, NHRP and others. Haven't heard anything about SSH/Telnet though. Those belong to Management Plane. Have googled for hours to find any Cisco document with the full list of protocols and how those are being marked (CS6/CS7) if sourced locally. Found nothing.

Anyone to spill the bins?

Much appreciate

[Karsten Iwen]

For some management-traffic you can control how it's marked:

router(config)#ip ssh dscp ?

  <0-63>  ip dscp value (default value 0 )

router(config)#ip telnet tos ?

  <0-FF>  TOS value

But I also don't have a complete list available.

-- 
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni

[Tymofii Dmytrenko]

Thanks for your input... Although it haven't made it clear

Here's my config

C3750#sh run all | inc ip.ssh|ip.telnet

ip ssh time-out 120

ip ssh authentication-retries 5

ip ssh break-string ~break

ip ssh dh min size 1024

C3750(config)#ip ssh dscp ?

  <0-63>  ip dscp value (default value 0 )

Looks odd to me. As I said, Wireshark displays all returning SSH frames (that is, originated on switch) with 802.1p = 6 and DSCP = CS6. The output above states the default value has to be 0, and I don't have any commands that rewrite the default behaviour.

I have QoS enabled on the switch (mls qos) with relevant maps created. I do not have any QoS policies for the locally originated traffic in place (i.e. ip policy globall command).

Strange

[Karsten Iwen]

Yes, really odd, it seems to me that the default is not 0, but 48. But the answer-packets I see in wireshark clearly have the DSCP-values that I set with this command. You need to log out of your actual session and log in again to see the changed DSCP-value in the SSH-session.

-- 
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni

[Tymofii Dmytrenko]

Yes.

I've explicitly set DSCP to 0 and confirmed that it indeed became 0 (session has to be re-initiated). Same for Telnet, using ToS 0...

That means all IOS devices by default mark Management Plane traffic as CS6... while no official documents says about it and IOS help states those have to be 0. Nice...

Thanks for your help.

Not sure if it's a bug, not sure if it behaves same way on all IOS versions

P.S. Confirmed that WLC5508 marks SSH as DSCP 0

[Karsten Iwen]

Not sure if it's a bug, not sure if it behaves same way on all IOS versions

I remember that control-traffic is by default marked by CS6. But I don't remember where that was documented ... :-(

-- 
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni

[Tymofii Dmytrenko]

You probably refer to Control Plane traffic, which is indeed marked as CS6/CS7... and it is EIGRP/OSPF/STP/VRRP/HSRP/GLBP/IS-IS, etc...

There are tons of documents about Control Plane traffic. There is not a word about SSH/Telnet as they are Management Plane protocols.

[Josh.Walker]

I recently found this to still be true in IOS 15.5. I am really

surprised because SSH is both a terminal protocol and a file transfer

protocol. As mentioned in this post it should be in the management

plane right?

If you used the SCP server on the device to copy to another device,

the large volume of CS6 traffic could cause actual control Plane

protocol like routing protocols, NHRP, etc to tail drop.

Before the surge in VPN networks I would have just said allocate

bandwidth for CS and change CS6 to a fair queue to protect the

control plane protocols but Cisco does not support Fair-Queue of

traffic based on the pre GRE/IPSEC encapsulated packets. MPLS

providers still havent figured out that they need to turn on fair

queueing on the PE routers either (I might do a seperate write up on

how this makes us all think we need to upgrade our circuits when all

we really need is fair queue to be enabled on MPLS PE routers.)

With that said I would suggest moving SSH from your Cisco Devices to

AF33 and using WRED to drop packets 1/10 when your queue depth

reaches half. Be sure to make sure there is more than enough

bandwidth allocated to AF3X to support all your call controll

traffic.

Also, my online research seems to support that Juniper can queue

packets based on the Pre (gre/IPSEC) headers in a fair queue. Can

anybody confirm? This may give a serious competive edge to Juniper by

keeping your circuit costs down.

I think my previous comment is especially true now that most devices

support RFC1323 scaling windows and are capable of filling the

transmission queue of much larger bandwidth interfaces even when

delay is high.