[j-nsp] JUNOS and MX Trio cards

[Derick Winkworth]

So basically, this stalled route issue has been going on for so long, that its truthful to say that Juniper probably doesn't think its important to fix?  or they don't care?

I wonder what their official line is.  Might be similar to their official line with respect to the manufacturing issue with the EX series, where so many ASICs are just bad... I think they have some code in JUNOS now that detects the bad ASICs and just resets them when the failure detected.

How unfortunate.  I wonder of Alca-Lu can do better.  Lord knows Cisco could care less  about code quality.  surely some networking vendor must give a sh*t.






________________________________
From: Richard A Steenbergen <ras at e-gerbil.net>
To: Derick Winkworth <dwinkworth at att.net>
Cc: "juniper-nsp at puck.nether.net" <juniper-nsp at puck.nether.net>
Sent: Tue, June 29, 2010 2:59:55 PM
Subject: Re: [j-nsp] JUNOS and MX Trio cards

On Tue, Jun 29, 2010 at 08:37:20AM -0700, Derick Winkworth wrote:
> When you say 'transit session' what do you mean exactly?? Also 
> disappointed to hear about the bugs.?

Transit (n): An EBGP session where an external ASN sends you a full copy 
of the global routing table, usually in exchange for money. :)

> Is the stuck-in-pending issue easily reproducible?? I have read some 
> of your past? posts, but recently it sounds like this can be 
> reproduced without a lot of effort?

Trivially reproducable here, all that seems to be required is a decent 
number of BGP sessions that you have to send the update to. Just last 
night I noticed it took over 6 minutes to remove the routes and stop 
forwarding traffic to a ebgp session I shut down on a 9.6R4 router 
(which was mostly cpu idle before starting), and EX8200s running 10.1 
have taken 5-7 minutes to start installing or exchanging routes with 
nothing more than 2 IBGP RR feeds and a local transit session. Usually 
the problem is worst after a fresh reboot, where it can take 10-20 
minutes to actually install the routing table into hw, but on newer code 
it seems to be happening on an otherwise stable router with just a 
single BGP session flap.

-- 
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)