Re: [j-nsp] MX104 capabilities question
Adam, Is the port buffer on the asr903 similar to the mx104? /Duane On Jun 7, 2016, at 6:56 PM, Adam Vitkovsky 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 > ---
Re: [j-nsp] MX104 capabilities question
It can't hold a full table in it's FIB for sure, but in the RIB it's fine: inet.0: 588286 destinations, 1091804 routes (588284 active, 0 holddown, 2 hidden) -- Tim On Thu, Jun 9, 2016 at 9:40 AM, Aaron wrote: > Thanks, Let me test this claim that an acx5048 cannot hold a full bgp > table…… anyone know a way to get a test bgp session for a full feed ? > > > > -Aaron > > > > > > “I think the big thing the ACX5048 is lacking is the ability to hold a > full routing table compared to the MX104 and ASR9001. Remember the ACX5048 > has a Broadcom Trident II chipset.” > > > > > > ___ > 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
Re: [j-nsp] MX104 capabilities question
> On 9 Jun 2016, at 07:40, Aaron wrote: > > Thanks, Let me test this claim that an acx5048 cannot hold a full bgp table…… > anyone know a way to get a test bgp session for a full feed ? here’s a quick way to get a full dfz into your lab. http://www.stubarea51.net/2016/01/21/put-50-bgp-routes-in-your-lab-network-download-this-vm-and-become-your-own-upstream-bgp-isp-for-testing/ q. -- quinn snyder | snyd...@gmail.com signature.asc Description: Message signed with OpenPGP using GPGMail ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX104 capabilities question
On 09/06/16 14:39, Saku Ytti wrote: They do something quite different than JNPR or CSCO. I think programming language is important, and I think C is terrible language, It is a terrible, terrible language. Their should be a C driving license, and unless you're writing kernel code, you shouldn't be allowed to use it. because it's very hard to write quality code on. Arista isn't really using C, mostly C++ and good portion of that is machine generated from their own proprietary state description language. They also heavily unit test and automate black-box testing. Ooh, that's interesting. They've actually adopted some modern software practices. How novel! I wish someone would do something even more novel, like create full routing suite in Erlang. But from what we have now in the market, I think Arista is most innovative. Yeah it'd be great to move away from this low-level paradigm for NOS code to a language and runtime with better features. I guess all the IOS/JunOS devs starts to see the problem in terms of their existing solution set, when all you have is a hammer etc. It's a shame the whitebox switching platforms don't have better control plane (as well as better hardware programming APIs, or at least some open docs). It would be interesting to experiment with some of these ideas. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX104 capabilities question
❦ 9 juin 2016 16:40 CEST, "Aaron" : > Thanks, Let me test this claim that an acx5048 cannot hold a full bgp > table…… anyone know a way to get a test bgp session for a full feed ? With ExaBGP, you can use a MRT dump: https://github.com/YoshiyukiYamauchi/mrtparse Here is one: http://data.ris.ripe.net/rrc00/latest-bview.gz -- Choose a data representation that makes the program simple. - The Elements of Programming Style (Kernighan & Plauger) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX104 capabilities question
Well not really but its a rather new platform. Give it 6-12 months to mature and perhaps it will actually work. ;) //Gustav -Ursprungligt meddelande- Från: Aaron [mailto:aar...@gvtc.com] Skickat: den 9 juni 2016 16:45 Till: Gustav Ulander ; 'Mark Tinka' ; 'Colton Conor' Kopia: 'Juniper List' Ämne: RE: [j-nsp] MX104 capabilities question You mention the NCS5K ... have you seen one actually work ? My tests turned up really bad findings in my lab a few months ago. Has cisco fixed that thing ? I'd really like to know because it was a pretty sweet box with ~40 - 10gig and 4 - 100gig, but had major issues. - Aaron ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX104 capabilities question
You mention the NCS5K ... have you seen one actually work ? My tests turned up really bad findings in my lab a few months ago. Has cisco fixed that thing ? I'd really like to know because it was a pretty sweet box with ~40 - 10gig and 4 - 100gig, but had major issues. - Aaron ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX104 capabilities question
Thanks, Let me test this claim that an acx5048 cannot hold a full bgp table…… anyone know a way to get a test bgp session for a full feed ? -Aaron “I think the big thing the ACX5048 is lacking is the ability to hold a full routing table compared to the MX104 and ASR9001. Remember the ACX5048 has a Broadcom Trident II chipset.” ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX104 capabilities question
On 9/Jun/16 15:24, Gustav Ulander wrote: > I would think that the 7280R is more a competitor to ACX5k and NCS 5k boxes? > But would be really interested to see where the MPLS feature set is in > maturity as Mark says. > > All three boxes should be really handy to have for P dutys when doing no or > very little BGP on them except the Arista one then. What I know from Arista is that they are still a long way away from offering decent MPLS capability in EOS. However, basic IP should be fine, although I'm not sure how this translates for their BGP implementation. IGP-wise, they seem to be doing fine, although I have no direct experience. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX104 capabilities question
On 9 June 2016 at 16:24, Gustav Ulander wrote: > I would think that the 7280R is more a competitor to ACX5k and NCS 5k boxes? > But would be really interested to see where the MPLS feature set is in > maturity as Mark says. I'd say PTX and NCS, not ACX and definitely not MX/ASR. Features are largely customer driven, so either buy lot of boxes and get features you need, or wait until someone with your needs buys them :/ -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX104 capabilities question
On 9 June 2016 at 15:54, Mark Tinka wrote: > But is the IP and MPLS code mature enough for real-world use? It's getting there, customer by customer. It's not there for me. I expect Arista to be serious player in SP segment in a <2 years. As Arista is still controlled by owners who work there on daily basis, they can do things well, instead of seeking immediate gratification while adding technological debt. And none of them are in their first rodeo, are financially independent so I don't think they're interested in doing big exit, I think they're solely motivated in building great company and a great product. How long this issue will persist is anyone's guess. They do something quite different than JNPR or CSCO. I think programming language is important, and I think C is terrible language, because it's very hard to write quality code on. Arista isn't really using C, mostly C++ and good portion of that is machine generated from their own proprietary state description language. They also heavily unit test and automate black-box testing. I think they are fundamentally able to produce less buggy code than JNPR or CSCO. They are doing some of the classic mistakes, like insisting market that they have single image like JNPR highlighted as big competitive advantage over CSCO back in the day. But they'll need to get rid of this message when moving to 64b or then they need to screw people running older HW not capable for 32b. I wish someone would do something even more novel, like create full routing suite in Erlang. But from what we have now in the market, I think Arista is most innovative. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX104 capabilities question
I would think that the 7280R is more a competitor to ACX5k and NCS 5k boxes? But would be really interested to see where the MPLS feature set is in maturity as Mark says. All three boxes should be really handy to have for P dutys when doing no or very little BGP on them except the Arista one then. //Gustav -Ursprungligt meddelande- Från: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] För Mark Tinka Skickat: den 9 juni 2016 14:55 Till: Colton Conor ; Aaron Kopia: Juniper List Ämne: Re: [j-nsp] MX104 capabilities question On 9/Jun/16 14:48, Colton Conor wrote: > > A better question is would you consider an Arista 7280R in place of a > MX104 or ASR9001. The Arista 7280R can accept full routes, and has a > very similar pricepoint. Not to mention 48 10G ports, and 6 100G ports. But is the IP and MPLS code mature enough for real-world use? Mark. ___ 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
Re: [j-nsp] MX104 capabilities question
On 9/Jun/16 14:48, Colton Conor wrote: > > A better question is would you consider an Arista 7280R in place of a MX104 > or ASR9001. The Arista 7280R can accept full routes, and has a very similar > pricepoint. Not to mention 48 10G ports, and 6 100G ports. But is the IP and MPLS code mature enough for real-world use? Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX104 capabilities question
Aaron, I think the big thing the ACX5048 is lacking is the ability to hold a full routing table compared to the MX104 and ASR9001. Remember the ACX5048 has a Broadcom Trident II chipset. A better question is would you consider an Arista 7280R in place of a MX104 or ASR9001. The Arista 7280R can accept full routes, and has a very similar pricepoint. Not to mention 48 10G ports, and 6 100G ports. On Wed, Jun 8, 2016 at 9:58 AM, Aaron wrote: > I realize these are 2 totally different style boxes, but I'll ask anyway... > > An ACX5048 with (72) 10 gig ports (or... (48) 10 gig ports with (6) 40 gig > ports) at ~$15K ... > > Would anyone consider putting a ACX5048 in place of a MX104/ASR9k ? > > - Aaron > > > ___ > 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
Re: [j-nsp] MX104 capabilities question
On 8/Jun/16 16:58, Aaron wrote: > I realize these are 2 totally different style boxes, but I'll ask anyway... > > An ACX5048 with (72) 10 gig ports (or... (48) 10 gig ports with (6) 40 gig > ports) at ~$15K ... > > Would anyone consider putting a ACX5048 in place of a MX104/ASR9k ? I wouldn't :-). Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
