QoS Service Policy Directional Question

[d.hodgson]

Hi folks,

we use Modular Quality of Service to classify and mark Voice and Video Conferencing Traffic.

VC and Voice use DSCP, IP-Prec and COS.

A sample of our network is...

VideoConferencingServer1(VCS1)-Layer3Switch-Router-FrameRelayCloud-Router-Layer3Switch-VideoConferencingServer2(VCS2)

On both routers we have "service-policy out" on the FrameRelay interface. We use the command "priority percent" for Voice and Video Conferencing, everything else uses the "bandwidth" command.

So from what I understand packets from VCS1 going to VCS2 will be sent out over the frame first, this is fine, packets from VCS2 going to VCS1 will also be sent out first.

But here's where I get confused, which isn't difficult :)...

The packets from VCS1 arrive on the router at the VCS2 end, does that router then need to have a "service-policy out" on the fast ethernet so that the packets get sent out first to the Layer3Switch?

Does the same apply to the Layer 3 switch (do I have to create the same service policy), or will simply trusting the DSCP values work on the router uplink interface and the VCS interface?

I'm happy with the way QoS works mainly and our configuration, the priority percent and bandwidth commands I know, I just can't seem to get my head around the way the router handles transiting traffic from a QoS perspective.

many thanks

Dave

[bill.efthimiou]

Hi Dave,

I can't see what you QOS policy is doing, so I could miss something, but I hope the below helps.

Generally, your have an output service policy on an interface, because it is a congestion point on your network. Typically these congestion points are created by link speed mismatches, or aggregation points in the network. For example, you have a router with an Ethernet (or FastEthernet, etc) interface, taking traffic and sending it down a slower speed interface (your Frame Relay interface). Your QOS policy is an attempt to manage this congestion point in effort to ensure service to your most critical services, in this case voice and video.

If you take traffic coming in the opposite direction, you have a slower link (the Frame Relay link) taking traffic in and the router is sending out a faster link (the Ethernet). Given this scenario, you don't expect to have any congestion because the faster link will always be able to service the traffic coming in from a slower link. Therefore I don't see the point in applying a QOS policy. This is assuming the Ethernet is directly connected to the local switch ( and not going through a third party provider, etc).

If you wanted to change the QOS markings, you could change the markings using either an input or output service policy. But otherwise, I don't see the need or any additional policies.

The attached switch interface should trust whichever QOS DS fields you are marking. The idea with trust is so that you can queue in your LAN switches using the same marking you set an the originating end, rather than re-marking again.

I hope this helps.

Regards,

Bill.

[d.hodgson]

Hi Bill,

that makes sense. So does the ethernet interface do a FIFO? So priority traffic being received will be shunted out the fast ethernet interface fisrt anyway without any QoS policy?

In another scenario we have a router with multiple fast ethernet interfaces going to different subnets and sending and receiving a lot of data, the frame service is still used and carries VC traffic, in this case would I then apply a service policy out to the fast ethernet interface to the VCS?

thanks

Dave

[bill.efthimiou]

Hi Dave,

Given the defaults for an ethernet it should be FIFO. The output of a show interface, would confirm this for you. The point here however, is that you would not expect any interface congestion on the ethernet interface for egress traffic. That is, given there are only two interfaces on the router, one being a serial/Frame relay service and the other being an ethernet service.

Given your other scenario the situation may be different. In the event you have a router with two ethernets and a Frame relay, then yes, there is the potential for congestion on any of the interfaces. In this case you may want to apply an output QOS policy.

[d.hodgson]

Hi Bill,

thanks for the info mate, it's what I thought and am glad to hear it confirmed with another professional.

However can I just clarify something...

in the other scenario you mention "congestion", now that's fine if we're trying to garuantee bandwidth, but what if I want to push out Voice and VC traffic faster than anything else, so in the case of having multiple ethernet interfaces if the ethernet closest to the VCS is not congested but is sending packets through first from the other ethernet interface before forwarding the VC packets then quality will suffer, so by using an output policy and expressing the "prioirty" command it will ensure that if it receives any VC traffic it will send it out the interface closest to the VC before anything else, including traffic from the other ethernet.

Is that right?

thanks

Dave

[Joseph W. Doherty]

"The packets from VCS1 arrive on the router at the VCS2 end, does that router then need to have a "service-policy out" on the fast ethernet so that the packets get sent out first to the Layer3Switch?"

It might; depends on whether the router could offer more traffic to the link to the L3 switch than the link provides. Usually this isn't the case, but it can be.

"Does the same apply to the Layer 3 switch (do I have to create the same service policy), or will simply trusting the DSCP values work on the router uplink interface and the VCS interface?"

It could (although most L3 switches don't support QoS policies as well, or exactly like, routers), although if the VC is the only device connected to the L3 switch port, usually not. (Even if it is the only device on the L3 switch port, there are other possible issues when trying to guarantee service levels. E.g. backplane/fabric bandwidth, bandwidth to card slot, etc.)

On the issue of simply trusting DSCP values, much depends on the L3 switch's featurs and configuration. For example, some Cisco switches will pass DSCP values but not honor them with QoS support disabled, but when QoS support enabled, will reset them unless you configure to properly process them. (Then there's also L3 DSCP vs. L2 CoS issues.)

What it all basically comes down to is congestion management. Anywhere offered traffic load bandwidth can exceed available bandwidth, you might need some kind of QoS capability to guarantee the performance of some of the traffic. The most common congestion point is LAN to WAN, but for example, in your described topology I would suspect the next most likely congestion point is from the L3 switch to the router.