[j-nsp] m320

Fri Dec 21 02:27:31 EST 2007

These details are very important to anyone who has a keen interest in how
their $250,000 box works.

And, how do you get the idea that the ASICs are "based upon a robust operating
system that is loosely based upon the basic routeD and other open source code" ?

If you actually took the time to read any of the most basic explanations about
how any Juniper architectures work, that would be a most absurd statement.

So, let's not "keep it stupid and simple" (except for the people here who
have future job plans at Burger King.)

If you think that issues with pty limits in FreeBSD or filesystem corruption
due to system failure are serious issues to production users of this
hardware, you have got to be bluffing.  Production users have redundant REs
to deal with issues like filesystem corruption, or any of the other multitude
of reasons that an RE could fail.  And, pty limits? Even JunOS 7 comes with 32 
ptys.  Is that really a serious problem for you?  What exactly are you
doing to "jack in and out the processor" that is causing "filesystem
corruption" ?  What the hell does that even mean????  Did your test involve
repeatedly inserting the RE, waiting for it to boot, and removing it?  And if
so, does this model your production usage?

Oh, and, what does Unisphere ERX have to do with Stratacom?  Do
you throw around random bullshit like this expecting people's eyes to
glaze over and then expect their brains to shut off when you then suggest
that we "keep it stupid and simple" ?

Sorry, but discussing this equipment is mutually exclusive with keeping it
"stupid"

Chris

Evan Williams [evangellick at btinternet.com] wrote:
> 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 
> 
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

-- 
"You were about to change the channel when God healed you" -- Benny Hinn