[c-nsp] Cisco IOS/XE :: H-QoS for Multi-VRF / Sub-interface setup

eyeballi77 eyeballi77 at gmail.com
Tue Jun 28 07:56:13 EDT 2016


Thanks Brian..  appreciate the detailed response!

In the following for native IOS; the examples show that the fragment
function is applied to default class and the restriction section of (
http://goo.gl/bp47Dy) specifies only default class.

http://goo.gl/uqJ8T3

As the traffic I am looking to aggregate would be in a higher class, it
looks as if the answer to my query is that it is not possible for anything
other than default class.

Regards,
Neil


On 24 June 2016 at 13:54, Brian Turnbow <b.turnbow at twt.it> wrote:

> Hi Niel,
>
>
>
> Fragment creates an upper level so to speak, bandwidth that you can use in
> your policies
>
>
>
> You create   an aggregate policy and declare a service fragment tag
>
>
>
> policy-map aggregate-member-link
>
>   class BIGAGG service-fragment aggr1
>
>   shape average 10000000
>
>
>
> and then use it in your parent policy
>
>
>
> policy-map parent
>
>   class class-default fragment aggr1
>
>   shape average 5000000
>
>   service-policy child-if-needed
>
> !
>
> !
>
>
>
>
>
>  The aggregate goes to the main interface
>
> interface GigabitEthernet0/0/3
>
> no ip address
>
> load-interval 30
>
> negotiation auto
>
> service-policy output aggregate-member-link
>
> !
>
>
>
> And the policies go on the sub interfaces
>
>
>
> interface GigabitEthernet0/0/3.10
>
> encapsulation dot1Q 10
>
> ip address 172.1.2.200 255.255.255.0
>
> service-policy output parent
>
> !
>
> interface GigabitEthernet0/0/3.11
>
> encapsulation dot1Q 11
>
> ip address 172.2.2.200 255.255.255.0
>
> service-policy output parent
>
>
>
>  interface GigabitEthernet0/0/3.12
>
> encapsulation dot1Q 12
>
> ip address 172.2.3.200 255.255.255.0
>
> service-policy output parent
>
>
>
> HTH
>
>
>
> Brian
>
>
>
> *From:* neil.g.morris at gmail.com [mailto:neil.g.morris at gmail.com] *On
> Behalf Of *eyeballi77
> *Sent:* venerdì 24 giugno 2016 14:25
> *To:* Brian Turnbow
> *Cc:* cisco-nsp at puck.nether.net; eyeballi77 at gmail.com
> *Subject:* Re: [c-nsp] Cisco IOS/XE :: H-QoS for Multi-VRF /
> Sub-interface setup
>
>
>
> Thanks Brian for your response,
>
>
>
> I have also looked into this also under our previous topic (
> http://goo.gl/wmVffr), but I believe this approach shares the default
> class through the fragment key word (if I understand it correctly).
>
>
>
> The key point that I need input on is the ability to use qos-groups across
> the multiple VRF's to shape the common traffic classes to a single
> bandwidth.
>
>
>
>
>
>
>
> On 24 June 2016 at 12:23, Brian Turnbow <b.turnbow at twt.it> wrote:
>
> Hi,
>
> try taking a look at service-fragment.
> It will work on subinterfaces, but I'm not sure about using it with
> different vrfs.....
>
>
> 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
>
>
> Brian
>
>
>
> > -----Original Message-----
> > From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of
> > eyeballi77
> > Sent: venerdě 24 giugno 2016 10:45
> > To: cisco-nsp at puck.nether.net
> > Subject: [c-nsp] Cisco IOS/XE :: H-QoS for Multi-VRF / Sub-interface
> setup
> >
> > Hi all,
> >
> > Can you help clarify for me on my understanding of the above.  I have a
> > 10Mb cct and want share the overall bandwidth across all VRF's/sub-
> > interfaces as opposed to dedicating specific chunks of bandwidth to
> specific
> > VRF/interfaces.
> >
> > By placing the parent policy on the physical interface with multiple
> child
> > policies relating to each of the VRF's.
> >
> > My thinking being that traffic will be classified from each vrf to a
> qos-group
> > and the child policies with match/police/shape based on the qos-groups.
> >
> > Appreciate any guidance/input
> >
> > Neil
>
> > _______________________________________________
> > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
>


More information about the cisco-nsp mailing list