[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Low density Juniper (or alternative) Edge
- Subject: Low density Juniper (or alternative) Edge
- From: mark.tinka at seacom.mu (Mark Tinka)
- Date: Wed, 16 Mar 2016 09:40:28 +0200
- In-reply-to: <CAEQS+Yc=c4LfeAJDZk+FqW_nB4B-fZSn_C8+_bAUz_A9n=db7w@mail.gmail.com>
- References: <[email protected]> <[email protected]> <[email protected]> <CAEQS+Yc=c4LfeAJDZk+FqW_nB4B-fZSn_C8+_bAUz_A9n=db7w@mail.gmail.com>
On 15/Mar/16 20:14, ML-NANOG-Stefan-Jakob wrote:
>
> Do yo have more details what's wrong with the XR platform?
>
> Which hardware do we talk about and which XR version is your statement
> applying?
Well, as it turns out, I just found out and confirmed that since IOS XE
3.12S and later, Cisco introduced a new feature called Aggregate
EtherChannel Quality of Service:
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/qos_mqc/configuration/xe-3s/asr1000/qos-mqc-xe-3s-asr1000-book/qos-mqc-xe-3s-asr1000-book_chapter_01011.html
With this, you can now apply a QoS policy on a LAG port and it will work
with (almost) all QoS features without you needing to apply the policies
on the LAG member links. I still need to spend some more time testing
the policing side of things, particularly how the data plane is
programmed re: carving of configured bandwidth across member ports in
the LAG.
I also see some good work being done on the ASR920 platform (also an IOS
XE-based system), as per below:
http://www.cisco.com/c/en/us/td/docs/routers/asr920/configuration/guide/qos/qos-guidelines-xe-3-13-asr920-book.html#ID-1374-00000345