cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

Community Helping Community

371
Views
5
Helpful
5
Replies
Beginner

Software Queues when Shaping on Sub Interfaces

Hi Experts,

I need some help from you to understand how the software queue would work in a situation where shaping with nested queuing is applied on sub interfaces. I understand that eacch Interface has a buffer that it uses to queue excessive packets either limited by the interface speed or the parent shaper and if the queues are also exceeded it results in tail drops. What happens in case of sub interfaces ? When HQOS is applied on subinterfaces the individual shapers on the sub interfaces backpressure the traffic and the excess traffic is queued. In this case does the queue remain the same or even the software queue is logically seperated based on the BW of each sub interface. Based on this understanding I needed to know is there any value in having a separate logical link only for Video traffic whereas the physical interface remains the same.

Regards

Umesh

1 ACCEPTED SOLUTION

Accepted Solutions
VIP Expert

On the local physical

On the local physical interface, and for what you've described, I would agree there's no real advantage separating functional traffic classes into different subinterfaces.  There's a major disadvantage, though.

By creating two subinterfaces, each shaped, neither can take advantage of the other's unused bandwidth.

Normally, the only reason you would do as you describe, if the subinterfaces will direct their traffic to different physical endpoints that you would be overrun if you sent them more than the shaped value.

View solution in original post

5 REPLIES 5
VIP Expert

I don't believe I fully

I don't believe I fully understand what you're asking.

If you shape and have QoS on subinterfaces, queuing and bandwidth applies to each, however you can still have congestion at the physical interface, and so some platforms support separate queuing/shaping there too.  I.e. if the aggregate of subinterfaces is more than the interface can deal with, you may desire QoS there too.

Highlighted
Beginner

Hi Joseph,

Hi Joseph,

Sorry for the delay in response, I will try to explain this in more details.

The provider provides a Single Ethernet handoff lets say with 20 Mbps BW. Out of this 20 Mbps 14 Mbps is dedicated on a subinterface to Data (All Application data + VOIP) and is part of the Data VRF. Second subinterface is given the remaining 6 Mbps and is for Video Conferencing is part of the Telepresence VRF.

Each subinterface has a shaper applied equal to the BW dedicated for it. It is said that the separate Telepresence VRF on a subinterface is created to ensure TP and Data + VOIP traffic are kept on separate links.

My question is whether this is really worth? Each subinterface will shape the data but physical interface remains the same. Would it not be same as having as single interface with a 20 Mbps shaper applied and dedicated queue for Video and VOIP with PQ and other Data classes as they are ?  The reason I question this is because although virtually separate queues are created but the physical interface is the same and would have the same queue ?

Thanks in advance

Regards

Umesh

VIP Expert

On the local physical

On the local physical interface, and for what you've described, I would agree there's no real advantage separating functional traffic classes into different subinterfaces.  There's a major disadvantage, though.

By creating two subinterfaces, each shaped, neither can take advantage of the other's unused bandwidth.

Normally, the only reason you would do as you describe, if the subinterfaces will direct their traffic to different physical endpoints that you would be overrun if you sent them more than the shaped value.

View solution in original post

Beginner

Hi Joseph,


Hi Joseph,

The main data VRF subinterface has shaping with LLQ and has a dedicated class for Video with matches dscp AF41 for any desktop Video traffic. The second subinteface which is the one dedicated for Telepresence also has shaping with class based queuing and again matches AF41 and reserves 96% of the VRF BW to this queue. When there are two different shapers would they not act differently based on the traffic being sent them? For example the Data VRF may not sense congestion and hence the child queueing may not come into picture. At the same moment the Video VRF faces congetion and the queueing comes into action.

The second scenario when both VRF's are congested and both shapers start queueing traffic. Will both the shapers have separate queues for their traffic? In this situation a common queue in both the VRF's matches af41 will the router assign a single queue for both the VRF's in which case the TP VRF being segmeneted would be impacted.

Lets suppose we have tow similar VRF's and shapers each having 5 similar classes viz EF, AF41, Business Critical, WEB, XYZ and on both interface the class map matches the same DSCP value. Will the router alot 10 queues 5 for one VRF and 5 to the other and provided the combines BW of the VRF's is not more than the physical interface rate each VRF will be protected from the other VRF's traffic bursts of congestiion.

I know its too many questions at a time, but I have been doing some brain stroming to understand the working and how the router would treat this configuration and came up with these questions. Hoping you can clear most of my doubts as usual :)

Thanks in advance

Regards
Umesh

VIP Expert

Laugh - yes lots of questions

Laugh - yes lots of questions.

Let's backup a step, and look at QoS, in general, which may address your questions.

Assume you have one interface with two active flows of traffic, say FTP and telnet.  Also let's assume the FTP flow is saturating the link.

If the interface only has one FIFO queue, it's likely the FTP traffic will be adverse to the telnet traffic.

To try to minimize the impact of the FTP traffic against telnet traffic, we create a policy such as:

policy-map FTPnTelnet1
 class FTP
  bandwidth 99 percent
 class telnet
  bandwidth 1 percent

Would the above "help" the telnet traffic?  It might, as we have two queues we can manage.  If telnet needs less than 1 percent of the bandwidth, the above might be needed.

However, if we use a policy such as:

policy-map FTPnTelnet2
 class FTP
  bandwidth 1 percent
 class telnet
  bandwidth 99 percent

Telnet traffic is likely to be dequeued before FTP which likely means telnet won't be impacted by the FTP traffic.  Yet, assuming telnet traffic uses very little bandwidth, the above policy barely impacts the FTP traffic.  (BTW, the above is close to treating telnet as PQ would on most Cisco switches.)

Some important take aways from the above, having different queues allows us additional control over congestion issues; the reason FTP can be adverse to telnet, they are both using the same resource.

The above might be applied to a single interface, but what if we were using subinterfaces?

You might have a policy for each subinterface:

policy-map subint1
 class FTP
  bandwidth ?? percent
policy-map subint2
 class telnet
  bandwidth ?? percent

but how should the bandwidths be assigned?

Unfortunately, we have a real problem here.  The two policies aren't managed as one.  The FTP traffic can still saturate the physical interface, but regardless of how we assign bandwidths, each subinterface stands alone.

The above might be changed to:

policy-map subint1
 class FTP
  bandwidth 99 percent
 class telnet
  bandwidth 1 percent
policy-map subint2
 class FTP
  bandwidth 99 percent
 class telnet
  bandwidth 1 percent

Now, telnet will get priority within its own subinterface, but still telnet on subinterface 2 will not get priority over FTP on subinterface 1.

If we shape each subinterface QoS policy, such that all their aggregates don't exceed the physical interface's bandwidth, then the subinterface policies might be effective, but look again at the very first policy, where FTP had 99 percent.  I.e. you can still have an issue.

The solution can be found by having QoS on both the physical and subinterfaces, but many Cisco platforms don't support this, or support it well.

I haven't worked multiple VRF as you propose, but I suspect, you're going to bump into similar issues.

CreatePlease to create content
Content for Community-Ad
FusionCharts will render here