[j-nsp] MX104 capabilities question

Duane Grant duaneogrant at gmail.com
Thu Jun 9 23:00:55 EDT 2016


Adam,

Is the port buffer on the asr903 similar to the mx104?  

/Duane


On Jun 7, 2016, at 6:56 PM, Adam Vitkovsky <Adam.Vitkovsky at gamma.co.uk> wrote:

>> Ross Halliday
>> Sent: Tuesday, June 07, 2016 10:01 PM
>> To: Saku Ytti
>> Cc: juniper-nsp at puck.nether.net
>> Subject: Re: [j-nsp] MX104 capabilities question
>> 
>> Hi Saku,
>> 
>>> I don't see how this makes it any less of a box, in my mind this makes
>>> it superior box. You lost single PFE/linecard, which happens to be
>>> only linecard you have.
>>> In my mind fabricless single-linecard design is desirable, as it
>>> reduces delay and costs significantly. Not only can you omit fabric
>>> chip, but you can get >2x the ports on faceplate, as no capacity is
>>> wasted on fabric side.
>> 
>> This is a good point but kind of tangential to what I was getting at. Before we
>> were really familiar with the MX104, we went on sales and marketing
>> material that talked about "the little" MXes and "MXes with multiple slots".
>> It's very misleading. Even JUNOS MX documentation talks about FPCs being
>> separate in control and forwarding plane operations, when in reality there's
>> only AFEB0 and that's the whole box. No isolation, and "slot diversity" is
>> basically only a little bit better than adjacent ports... Again, contrary to what
>> the popular advice about "multi-slot MX routers" is. The MX104 is not really a
>> multi-slot router in the traditional sense, it just takes more MICs.
> One thing I'm not clear about MX104 and MX80 is, are there two TRIO chips or just one?
> 
> 
>>> Regarding PR1031696, years ago I had bunch of 3rd party SFPs which
>>> would crash MX PFE. I practically begged JTAC to fix it. The issue was
>>> caused by SFP being sluggish to answer to I2C polling, and the code
>>> which was expecting an answer crashed when it couldn't receive I2C
>>> answer fast enough. I tried to explain to them, it's only matter of
>>> time before original SFP develops I2C error, at which point you'll see
>>> this from customer buying 1st party optics. JTAC was unconvinced, told
>>> me to re-open if I see it on 1st party.
>>> I used many channels to complain, but no avail. To me this was
>>> absolutely appalling and short-sighted behaviour.
>> 
>> Yes, and then it crashes every single SFP... brilliant design backed with
>> brilliant support... give me a break!
>> 
>>> But all platforms can have all kind of problems, and if you would have
>>> multiple linecards, sure, in this case you'd only crash one of them.
>>> But just having multiple linecards won't help that much, you can still
>>> crash all linecards due to RE problem, so you're still going to need
>>> second router for proper redundancy, at which point it becomes
>>> immaterial if you have this 'linecard redundancy' or not.
>> 
>> All kinds of problems happen, yes the only "real" safeguard is to put every
>> customer on their own PE. You might remember a previous conversation we
>> had regarding the DDoS Protection mechanism. This thing is a major thorn in
>> my side. Thanks to this "faster" design, when one of these filters kicks in, any
>> traffic matching that class on the ENTIRE box is blackholed. I don't think this is
>> appropriate behaviour: In my experience, it actually *creates* a DoS
>> situation on these boxes.
> Hmm that's a good point actually, haven’t realised that.
> Since the first level at which the policers are applied is per LU that really makes a difference whether the box has just one or two LUs.
> 
> I really feel like cisco dropped the ball with RSP2 for ASR903 -heck if they would allow at least 2M of routes it would be no brainer, compared to MX104.
> 
> 
> adam
> 
> 
> 
> 
> 
> 
> 
>        Adam Vitkovsky
>        IP Engineer
> 
> T:      0333 006 5936
> E:      Adam.Vitkovsky at gamma.co.uk
> W:      www.gamma.co.uk
> 
> This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of this email are confidential to the ordinary user of the email address to which it was addressed. This email is not intended to create any legal relationship. No one else may place any reliance upon it, or copy or forward all or any of it in any form (unless otherwise notified). If you receive this email in error, please accept our apologies, we would be obliged if you would telephone our postmaster on +44 (0) 808 178 9652 or email postmaster at gamma.co.uk
> 
> Gamma Telecom Limited, a company incorporated in England and Wales, with limited liability, with registered number 04340834, and whose registered office is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.
> ---------------------------------------------------------------------------------------
> This email has been scanned for email related threats and delivered safely by Mimecast.
> For more information please visit http://www.mimecast.com
> ---------------------------------------------------------------------------------------
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp


More information about the juniper-nsp mailing list