[j-nsp] m320

[Evan Williams]

why concern yourself with these details, at the end of the day it is a quite 
simple concept that Juniper created, that is they have developed the ASICs 
that do the day to day shifting of routed traffic, based upon a robust 
operating system that is loosely based upon the basic routeD and other open 
source code. The only issues I have come across in my experience has been 
when the platform has been implemented, is that the operator has failed to 
consider the almost exponential growth of the working environment. I would 
humbly refer all to the basic concept and pay homage to RFC1925.

Let us all face facts the real reason your M or E series is failing is that 
you haven't spent enough money on the hardware upgrade or your bean counter 
has not understood that this is business critical hardware. An aside, let us 
all applaud that IOS-XR has become the illegitimate child of Junos and the 
non-recognised child Unisphere (ERX, son of Stratacom) comand line.

I acknowledge that there are issues with M series, but IMHO these are always 
down to the fact that expectations for 5 year old hardware will rarely meet 
the needs of todays environment. vis-a-vis LDP ( inet.3/ mpls.0 table) 
failures, The only real issue that I have experienced with the platform. 
This issue was caused by the failure to understand the aforementioned 
RFC1925.

Homage as always to Aviva, who so well explains the concept in the 
introduction to the wonderful book. A absolute must for your seasons 
stocking.

I tested the M320 for introduction into an well-known global operators 
network and could only find 3 defects in extensive systems integration; one 
related to the way that FreeBSD deals with the setting of  maximium telnet 
sessions, another with the failure of the blue box to observe frame relay 
forum standrads and the last with the fact that you can't jack in and out 
the processor on an Unix/linux operating system without expecting some sort 
of file sytem corruption. BTW the box is now there doing the job, hwether 
better or worse than its Gigabit switching compadre, I do not know.

seasons greeting and at least the days are getting longer for us up north, 
good luck down south. Apologies if this lacks relavance.

keep them coming, lets keep it stupid and simple.


Evan






----- Original Message ----- 
From: "Richard A Steenbergen" <ras at e-gerbil.net>
To: "sunnyday" <cscosunny at gmail.com>
Cc: "Juniper-Nsp" <juniper-nsp at puck.nether.net>
Sent: Friday, December 21, 2007 12:04 AM
Subject: Re: [j-nsp] m320


> On Thu, Dec 20, 2007 at 11:53:49PM +0200, sunnyday wrote:
>> my question was about load balancing because i read that at internet
>> processor 2 is per flow an plain internet processor is random
>
> It isn't random, but it is per-packet which potentially allows reordering
> to occur inside a flow.
>
> The original Internet Processor was Juniper's first attempt at designing a
> forwarding ASIC, and hasn't shipped in any product since around 2000 or
> so. The only platforms it ever shipped in were the original M40s and some
> early M20s. Everything after that has used flow-based load balancing,
> including the M320 which uses a newer architecture not based on the IP
> chips at all.
>
> -- 
> Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
> GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp