• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

QoS

James Bond

James Bond

Diamond Member
Is QoS usually something that is implemented on the perimeter of a network and on point to point links, or is it often done in the core of a network as well?

 
You mark the packets at the edge, then you implement your QoS policy at aggregation/distribution and core layers. So it is done end to end, but the important aspect is where it is marked and the diffserv codepoints applied/changed.

The core doesn't typically need a lot of QoS because normally you don't oversubscribe the core. QoS here is more about queue management and keeping jitter consistent.
 
It depends largely on your trust boundaries. It's good practice to place the trust boundary as close to the source (and away from the core) as possible.
 
Originally posted by: Tizyler
Thanks Spidey.

So if I mark them at the edge on ingress, they stay marked as they traverse the core?
Click to expand...

I'm going to answer this assuming Cisco hardware. When packets with marked values (assuming dscp here) traverse your core, those DSCP values will be preserved upon retransmission, by default. However, once you enable qos globally:
switch(config)#mls qos

The switch is going to start treating all interfaces as untrusted, and will remark those DSCP values to 0. In order to configure any queue management in your core, you'll need to enable qos, and therefore configure trusting (at the very least) on your interfaces. There are also a whole host of other considerations once you enable qos globally.

What kind of hardware are we talking here?
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top