Cisco - PE MPLS QoS - Flexwan vs SIP-200/400

Associate
Joined
18 Oct 2002
Posts
2,413
Hi guys,

This ones aimed at the server providers folks!

Looking at the above options to expand L3 QoS capability within a Cisco 7609. Has anyone had experience with either.

Current research suggests SIP is the way to go as Flexwan (enhanced) only support the pa-2fe-fx cards, giving a total max density of only 4 x 10/100 ports.

If I was to go down the SIP-200/400 route (along, I assume I would have no problems vlan'ing off single gig ports and applying QoS policies across sub-interfaces?

Any input appreciated :)
 
Hi guys,

This ones aimed at the server providers folks!

Looking at the above options to expand L3 QoS capability within a Cisco 7609. Has anyone had experience with either.

Current research suggests SIP is the way to go as Flexwan (enhanced) only support the pa-2fe-fx cards, giving a total max density of only 4 x 10/100 ports.

If I was to go down the SIP-200/400 route (along, I assume I would have no problems vlan'ing off single gig ports and applying QoS policies across sub-interfaces?

Any input appreciated :)

Hi,

In terms of QoS on 7600s, yeah - the SIP cards are pretty much the way to go, we ended up using them to provide more 'advanced' QoS at our edge to some of our bigger customers, MPLS VPN (CBWFQ/LLQ) with 8 Cos on Gig interfaces etc, they support MPLS label imposition so you can also do core facing VPLS on them too.

In terms of breaking down an interface down into loads of sub-interfaces, I've done this on the XR 12000s just not on 7600s - only done single physical interfaces on 7600s, off the top of my head you can split 30k queues down across 2048 different sub-interfaces or something. They do LLQ a little differently - policers sometimes don't work if theres only LLQ traffic on the link and other weird stuff.

I've done loads of testing on all manner of cards, and whilst most of the time they work brilliantly, however because it's all being done on ASIC/FPGA/hardware you can sometimes run into 'restrictions' and find the particular permutation of config/scenario doesn't work the way it says it will in the QoS books if you know what I mean :) Theres also a long list of commands that aren;t supported on the SIP cards in the Cisco config guides, but most of them are trivial.

If in doubt, speak to Cisco or see if you can borrow a pair and hire a Spirent or Ixia tester then throw traffic at them, to see what happens in your specific implementation.
 
Thanks - was hoping for a detailed response like that!

I assume you normally just use basic marking and policing (i.e. mls xxx.xxx) on l2 line cards - i.e. x6748's. Is this normally sufficient to for voice/real-time traffic in a PE-CPE scenario?

Cheers mate.
 
Hi,

Yes, you can do all the vanilla MLS QoS stuff and allocate traffic to the queues/buffers/thresholds in each port, then apply it with WRR. The 67xx ports have 2x rx queues, 4x tx queues each with 8 thresholds so whilst theres a bit of granularity - it's never going to be as flexible as MQC based queueing on a SIP card.

In my experience, WRR/SRR are more suited to higher bandwidth LAN deployments, where everything is contiguous across the switch (lots of ports all with pretty much the same config)

What a lot of people don't know, is that on some 67xx cards, an 'earl' controller manages several groups of ports across each blade, (think its 4, 8 or 12 at a time) if you apply WRR values to one port - it copies that config to all other ports under its control, which isn't very good when you have a load of ports next to each other that require different settings, I may be wrong as it's been a while since I configured WRR on these cards but I'm pretty sure it plagued us to death at the time lol.
                
 
To echo somewhat, the SIP cards are the way to go from what I hear, flexwan was always a less than perfect solution, I can't offer much first hand experience here though as we've retired virtually all our core Cisco gear now in favour of Juniper and Brocade. I do know there are still generalised issues as mentioned due to the fact the 7600s are still architecturally 6500 switches no matter what Cisco say - test your config or get the vendor to certify it'll work before you hand over any cash...
 
Back
Top Bottom