[c-nsp] ASR1000 support of policing on etherchannel

Dmitry Kiselev dmitry at dmitry.net
Mon Dec 6 16:18:34 EST 2010


Hello!

On Sat, Dec 04, 2010 at 01:56:34PM +1300, Pshem Kowalczyk wrote:

> > Does somebody in the list have any info about plans to support policing on etherchannel on ASR1000 platform? Both trains 12.2 and 15.0 does not support it. :(
> >
> > Restrictions for Traffic Policing
> >  - Traffic policing is not supported on the EtherChannel interfaces.
> 
> To be honest I would not expect that any time soon. If you consider
> that your interfaces can be on different SIPs and that near realtime
> communication between is required to do shaping or policing you can
> see the complexity of the task.


It's looks slightly strange becouse of centalized forwarding paradigm hidden behind ESP/QFP.
Moreover, really distributed platforms like ASR9K and CRS supports all QoS features for etherchannels. I mean, sync for queueing and policing between different Trident chips is possible in realtime and already done:

QoS and Link Bundling
 - The Link Bundling feature supports all the QoS features ... <snip>
http://www.cisco.com/en/US/docs/routers/asr9000/software/asr9k_r4.0/qos/configuration/guide/qc40link_bundle.html#wp1234832


> Since we encountered exactly the same problem we decided to go down a
> slightly different route. We only use 2 links (or potentially 4 links)
> EtherChannels to allow for more equal load balancing. Then we apply
> somewhat more relaxed (in comparison with what we want to achieve)
> policies to the physical interfaces that constitute the bundle. It's
> not ideal, but so far this is the only way around we found. This is
> for outbound only as well. For inbound traffic we relay on the other
> end of the links.


Thanks for hint, I will try it. It is better than nothing :)


-- 
Dmitry Kiselev


More information about the cisco-nsp mailing list