John,
we are considering these nexus switches as a core for a small (for now)
exchange point, so there will definitely be multiple ports talking to
one and vice versa. Let's say the switch would be utilized up to 90% (45
ports in case of 5548, 90 in case of 5596), half of the active ports
would handle around 8 Gbps. The rest would be utilized up to 3 Gbps.
Whole amount of a traffic would be standard Internet flows.
This gives me real utilization of 240 Gbps or 500 Gbps in case of 5596.
These are of course extreme values which will not be reached, but I need
to know limits of this platform regarding to this use-case.
Thanks,
Jiri Prochazka
Dne 31.1.2012 0:52, John Gill napsal(a):
Hi Jiri,
This sounds pretty straightfoward, the thing you need to look at most
closely now is the traffic flows. Being all 10G is good because you
will be cut-through switching unless there is congestion, which causes
you to queue (store and forward).
Do you expect multiple ports to be talking to one port at the same
time? If this is the case, your decision will need to include how
much buffering you require to be able to handle this congestion.
The common misunderstandings I see on this platform vs some other
switches are the concept of cut-through switching and ingress queuing.
Cut-through switching results in errors not being detected until after
a frame is transmitted, so we may see one initial error increment
errors across multiple switch hops - the advantage is low latency and
low jitter. With ingress queuing, you have to look for queuing
discards on the input port so knowing your traffic patterns is very
helpful for understanding where congestion could occur. The switch
spreads congestion out amongst all input ports so every port
contributing to the congestion is responsible to handle it's own
queue. To be clear, the fabric is non-blocking, but you can always
have scenarios where you have 2+ ports sending to 1 port. This can
happen for a short time, but not indefinitely without queue drops.
This 5548P architecture document certainly applies for the 5596UP,
except we have more ports and a scaled up fabric. The "U" designates
the ports are Universal, meaning they can be configured for ethernet
or fibrechannel.
http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9670/ps11215/white_paper_c11-622479.html
Obviously I am telling you what cisco has already available, but I am
interested in you getting what you think you're getting. I am not in
sales, I am involved in support for this platform. I will hear about
it if something is not up to expectations or goes badly.
Regards,
John Gill
cisco
On 1/27/12 5:13 PM, Jiri Prochazka wrote:
John,
thank you for a reply. I am interrested in unicast traffic only, no L3,
no QoS requirements, low-latency is not needed, 10G ports only. Switches
would be used for a standard Internet traffic flows.
I am really interrested in these switches, but I don't want to buy a pig
in a poke..
Regards,
Jiri Prochazka
Dne 27.1.2012 22:19, John Gill napsal(a):
Hi Jiri,
The bandwidth to the fabric is dedicated and the expansion modules
have their own forwarding engines on them, so they are no different
than the base ports except that they can be swapped out.
What kind of traffic are you interested in running? Unicast,
multicast, QoS requirements? Do you have low-latency requirements? 10G
or 1G? Do you know how much buffering you would need with your traffic
flows? Or is this mostly fact finding for now? Let me know if you have
any specific rumors as well.
Regards,
John Gill
cisco
On 1/26/12 8:30 PM, Jiri Prochazka wrote:
Hi,
we are considering investment in a few Nexus 5596 switches. All Cisco
documents say it has 96 non-blocking 10G ports (for L2). Is it
_really_
true? Can the switch reach throughput of 960 Gbps regardless the
traffic
distribution? Is't there some hidden limitaion, which is not presented
by Cisco? :-) I've heard some rumors about this, but nothing
particular.
First thig which comes to my mind is a doubt, if all three expansion
modules really do have 160 Gbps connection to the fabric..
Thank you for comments,
Jiri
_______________________________________________
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/
