i have a question regarding QoS on non-trunk links.
If i have two switches connected via a normal uplink (no trunk) and a frame is sent from one switch to another no CoS information is included in this frame as it is not a tagged frame, but how does the other switch apply QoS to this frame then. Will it use the ToS byte?
So if there is no trunk connection in the beginning, e.g. a PC is connected to an access port of the switch and the PC sends a data packet to the switch, the switch apllies QoS to this frame(if configured but in this case lets assume the switch applies a higher DSCP value to the packets on the port). So the first switch uses DSCP, as it cant use CoS, and switches the packet with high priority. But as soon as the packet is send to the other switch, again no trunk connection, how will the other switch handle the QoS part? Will it just use the ToS part?
And if so how does it work as i thought at ingress the switch would check the CoS value to see in which ingress queue to put the frame.
But with the above mentioned scenario there is no CoS value to check, but still the frame has QoS applied to it but only on L3 (DSCP).
Or can the switch check also the ToS part on an ingress port to know where to put it?
What i dont understand is, if you have two switches connected via a uplink connection (no trunk) and on the first switch you connect an ip phone for example and apply CoS on the ingress port, the frame travels through the switch with high priority but as soon as it leaves the switch on the uplink the CoS is lost. So if the second switch receives the frame it does not see any CoS and treats is as any other frame, even though there is still a ToS part. Or is the ToS part also lost? I dont think so.
So my question would be, does the second switch use the ToS part to prioritize the frame and when no CoS is received by the second switch does it apply QoS only after the frame was switched to the forwarding enginge as the port cant use the CoS to check which queue it should use.
Its hard to make clear what i mean but hope one can understand it.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...