12-17-2013 06:24 AM - edited 03-07-2019 05:07 PM
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
12-17-2013 06:56 AM
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
12-17-2013 07:16 AM
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
12-17-2013 07:52 AM
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
12-17-2013 09:48 AM
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
12-17-2013 09:54 AM
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
12-17-2013 09:56 AM
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.
07-29-2016 01:16 PM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide