One incredible frustration we're going through lately on the MX boxes is the BRAS function as Mark mentioned briefly ..... we're up to "bleeding edge" code now (11.4R1.14) just to get what we consider typical features of a BRAS box. Combine that with the first BRAS box I've seen that is picky about Radius VSA's and it makes it really difficult to deploy. We are not sure if the word "stable" enters the equation yet as a BRAS neither - time will tell as we're pushing out several of these boxes shortly despite concerns around code.
Paul -----Original Message----- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Mark Tinka Sent: Tuesday, January 31, 2012 3:05 AM To: James Jones Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Recommended Releases now posted for MX, M, T, QFX On Tuesday, January 31, 2012 12:32:26 AM James Jones wrote: > I am just curious what issues you guys are having with the junos > releases? Run through the archives to get a feel for what issues folk are facing. And these are just the issues that folk have decided to share. There are others that aren't shared, or folk that aren't sharing entirely. > I am currently not having issues > with any of my Juniper kit. It's really dependent on how kinky you're running your boxes. If you look at my route reflectors (M120's), 10.4R4.5 is solid, no issues. If you look at my PE Aggregation routers (MX480's, M320's, T320's), you don't want to know. If you look at the MX480 we're trying to make a BRAS, all bets are off :-). > It would be interesting to > understand the use cases in which you are seeing issues. The problem is that since Junos 9.4, we've all been thinking and hoping that the R4 release of that train (and all the ones following it) would be the ideal one. The solid one. The one on which we can hang our boots on and kick back. But alas, that was never to be the case, and given we're now literally peeking at Junos 13 (or 14, or 15, whatever they decide to do after 12), it's amazing that we're all still chasing that ever elusive dream of a stable Junos. Which, by the way, is not to discount all the good work that Juniper have done, particularly since the debacle that was Junos 10.2, but given that operators need to choose between: o Stable code. o Code that features you actually want. o Code that will be under Juniper EEOL program. o Code that will run new hardware. o Code that will fix all issues past without bringing issues present. ... you can see where all the frustration is coming from. What's worse, Junos 8 was a dream, so we all know what it's like to have good code :-). Mark. _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp