QoS "end to end"

[Wesker]

Hello guys.

The question is about prioritizing SSH traffic from my PC to Linux server:

My PC with SSH <-> Cat 9300 <-> Cat 4500 <->Cat 3750< - >Linux server

I configured policy only on Cat 9300:

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) Applied it on an uplink interface at 9300

(conf-if)#interface GigabitEthernet2/0/35
service-policy output SSH-QoS

Assuming that transit switches (Catalyst 4500 and Catalyst 3750) not altering DSCP field, do I still need to configure same policy on their uplinks?

The thing is, I collected dump (port mirroring) from the uplink at Cat 3750 and it shows that packets from my PC are correclty marked with CS2 DSCP value, but SSH packets sent back by Linux server to my PC have default AF21 marking, same story when I capture packets on Cat 9300.

[Joseph W. Doherty]

It may have changed with later IOS versions, but many older Cisco switches had, by default, QoS disabled, but if enabled, they would set ToS to zero and use a simple egress QoS policy.  The later switches, by default, also have a simple egress QoS policy but do not change ToS.

You're sure your server and other switches are not changing ToS?

[Wesker]

"You're sure your server and other switches are not changing ToS?" verifying this now, thanks

[MHM Cisco World]

The QoS is unidirectional' 

I.e. 

Client to Server 

The traffic from client to server can apply qos different than traffic from server to client.

MHM

[Joseph W. Doherty]

Correct, and although it doesn't appear to be the case here, QoS can also vary if there are multiple paths.

[MHM Cisco World]

The thing is, I collected dump (port mirroring) from the uplink at Cat 3750 and it shows that packets from my PC are correclty marked with CS2 DSCP value, but SSH packets sent back by Linux server to my PC have default AF21 marking, same story when I capture packets on Cat 9300.

It is what he ask for 

MHM

[Wesker]

But in general, it it correct to have QoS dscp marking only at catalyst
9300 uplink interface? Meaning no other devices in the network rewrite dscp
field?
I mean, initiated SSH session from my PC connected to Cat 9300 will it be
all marked with CS2 (forward and backwards ssh packets from the server)?
Like whether dscp is retained for one session even if other end device not
rewrites it?

[MHM Cisco World]

The end linux can rewrite the qos and that why you see different qos tag.

MHM

[Joseph W. Doherty]

---

@Wesker wrote:
But in general, it it correct to have QoS dscp marking only at catalyst
9300 uplink interface? Meaning no other devices in the network rewrite dscp
field?

---

In theory, actually no transit device should be marking ToS, except in two cases.  First case, host device doesn't mark properly, if at all.  Second case, there's a "good" reason why the marking needs to be changed.  The latter might be, traffic is out of some SLA or traffic is transiting to another and different QoS policy domain (i.e. for the latter, same markings may have different QoS support.)

In your case, if the host isn't marking the traffic appropriately, an ingress policy on the edge port would be the recommended place for analysis of traffic, and (re)marking ToS, if necessary.

As to how return traffic is marked, that depends on the receiving host and network devices that traffic transits, especially host's edge port.

[MHM Cisco World]

That Correct if he capture traffic within SW

If he captured traffic in wire then sure Linux rewrite value not SW.

MHM

[Joseph W. Doherty]

My guess is OP was expecting either received ToS marking to be reflected or reset to zero.  Anything else often implies a deliberate ToS marking.