cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
431
Views
0
Helpful
3
Replies
Jordan Dalley
Beginner

Shape average across multiple output interfaces

Hi All,

I don't often post up on here but I've hit a snag with creating a Shape and Queue that works when the service policy is bound to output on two lan interfaces on an ASR 1001-X.

The scenario is this.

GigabitEthernet0/0/0 - WAN Interface (PIR of 400mbps from the ISP's policer)
GigabitEthernet0/0/1 - LAN Interface 1
GigabitEthernet0/0/2 - LAN Interface 2

So I have 400mbps coming in on Gi0/0/0, but what I want to achieve is a fair-queue shaper that pools the 400mbps worth of bandwidth between the two LAN interfaces. Instead it doesn't do that.. it gives 400mbps per interface with the below config, and I don't want to restrict each interface to 200mbps. I want either interface to have the full 400mbps if available.

class-map match-all cm-wan-input
 match input-interface GigabitEthernet0/0/0
!
policy-map pm-shape-lan-output
 class cm-wan-input
  shape average 400m
  fair-queue
!
interface GigabitEthernet0/0/1
 service-policy output pm-shape-lan-output
!
​interface GigabitEthernet0/0/2
 service-policy output pm-shape-lan-output
!

Has anyone encountered this issue before? Is there a way to group a service-policy between interfaces? It seems that it treats every "output" as it's own separate policy.

In a nutshell, I'd like to apply a service-policy once to a group of two interfaces.

Any help is appreciated.

3 REPLIES 3
Robert Hillcoat
Beginner

The configuration you have will not achieve this as combined the interfaces can use 800m. Essentially your creating 2 different queues. 

Check out this article it explains it well but with sub interfaces. With a particular restriction...... 

  • Applies only when multiple subinterfaces with policy maps are attached to the same physical interface. This feature cannot be used to collectively classify default traffic classes or other traffic classes of policy maps on different physical interfaces.

http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/qos_mqc/configuration/xe-3s/qos-mqc-xe-3s-book/qos-agg.html#GUID-39445D58-0857-421C-B79B-C345C768AAB3

 

Hi Robert,

Many thanks for your post, it is appreciated.

Looks like I'm toasted on this one then. I suppose the only other option is a port-channel or something, but it's not ideal as this is a hub router feeding some spokes and various vlans.

Cheers,
Jordan.

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Robert's suggestion, if you can use it, is quite good.

You use one interface with a shaper on a parent gig interface that has subinterfaces for your two VLANs.  This would accomplish your requirement.

An alternative would be to police at 400 Mbps on your ingress port (assuming it's the sole source that feeds the two egress ports).  Unfortunately, policing won't queue burst as a shaper would.

Another alternative, rather a Rube Goldberg one, would be to self loop traffic through a pair of gig interfaces "between" the existing ingress and egress ports.  You would shape there, before the traffic gets to your two physical egress ports.