QoS DSCP

[Wesker]

Hi everyone, to prioritize port 22 traffic(to avoid congestion) is the below sufficient? Or it is needed to be added bandwidth allocation like # bandwidth 50; # police 200000 conform-action transmit etc? I mean does the switch prioritize packets based solely on their DSCP marking(CS2 goes before CS0 etc) or do I need to specify bandwidth, policing etc n step "3"?

Here's my config: 

1)

access-list 101 permit tcp any any eq 22

2)

class-map SSH
match access-group 101

3)

policy-map SSH-QoS
class SSH
set dscp cs2

4) **Apply/or remove at the needed interface (uplinks , to Po members)**

interface GigabitEthernet2/0/35
service-policy output SSH-QoS

[David Ruess]

Hello,

From what it looks like you have just identified the traffic. You would also need to prioritize it with specific values as you mentioned above. I don't know what the default would be if unspecified. If I had to guess its the default of FIFO.

-David

[Wesker]

I was under impression that catalyst 9300 (17.4) switch will prioritize based only on DSCP markings priority tables without specifying bandwidth/policing/shaping. I did collect traffic dump and it does show correct markings.

[DenisBrowne]

---

@Weskercompassmobile wrote:

Hi everyone, to prioritize port 22 traffic(to avoid congestion) is the below sufficient? Or it is needed to be added bandwidth allocation like # bandwidth 50; # police 200000 conform-action transmit etc? I mean does the switch prioritize packets based solely on their DSCP marking(CS2 goes before CS0 etc) or do I need to specify bandwidth, policing etc n step "3"?

Here's my config: 

1)

access-list 101 permit tcp any any eq 22

2)

class-map SSH
match access-group 101

3)

policy-map SSH-QoS
class SSH
set dscp cs2

4) **Apply/or remove at the needed interface (uplinks , to Po members)**

interface GigabitEthernet2/0/35
service-policy output SSH-QoS

---

The DSCP marking alone classifies the traffic but does not ensure bandwidth or priority management. For effective QoS, you should also configure bandwidth allocation and policing. Without these, the switch may still default to FIFO, impacting performance. Adding these settings will give you better control over traffic handling.

[Joseph W. Doherty]

Later Cisco switch QoS implementations usually have a "default" egress policy, which often takes into account the ToS marking, and may vary by device.

Since yours device is a 9K switch (?), but you've defined an egress policy, that policy does tag that class matched traffic with CS2, which downstream devices may chose, or not, to treat specifically.  On this device, any egress CBWFQ policy has an implicit default-class and I believe, unless you exceed 8 egress queues (on a 9k), your SSH class will have a dedicated egress queue.  What I don't know is how bandwidth ratios are implicitly split between this class and class-default.  There's likely some "default" bandwidth split (which may vary across devices or even IOS versions), so I always suggest (as you've gone to the trouble to have an explicit class), you define how you want this class and class-default to manage bandwidth.

BTW, one issue I once ran into with SSH, you cannot tell it apart from SCP.  The two, SSH vs. SCP, should normally have very different QoS allocations.

[Wesker]

Thanks everyone for the input, I did apply the following but as soon as I enable marking on a end device port(step 3), it (this device) can not ping any hosts located on another switch, traceroute works well.  After I remove "input" marking policy from the port, ping starts to work well again. Could it be that some intermediary device, let's say firewall, filters  packets with CS2 dscp? sounds unrealistic but still there's something...

Single switch:

0)

#sh access-lists 101
Extended IP access list 101
10 permit tcp any any eq 22
20 permit tcp any eq 22 any
30 permit udp any any eq snmp
40 permit udp any any eq snmptrap
50 permit udp any eq snmp any
60 permit udp any eq snmptrap any
70 permit icmp any host 192.168.96.59 echo
80 permit icmp any host 192.168.96.59 echo-reply
90 permit icmp host 192.168.96.59 any echo
100 permit icmp host 192.168.96.59 any echo-reply

1) 

class-map match-all QoS-Queueing
match dscp cs2

class-map match-all QoS-Marking
match access-group 101

2) applying on uplink as "output" direction policy

policy-map QoS-Queueing-Policy
  class QoS-Queueing
   bandwidth percent 2

3)Applying on a end device port in "input" direction 

policy-map QoS-Marking-Policy
class QoS-Marking
set dscp cs2

[Joseph W. Doherty]

---

@Wesker wrote:

Thanks everyone for the input, I did apply the following but as soon as I enable marking on a end device port(step 3), it (this device) can not ping any hosts located on another switch, traceroute works well.  After I remove "input" marking policy from the port, ping starts to work well again. Could it be that some intermediary device, let's say firewall, filters  packets with CS2 dscp? sounds unrealistic but still there's something...

---

Yes, a FW could do that, although seems unusual for one to do so.

What do your policy stats show?

I don't see any glaring errors that would cause the result you describe.  However, you're ACL is set up for bidirectional traffic, but only host port edge traffic would be subject to it.  I.e. it has ACEs that should never be matched.

[Wesker]

UPDATE: after I removed "20 permit tcp any eq 22 any" from access list ping started to work

[Joseph W. Doherty]

---

@Wesker wrote:

UPDATE: after I removed "20 permit tcp any eq 22 any" from access list ping started to work

---

That's interesting!

Ping doesn't use TCP and that ACE would be applicable to return SSH traffic.  I.e. unclear you would be matching on it, at all (unless packet coming from a SSH server), and even if you did, why setting ToS to CS2 should matter, isn't clear.

[Wesker]

By not working, I meant packets arriving at my computer are not marked CS2
(they are AF21). To test this, I initiate ssh connection to my computer
from that remote device connected to 1/0/29

[Joseph W. Doherty]

"By not working, I meant packets arriving at my computer are not marked CS2 (they are AF21). To test this, I initiate ssh connection to my computer from that remote device connected to 1/0/29"

From what you've posted, that should not be the case.

[Wesker]

Seem like ingress marking is not working, port g1/0/29 and 2/0/29 connected to device initiating SSH, although making policy counters are increasing..

my PC <--> Cat 9300 <-->Cat 4500  <-->[uplink queue output policy Te1/1/1, 2/1/1]Cat 9300  <-->[ingress marking policy g1/0/29, g2/0/29] end device 

as far as I can see neither Cat 9300 or Cat 4500 do change dscp markings so it should be trusted by default...

both uplink and device port are  part of a port channel, second interface having same policy applied although only 2/0/29 counters are increasing.

#sh policy-map interface

GigabitEthernet1/0/29

Service-policy input: QoS-Marking-Policy

Class-map: QoS-Marking (match-all)
0 packets
Match: access-group 102
QoS Set
dscp cs2

Class-map: class-default (match-any)
588 packets
Match: any
TenGigabitEthernet1/1/1

GigabitEthernet2/0/29

Service-policy input: QoS-Marking-Policy

Class-map: QoS-Marking (match-all)
***********65 packets *********
Match: access-group 102
QoS Set
dscp cs2

Class-map: class-default (match-any)
8017 packets
Match: any

[jamesmick]

---

@Weskershermanoaks wrote:

Hi everyone, to prioritize port 22 traffic(to avoid congestion) is the below sufficient? Or it is needed to be added bandwidth allocation like # bandwidth 50; # police 200000 conform-action transmit etc? I mean does the switch prioritize packets based solely on their DSCP marking(CS2 goes before CS0 etc) or do I need to specify bandwidth, policing etc n step "3"?

Here's my config: 

1)

access-list 101 permit tcp any any eq 22

2)

class-map SSH
match access-group 101

3)

policy-map SSH-QoS
class SSH
set dscp cs2

4) **Apply/or remove at the needed interface (uplinks , to Po members)**

interface GigabitEthernet2/0/35
service-policy output SSH-QoS

---

Prioritizing port 22 traffic using DSCP marking alone will prioritize the packets, but it doesn't guarantee bandwidth or prevent congestion. To ensure consistent performance, you should also configure bandwidth allocation and policing. This way, the switch not only prioritizes the traffic but also reserves the necessary resources to maintain performance under heavy load.

[Joseph W. Doherty]

"Prioritizing port 22 traffic using DSCP marking alone will prioritize the packets . . ."

In general or OP policy explicitly?

In general, it depends on QoS config.

For OP policy, there are two classes, one explicit, and one (class-default) implicit.  So, used as egress policy, as in OP, CS2 does obtain differential treatment, but really not prioritized treatment, although a different policy could so provide.  As its own non-LLQ class, it should, though, have a guarantee of some minimum bandwidth.