Jesper,
Nice sig, actually we do believe it to be a issue, in doing CEF feature
testing we too discovered we could support sending packets out of sequence,
and the knock on effect to the end applications, not just voice & video.
http://www.cisco.com/univercd/cc/td/doc/product/software/ios112/ios112p/gsr/
cef.htm#xtocid2626427
Please see http://puck.nether.net/cisco-nsp/packet_reordering1.pdf this is
an IEEE document and
http://puck.nether.net/cisco-nsp/Router_Arch_WP_129-31.pdf a Cisco white
paper on the subject of architectures, these are in the public domain.
>Juniper also said they will come out with a solution where the Packet
>Director will ensure that all packets in a flow will always go to
>the same I/O manager/SFM thus there will be no packet reordering.
On the 160 if the Packet Director has the task of receiving the inbound
packets from the physical interface and deciding which of the four planes to
send them to. Since none of the forwarding engines have had a chance to see
this packet yet, then the Packet Director has no way to make an intelligent
decision as to which of the four planes to send the packet to. In
particular, it cannot know which output port the packet will ultimately be
sent to.
Next the Packet Director must make sure the 10G of received bandwidth is
equally split to each of the four 2.5G planes, otherwise basic throughput at
10G won’t be achieved, and that the Packet Director has no visibility to the
traffic on other linecards, and in particular has no means to collaborate
with other Packet Directors in making its decision.
So we are assuming that all the line cards are replaced, hence back to the
topic we trash them.
(after we replace it with "something better than you're used too" and pay
freight of course).
Regards
Frank Bruce
Consulting SE, NSP West
Cisco Systems Ltd
---------------------------------------------------------------
| | | 3 The Square, Stockley Park
:|: :|: | Uxbridge, England. UX11 1BN
:|||: :|||: | Office : +44(0)20-87568000
.:|||||||:..:|||||||:. | The Views Expressed Are My Own
C i s c o S y s t e m s | And May Not Reflect Cisco's
---------------------------------------------------------------
All Cisco technical support should be conducted via the TAC.
How to use the Cisco TAC
http://www.cisco.com/public/support/help.shtml
TAC Newsletter
http://www.cisco.com/public/news_training/itsnews/subscribe.shtml
From: Jesper Skriver [mailto:jesper@skriver.dk]
Sent: Monday, 12 February 2001 1:07 AM
To: Avi Freedman
Cc: Daniel L. Golding; Randy Bush; Terence; Juniper nsp
Subject: Re: Secondhand, Offlease, Etc.
On Sun, Feb 11, 2001 at 12:02:11AM -0500, Avi Freedman wrote:
>
> Sigh, reminds me of when Sun used to landfill old 3/50s they took in
> trade instead of doing something useful for nonprofits.
>
> This is different, of course.
>
> So Juniper has a "use m5s instead of 7206s" program and Cisco has
> the "Juniper buyback". I guess we all benefit from this somehow?
>
> Anyway, on-topic:
>
> My understanding of the "packet reordering" issue is that Juniper
> claims that it can (not will) only happen if there's only one
> flow going across the whole router. Is this essentially correct?
That's not what I heard, I was told it could happend in corner cases
where 2 flows had common ingress and egress interfaces, one flow only of
small packets, and one only of larger packets.
But the real issue here is, is it really a problem, I'd say not.
Juniper also said they will come out with a solution where the Packet
Director will ensure that all packets in a flow will always go to
the same I/O manager/SFM thus there will be no packet reordering.
/Jesper
-- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work: Network manager @ AS3292 (Tele Danmark DataNetworks) Private: Geek @ AS2109 (A much smaller network ;-)One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them.
This archive was generated by hypermail 2b29 : Mon Aug 05 2002 - 10:42:40 EDT