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