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" <[EMAIL PROTECTED]> To: "sunnyday" <[EMAIL PROTECTED]> Cc: "Juniper-Nsp" <[email protected]> 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 <[EMAIL PROTECTED]> http://www.e-gerbil.net/ras > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) > _______________________________________________ > juniper-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
