Re: Juniper M10i sufficient for BGP, or go with M20?
Strange. My rep always took pride in the fact that M- and T- series devices have no overcommit at all.. Maybe things changed, we use no quad-gig. Many of Junipers cards for the M7/M10 are oversubscribed- just look at
I'm very happy about the Juniper devices I manage. They're expensive but very reliable, and their config interface has lots of unique features. Juniper's greatest asset over Cisco is the single software image for all
their pdf's on the subject: http://www.juniper.net/products/modules/100044.pdf http://www.juniper.net/products/modules/100163.pdf their systems. In my latest purchase that didn't justify paying 4 times as much no matter how much I love the software. -Don
On May 14, 2007, at 7:57 PM, Donald Stahl wrote:
I'm very happy about the Juniper devices I manage. They're expensive but very reliable, and their config interface has lots of unique features. Juniper's greatest asset over Cisco is the single software image for all their systems. In my latest purchase that didn't justify paying 4 times as much no matter how much I love the software.
Warren: For me the greatest asset is the stability... the stability and performance... The two greatest assets are stability and performance... and the fact that the commands that you can type actually do something[0]. The *three* greatest assets are stability and performance and the fact that the commands that you can type actually do something... and the ease of the CLI. The *four" greatest ... no ... Amongst their greatest assets are the stability, performance, commands that actually DO something, the CLI...... I'll come in again. [Warren exits] Donald: Juniper's greatest asset over Cisco is the single software image for all their systems [JARRING CHORD] [Warren bursts in] Amongst their greatest assets are the stability, performance, commands that actually DO something, the ability to actually count the bits that you send[1]... and pretty colors - Oh damn! Warren [0] -- You haven't lived until you have spent 4 hours in the middle of the night trying to figure out why the command that you typed (and that shows up in the config) doesn't work -- only to be told "Oh, that doesn't exist in this train, you need to upgrade to <inset some new version that doesn't include the ability to actually forward packets or something else equally critical>, we just reused the same parser..." [1] -- If you haven't run into the "oh, we can either forward packets *really* fast, or count them, but not both" answer then you haven't been doing this long enough. P.S: I neither work for, nor hold any stock of either of the above companies.
On Wed, May 16, 2007 at 12:16:03AM -0400, Warren Kumari wrote:
[0] -- You haven't lived until you have spent 4 hours in the middle of the night trying to figure out why the command that you typed (and that shows up in the config) doesn't work -- only to be told "Oh, that doesn't exist in this train, you need to upgrade to <inset some new version that doesn't include the ability to actually forward packets or something else equally critical>, we just reused the same parser..."
Oh, only 4 hours? We went thru this for two weeks with TAC for the exact same reason. In our case: QoS on MLPPP on ATM PVCs. You can configure that fine on 12.2S, but it's only supported in 12.2SB. After the recommended upgrade ("this version should be fine with your hardware/software/features combination"), MLPPP on ChSTM1 stopped working, yay! Not that they had "sh tech" outputs to double-check for such known bugs before recommending an upgrade, no... of course they did. First and foremost TAC job always seems to be "collect intellig^Wconfigs of our customers" as we all know. :-Z Now we're another step into upgrade-to-latest-greatest lala-land (31SB5). No obvious problems yet (except that we can't standardise on that version as PA-MC-8E1 stopped working [EOL, yay!], and we have those deployed in other boxes). Let's see wether we will encounter the mem leak problems other folks in the industry observed with 31SB*. [hardware is NPE-G1 btw] Shared Cisco trouble halves the pain. :-) </rant mode=SCNR>
[1] -- If you haven't run into the "oh, we can either forward packets *really* fast, or count them, but not both" answer then you haven't been doing this long enough.
To be fair, JNPR had bugs regarding that too. But they fixed them quickly. I'm not sure wether one can nowadays believe the counters on the dsc discard interface btw...
P.S: I neither work for, nor hold any stock of either of the above companies.
Dito :) Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
participants (3)
-
Daniel Roesen -
Donald Stahl -
Warren Kumari