Adam, Is the port buffer on the asr903 similar to the mx104?
/Duane On Jun 7, 2016, at 6:56 PM, Adam Vitkovsky <adam.vitkov...@gamma.co.uk> wrote: >> Ross Halliday >> Sent: Tuesday, June 07, 2016 10:01 PM >> To: Saku Ytti >> Cc: juniper-nsp@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.vitkov...@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 > postmas...@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@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
