Peter,
There is no issue with MPLS. Take a look here:
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/122sx/swcg/m
plsqos.htm
Arie
________________________________
From: Peter Basquiat [mailto:[EMAIL PROTECTED]
Sent: Sunday, May 06, 2007 00:16 AM
To: Arie Vayner (avayner)
Cc: [email protected]
Subject: Re: [c-nsp] 7600 Linecard decisision
2007/5/5, Arie Vayner (avayner) <[EMAIL PROTECTED]>:
PFC can do policing (actually it has some different
policing options over the regular policing in regular IOS), but it can't
do shaping.
Queuing is done on the egress linecard.
As i understood the 1pXqXt WRR/DWRR queueing is only possible
with COS-Mapping. Does this mean that's not possible in MPLS core
to prioritize? I assume that on MPLS swapping LSR only EXP
values are available and not DSCP or Prec.
Arie
________________________________
From: Peter Basquiat
[mailto:[EMAIL PROTECTED]
Sent: Saturday, May 05, 2007 21:33 PM
To: Arie Vayner (avayner)
Cc: [email protected]
Subject: Re: [c-nsp] 7600 Linecard decisision
Arie, thanks for your answer.
When comparing this two different QoS models
with each other, where are the main differences?
Are there real disadvantages compared to
"normal" CBWFQ?
I believe that I will never use all possible
classes in CBWFQ. It seems that PFC-QoS only supports
up to 8 queues, this would be enough for our
purposes.
Per (Ethernet Subinterface/Frame-Relay VC)
Queueing/Shaping/Policing should be possible, i dont think
that the PFC isnt able to do that, right?
2007/5/5, Arie Vayner (avayner)
<[EMAIL PROTECTED]>:
Peter,
The main difference is that all the
"native" LAN modules on the 7600
(meaning all the WS-X65/67 etc) can't
actually support the "normal"
class-based QoS model, but use a
different model.
You can read about it here:
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/122sx/swcg/q
os.htm
This has to do with the way the packets
are being handled inside the
device. For the native LAN modules, all
QoS functionality is done on the
PFC, and it supports only the above QoS
functionality.
When using SIP modules (or older
OSM/FlexWan modules), the QoS
functionality (as well as other things
such as MPLS features) are
enhanced by the fact that the SIP has
extended processing resources on
the module and the software allows using
this processing power for
features which are not available on the
native LAN modules. This
explains the additional cost - the SIPs
have much more hardware on them
(such as processor, memory etc)
I think you can find some interesting
reading on the SIPs here:
http://www.cisco.com/univercd/cc/td/doc/product/core/cis7600/76sipspa/si
pspasw/index.htm
Arie
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:
[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> ] On Behalf Of Peter Basquiat
Sent: Saturday, May 05, 2007 19:09 PM
To: [email protected]
Subject: Re: [c-nsp] 7600 Linecard
decisision
It's not really clear in which direction
our QoS stuff will expand. At
the moment Iam thinking on typically
class-based wfq on core and edge.
What are the differences regarding QoS
on the WS-X6582-2PA compared to
SIP400/SPA?
Other question: talking about features,
what's with the WS-X67xx
modules, are there other/more features
available or do they have only
more bandwidth?
SIP400+SPA is much more expensive,
without knowledge about the exact
advantages it's really
hard to judge.
>Peter,
>
>Going for the SIP/SPA combination would
allow you more features
>especially
with regards to QoS and VPN PE-CE
support.
>Can you expand a bit about what kind of
core/access QoS you require?
>
>Arie
_______________________________________________
cisco-nsp mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at
http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
