Re: [j-nsp] MX104 capabilities question
On 7 July 2016 at 12:11, Saku Ytti wrote: > On 7 July 2016 at 13:22, Gavin Henry wrote: > > Hey, > >> Any developer can introduce bugs irrelevant of the language but some >> languages just have bugs that you >> would need to know C to fix. At Arista's level they are using C as >> everything touches C at some point be it >> bootstrapping the mini-any-lang to get to the state of compiling a >> language implementation from source. > > There are actually many languages with no runtime, which you can write > lowest level at possible. It's entirely possible to write all the low > level stuff in C++ or better yet Rust, you'll get sparser version of > the language, but it can be done. I'm not fluent in all programming languages at all, but I'd be interested in ready up on those that don't use C to get their main binaries to a certain point to compile the rest to get the final main binary ready. For example Perl's miniperl etc. >> I would say using C in the right place within a company puts them at a >> *massive* advantage. > > In comparison to what language, all languages? Why? The "in the right place" is the strong emphasis here, which goes back to the right tool for the right job. > C++ and Rust are > arguably more complicated languages, and it will take more time to > learn them. But we're talking about senior developers anyhow, so it's > an advantage that some experience is needed before you appear > proficient. And after you've paid the complexity tax, there are > dividends. Agreed. It's Senior devs that will have the confidence to say out loud that "this is better done in X language". >> Some interesting reading: > >> Again, very true. Further proof that the language is irrelevant and >> the "right tool for the job". The issue being >> algorithms, architecture of said toolset/project need to be understood >> clearly. The language is the second bit. >> Is that level still being taught or is it learned on the job? > > Aren't these mutually exclusive 'language is irrelevant' and 'right > tool for the job', I am arguing C is not the right tool for the job, > when talking about vast majority of things written in C. Routing stack > is way too high level for C. "Vast majority of things written in C"? For example? I would say things as critical as a routing stack would need C and that's why most are written in C. But again, this comes down to your other points about inhouse skillset vs "the right tool for the job". If a routing stack can be written in X language and supported by X company and it's "fast enough" or "good enough", then that's what it should be written in as X language is then the right tool for the job. > Kernel is probably fine in C, but even for that, I'd rather consider Rust > today. Understood. > I think good portion of IOS and RPD are written by people who learned > C on the job. They didn't enter the company as developer, but as they > were dealing with customer issues and had access to code base, they > started hacking on it. How many years until they realised how things > should have been written, 5? 10? No idea how their ecosystems work. >> Test, test and test as you know. It's very easy to write crap code, >> full stop :-) > > It is considerably harder to write bad code higher level languages > than in C. Especially in garbage collected ones, which are perfectly > acceptable for majority of use-cases, when it does not matter if you > pause for few milliseconds now and then. For our comments we need to define "bad code". Is that not using the write techniques or writing slow code. Test and benchmark when it's needed. > I'm not making absolute statements, I'm trying say there is some > probability of introducing a bug per feature or line of code written, > and I don't think this probability is constant and I believe this > probability is amongst highest in C. I would say it depends. If that code base has it's own memory management routines and pointer routines it may be safe to add lines of code where errors get caught. Software crashes with any language as us humans write it: https://github.com/search?q=This+should+never+happen&type=Code&utf8=%E2%9C%93 >> There in lies the whole point which I do agree with. Finding good or >> great C programmers is hard. Lots of C++. > > And if you can't find them for the salary which makes economically > sense, then you are in disadvantage compared to company who is using > tools to which they can find them. And said tools will be the "right tool for the job". -- Kind Regards, Gavin Henry. Winner of the Best Business ITSP (Medium Enterprise) 2016! http://www.surevoip.co.uk/2016-best-provider ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX104 capabilities question
On 7 July 2016 at 13:22, Gavin Henry wrote: Hey, > Any developer can introduce bugs irrelevant of the language but some > languages just have bugs that you > would need to know C to fix. At Arista's level they are using C as > everything touches C at some point be it > bootstrapping the mini-any-lang to get to the state of compiling a > language implementation from source. There are actually many languages with no runtime, which you can write lowest level at possible. It's entirely possible to write all the low level stuff in C++ or better yet Rust, you'll get sparser version of the language, but it can be done. > I would say using C in the right place within a company puts them at a > *massive* advantage. In comparison to what language, all languages? Why? C++ and Rust are arguably more complicated languages, and it will take more time to learn them. But we're talking about senior developers anyhow, so it's an advantage that some experience is needed before you appear proficient. And after you've paid the complexity tax, there are dividends. > Some interesting reading: > Again, very true. Further proof that the language is irrelevant and > the "right tool for the job". The issue being > algorithms, architecture of said toolset/project need to be understood > clearly. The language is the second bit. > Is that level still being taught or is it learned on the job? Aren't these mutually exclusive 'language is irrelevant' and 'right tool for the job', I am arguing C is not the right tool for the job, when talking about vast majority of things written in C. Routing stack is way too high level for C. Kernel is probably fine in C, but even for that, I'd rather consider Rust today. I think good portion of IOS and RPD are written by people who learned C on the job. They didn't enter the company as developer, but as they were dealing with customer issues and had access to code base, they started hacking on it. How many years until they realised how things should have been written, 5? 10? > Test, test and test as you know. It's very easy to write crap code, > full stop :-) It is considerably harder to write bad code higher level languages than in C. Especially in garbage collected ones, which are perfectly acceptable for majority of use-cases, when it does not matter if you pause for few milliseconds now and then. I'm not making absolute statements, I'm trying say there is some probability of introducing a bug per feature or line of code written, and I don't think this probability is constant and I believe this probability is amongst highest in C. > There in lies the whole point which I do agree with. Finding good or > great C programmers is hard. Lots of C++. And if you can't find them for the salary which makes economically sense, then you are in disadvantage compared to company who is using tools to which they can find 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 7 July 2016 at 08:59, Phil Mayers wrote: > On 07/07/16 02:21, Gavin Henry wrote: > >> That last sentence is quite a sweeping statement about C. > > > The underlying basis for the statement - C is a hard language to program > well - is not at this point a controversial one, IMHO. Agreed. >> You can make great software in any language. I think this argument is >> false. > > > I think the argument has a lot going for it. OK. > C is a difficult language to use well; even developers with decades of > experience get caught out by the subtleties of things like pointer aliasing > and integer behaviour. There's a huge research effort by smart people to > improve that situation - as an example, things like ubsan in Clang to detect > and warn on use of undefined behaviour. John Regehr's blog is a good read on > the topic of how gnarly C can be, for those interested. Excellent to hear. > I think it's totally reasonable to argue that other languages can fit a > problem set better than C, can reduce the cognitive load on the developer, > and can prove more amenable to things like static analysis and automated > testing. Again agreed. I didn't say otherwise. > Other languages could include, here, a restricted subset of C with > least-surprise behaviours. But TBH, given the focus on multicore, I think a > language with better support for concurrency would be a more appropriate > choice (Erlang was mentioned; it's a shame that never took off, it's really > ideally suited for the task of network protocol speaker). Erlang is nice, but again the developers of this language do need C to get to the first point of building the language, as do most compilers as you know. C needs to be taught more as the fundamentals are not hard but everything in our world today relies on it. > Developers are people, and recognising the human limits of the process is > important. Frankly, I would agree with the notion that C is a very poor > choice for almost anything outside hardware-level work (kernel, driver) > these days, simply because CPU is cheap, and human cognition expensive, and > higher level languages trade costs in former for savings in the latter. I would also agree. But since the thread is ending about Arista, they are using it in the right place and as Saku states they are moving to the top of their game. As some point, not using the right tool means your technical dept is huge to repay. But that's what refactoring is for :-) My fear, like what is happening in the Oil Industry here, not just in Scotland, but globally, is that because the workforce is ageing, knowledge is getting lost. The things taught at Uni are not attractive and are hard for paying students, so they are dropped. This in turn means those coming into industry are not as good or as many and as the workforce ages there is a massive gap. Players like Arista and other commercial bodies need to help improve this. Thanks. P.S. My son was up until 02:45 today so some of above may hurt your eyes and mess with your brain. -- Kind Regards, Gavin Henry. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX104 capabilities question
On 7 July 2016 at 08:33, Saku Ytti wrote: > On 7 July 2016 at 04:21, Gavin Henry wrote: > > Hey, > >>> This comment was specifically about how they write the software. I >>> don't believe market has enough skilled labour to write any >>> significant SLOC on C. I think use of C puts any company in >>> disadvantage due to the cost of introducing bugs. >>> >> That last sentence is quite a sweeping statement about C. > > I accept that it is controversial. But it should be uncontroversial to > state, that some languages make more compile-time promises of > correctness than C does. True. My point was "I think use of C puts any company in disadvantage due to the cost of introducing bugs." Any developer can introduce bugs irrelevant of the language but some languages just have bugs that you would need to know C to fix. At Arista's level they are using C as everything touches C at some point be it bootstrapping the mini-any-lang to get to the state of compiling a language implementation from source. I would say using C in the right place within a company puts them at a *massive* advantage. Some interesting reading: https://ca.linkedin.com/jobs/view/17353638 http://blog.tsunanet.net/2013/03/why-i-joined-arista-networks.html http://www.bctechnology.com/jobs/Arista-Networks/106315/Software-Engineers-(multiple-positions).cfm >> There are massive Linux Kernel Hackers of course, which of course uses C. > > Kernel is one of the very few things you have to write in language > like C, C++ or Rust. I suspect many of top class Linux hackers can't > be hired to write RPD or iosd. Given environment, which you view as > broken, but not being allowed to fix it may not be acceptable to > people who are passionate about their work. Again, very true. Further proof that the language is irrelevant and the "right tool for the job". The issue being algorithms, architecture of said toolset/project need to be understood clearly. The language is the second bit. Is that level still being taught or is it learned on the job? >>> Combine these, and I think it makes Arista fundamentally more able to >>> produce better software. >> >> You can make great software in any language. I think this argument is false. > > I'm not argumenting it's impossible to make great software in any > language, I'm argumenting different languages give you different > probability of ending up with good software. Mainly because C makes > very few compile time guarantees, it's powerful tool, but it's also > very easy to write bad, yet seemingly working code on it. I'm sorry, I just don't agree. Ending up with good software comes down to design, understanding, maintaining and testing (not in that order). The choice of language makes no difference. Yes, you may get to the "good software" position sooner using a certain language, but just because something is hard, doesn't mean it shouldn't be done. Just look at Arista. "it's powerful tool, but it's also very easy to write bad, yet seemingly working code on it." Test, test and test as you know. It's very easy to write crap code, full stop :-) > I don't think market has sufficient amount of economically viable > people who can produce good C code. So my argument is, by generating > lot of code and by using C++, it is fundamentally cheaper for Arista > to produce quality code, giving them competitive advantage. There in lies the whole point which I do agree with. Finding good or great C programmers is hard. Lots of C++. I've found that out this month myself. I did C at Uni 15 years ago and just finished a 16 week C course here: http://www.cs.manchester.ac.uk/study/professional-development/study-options/distance-learning/foundation/course-modules/programming-in-c/ C is my world as everything we use (SureVoIP and Suretec) is written in it, even other languages we use are initially written in C. I've tried to find a Masters in Software Engineering with a strong emphasis in C in the UK, but they all use Java but you can use C for you dissertation. I've joined professional commercial groups like ACCU (http://accu.org/) but everyone is doing C++. I have found some mentoring programs though. The MSc is not needed for my job though. Anyway, my final point is as generations move on, tough things that we all rely on are getting left behind because there's a quicker way to do it. Problems solved and solutions get re-invented as they aren't taught anymore. But we all know that as human beings. Doing something the hard way that takes longer is not always doing it badly. -- Kind Regards, Gavin Henry. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX104 capabilities question
On 07/07/16 02:21, Gavin Henry wrote: That last sentence is quite a sweeping statement about C. The underlying basis for the statement - C is a hard language to program well - is not at this point a controversial one, IMHO. You can make great software in any language. I think this argument is false. I think the argument has a lot going for it. C is a difficult language to use well; even developers with decades of experience get caught out by the subtleties of things like pointer aliasing and integer behaviour. There's a huge research effort by smart people to improve that situation - as an example, things like ubsan in Clang to detect and warn on use of undefined behaviour. John Regehr's blog is a good read on the topic of how gnarly C can be, for those interested. I think it's totally reasonable to argue that other languages can fit a problem set better than C, can reduce the cognitive load on the developer, and can prove more amenable to things like static analysis and automated testing. Other languages could include, here, a restricted subset of C with least-surprise behaviours. But TBH, given the focus on multicore, I think a language with better support for concurrency would be a more appropriate choice (Erlang was mentioned; it's a shame that never took off, it's really ideally suited for the task of network protocol speaker). Developers are people, and recognising the human limits of the process is important. Frankly, I would agree with the notion that C is a very poor choice for almost anything outside hardware-level work (kernel, driver) these days, simply because CPU is cheap, and human cognition expensive, and higher level languages trade costs in former for savings in the latter. Cheers, Phil ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX104 capabilities question
On 7 July 2016 at 04:21, Gavin Henry wrote: Hey, >> This comment was specifically about how they write the software. I >> don't believe market has enough skilled labour to write any >> significant SLOC on C. I think use of C puts any company in >> disadvantage due to the cost of introducing bugs. >> > That last sentence is quite a sweeping statement about C. I accept that it is controversial. But it should be uncontroversial to state, that some languages make more compile-time promises of correctness than C does. > There are massive Linux Kernel Hackers of course, which of course uses C. Kernel is one of the very few things you have to write in language like C, C++ or Rust. I suspect many of top class Linux hackers can't be hired to write RPD or iosd. Given environment, which you view as broken, but not being allowed to fix it may not be acceptable to people who are passionate about their work. >> Combine these, and I think it makes Arista fundamentally more able to >> produce better software. > > You can make great software in any language. I think this argument is false. I'm not argumenting it's impossible to make great software in any language, I'm argumenting different languages give you different probability of ending up with good software. Mainly because C makes very few compile time guarantees, it's powerful tool, but it's also very easy to write bad, yet seemingly working code on it. I don't think market has sufficient amount of economically viable people who can produce good C code. So my argument is, by generating lot of code and by using C++, it is fundamentally cheaper for Arista to produce quality code, giving them competitive advantage. -- ++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 22 Jun 2016 13:51, "Saku Ytti" wrote: > > On 22 June 2016 at 10:41, joel jaeggli wrote: > >>> Can you expand on what you mean by the following quote: "I think they are > >>> fundamentally able to produce less buggy code than > >>> JNPR or CSCO. > > > > yeah if there's any fundamental about it, it's that it carry less > > legacy, is more general purpose, and has less hardware, wierd corner > > cases and unreasonable customer demands to support. It has it share of > > bugs, missing features and hardware specific limitations and quirks. > > This comment was specifically about how they write the software. I > don't believe market has enough skilled labour to write any > significant SLOC on C. I think use of C puts any company in > disadvantage due to the cost of introducing bugs. > That last sentence is quite a sweeping statement about C. > Arista, as I understand it, does not use C, but code is predominantly > C++, and even for that, good portions of the C++ code are generated > from higher level internal language. There are massive Linux Kernel Hackers of course, which of course uses C. > Combine these, and I think it makes Arista fundamentally more able to > produce better software. You can make great software in any language. I think this argument is false. -- Kind Regards, Gavin Henry. Winner of the Best Business ITSP (Medium Enterprise) 2016! http://www.surevoip.co.uk/2016-best-provider ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX104 capabilities question
On 22 June 2016 at 10:41, joel jaeggli wrote: >>> Can you expand on what you mean by the following quote: "I think they are >>> fundamentally able to produce less buggy code than >>> JNPR or CSCO. > > yeah if there's any fundamental about it, it's that it carry less > legacy, is more general purpose, and has less hardware, wierd corner > cases and unreasonable customer demands to support. It has it share of > bugs, missing features and hardware specific limitations and quirks. This comment was specifically about how they write the software. I don't believe market has enough skilled labour to write any significant SLOC on C. I think use of C puts any company in disadvantage due to the cost of introducing bugs. Arista, as I understand it, does not use C, but code is predominantly C++, and even for that, good portions of the C++ code are generated from higher level internal language. Combine these, and I think it makes Arista fundamentally more able to produce better software. You don't have better people than your competitors, that's very risky way to look at things, but you can choose your tools. I think Arista has chosen better, they don't need better people to be better. -- ++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 22 June 2016 at 04:02, Colton Conor wrote: Hey, > My understanding is right now they indeed do have a single downloadable file > no matter which arista switch model you have. Is that not the case? Are you > saying this file is 32 bit and not 64? That would suprise me since I beleive > most of their recent switches have more than 8GB of RAM in them. Yes, but like Juniper in its early days, it's artificial. It's lack of legacy. It's not situation which is sustainable, and it's damaging to use it as marketing gimmick, like Juniper did. They are already not supporting certain gear, because memory restrictions, alternative solution would have been to fork images, but that would lose them the marketing gimmick of single image/release. 32b/64b is the same, they could do 64b but there are kit in the field which can't do 64b, so they'd need two images. In some point in future, they will have multiple images. -- ++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 6/21/16 7:12 PM, Josh Hoppes wrote: > PAE can get the kernel to address more than 4GB of RAM, however a single > process will still be limited. this is straying off topic but. yeah it doesn't use pae... Arista kernels are 64 bit, user space is 32 bit derived from FC14. Linux XX 3.4.43.Ar-3052562.4155M #1 SMP PREEMPT Sun Mar 20 19:36:57 PDT 2016 x86_64 x86_64 x86_64 GNU/Linux all the control-plane cpus are 64 bit with the TORs having AMD apus. and the beefier boxes having and intel xeon based RE. big processor : 7 vendor_id : GenuineIntel cpu family : 6 model : 42 model name : Intel(R) Xeon(R) CPU @ 2.60GHz stepping: 7 little (this is a 7048t which is old) processor : 1 vendor_id : AuthenticAMD cpu family : 16 model : 6 model name : AMD Turion(tm) II Neo N41H Dual-Core Processor stepping: 3 microcode : 0x1b6 cpu MHz : 1499.919 that said 4GB (which is typical for the single asic tors up until very recently) is kinda tight, depending on how you use them so the older boxes aren't going to last forever. > On Tue, Jun 21, 2016 at 8:02 PM, Colton Conor > wrote: > >> Saku, >> >> Can you expand on what you mean by the following quote: "I think they are >> fundamentally able to produce less buggy code than >> JNPR or CSCO. yeah if there's any fundamental about it, it's that it carry less legacy, is more general purpose, and has less hardware, wierd corner cases and unreasonable customer demands to support. It has it share of bugs, missing features and hardware specific limitations and quirks. >> 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." >> >> My understanding is right now they indeed do have a single downloadable >> file no matter which arista switch model you have. Is that not the case? >> Are you saying this file is 32 bit and not 64? That would suprise me since >> I beleive most of their recent switches have more than 8GB of RAM in them. >> >> On Thu, Jun 9, 2016 at 8:39 AM, Saku Ytti wrote: >> >>> 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 >> > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > signature.asc Description: OpenPGP digital signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX104 capabilities question
PAE can get the kernel to address more than 4GB of RAM, however a single process will still be limited. On Tue, Jun 21, 2016 at 8:02 PM, Colton Conor wrote: > Saku, > > Can you expand on what you mean by the following quote: "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." > > My understanding is right now they indeed do have a single downloadable > file no matter which arista switch model you have. Is that not the case? > Are you saying this file is 32 bit and not 64? That would suprise me since > I beleive most of their recent switches have more than 8GB of RAM in them. > > On Thu, Jun 9, 2016 at 8:39 AM, Saku Ytti wrote: > > > 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 > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX104 capabilities question
Saku, Can you expand on what you mean by the following quote: "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." My understanding is right now they indeed do have a single downloadable file no matter which arista switch model you have. Is that not the case? Are you saying this file is 32 bit and not 64? That would suprise me since I beleive most of their recent switches have more than 8GB of RAM in them. On Thu, Jun 9, 2016 at 8:39 AM, Saku Ytti wrote: > 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
> Duane Grant [mailto:duaneogr...@gmail.com] > Sent: Friday, June 10, 2016 4:01 AM > > Adam, > > Is the port buffer on the asr903 similar to the mx104? > The only thing I was able to dig out was that on RSP3 is below. Internal Packet Buffer onchip (per ASIC) 16MB. External Packet Buffer (per ASIC) 4G. (there are two ASICs on the RSP). 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
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 obl
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
Re: [j-nsp] MX104 capabilities question
On 8 June 2016 at 17:58, Aaron wrote: > Would anyone consider putting a ACX5048 in place of a MX104/ASR9k ? Be sure you're happy with FIB size, with ACL size, ACL features (ipv4+ipv6, at the same time), control-plane protection etc. ACX across the board is pretty good, if you can live with the compromises made. I often find I can't. -- ++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 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
Re: [j-nsp] MX104 capabilities question
On 8 June 2016 at 00:00, Ross Halliday wrote: Hey, > 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. It's pretty funny situation, IOS-XR out of the box probably has best in the market control-plane protection. Juniper has pretty non-existing. But for operator knowing how to configure it right, IOS-XR cannot be configured correctly, you'll always have to carry significant shared risks. Trio+ platforms, otoh, can be configured almost correctly, essentially with almost no shared risks. To put it bluntly, you configured the box incorrectly. Even if you had multiple linecards, you would have killed all of the traffic in the single NPU, so you'd have severe collateral damage anyhow. And if you had multiple MX104 (i.e multiple linecards) you'd have higher resiliency than multiple linecards in single chassis. You need to look into DDoS-protection, reduce the default aggregate pps rates significantly (there is built in policer for how much NPU can punt, and many DDoS protection protocols are higher rate than that). And crucially you need to make sure you have per-IFL ddos-protection set to sufficiently low number, so if one of your customers has L2 loop and pukes some trash on your control-plane, you'll only police that IFL, leaving all other IFL operating normally. > These routers have their place, they're definitely a Swiss Army Knife type of > machine, it's just that the handle is really small... I agree the control-plane is shite, it's not DFZ router because of that. But I don't agree on the single linecard design being liability, to me it's an advantage. Fabric and distributed design is hack we need, because technology isn't there to offer reasonable amount of ports with single chip. -- ++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 Tue, Jun 07, 2016 at 10:56:23PM +, Adam Vitkovsky wrote: > > > One thing I'm not clear about MX104 and MX80 is, are there two TRIO chips or > just one? There is only 1 NPU on both platforms. My problem with MX104 is the same 'practical-use-case' scenario and port economics you described. While MX104 provides simpler design and less things to potentially fail, when I need to deploy a peering router with acceptable 10G port density, ASR 9k tends to be more cost-effective and useful IMO; and then, there is that slow BGP performance issue on MX104, which does not exist on ASR9001. Saku did raise one important point though a few weeks earlier in c-nsp regarding ASR 9001 -- it is 32-bit; and with IOS-XR moving to 64-bit architecture, the future of 9001 as a platform is questionable when making new purchasing decisions. It certainly is something to think about. But let's talk price here, specifically port costs. To achieve 8x 10GE on MX104, you need built-in 4x10GE unlock port license, and then you need two MIC-3D-2XGE-XFP, which by themselves are priced like licenses (router ports aren't cheap). By the time you're done pricing out an MX104 loaded up to 8x 10GE interfaces with just single RE (but two PSUs), you might as well pick up an ASR 9006 with a single MOD80 card to match the configuration as closely as possible to a loaded MX104. This is what we ended up doing to replace an aging MX80 router doing peering. Plus, on 9006, you get a real control-plane that is directly comparable to that of MX240/480 (RSP440 or 880) that has no problems doing heavy BGP work. Given that MX104 only has half the NPU of what 9001 offers, plus lower bandwidth, plus craptastic convergence speed, I would expect the price to be competitively lower, not exactly same or slightly higher than that of comparable ASR9k box, which in practice functions just fine doing heavy BGP. We don't need GRE tunnels on our peering routers, we just need MPLS 1-label imposition/disposition, IGP, fast BGP convergence, and acceptable 10GE port costs--that it.. it's not too much to ask for. For us at least, ASR9K meets that; MX104 does not. James ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX104 capabilities question
One Trio chip set. Sent from my iPhone On Jun 7, 2016, at 5: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 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX104 capabilities question
> 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
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. > 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. These routers have their place, they're definitely a Swiss Army Knife type of machine, it's just that the handle is really small... Oh - and something I forgot to mention in my original email: The MX104 doesn't support ISSU like the "real" MX routers do. ISSU isn't an option until somewhere in the 14.x train, I think, and JTAC's recommended stable release is still in the 13.x train. Kind of ticked about that one. Cheers Ross ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX104 capabilities question
> So the next bump up (which is an investment no doubt) is the larger MX > series. The MX240 has two card slots available. Using 16x10G or 32x10G will > yield a nice port density. One school of thought is since the MX480 bare > chassis is not much more than that of the MX240, it makes more ROI sense > just to opt for the larger chassis. YMMV Don't forget that the support is going to be higher on the 480 chassis. Also, technically you can run 3 MPCs in the the MX240 if you only run one RE. We do this, and then we deploy the MX240s in pairs which provides full chassis redundancy which makes us much more comfortable. This would be hard to do with the MX480 since the chassis is physically so much bigger - two in a rack is a huge amount of space. T ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX104 capabilities question
I thank everyone for their thoughts and comments, they do indeed jive with what I had already thought about the product. As long as the MX104 is capable of handling the 5 full table BGP peers (slow I understand) I think its worth rolling one as it has to be better them my Sup720CXL’s which forces us to take smaller tables already (we are currently having to take only /20 and greater + default) from our providers as the 720 just cant hang at full tables.In our particular application, we do not have any significant traffic (less than 1 Gb aggregate) but large companies like redundancy so this is a good alternative. If we were routing 20-30Gb /sec I think I might make the call to move to the MX240 but the cost doesn’t justify the end result in this case. I will offer the bosses the alternative MX240 but doubt they will like the cost. I guess we can say its all about compromises everywhere. Thanks again to the list. Ralph From: Bill Blackford [mailto:bblackf...@gmail.com] Sent: Tuesday, June 7, 2016 11:14 AM To: Ralph E. Whitmore, III Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] MX104 capabilities question A lot of folks have responded to this so at the risk of belaboring the point, yes the MX104 is very slow to load the FIB or during a churn. But forwarding performance is solid! Port density is an issue. MX104 can hold up to 12 ports @10G and has no issues forming LAG's across each MIC or in combination with the on-board ports, but maxes out at 80Gbps so with a 1:1 subscription, you're limited to 8 10G ports. You can run out of those very quickly particularly if it's a peering router and you opt for direct PNI's as time goes on and scale increases. Adding a second MX104 doesn't help much because once you make all of the needed redundant interconnects, you're still very limited on ports. So the next bump up (which is an investment no doubt) is the larger MX series. The MX240 has two card slots available. Using 16x10G or 32x10G will yield a nice port density. One school of thought is since the MX480 bare chassis is not much more than that of the MX240, it makes more ROI sense just to opt for the larger chassis. YMMV On Mon, Jun 6, 2016 at 1:01 AM, Ralph E. Whitmore, III mailto:ral...@interworld.net>> wrote: I am in the process of replacing my old cisco650x hardware and was steered to this list to pose the following questions: I have 4 primary BGP transits each delivering 600k+ routes to me and we will be adding another probably 600k+peer in the near future. The sales rep recommended the MX 104 to us first, but then came back to us and said "Sorry this router isn't adequate for your needs you need to be in the MX240 Chassis" I read the spec's I can find and it says from a routing engine perspective (RE-S-MX104) that it will handle the routes with room to grow on." From Juniper: IPv4 unicast FIB 1 million IPv6 unicast FIB 512K Ipv4 RIB 4 million IPv6 RIB 3 million So the question is: is there some other limiting factor(s) that should steer me away from the MX104 to the MX240 Chassis? Is the sales rep blowing smoke? I am hoping to find someone here who has tried this config and will either say yes this is great solution or OMG, I'd never try that again. Thanks Ralph ___ juniper-nsp mailing list juniper-nsp@puck.nether.net<mailto:juniper-nsp@puck.nether.net> https://puck.nether.net/mailman/listinfo/juniper-nsp -- Bill Blackford Logged into reality and abusing my sudo privileges. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX104 capabilities question
A lot of folks have responded to this so at the risk of belaboring the point, yes the MX104 is very slow to load the FIB or during a churn. But forwarding performance is solid! Port density is an issue. MX104 can hold up to 12 ports @10G and has no issues forming LAG's across each MIC or in combination with the on-board ports, but maxes out at 80Gbps so with a 1:1 subscription, you're limited to 8 10G ports. You can run out of those very quickly particularly if it's a peering router and you opt for direct PNI's as time goes on and scale increases. Adding a second MX104 doesn't help much because once you make all of the needed redundant interconnects, you're still very limited on ports. So the next bump up (which is an investment no doubt) is the larger MX series. The MX240 has two card slots available. Using 16x10G or 32x10G will yield a nice port density. One school of thought is since the MX480 bare chassis is not much more than that of the MX240, it makes more ROI sense just to opt for the larger chassis. YMMV On Mon, Jun 6, 2016 at 1:01 AM, Ralph E. Whitmore, III < ral...@interworld.net> wrote: > I am in the process of replacing my old cisco650x hardware and was steered > to this list to pose the following questions: > > I have 4 primary BGP transits each delivering 600k+ routes to me and we > will be adding another probably 600k+peer in the near future. The sales > rep recommended the MX 104 to us first, but then came back to us and said > "Sorry this router isn't adequate for your needs you need to be in the > MX240 Chassis" I read the spec's I can find and it says from a routing > engine perspective (RE-S-MX104) that it will handle the routes with room > to grow on." > > From Juniper: > IPv4 unicast FIB 1 million > IPv6 unicast FIB 512K > > Ipv4 RIB 4 million > IPv6 RIB 3 million > > > So the question is: is there some other limiting factor(s) that should > steer me away from the MX104 to the MX240 Chassis? Is the sales rep blowing > smoke? I am hoping to find someone here who has tried this config and will > either say yes this is great solution or OMG, I'd never try that again. > > Thanks > > Ralph > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > -- Bill Blackford Logged into reality and abusing my sudo privileges. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX104 capabilities question
On 7 June 2016 at 17:43, Adam Vitkovsky wrote: > Alright but isn't running GRE tunnels over limited MTU with a need to > reassemble fragments rather special case? I mean those as separate datapoints.Typhoon will crap out at like 12Mpps of GRE, far cry from Trio. And all fragmentation will be punted to LC CPU, where as Trio does it HW. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX104 capabilities question
> From: Saku Ytti [mailto:s...@ytti.fi] > Sent: Tuesday, June 07, 2016 2:56 PM > To: Adam Vitkovsky > Cc: Ross Halliday; juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] MX104 capabilities question > > On 7 June 2016 at 11:16, Adam Vitkovsky > wrote:¨ > > > These are all valid theoretical constrains. > > Yet MX104/MX80 system capacity is 80Gbps and ASR9k1 is 120Gbps. > > Because ASR9k1 has 2 NPUs. > > > And as we all know if you shift from the ideal packet size and pure IP > > routing the forwarding performance deteriorates more quickly on > > juniper NPs compared to cisco NPs. > > Citation needed. It's not black and white. ASR9k can't do defrag on HW, all is > punted, Trio does at very reasonable rate in HW. Trio has much better GRE > performance . > Alright but isn't running GRE tunnels over limited MTU with a need to reassemble fragments rather special case? For BAU Internet edge implementations you need fast BGP(control-plane) decent forwarding performance while edge/DoS filters are on(yup TCAM helps with that a lot, although you can't get crazy with the length of the filters) and fast RIB to FIB programing (yes, one could argue that cisco is not quite running circles around juniper, but on that note XR/XE/IOS supports PIC for pure IPv4 so no need to get your hands dirty with vpnv4 if you need a simple workaround for slow RIB to FIB programing) and a decent netflow (yes I'm aware it has its issues on XR). > > Also the RP on ASR9k1 is faster than one used in MX104. > > The HW itself on MX104 is faster, ASR9k1 is P4040 I believe, MX104 is P5021. > But of course that's not full truth. For example RSP720 is slower CPU than > MX104, but RSP720 control-plane runs circles around MX104. Why JunOS is so > dog slow, particularly on PPC, I have no idea. > Well I'd have couple, but none would benefit this particular discussion. > > So I'd say ASR9k1 is better box than MX104/MX80. > > I wouldn't, but I accept it's opinion not fact. > I stated couple facts above why if selecting a router for Internet edge it is a clear cut to me. 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
Re: [j-nsp] MX104 capabilities question
On 7 June 2016 at 11:16, Adam Vitkovsky wrote:¨ > These are all valid theoretical constrains. > Yet MX104/MX80 system capacity is 80Gbps and ASR9k1 is 120Gbps. Because ASR9k1 has 2 NPUs. > And as we all know if you shift from the ideal packet size and pure IP > routing the forwarding performance deteriorates more quickly on juniper NPs > compared to cisco NPs. Citation needed. It's not black and white. ASR9k can't do defrag on HW, all is punted, Trio does at very reasonable rate in HW. Trio has much better GRE performance . > Also the RP on ASR9k1 is faster than one used in MX104. The HW itself on MX104 is faster, ASR9k1 is P4040 I believe, MX104 is P5021. But of course that's not full truth. For example RSP720 is slower CPU than MX104, but RSP720 control-plane runs circles around MX104. Why JunOS is so dog slow, particularly on PPC, I have no idea. > So I'd say ASR9k1 is better box than MX104/MX80. I wouldn't, but I accept it's opinion not fact. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX104 capabilities question
> Of Saku Ytti > Sent: Tuesday, June 07, 2016 7:02 AM > > On 7 June 2016 at 03:09, Ross Halliday > wrote: > > Hey, > > 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. > Because of this design choice, I think MX80/MX104 is better box with smaller > BOM than ASR9001. > These are all valid theoretical constrains. Yet MX104/MX80 system capacity is 80Gbps and ASR9k1 is 120Gbps. And as we all know if you shift from the ideal packet size and pure IP routing the forwarding performance deteriorates more quickly on juniper NPs compared to cisco NPs. Also the RP on ASR9k1 is faster than one used in MX104. So I'd say ASR9k1 is better box than MX104/MX80. 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
Re: [j-nsp] MX104 capabilities question
On 7 June 2016 at 03:09, Ross Halliday wrote: Hey, > The MX104 is a great value box, but lacks some features which make it a "big > boys" router. Aside from the RE, the control plane isn't as segregated as I > thought, leading to interesting bugs like PR1031696 - which caused me to > briefly lose all 10G optics in the entire chassis while installing an XFP; as > well as some irritating behaviour from the ddos-protection mechanism. The > larger chassis are *sort of* like running DFC cards in a 6500, were > forwarding operations are pushed down. MX104 entirely relies on an integral > system in the chassis and all you install are MICs, *sort of* like running a > module with CFC and relying on the SUP. 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. Because of this design choice, I think MX80/MX104 is better box with smaller BOM than ASR9001. 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. 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. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX104 capabilities question
We made the same move, from a network of SUP720-3CXLs up to MX104, over the last two years. Our busiest MX104 ingests 3 full feeds and around 100k prefixes via an IXP. I'll echo Mark's sentiments: The MX104 has similar problems in that the CPU must update the FIB when the RIB changes. Small things like individual peers or normal churn aren't a big deal, but if we drop a major peer (say 300k prefixes destined to them), it's not pretty. It's not a slug like the 600 MHz MIPS SUP720 RP, but you can anticipate a couple minutes of reachability problems while the hardware shortcuts are updated to point out somewhere that accepts packets. The MX104 is a great value box, but lacks some features which make it a "big boys" router. Aside from the RE, the control plane isn't as segregated as I thought, leading to interesting bugs like PR1031696 - which caused me to briefly lose all 10G optics in the entire chassis while installing an XFP; as well as some irritating behaviour from the ddos-protection mechanism. The larger chassis are *sort of* like running DFC cards in a 6500, were forwarding operations are pushed down. MX104 entirely relies on an integral system in the chassis and all you install are MICs, *sort of* like running a module with CFC and relying on the SUP. I agree that you should spring for the MX240, which allows you the better RE, if you can afford/justify it. Unfortunately the larger MX platforms require the use of MPCs (not just MICs) so you wind up with a pretty awful number "just" to get a better RE, but there's a significant architectural difference, too. Depends on whether these are worth it to you or not. I imagine we'll eventually upgrade some of our key MX104s to the grown-up versions and reuse them elsewhere, but for now they do the job! Cheers Ross > -Original Message- > From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf > Of Mark Tinka > Sent: Monday, June 06, 2016 4:16 AM > To: Ralph E. Whitmore, III > Cc: juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] MX104 capabilities question > > > > On 6/Jun/16 10:01, Ralph E. Whitmore, III wrote: > > > I am in the process of replacing my old cisco650x hardware and was > steered to this list to pose the following questions: > > > > I have 4 primary BGP transits each delivering 600k+ routes to me and we > will be adding another probably 600k+peer in the near future. The sales > rep recommended the MX 104 to us first, but then came back to us and said > "Sorry this router isn't adequate for your needs you need to be in the > MX240 Chassis" I read the spec's I can find and it says from a routing > engine perspective (RE-S-MX104) that it will handle the routes with room > to grow on." > > > > >From Juniper: > > IPv4 unicast FIB 1 million > > IPv6 unicast FIB 512K > > > > Ipv4 RIB 4 million > > IPv6 RIB 3 million > > > > > > So the question is: is there some other limiting factor(s) that should > steer me away from the MX104 to the MX240 Chassis? Is the sales rep > blowing smoke? I am hoping to find someone here who has tried this config > and will either say yes this is great solution or OMG, I'd never try that > again. > > The MX104 will support 4x BGP sessions in the control plane (4GB RAM). > The problem is that the CPU on this router is massively slow, so you > will be in pain if you've got lots of churn. > > FIB-wise, you will be fine with the MX104. > > If you have the cash, go for the Intel-based RE's (MX240/480/960). If > you don't mind Cisco, consider the ASR1000-X platforms. > > 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 6/Jun/16 10:01, Ralph E. Whitmore, III wrote: > I am in the process of replacing my old cisco650x hardware and was steered to > this list to pose the following questions: > > I have 4 primary BGP transits each delivering 600k+ routes to me and we will > be adding another probably 600k+peer in the near future. The sales rep > recommended the MX 104 to us first, but then came back to us and said "Sorry > this router isn't adequate for your needs you need to be in the MX240 > Chassis" I read the spec's I can find and it says from a routing engine > perspective (RE-S-MX104) that it will handle the routes with room to grow > on." > > >From Juniper: > IPv4 unicast FIB 1 million > IPv6 unicast FIB 512K > > Ipv4 RIB 4 million > IPv6 RIB 3 million > > > So the question is: is there some other limiting factor(s) that should > steer me away from the MX104 to the MX240 Chassis? Is the sales rep blowing > smoke? I am hoping to find someone here who has tried this config and will > either say yes this is great solution or OMG, I'd never try that again. The MX104 will support 4x BGP sessions in the control plane (4GB RAM). The problem is that the CPU on this router is massively slow, so you will be in pain if you've got lots of churn. FIB-wise, you will be fine with the MX104. If you have the cash, go for the Intel-based RE's (MX240/480/960). If you don't mind Cisco, consider the ASR1000-X platforms. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
[j-nsp] MX104 capabilities question
I am in the process of replacing my old cisco650x hardware and was steered to this list to pose the following questions: I have 4 primary BGP transits each delivering 600k+ routes to me and we will be adding another probably 600k+peer in the near future. The sales rep recommended the MX 104 to us first, but then came back to us and said "Sorry this router isn't adequate for your needs you need to be in the MX240 Chassis" I read the spec's I can find and it says from a routing engine perspective (RE-S-MX104) that it will handle the routes with room to grow on." >From Juniper: IPv4 unicast FIB 1 million IPv6 unicast FIB 512K Ipv4 RIB 4 million IPv6 RIB 3 million So the question is: is there some other limiting factor(s) that should steer me away from the MX104 to the MX240 Chassis? Is the sales rep blowing smoke? I am hoping to find someone here who has tried this config and will either say yes this is great solution or OMG, I'd never try that again. Thanks Ralph ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
