Re: [j-nsp] Going Juniper
Hey, On 23 April 2018 at 16:25, wrote: > Well I envy you then :). > But was it for more-less like to like HW? -say modular card in both cases > -similar physical/logical BW to fabric and similar modules with similar port > count? Yes. > Was it just one time RPF discount or a pricing framework for future deals. Both have happened. > Now with the knob available in 17 Junos the benefit of A9k architecture is > reduced to the ability to protect high priority traffic when NPU is > overloaded down to 10GE entity level whereas on Juniper it's just per NPU as > a whole. I think the scenario you have may not be scenario many have. I know ASR9k drops on ingress on 10GE basis, so let's say your egress 10GE port has 5 VLANs, you've shaped them to 1Gbps each. Then one VLAN gets 20Gbps DDoS, all of the VLANs are congested, because you're dropping 10G on the ingress NPU, unaware of the egress VLANs. This same scenario would work just fine in MX. I'm not saying MX is superior on QoS. I'm just saying when you know the compromises made by each platform, and you cherry pick compromises, you can make anything look bad/good, this is what vendors pay Miercom to do. The results are not fabrications, but are they practical or useful to most or even many? > That's why I say in general, sure there are exceptions. General would need thorough data. Our opinion is coloured by which platform gets features that are relevant to us, we don't track those unrelevant to us. > Interesting, just curious how may VRFs/prefixes you ran into scaling issues? No VRFs. We have RIB of some 10M prefixes and about up-to 1M lines of config in device. > That's certainly a valid viewpoint on the patches thing. > I'm looking at it from a different angle though, the angle I'm looking at it > is software testing (regression testing in particular). > We spend significant effort on SW testing making sure it works as expected, > now if midway or god forbid towards the end of the whole exercise we find out > a show stopper we can't afford to repeat the whole process again for a > different release that doesn't have this problem (or wait for one to be > developed) this is where targeted patches are great help -you just need to > test dependencies for the delta then. > (and no having vendor to do the bug scrub and recommend bug free code for > your specific case is not the solution, will get you some head start but you > still need to perform the rigorous testing). I can't agree with your testing point, the testing you've done is not valid post SMU install. You are not spot fixing anything with the DDTS SMU, it's just newer version of given binary with all the changes included. Unless you're getting some engineering SMU and special build for you, which they usually refuse to support in meaningful way, so it's operationally risky. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
> Saku Ytti [mailto:s...@ytti.fi] > Sent: Monday, April 23, 2018 10:20 AM > > On 23 April 2018 at 11:34, wrote: > > > Well first of all juniper made it this far only because it's a cheap > > alternative to cisco, and you always get what you pay for. > > I and lot others on the list would disagree. Juniper was and still is > fundamentally automation friendly, where as even IOS-XR is not, as there is > no single source of truth from which CLI and machine presentation is built. > IOS-XR also has very contrived commit process, as there is no 'configuration' > or 'commit' component team, commit for tunnels is owned by tunnel > component team, commit for BGP is owned by BGP component team. The > commit working as well as it does in IOS-XR is surprising. > Commit/configuration process should not be of any concern to say BGP > developer, it should be free magic provided by the infrastructure. You have > very one-dimensional view to this. > In the RFPs I've been involved there never has been any significant price > advantage in JNPR to CSCO, both been available at similar commercial terms > to us. > Well I envy you then :). But was it for more-less like to like HW? -say modular card in both cases -similar physical/logical BW to fabric and similar modules with similar port count? Was it just one time RPF discount or a pricing framework for future deals. But price is just one part of it there's the whole ecosystem as well and with Juniper I feel like they actually listen while with Cisco you need to be at&t size to get meaningful attention. > > In HW MX-es internal architecture will *never be as solid as ASR9k's one. > > This is matter of debate. I'd view Trio next-generation to EZChip. I'd expect > for example NPU class device to support fragmentation in HW (crucial in > many mobile deployments) which ASR9k does not do. For me also punt > architecture in ASR9k is inferior to MX. However CSCO has something very > very interesting in HW pipeline, and I have high trust they can execute the > HW, but I have very little hopes IOS-XR will be fixed in meaningful manner. > My feeling is, internally no hard problems can be fixed in IOS-XR, because if > problem touches >1 component team, there seem no process to do that, it's > more desirable to add technological debt and do massive hacks to get > problem fixed inside single component, rather than fix some architectural > problem which requires multicomponent fixes. > The clear benefit I see in ASR9k HW architecture is multicast, but that's > never > been relevant to me. > Now with the knob available in 17 Junos the benefit of A9k architecture is reduced to the ability to protect high priority traffic when NPU is overloaded down to 10GE entity level whereas on Juniper it's just per NPU as a whole. > > 1) In general Junos is trailing XR in development (the gap seem to be > > around a year or little over), so if you need a new feature it'll be > > cutting edge on Junos while old news in XR. > > I think it's easy to show examples in both direction. IOS-XR was over decade > later with flowspec? > That's why I say in general, sure there are exceptions. > > 2) Junos is truly suffering from its monolithic nature (everything in > > RPD), in XR you can install only what you need reducing the bug > > surface, and the modularity allows for faster development. > > This is heavily contested opinion. Yes, on paper IOS-XR architecture is more > elegant. In practice I have more customer effecting defects in IOS-XR than > JunOS customers, more BGP scaling issues, more configuration size issues. > The flip side in multiprocess architecture like IOS-XR is that you end up > state > duplicating as some state simply isn't fast enough in the IPC design, and once > you end up state duplicating you expose yourself to state sync problems. > Interesting, just curious how may VRFs/prefixes you ran into scaling issues? -but I think these scaling issues are inevitable in high scale deployments -it's just a nature of parsing through big tables. My point is Junos folks know what to do to improve their BGP implementation and most of the stuff is there in the pipeline, it just takes ages to implement due to BGP sitting with a bunch of other stuff in the RPD. > > 3) In XR installing SMUs or PIEs to fix bugs is business as usual > > right, but how many of you are familiar with JSUs to do the same in > > Junos -the framework is so rarely used by customers that it's buggy in > > itself. > > The SMU is fallacy in my opinion, the SMUs are marketed as spot fixes to > specific DDTS, while they really are just shipping newer version for set of > binaries. So you get into this confusing state where to install DDTSx you must > uninstall DDDTSy and install DDTSz. It would be far easier if they didn't have > so much marketing pixie dust, if they didn't call SMUs DDTS, but just call > SMUs by the version of binaries you ship, and say DDTS requires BGP 4.2 and > RIB 2.2 or newer, t
Re: [j-nsp] Going Juniper
On 23/Apr/18 11:20, Saku Ytti wrote: > The SMU is fallacy in my opinion, the SMUs are marketed as spot fixes > to specific DDTS, while they really are just shipping newer version > for set of binaries. So you get into this confusing state where to > install DDTSx you must uninstall DDDTSy and install DDTSz. It would be > far easier if they didn't have so much marketing pixie dust, if they > didn't call SMUs DDTS, but just call SMUs by the version of binaries > you ship, and say DDTS requires BGP 4.2 and RIB 2.2 or newer, then no > one would find it confusing you don't need older versions of BGP and > RIB installed and that anything 4.1 BGP fixes, 4.2 BGP fixes. > But even if they do fix this communication problem, the whole SMU is > almost always useless complexity for vendor, as for us router is > mostly BGP control plane, if update flaps BGP there is no upsize to > reload for us. It would be so much simpler to engineer router which > boots in 30seconds and supports 0 patching, than to do this. I would > prefer the former. Obviously the best solution would be router where I > can update everything without reloading or flapping anything in > control-plane, (why can I do that in my irssi, but not in my IOS-XR > BGP?) but I can't see that happening any time soon, and I'm not going > to pay vendor premium to make it happen, I'm good restarting router > 2-4 times a year, as long as the update process doesn't take 3-4 > hours. Seems to only be getting worse, with later versions of IOS XR. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
On 23 April 2018 at 11:34, wrote: > Well first of all juniper made it this far only because it's a cheap > alternative to cisco, and you always get what you pay for. I and lot others on the list would disagree. Juniper was and still is fundamentally automation friendly, where as even IOS-XR is not, as there is no single source of truth from which CLI and machine presentation is built. IOS-XR also has very contrived commit process, as there is no 'configuration' or 'commit' component team, commit for tunnels is owned by tunnel component team, commit for BGP is owned by BGP component team. The commit working as well as it does in IOS-XR is surprising. Commit/configuration process should not be of any concern to say BGP developer, it should be free magic provided by the infrastructure. You have very one-dimensional view to this. In the RFPs I've been involved there never has been any significant price advantage in JNPR to CSCO, both been available at similar commercial terms to us. > In HW MX-es internal architecture will *never be as solid as ASR9k's one. This is matter of debate. I'd view Trio next-generation to EZChip. I'd expect for example NPU class device to support fragmentation in HW (crucial in many mobile deployments) which ASR9k does not do. For me also punt architecture in ASR9k is inferior to MX. However CSCO has something very very interesting in HW pipeline, and I have high trust they can execute the HW, but I have very little hopes IOS-XR will be fixed in meaningful manner. My feeling is, internally no hard problems can be fixed in IOS-XR, because if problem touches >1 component team, there seem no process to do that, it's more desirable to add technological debt and do massive hacks to get problem fixed inside single component, rather than fix some architectural problem which requires multicomponent fixes. The clear benefit I see in ASR9k HW architecture is multicast, but that's never been relevant to me. > 1) In general Junos is trailing XR in development (the gap seem to be around > a year or little over), so if you need a new feature it'll be cutting edge > on Junos while old news in XR. I think it's easy to show examples in both direction. IOS-XR was over decade later with flowspec? > 2) Junos is truly suffering from its monolithic nature (everything in RPD), > in XR you can install only what you need reducing the bug surface, and the > modularity allows for faster development. This is heavily contested opinion. Yes, on paper IOS-XR architecture is more elegant. In practice I have more customer effecting defects in IOS-XR than JunOS customers, more BGP scaling issues, more configuration size issues. The flip side in multiprocess architecture like IOS-XR is that you end up state duplicating as some state simply isn't fast enough in the IPC design, and once you end up state duplicating you expose yourself to state sync problems. > 3) In XR installing SMUs or PIEs to fix bugs is business as usual right, but > how many of you are familiar with JSUs to do the same in Junos -the > framework is so rarely used by customers that it's buggy in itself. The SMU is fallacy in my opinion, the SMUs are marketed as spot fixes to specific DDTS, while they really are just shipping newer version for set of binaries. So you get into this confusing state where to install DDTSx you must uninstall DDDTSy and install DDTSz. It would be far easier if they didn't have so much marketing pixie dust, if they didn't call SMUs DDTS, but just call SMUs by the version of binaries you ship, and say DDTS requires BGP 4.2 and RIB 2.2 or newer, then no one would find it confusing you don't need older versions of BGP and RIB installed and that anything 4.1 BGP fixes, 4.2 BGP fixes. But even if they do fix this communication problem, the whole SMU is almost always useless complexity for vendor, as for us router is mostly BGP control plane, if update flaps BGP there is no upsize to reload for us. It would be so much simpler to engineer router which boots in 30seconds and supports 0 patching, than to do this. I would prefer the former. Obviously the best solution would be router where I can update everything without reloading or flapping anything in control-plane, (why can I do that in my irssi, but not in my IOS-XR BGP?) but I can't see that happening any time soon, and I'm not going to pay vendor premium to make it happen, I'm good restarting router 2-4 times a year, as long as the update process doesn't take 3-4 hours. > Anyhow, I'm glad you, and I'm sure many others on the list, have a positive > experience with Juniper boxes, having Juniper on the market as a strong and > healthy competitor to Cisco is essential for the whole industry. Doesn't look so healthy to me, low volumes, low market cap, low investor interest. JNPR is less than half of PANW market cap, and PANW is 100% COTS no HW innovation, only security portfolio and there are probably 10 viable firewall vendors on the market. Doesn't make any sense t
Re: [j-nsp] Going Juniper
> Aaron Gould [mailto:aar...@gvtc.com] > Sent: Wednesday, April 18, 2018 2:44 PM > > Really? I'm hearing rumblings of pain in new XR upgrades > > google - [c-nsp] Cisco ASR99xx 64-bit upgrade 6.3.1 to 6.3.2 > > or > > https://lists.gt.net/cisco/nsp/199480 > > I can't say from experience since I'm sitting on 4.1.2 (lol, hey, it works!) I > recall XR and PIES being for straightforward, but I don't think Junos upgrades > for me have been as involved as XR and separate PIES > > I upgraded (5) MX960's within the past week to newer Junos with vmhost > using ISSU process and it went very nicely > > I upgraded an EX4550 yesterday for 40 gig pic compatibility and it also went > nicely > > Cisco and Juniper wouldn't have made it this far in the network industry if > they both weren't great options. It is interesting to compare two great things > :) > Well first of all juniper made it this far only because it's a cheap alternative to cisco, and you always get what you pay for. In HW MX-es internal architecture will *never be as solid as ASR9k's one. *That is not me saying never but MX team saying never when we proposed some changes to the architecture in order to get them where ASR9k is in terms of platforms internal architecture (at least on the paper), but to be fair they fixed 2 out of 3 design flaws, (by asic redesign and by added knob) so the "never" was only for the third one -one you're least likely to hit I'd say). And it goes without saying that ASR9k internals are also not 100% flawless straight out of the box and need some tweaking in LC cli. In SWs it's little more complicated, 1) In general Junos is trailing XR in development (the gap seem to be around a year or little over), so if you need a new feature it'll be cutting edge on Junos while old news in XR. 2) Junos is truly suffering from its monolithic nature (everything in RPD), in XR you can install only what you need reducing the bug surface, and the modularity allows for faster development. 3) In XR installing SMUs or PIEs to fix bugs is business as usual right, but how many of you are familiar with JSUs to do the same in Junos -the framework is so rarely used by customers that it's buggy in itself. 4) Junos BGP implementation, well ya'll know my views... Anyhow, I'm glad you, and I'm sure many others on the list, have a positive experience with Juniper boxes, having Juniper on the market as a strong and healthy competitor to Cisco is essential for the whole industry. Despite what I said I'm a big fan of juniper, love the support and attention they give even to smaller deals, Yes it sometimes takes a bit longer to get to right people in India to talk about ASIC internals in comparison to just pinging Xander or Aleks on cisco support page to get the same level of info. But the most important thing for me is they listen are willing to improve. adam netconsultings.com ::carrier-class solutions for the telecommunications industry:: ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
IPv6? Or am I at risk of lighting a fire :-)? Mark. On 21/Apr/18 21:55, Aaron Gould wrote: > $5-10 per ip ?! Buy it now! > > I was propositioned just this week about my letting go of a /17 for half a > million dollars ! that's about $15/per ip > > My MX104 with MX-MIC-16G were about $25k > > I bought 2 and put ~6,000 dsl customers behind them > > I'm so glad I did > > -Aaron > > > > -Original Message- > From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of > mike+j...@willitsonline.com > Sent: Friday, April 20, 2018 6:37 PM > To: bo...@pobox.com > Cc: juniper-nsp@puck.nether.net > Subject: Re: [j-nsp] Going Juniper > > > > On 04/13/2018 02:30 PM, bo...@pobox.com wrote: >> On Mon, 9 Apr 2018, mike+j...@willitsonline.com wrote: >> >>> Id even like to do cgnat for up to 5000 users but not sure if a >>> single box setup would be wise. >> I'm curious why you and other service providers are interested in >> CGNAT when IPv4 addresses are still relatively cheap to buy. In many >> cases, even the hard costs of CGNAT are less thant what the needed >> IPv4 addresses cost, let alone the large operational costs of >> supporting users behind NATS, so I'm guessing your motivations aren't >> about cost, is that right? >> > Cheap... hmm... $5 - $10/each is not cheap, but at that level, nat is > like printing money. Now, if someone had a /20 for closer to $1/ea, > maybe... but what I know of that market is, forget it. > > ___ > 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 > . > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
$5-10 per ip ?! Buy it now! I was propositioned just this week about my letting go of a /17 for half a million dollars ! that's about $15/per ip My MX104 with MX-MIC-16G were about $25k I bought 2 and put ~6,000 dsl customers behind them I'm so glad I did -Aaron -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of mike+j...@willitsonline.com Sent: Friday, April 20, 2018 6:37 PM To: bo...@pobox.com Cc: juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Going Juniper On 04/13/2018 02:30 PM, bo...@pobox.com wrote: > On Mon, 9 Apr 2018, mike+j...@willitsonline.com wrote: > >> Id even like to do cgnat for up to 5000 users but not sure if a >> single box setup would be wise. > > I'm curious why you and other service providers are interested in > CGNAT when IPv4 addresses are still relatively cheap to buy. In many > cases, even the hard costs of CGNAT are less thant what the needed > IPv4 addresses cost, let alone the large operational costs of > supporting users behind NATS, so I'm guessing your motivations aren't > about cost, is that right? > Cheap... hmm... $5 - $10/each is not cheap, but at that level, nat is like printing money. Now, if someone had a /20 for closer to $1/ea, maybe... but what I know of that market is, forget it. ___ 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] Going Juniper
On 04/13/2018 02:30 PM, bo...@pobox.com wrote: > On Mon, 9 Apr 2018, mike+j...@willitsonline.com wrote: > >> Id even like to do cgnat for up to 5000 users but not sure if a >> single box setup would be wise. > > I'm curious why you and other service providers are interested in > CGNAT when IPv4 addresses are still relatively cheap to buy. In many > cases, even the hard costs of CGNAT are less thant what the needed > IPv4 addresses cost, let alone the large operational costs of > supporting users behind NATS, so I'm guessing your motivations aren't > about cost, is that right? > Cheap... hmm... $5 - $10/each is not cheap, but at that level, nat is like printing money. Now, if someone had a /20 for closer to $1/ea, maybe... but what I know of that market is, forget it. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
On 19/Apr/18 16:50, Josh Richesin wrote: > I think it is by design as well, but really defeating the purpose therefore > misleading us – the loyal customers. Juniper is an excellent platform, but > sometimes you want / need to start small and grow into a device. Like > previously mentioned, the MX104 is pretty ridiculous. I am sure Juniper lost > some loyal Juniper fans over this as the bean counters are saying, “what do > you mean it is going to cost that much more $$$ to enable the 10g ports that > are just sitting there.” In my opinion, they should have at least made it > the same cost, or maybe a little more money. It is actually cheaper for the > guys that bought MX104’s to buy a new MX204, than to upgrade the MX104 Base > effectively making the initial MX104 an expensive boat anchor. Agreed. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
CONFIDENTIAL and/or SENSITIVE Information Enclosed. This message cannot be forwarded, printed, or otherwise used without the sole and express permission of Sureline Broadband. Confidentiality Notice: This message and all attachments are subject to the Electronic Communications Privacy Act, Title 18 U.S.C. This email may contain information that is privileged, confidential, or otherwise exempt from disclosure under applicable law. If you are not the addressee or you have received this email in error, please delete this email, and contact us immediately at bill...@surelinebroadband.com. Sureline Broadband - Confidential: This content is proprietary information intended for internal use only. This content cannot be modified, copied, forwarded or printed without the sole and express permission of Sureline Broadband. I think it is by design as well, but really defeating the purpose therefore misleading us – the loyal customers. Juniper is an excellent platform, but sometimes you want / need to start small and grow into a device. Like previously mentioned, the MX104 is pretty ridiculous. I am sure Juniper lost some loyal Juniper fans over this as the bean counters are saying, “what do you mean it is going to cost that much more $$$ to enable the 10g ports that are just sitting there.” In my opinion, they should have at least made it the same cost, or maybe a little more money. It is actually cheaper for the guys that bought MX104’s to buy a new MX204, than to upgrade the MX104 Base effectively making the initial MX104 an expensive boat anchor. Josh On 4/19/18, 2:30 AM, "juniper-nsp on behalf of Mark Tinka" wrote: On 10/Apr/18 15:10, Josh Baird wrote: > I have found the licensing costs on the MX104 to be pretty ridiculous. I > can buy a brand new MX204 with plenty of 10Gbps interfaces for cheaper than > it would be up upgrade the "base" MX104 (MX104-MX5 bundle) to enable the > four of the built-in 10Gbps interfaces and additional chassis throughput. I think that is by design :-). Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp Confidentiality and Sensitive Information Notice: This message and all attachments are subject to the Electronic Communications Privacy Act, Title 18 U.S.C. and the sole property of Sureline Broadband. This email may contain information that is privileged, sensitive, confidential, or otherwise exempt from disclosure under applicable law, and may not be copied, printed, or forwarded without the express and sole permission of Sureline Broadband. If you are not the addressee or you have received this email in error, please delete this email, and contact us immediately at bill...@surelinebroadband.com. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
The way I've deployed my dual MX104's for CGNat using the MS-MIC-16G has been great for us. I now have ~5,000 DSL subscribers and one Cable Modem CMTS community (/24 - ~250 subs) all sitting behind those dual MX104's The MX104's are both similar... - dual 10 gig connected with ae lag - mpls enabled PE, like Nat-on-a-stick - purely MPLS L3VPN --- inside domain is MPLS L3VPN -- inside domain for dsl - vrf x -- inside domain for cable modem - vrf y --- outside domain is MPLS L3VPN -- same outside domain for internet next hop for both dsl and cable modem, however I use a different public outside pool for dsl and cable modem ...just wanted to say that the way I'm using the MX104's is working out quite nicely. -Aaron Previous post mentioned... ". Shame though about the MX104's, only had those in since 2016. .But the MX104 was, basically, a very poor decision from Juniper. I hope it's haunting at least one person there never to repeat such in the future. You can't play games with your customers like that..." ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
On 18/Apr/18 09:52, Gert Doering wrote: > Judging from the recent threads on JunOS upgrade pains, seems they did... > > "New feature: more annoying software upgrades than IOS XR!" I was gonna say, "Except that" :-). Mark. 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] Going Juniper
On 11/Apr/18 13:08, Ola Thoresen wrote: > > > But as you say, you can easily use the exact same hardware in a > regular L2 setup, the thing you gain from the satellite setup is > central management of only the routers, which can be a time and > management saver. Isn't that was SDN was for :-)... Oh wait, it's now IDN :-)... Oh hell, can't keep up... Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
On 11/Apr/18 12:51, Saku Ytti wrote: > I have strong dislike to satellite solutions. I'd rather even run L2 > backhaul than satellite. There tends to be all kind of catches and > esoteric differences between 'native' port and satellite port, and > those are not documented anywhere, probably not even known to vendor, > and you just stumble on them as you go. As well as you have to carry > the increased bug surface of the vendor's proprietary host<->satellite > code. > > Granted at least JNPR offering allows you to run same device as pure > L2, with Cisco offering it is satellite-only box, cannot be used as > L2. I know some of Nokia's satellites can also operate as standalone, but yes, I am with you. At least once a quarter, a vendor is trying to sell me a satellite. Not sure how they forgot why I asked them to stop talking that way to me a quarter ago :-). Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
On 11/Apr/18 11:51, James Bensley wrote: > I had heard (more or less from the horses mouth) that the MX104's were > initially developed for an Indian telco - they basically wanted MX80s > but with a higher temperature rating and dual REs, allowing them to be > used in mobile base station sites. These would be hard to reach so > they needed reliability (dual REs) and sometimes "external" (as in not > in an air-cooled DC but maybe a roof-top cabinet etc.). Upgraded REs > would have been great. I have seen some that run with low CPU > "normally" but when they are being polled by SNMP they spike to 100%. If I had a penny for every time a new box was developed for mobile backhaul... Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
On 11/Apr/18 11:31, Saku Ytti wrote: > I suspect more correct reason is that they don't see sufficient market > potential in device like MX104. I think Cisco and Juniper are very > confused about market, they appear to think entire market consists > solely of large scale DC providers. That only addressable market is > market which wants extremely dense 100GE boxes. 1GE is dead, 10GE is > almost dead. This is not limited to the packet space - any reputable DWDM vendor is now building for, what's the new buzzword these days, ah yes, "Webscale" :-|... Juniper have, generally, struggled with the non-Ethernet market. They did okay during the M-series era, but as Cisco moved away from the 7500 series to the 1 series to the 2600/2800 series to the 7200 series and now to the ASR1000, Juniper never thought to play in that space. Then again, with everything being Ethernet now, it's probably cheaper to buy an MX240/480/960 or ASR9000-chassis-based in lieu of an ASR1000. And this why non-Ethernet + low-speed Ethernet from Cisco and Juniper is seeing a decline in development interest from them. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
On 11/Apr/18 00:23, Olivier Benghozi wrote: > I suppose/hope that the product manager who took such decision is now in a > madhouse. +1. Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
On 10/Apr/18 15:10, Josh Baird wrote: > I have found the licensing costs on the MX104 to be pretty ridiculous. I > can buy a brand new MX204 with plenty of 10Gbps interfaces for cheaper than > it would be up upgrade the "base" MX104 (MX104-MX5 bundle) to enable the > four of the built-in 10Gbps interfaces and additional chassis throughput. I think that is by design :-). Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
On 10/Apr/18 05:07, Chris via juniper-nsp wrote: > > I can't speak for the MX240, but we have some deployments of the > MX104, MX80 and the vMX. > > For the MX104 (and the MX80) the main limitation they have is that the > CPU on the routing engine is terribly slow. This can be a problem for > you if you are taking multiple full tables with BGP. Even without > taking full tables, the RE CPU on the MX104's I have is basically > always at 100%. Commits are pretty slow as well. This shouldn't be > such an issue with the MX240 as it has a wider range of routing > engines available with much better specs. We've discontinued all our MX80's - moved those to MX480's. We are in the process of ditching all our MX104's. Most likely move those to MX480's as well. We got a lot of life out of our MX80's... ran them since 2012. Shame though about the MX104's, only had those in since 2016. I can't fault the MX80; it did what it was designed to do. But the MX104 was, basically, a very poor decision from Juniper. I hope it's haunting at least one person there never to repeat such in the future. You can't play games with your customers like that... Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
On 18 April 2018 at 18:10, Jared Mauch wrote: > Just because DNA could be sequenced, didn’t mean it was easy/cheap/accessible. It indeed was not. But now it's 350EUR, world changes. There are incapable operators, for sure. At least IOS offers for those simple method of prefix-list in/out, when you outgrow that one, learning TCL/LUA/mruby isn't going to be that much harder than RPL, and you won't outgrow it. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
> On Apr 18, 2018, at 11:06 AM, Saku Ytti wrote: > > Juniper was founded 1996 > Lua was released 1993 > Ruby was released 1995 > > And of course there was TCL before, and I'm sure other solutions > before that. Embedding programming language to your tools isn't very > new notion. Maybe route-maps are sufficiently simple to justify their > existence, but RPL decidedly looks like it's suffering NIH and would > have been cheaper and better if they used some existing language. Not really as IOS-XR was started around the time that Juniper was started. Also suggesting that a language invention equals broad knowledge in the industry of how to use it properly, what it’s capabilities are, etc is misleading. Just because DNA could be sequenced, didn’t mean it was easy/cheap/accessible. :-) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
Juniper was founded 1996 Lua was released 1993 Ruby was released 1995 And of course there was TCL before, and I'm sure other solutions before that. Embedding programming language to your tools isn't very new notion. Maybe route-maps are sufficiently simple to justify their existence, but RPL decidedly looks like it's suffering NIH and would have been cheaper and better if they used some existing language. On 18 April 2018 at 17:56, Gert Doering wrote: > Hi, > > On Wed, Apr 18, 2018 at 05:48:23PM +0300, Saku Ytti wrote: >> Personally I'm not sure why vendors bother inventing some DSL for >> this, instead of just using prior art like lua or mruby where they >> offer prefixes as objects with plenty of useful methods. > > "prior art"? > > Fairly sure JunOS is 10 years older than lua or ruby... > > XR might only be 5 years older. > > gert > -- > "If was one thing all people took for granted, was conviction that if you > feed honest figures into a computer, honest figures come out. Never doubted > it myself till I met a computer with a sense of humor." > Robert A. Heinlein, The Moon is a Harsh Mistress > > Gert Doering - Munich, Germany g...@greenie.muc.de -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
Hi, On Wed, Apr 18, 2018 at 05:48:23PM +0300, Saku Ytti wrote: > Personally I'm not sure why vendors bother inventing some DSL for > this, instead of just using prior art like lua or mruby where they > offer prefixes as objects with plenty of useful methods. "prior art"? Fairly sure JunOS is 10 years older than lua or ruby... XR might only be 5 years older. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
On 18 April 2018 at 16:50, Gert Doering wrote: > I really *really* like RPL. And the amazingly fast BGP in general. > > Route-Policies in JunOS seem to be a bit... "surprisy". I think RPL is probably slightly better, but it's close one and both have some negative/positive. Personally I'm not sure why vendors bother inventing some DSL for this, instead of just using prior art like lua or mruby where they offer prefixes as objects with plenty of useful methods. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
Hi, On Wed, Apr 18, 2018 at 08:35:23AM -0500, Aaron Gould wrote: > Like what ? What are those things you really wish Juniper would do that > Cisco did in XR ? > > I've been working with XR for several years now, and I'm really liking what > I'm seeing in Junos. I really *really* like RPL. And the amazingly fast BGP in general. Route-Policies in JunOS seem to be a bit... "surprisy". gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
Really? I'm hearing rumblings of pain in new XR upgrades google - [c-nsp] Cisco ASR99xx 64-bit upgrade 6.3.1 to 6.3.2 or https://lists.gt.net/cisco/nsp/199480 I can't say from experience since I'm sitting on 4.1.2 (lol, hey, it works!) I recall XR and PIES being for straightforward, but I don't think Junos upgrades for me have been as involved as XR and separate PIES I upgraded (5) MX960's within the past week to newer Junos with vmhost using ISSU process and it went very nicely I upgraded an EX4550 yesterday for 40 gig pic compatibility and it also went nicely Cisco and Juniper wouldn't have made it this far in the network industry if they both weren't great options. It is interesting to compare two great things :) - Aaron ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
Like what ? What are those things you really wish Juniper would do that Cisco did in XR ? I've been working with XR for several years now, and I'm really liking what I'm seeing in Junos. Don't get me wrong, I really like XR. I'm liking Junos just as much... and my appreciation for Junos is growing every day, the more I work with it. - Aaron ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
2018-04-18 14:07 GMT+02:00 Julien Goodwin : > On 18/04/18 17:52, Gert Doering wrote: > > Hi, > > > > On Wed, Apr 18, 2018 at 08:37:51AM +0100, adamv0...@netconsultings.com > wrote: > >> Ha, I really wish Juniper would look at what XR did on whole host of > things > >> :) > > > > Judging from the recent threads on JunOS upgrade pains, seems they did... > > > > "New feature: more annoying software upgrades than IOS XR!" > > Next version: Randomly disappearing config lines, hope you didn't need > those BGP policies! > > (Also, fun bar topic, IOS XR or Ironware, which is more painful for OS > upgrades?) > Actually, I have been playing with IronWare for the past 6 years and it has become much more painless as it is automated now. Still, it lacks ISSU that it will never get. My 2 cents. > ___ > 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] Going Juniper
On 18/04/18 17:52, Gert Doering wrote: > Hi, > > On Wed, Apr 18, 2018 at 08:37:51AM +0100, adamv0...@netconsultings.com wrote: >> Ha, I really wish Juniper would look at what XR did on whole host of things >> :) > > Judging from the recent threads on JunOS upgrade pains, seems they did... > > "New feature: more annoying software upgrades than IOS XR!" Next version: Randomly disappearing config lines, hope you didn't need those BGP policies! (Also, fun bar topic, IOS XR or Ironware, which is more painful for OS upgrades?) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
Hi, On Wed, Apr 18, 2018 at 08:37:51AM +0100, adamv0...@netconsultings.com wrote: > Ha, I really wish Juniper would look at what XR did on whole host of things > :) Judging from the recent threads on JunOS upgrade pains, seems they did... "New feature: more annoying software upgrades than IOS XR!" gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
> Jared Mauch > Sent: Wednesday, April 18, 2018 12:39 AM > > > > > On Apr 17, 2018, at 7:02 PM, Saku Ytti wrote: > > > > > > DDoS protection out-of-the-box is for all practical purposes not > > configured at all, which is unfortunate as that is what most people > > run. When configured correctly Trio has best CoPP I know of in the > > market, certainly better than Cisco or Arista have. > > I do wish that Juniper would look at what IOS-XR has done to make > configuring it much easier out of the box. An ASR 9K w/ default LPTS is much > nicer than a Juniper with default firewall filters. > Ha, I really wish Juniper would look at what XR did on whole host of things :) adam netconsultings.com ::carrier-class solutions for the telecommunications industry:: ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
Indeed, I remember our discussions on the topic before! I still haven't made much headway. It's worth pointing out, though, that the "not configured" state can pop up when you least expect it, such as an aggregate filtering action applied after a broadcast storm (which you THOUGHT you fixed, but for some reason a bunch of stuff doesn't work still and you can't get into the box and aren't sure why). Good to watch out for since a network where unexpected things don't happen isn't connected to anything and certainly doesn't have any administrators ;) - Ross -Original Message- From: Jared Mauch [mailto:ja...@puck.nether.net] Sent: Tuesday, April 17, 2018 7:39 PM To: Saku Ytti Cc: Ross Halliday; juniper-nsp@puck.nether.net Subject: Re: [j-nsp] Going Juniper > On Apr 17, 2018, at 7:02 PM, Saku Ytti wrote: > > > DDoS protection out-of-the-box is for all practical purposes not > configured at all, which is unfortunate as that is what most people > run. When configured correctly Trio has best CoPP I know of in the > market, certainly better than Cisco or Arista have. I do wish that Juniper would look at what IOS-XR has done to make configuring it much easier out of the box. An ASR 9K w/ default LPTS is much nicer than a Juniper with default firewall filters. - Jared ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
> On Apr 17, 2018, at 7:02 PM, Saku Ytti wrote: > > > DDoS protection out-of-the-box is for all practical purposes not > configured at all, which is unfortunate as that is what most people > run. When configured correctly Trio has best CoPP I know of in the > market, certainly better than Cisco or Arista have. I do wish that Juniper would look at what IOS-XR has done to make configuring it much easier out of the box. An ASR 9K w/ default LPTS is much nicer than a Juniper with default firewall filters. - Jared ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
Hey Ross, > The low-end MXes can do a lot of things, but that doesn't mean you SHOULD > necessarily do them. Anything CPU-heavy is a good example. Convergence time > on three full feeds takes about 10-15 minutes in my experience, say in the > case a major upstream drops. This isn't a big deal for everyone and for my > employer certainly not enough to justify a bigger box on its own. One of the > platform's strengths is also its weakness, in that the MX104 is essentially > fabricless. Each of the "PIC" slots is a carved out chunk of a single > forwarding engine. This is why they're limited to the 2-XFP MICs for 10 GbE > options, unlike bigger MXes that take MICs with a much greater port density > and support more than 4 SFP+es. This is also why you have things that will > affect the entire chassis at once, such as one of my favourite optics bug > (plug in an SFP too slowly and all SFPs reset) and the DDoS Protection > feature (blackholes an entire class of traffic on ALL ports). They are not > suitable for core use for th DDoS protection out-of-the-box is for all practical purposes not configured at all, which is unfortunate as that is what most people run. When configured correctly Trio has best CoPP I know of in the market, certainly better than Cisco or Arista have. DDoS protection has many levels 1. aggregate 2. per-npu 3. per-physical-interface 4. per-logical-interface 5. per-subscriber (session). 5. is dubious, as it's easy to congest the policer counts (Attacker changes SPORT). But 3-4 should protect you from issue you describe. If you limit each IFL or IFD, then single IFL or IFD won't congest whole NPU, and having for example BGP down in the IFL which is violating the BGP policer is entirely acceptable. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
A little late to the party, but I've been accused of worse. We transitioned our network from Cisco 6500 platform to MX104s, and at the same time converged our Internet Edge onto those MXes too. It's the only Juniper router I'm aware of that actually fits *nicely* into a two-post rack, and they draw little power for what they are (approx. 150W on DC at idle at lower temperatures). The low-end MXes can do a lot of things, but that doesn't mean you SHOULD necessarily do them. Anything CPU-heavy is a good example. Convergence time on three full feeds takes about 10-15 minutes in my experience, say in the case a major upstream drops. This isn't a big deal for everyone and for my employer certainly not enough to justify a bigger box on its own. One of the platform's strengths is also its weakness, in that the MX104 is essentially fabricless. Each of the "PIC" slots is a carved out chunk of a single forwarding engine. This is why they're limited to the 2-XFP MICs for 10 GbE options, unlike bigger MXes that take MICs with a much greater port density and support more than 4 SFP+es. This is also why you have things that will affect the entire chassis at once, such as one of my favourite optics bug (plug in an SFP too slowly and all SFPs reset) and the DDoS Protection feature (blackholes an entire class of traffic on ALL ports). They are not suitable for core use for th is reason. They are very handy but less than great. MX104 is really made for telecom remotes and small COs with limited floor plans. MX80 and variants would be a convenient solution if you got one from the used market and have a 4-post rack. Both are really intended as 1 GbE aggregation routers. The MX104 is better since it has redundant REs, and if you just need some stuff off of an MS-MIC then it'd be a reliable low-maintenance box. But be aware that you're paying a premium for the form factor and not for something that will be in your network for a long time as they have very limited upgradability. We were originally pretty excited but we're replacing a lot now since they just can't deliver the 10G port density we need. Heck I think you can get smart lightbulbs these days that come with 10GbE ports... Based on things I see in the mailing list, I'd take a serious look at splitting things up into more scalable components, such as the vMX and maybe an MX204 - systems that have real upgrade potential - although I have no idea what the pricing is like since we're going the "Big MX" route. On Wednesday, April 11, 2018 5:32 AM, Saku Ytti wrote: > > On 11 April 2018 at 04:31, Chris via juniper-nsp > wrote: > > > Since the MX104 has user replacable RE's I really wish Juniper would at > > least offer a different option with a more beefy CPU/RAM but I don't think > > that would ever happen... > > I think JNPR believes MX204 is the 'next gen MX104'. I bet if there > was MX204 with 2xQSFP28 + 24-48xSFP+, sold attractively priced with BW > license, so that SFP+ as 1GE and sub would make sense, those would > sell really well. Indeed it would. Even better if they hardened up the MX204 so it could be installed in the same environments. > New RE for MX104 was on the table early on in the MX104 history, but > then JNPR changed tracks, citing XEON not being thermally possible on > it. I would bet money that this has as much to do with it as planned limited lifetime of the platform. Maybe two thirds of our MX104s have baked PEM0 (the most down-wind power supply) out of existence. Any better CPU in there would have to be something like an ARM to keep the thing from roasting both power supplies simultaneously. > I suspect more correct reason is that they don't see sufficient market > potential in device like MX104. I think Cisco and Juniper are very > confused about market, they appear to think entire market consists > solely of large scale DC providers. That only addressable market is > market which wants extremely dense 100GE boxes. 1GE is dead, 10GE is > almost dead. I have noticed this as well. A lot of noise about ultra-dense machines that take up way too much space (depth) and need half a rack's worth of break-out cables to do anything interesting. That is, as long as "interesting" means "inside the building". I think vendors are taking "cloud" too seriously, as it seems that everybody's forgotten that the access and aggregation layers actually exist. Err I mean to say, just use hyperconverged Next Gen 5G. It's magic! Right? On Thursday, April 12, 2018 3:58 AM, James Harrison wrote: > > On 11/04/2018 10:51, James Bensley wrote: > > I would agree with > > you that low port coun't, good, and reasonably priced mixed 1G/10G > > devices aren't plentiful in choice from vendors. We open a lot of > > small PoPs so stuff like ME3600X/ASR920s, ASR9001, MX104 are great for > > us but each with their own caveats. > > Particularly if you include the requirement for temperature hardening - > we deploy a lot of street c
Re: [j-nsp] Going Juniper
On 11/04/2018 10:51, James Bensley wrote: > I would agree with > you that low port coun't, good, and reasonably priced mixed 1G/10G > devices aren't plentiful in choice from vendors. We open a lot of > small PoPs so stuff like ME3600X/ASR920s, ASR9001, MX104 are great for > us but each with their own caveats. Particularly if you include the requirement for temperature hardening - we deploy a lot of street cabinet sites, and MX104s and ASR902s are basically the only boxes in town that have reasonable 10G density and a sensible temperature range for external boxes. We don't need the full capability of a 104 (and feature-wise the 920 and 902s are chock full of unfortunate compromises) but sadly the higher bandwidth stuff based around x86 and BRCM silicon isn't yet entering the temp-hardened space. We have a few 104s out in prod doing fairly basic bits of EVPN and they're very capable boxes - just pricey for the ports we need. -- Cheers, James Harrison ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
>>> On 11 April 2018 at 13:43, Ola Thoresen wrote: >>> Granted at least JNPR offering allows you to run same device as pure >>> L2, with Cisco offering it is satellite-only box, cannot be used as >>> L2. >> >> I know what you mean, but I must say that this time it seems like they have >> more or less managed to do it right. They use pretty standard protocols for >> everything, it is just "packaged" so you don't need to think about it. >> >> But as you say, you can easily use the exact same hardware in a regular L2 >> setup, the thing you gain from the satellite setup is central management of >> only the routers, which can be a time and management saver. I have to say, I completely disagree. On 11 April 2018 at 13:12, Alexandre Guimaraes wrote: > Last notice that I have about Junos fusion, some features doesn’t work in to > satellite ports, like ethernet ccc. ^ This is the reason why. Fusion is a layer 1 extension, my 1st question to Juniper is why is there a DC version and a Service Provider version? https://www.juniper.net/assets/us/en/local/pdf/datasheets/1000523-en.pdf: "Junos Fusion Provider Edge is a technology enabler that overcomes optical pluggable p hysical limitations by delegating low-speed optical interfaces to a cost-appropriate switch, virtually expanding connectivity to thousands of ports from a single Juniper Networks MX Series 3D Universal Edge Router." "Junos Fusion Data Center provides automated network configuration and operational simplicity for medium to large data centers with up to four QFX1 switches deployed in the spine layer and any combination of up to 64 QFX5100, QFX5110-48S, QFX5200-32C, and EX4300 top-of-rack switches deployed as satellite devices." Basically the same justification for both technology variants - more ports for less money with zero touch deployment. Both scenarios can benefit from those proposed advantages so no need to make them separate products. Obviously they will to make more money, but it looked back it you have an Ethernet based layer 1 extension technology and there is more than one variant of it, in 2018 we're only using one kind of Ethernet here. OK, 2nd question, and this is my real annoyance, and why I believe Juniper haven't done it right; Why are certain features, e.g. Inter-AS MPLS Option B connections, not support over the Service Provider version? We're heavy users of OptB interconnects and these devices are supposed to be layer 1 extensions. Can they pass an Ethernet frame, yes or no? The answer is yes so anything higher level should be ignored in my opinion. After pressing Juniper they said that certain traffic types aren't support because when they release new Fusion version, they test the most common traffic types and they "can't test everything", and MPLS OptB's are on the "no time for testing" list. It is possible that it would work just fine, but if any issues arise they won't support it. Surely they should test that Ethernet frames pass OK and then support anything that runs over Ethernet? If you're selling a layer 1 extension service for Ethernet and a certain kind of traffic isn't support that runs over the top of Ethernet - that is a great big red flag to me. We only have Fusion because they wanted more people to run it - they sold it to us for cheaper than vanilla layer 2 switches. I feel dirty. Cheers, James. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
On 11. april 2018 14:12, Alexandre Guimaraes wrote: Hello everyone! Last notice that I have about Junos fusion, some features doesn’t work in to satellite ports, like ethernet ccc. Did you guys that use, can confirm that, or all features are available? I did set up a l2circuit between a vlan (interface xe-100/0/0.100, vlan 100 on a MX204 with a QFX5100 as satellite) and a remote MX80 a few days ago, and it worked flawlessly. Rgds. Ola Thoresen ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
Hello everyone! Last notice that I have about Junos fusion, some features doesn’t work in to satellite ports, like ethernet ccc. Did you guys that use, can confirm that, or all features are available? att Alexandre Em 11 de abr de 2018, à(s) 08:11, Ola Thoresen escreveu: > On 11. april 2018 12:51, Saku Ytti wrote: > >> On 11 April 2018 at 13:43, Ola Thoresen wrote: >> >> >>> We have recently started playing with MX204 and Junos Fusion, and that makes >>> a really nice setup. >>> With either EX4300 (for 1G) or QFX5100 (for 10G), you get a lot of ports and >>> a great routing engine for a "decent" cost. >> I have strong dislike to satellite solutions. I'd rather even run L2 >> backhaul than satellite. There tends to be all kind of catches and >> esoteric differences between 'native' port and satellite port, and >> those are not documented anywhere, probably not even known to vendor, >> and you just stumble on them as you go. As well as you have to carry >> the increased bug surface of the vendor's proprietary host<->satellite >> code. >> >> Granted at least JNPR offering allows you to run same device as pure >> L2, with Cisco offering it is satellite-only box, cannot be used as >> L2. > > I know what you mean, but I must say that this time it seems like they have > more or less managed to do it right. They use pretty standard protocols for > everything, it is just "packaged" so you don't need to think about it. > > But as you say, you can easily use the exact same hardware in a regular L2 > setup, the thing you gain from the satellite setup is central management of > only the routers, which can be a time and management saver. > > /Ola (T) > ___ > 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] Going Juniper
On 11. april 2018 12:51, Saku Ytti wrote: On 11 April 2018 at 13:43, Ola Thoresen wrote: We have recently started playing with MX204 and Junos Fusion, and that makes a really nice setup. With either EX4300 (for 1G) or QFX5100 (for 10G), you get a lot of ports and a great routing engine for a "decent" cost. I have strong dislike to satellite solutions. I'd rather even run L2 backhaul than satellite. There tends to be all kind of catches and esoteric differences between 'native' port and satellite port, and those are not documented anywhere, probably not even known to vendor, and you just stumble on them as you go. As well as you have to carry the increased bug surface of the vendor's proprietary host<->satellite code. Granted at least JNPR offering allows you to run same device as pure L2, with Cisco offering it is satellite-only box, cannot be used as L2. I know what you mean, but I must say that this time it seems like they have more or less managed to do it right. They use pretty standard protocols for everything, it is just "packaged" so you don't need to think about it. But as you say, you can easily use the exact same hardware in a regular L2 setup, the thing you gain from the satellite setup is central management of only the routers, which can be a time and management saver. /Ola (T) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
On 11 April 2018 at 13:43, Ola Thoresen wrote: > We have recently started playing with MX204 and Junos Fusion, and that makes > a really nice setup. > With either EX4300 (for 1G) or QFX5100 (for 10G), you get a lot of ports and > a great routing engine for a "decent" cost. I have strong dislike to satellite solutions. I'd rather even run L2 backhaul than satellite. There tends to be all kind of catches and esoteric differences between 'native' port and satellite port, and those are not documented anywhere, probably not even known to vendor, and you just stumble on them as you go. As well as you have to carry the increased bug surface of the vendor's proprietary host<->satellite code. Granted at least JNPR offering allows you to run same device as pure L2, with Cisco offering it is satellite-only box, cannot be used as L2. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
On 11/04/18 19:31, Saku Ytti wrote: > I suspect more correct reason is that they don't see sufficient market > potential in device like MX104. I think Cisco and Juniper are very > confused about market, they appear to think entire market consists > solely of large scale DC providers. That only addressable market is > market which wants extremely dense 100GE boxes. 1GE is dead, 10GE is > almost dead. Even in networks like that there's uses for 1g that won't go away (heck, some amazingly recent infrastructure kit is still 10m only). A box able to have a few 1g ports, even sacrificing some 10g ports is fine, but with a 100g uplink or two would be super handy. Not least of which, having somewhere to plug my laptop in if I need to visit a POP. The datasheet for the MX204[1] implies that all the ports can be switched to 1g mode, but I think only some can[2]. That's an improvement over when I first heard about the box (when the JNPR folk I was talking to didn't understand why I might want some 100g and 1g ports on the same box) which is great. 1: https://www.juniper.net/assets/us/en/local/pdf/datasheets/1000597-en.pdf specifically the table on page 3. 2: https://www.juniper.net/documentation/en_US/junos/topics/concept/port-speed-capability-mx204router.html ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
On 11. april 2018 11:31, Saku Ytti wrote: On 11 April 2018 at 04:31, Chris via juniper-nsp wrote: Since the MX104 has user replacable RE's I really wish Juniper would at least offer a different option with a more beefy CPU/RAM but I don't think that would ever happen... I think JNPR believes MX204 is the 'next gen MX104'. I bet if there was MX204 with 2xQSFP28 + 24-48xSFP+, sold attractively priced with BW license, so that SFP+ as 1GE and sub would make sense, those would sell really well. We have recently started playing with MX204 and Junos Fusion, and that makes a really nice setup. With either EX4300 (for 1G) or QFX5100 (for 10G), you get a lot of ports and a great routing engine for a "decent" cost. /Ola (T) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
On 11 April 2018 at 10:31, Saku Ytti wrote: > New RE for MX104 was on the table early on in the MX104 history, but > then JNPR changed tracks, citing XEON not being thermally possible on > it. I had heard (more or less from the horses mouth) that the MX104's were initially developed for an Indian telco - they basically wanted MX80s but with a higher temperature rating and dual REs, allowing them to be used in mobile base station sites. These would be hard to reach so they needed reliability (dual REs) and sometimes "external" (as in not in an air-cooled DC but maybe a roof-top cabinet etc.). Upgraded REs would have been great. I have seen some that run with low CPU "normally" but when they are being polled by SNMP they spike to 100%. > At least Nokia and Huawei seem to think there are other addressable > markets still, markets which still want to use 1GE and 10GE, with > various pluggable optics. We're now working to introduce Huawei into the mix. I would agree with you that low port coun't, good, and reasonably priced mixed 1G/10G devices aren't plentiful in choice from vendors. We open a lot of small PoPs so stuff like ME3600X/ASR920s, ASR9001, MX104 are great for us but each with their own caveats. Cheers, James. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
On 11 April 2018 at 04:31, Chris via juniper-nsp wrote: > Since the MX104 has user replacable RE's I really wish Juniper would at > least offer a different option with a more beefy CPU/RAM but I don't think > that would ever happen... I think JNPR believes MX204 is the 'next gen MX104'. I bet if there was MX204 with 2xQSFP28 + 24-48xSFP+, sold attractively priced with BW license, so that SFP+ as 1GE and sub would make sense, those would sell really well. New RE for MX104 was on the table early on in the MX104 history, but then JNPR changed tracks, citing XEON not being thermally possible on it. I suspect more correct reason is that they don't see sufficient market potential in device like MX104. I think Cisco and Juniper are very confused about market, they appear to think entire market consists solely of large scale DC providers. That only addressable market is market which wants extremely dense 100GE boxes. 1GE is dead, 10GE is almost dead. At least Nokia and Huawei seem to think there are other addressable markets still, markets which still want to use 1GE and 10GE, with various pluggable optics. -- ++ytti ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
Hi, On 10/04/2018 11:37 PM, mike+j...@willitsonline.com wrote: I know it can be set up and run like a champ and do some (undefined) number of gigabits without issue. What concerns me is that there are performance limitations in these software only platforms based on your processor/bus/card choices, and of course the performance of a software hash vs a hardware cam for forwarding table lookups. And usually (imho), you hit the platform limits like a truck running into a brick wall. However, if I knew I was only going to have just a few gbps (3?), I likely would be very interested doing a live deployment. However, with that said, it certainly is interesting enough to investigate and I'd love to see your writeup. At a minimum it sounds very useful and I may use vMX for pre-deployment testing purposes. The write up has been linked in one of the previous posts, so feel free to take a look at it there (I published it on my website as I suspect it will come in handy for other people trying to set this up). As for the actual performance limitations of the vMX, I have not managed to hit them at all and I suspect I won't ever for the size of the networks that they are deployed in. When I was testing I got up to 40G of throughput through it which was much more than enough (using various packet sizes to simuluate real traffic), I didn't get to test any further though. The CPU difference between pushing 500M/60k PPS and 9G/7m PPS was non existant - the graphs I have for my FPC on the vMX's is steady regardless of the traffic going through. On your mx104 you said cpu was pegged at %100 - operationally does this cause you any grief? How long does it take for your routes to recover after a peer flaps? (eg: your sending traffic to a dead peer before forwarding is updated to remove those). If you are logged in doing normal network stuff like looking up routes or making minor config updates, is the cli slogwash or can you move around and work? There are a few problems: * I use Ansible to deploy the configurations for network devices. The commit times are now quite bad (it can take almost 1.5 minutes) I had to adjust the timeout otherwise it would constantly fail. * For the actual traffic going through the devices I don't have any issues * Using the CLI to view routes, if you have a full table, can be a painful process. * Traffic going to dead peers is a problem, I have given up taking full tables on all of my MX80/MX104 devices. Sometimes this could mean an outage of over 30 minutes if BGP is flapping as well in my case. * Since I use Ansible to deploy the configs, I don't touch the CLI a lot directly. When I do, its responsive enough when making changes/viewing the config, the slow part is the commit process as well as viewing routes. Since the MX104 has user replacable RE's I really wish Juniper would at least offer a different option with a more beefy CPU/RAM but I don't think that would ever happen... ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
Hi, While PPC is clearly slower than x86 stuff, the problem is that JunOS should have never been compiled for this architecture. I suppose/hope that the product manager who took such decision is now in a madhouse. As Saku Ytti wrote in NANOG ML in 2014 (when comparing Cisco 6500/7600 and MX80/104): « if we compare MX80 and RSP720, where RSP720 has slightly lower performance CPU, RSP720 out-performs MX80 (and MX104) in BGP convergence and BGP scale. » > On 11 apr. 2018 at 00:04, Chuck Anderson wrote : > > MX104 and MX80 are PPC chips, not Intel. That is a big reason why > they are slow. I have problems like VRRP flapping due to CPU > starvation. This is in a lab, so it doesn't matter too much, but I > wouldn't want to put them into a production network. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
On Tue, Apr 10, 2018 at 08:37:41AM -0700, mike+j...@willitsonline.com wrote: > On 04/09/2018 08:07 PM, Chris via juniper-nsp wrote: > > For the MX104 (and the MX80) the main limitation they have is that the > > CPU on the routing engine is terribly slow. This can be a problem for > > you if you are taking multiple full tables with BGP. Even without > > taking full tables, the RE CPU on the MX104's I have is basically > > always at 100%. Commits are pretty slow as well. This shouldn't be > > such an issue with the MX240 as it has a wider range of routing > > engines available with much better specs. > > I know it can be set up and run like a champ and do some (undefined) > number of gigabits without issue. What concerns me is that there are > performance limitations in these software only platforms based on your > processor/bus/card choices, and of course the performance of a software > hash vs a hardware cam for forwarding table lookups. And usually > (imho), you hit the platform limits like a truck running into a brick > wall. However, if I knew I was only going to have just a few gbps (3?), > I likely would be very interested doing a live deployment. However, with > that said, it certainly is interesting enough to investigate and I'd > love to see your writeup. At a minimum it sounds very useful and I may > use vMX for pre-deployment testing purposes. > > On your mx104 you said cpu was pegged at %100 - operationally does this > cause you any grief? How long does it take for your routes to recover > after a peer flaps? (eg: your sending traffic to a dead peer before > forwarding is updated to remove those). If you are logged in doing > normal network stuff like looking up routes or making minor config > updates, is the cli slogwash or can you move around and work? MX104 and MX80 are PPC chips, not Intel. That is a big reason why they are slow. I have problems like VRRP flapping due to CPU starvation. This is in a lab, so it doesn't matter too much, but I wouldn't want to put them into a production network. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
FSVO tens Gbps and easily. I think INTC is quoting DPDK for hundreds of Gbps for latest XEONs. But everything depends on what you're actually doing, as it's run-to-completion it has highly variant pps performance depending on what is being done. Do you have filters? How large FIB? uRPF? 10Gbps is 15Mpps on smallest size frames. Also XEON isn't actually in any meaningful way cheap lookup chip, cost per Gbps is very large compared to BRCM stuff. But I can understand in some environments the compute is sunk cost, so it doesn't really matter and the the pps requirement is very modest. So there are use cases, but probably not as much as people intuitively think. On 10 April 2018 at 19:06, Josh Reynolds wrote: > There are x86 based routing platforms doing many tens of Gbps easily in > software. Things like vpp.io, DPDK, and others are driving things like FRR, > Cumulus, and now TNSR drastically forward. > > On Tue, Apr 10, 2018, 10:40 AM wrote: > >> On 04/09/2018 08:07 PM, Chris via juniper-nsp wrote: >> > Hi, >> > >> > On 10/04/2018 9:45 AM, mike+j...@willitsonline.com wrote: >> >> I see there is a terrific amount of used mx104 and mx240 out there >> >> and the specs all seem great. What I'm looking to do is have 2x 10g >> >> feeds, route bgp, do flow exporting, and do a certain amount of ingress >> >> filtering to protect the network from ddos.Id even like to do cgnat for >> >> up to 5000 users but not sure if a single box setup would be wise. >> > >> > I can't speak for the MX240, but we have some deployments of the >> > MX104, MX80 and the vMX. >> > >> > For the MX104 (and the MX80) the main limitation they have is that the >> > CPU on the routing engine is terribly slow. This can be a problem for >> > you if you are taking multiple full tables with BGP. Even without >> > taking full tables, the RE CPU on the MX104's I have is basically >> > always at 100%. Commits are pretty slow as well. This shouldn't be >> > such an issue with the MX240 as it has a wider range of routing >> > engines available with much better specs. >> > >> > The MX104's (and MX80's) have the MS-MIC-16G installed. We use the >> > MS-MIC-16G for IPSEC, NAT and stateful firewalling (service filters >> > are used to only send certain traffic to the stateful firewall). So >> > far there has only been 1 issue that I have personally encountered >> > with the MS-MIC-16 - the card has crashed on a previous release of >> > JunOS when adding a large number of IPSEC peers. Since upgraded I have >> > not experienced the same issue though. >> > >> > I also have some vMX's deployed (they are running on top of Dell >> > R740's with 3 x Intel X710 cards to give 12 x 10G interfaces). The >> > painful part on getting the vMX to work was the host setup with KVM - >> > the documents are severly lacking on Junipers side (but I have written >> > up the exact instructions to get the most recent 18.1R1 release >> > working on CentOS with no issues). >> > >> > So far after getting the issues with the KVM host ironed out I have >> > been very happy with the performance of the vMX. Since 17.4R1 you can >> > deploy a virtual MS-MPC (which requires extra CPU resources) which >> > will give you NAT support as well as stateful firewalling support. >> > Since its virtualised and the RE runs as a seperate VM you can assign >> > more or less resources to it as needed - I have 16G of RAM allocated >> > with 6 cores and the time to process/install a full table is only a >> > few seconds. They have survived some DDoS attacks that were large >> > enough to fill up the transit links with no issues as well. The >> > biggest thing is to make sure you get NIC's that support SR-IOV and >> > make sure the CPU is fast enough/has enough cores for your >> > requirements (you cannot over-allocate the cores!). For my use case, I >> > don't think I will be buying any more physical MX's unless I have an >> > actual reason to need their hardware, the vMX suites my needs just >> > fine. Juniper does provide a (limited) demo of the vMX, happy to send >> > you the install guide I wrote up for getting it working on KVM with >> > CentOS 7.4 (Ubuntu is also supported for KVM but the install process >> > is basically terrible). >> >> I have a lot of experience and confidence running embedded linux as a >> router doing bgp/ospf and so forth. Also running pfsense in virtual >> machines for various features. Never knew juniper had a software only >> option, that is pretty interesting to me. >> >> I know it can be set up and run like a champ and do some (undefined) >> number of gigabits without issue. What concerns me is that there are >> performance limitations in these software only platforms based on your >> processor/bus/card choices, and of course the performance of a software >> hash vs a hardware cam for forwarding table lookups. And usually >> (imho), you hit the platform limits like a truck running into a brick >> wall. However, if I knew I was only going to have just a few
Re: [j-nsp] Going Juniper
There are x86 based routing platforms doing many tens of Gbps easily in software. Things like vpp.io, DPDK, and others are driving things like FRR, Cumulus, and now TNSR drastically forward. On Tue, Apr 10, 2018, 10:40 AM wrote: > On 04/09/2018 08:07 PM, Chris via juniper-nsp wrote: > > Hi, > > > > On 10/04/2018 9:45 AM, mike+j...@willitsonline.com wrote: > >> I see there is a terrific amount of used mx104 and mx240 out there > >> and the specs all seem great. What I'm looking to do is have 2x 10g > >> feeds, route bgp, do flow exporting, and do a certain amount of ingress > >> filtering to protect the network from ddos.Id even like to do cgnat for > >> up to 5000 users but not sure if a single box setup would be wise. > > > > I can't speak for the MX240, but we have some deployments of the > > MX104, MX80 and the vMX. > > > > For the MX104 (and the MX80) the main limitation they have is that the > > CPU on the routing engine is terribly slow. This can be a problem for > > you if you are taking multiple full tables with BGP. Even without > > taking full tables, the RE CPU on the MX104's I have is basically > > always at 100%. Commits are pretty slow as well. This shouldn't be > > such an issue with the MX240 as it has a wider range of routing > > engines available with much better specs. > > > > The MX104's (and MX80's) have the MS-MIC-16G installed. We use the > > MS-MIC-16G for IPSEC, NAT and stateful firewalling (service filters > > are used to only send certain traffic to the stateful firewall). So > > far there has only been 1 issue that I have personally encountered > > with the MS-MIC-16 - the card has crashed on a previous release of > > JunOS when adding a large number of IPSEC peers. Since upgraded I have > > not experienced the same issue though. > > > > I also have some vMX's deployed (they are running on top of Dell > > R740's with 3 x Intel X710 cards to give 12 x 10G interfaces). The > > painful part on getting the vMX to work was the host setup with KVM - > > the documents are severly lacking on Junipers side (but I have written > > up the exact instructions to get the most recent 18.1R1 release > > working on CentOS with no issues). > > > > So far after getting the issues with the KVM host ironed out I have > > been very happy with the performance of the vMX. Since 17.4R1 you can > > deploy a virtual MS-MPC (which requires extra CPU resources) which > > will give you NAT support as well as stateful firewalling support. > > Since its virtualised and the RE runs as a seperate VM you can assign > > more or less resources to it as needed - I have 16G of RAM allocated > > with 6 cores and the time to process/install a full table is only a > > few seconds. They have survived some DDoS attacks that were large > > enough to fill up the transit links with no issues as well. The > > biggest thing is to make sure you get NIC's that support SR-IOV and > > make sure the CPU is fast enough/has enough cores for your > > requirements (you cannot over-allocate the cores!). For my use case, I > > don't think I will be buying any more physical MX's unless I have an > > actual reason to need their hardware, the vMX suites my needs just > > fine. Juniper does provide a (limited) demo of the vMX, happy to send > > you the install guide I wrote up for getting it working on KVM with > > CentOS 7.4 (Ubuntu is also supported for KVM but the install process > > is basically terrible). > > I have a lot of experience and confidence running embedded linux as a > router doing bgp/ospf and so forth. Also running pfsense in virtual > machines for various features. Never knew juniper had a software only > option, that is pretty interesting to me. > > I know it can be set up and run like a champ and do some (undefined) > number of gigabits without issue. What concerns me is that there are > performance limitations in these software only platforms based on your > processor/bus/card choices, and of course the performance of a software > hash vs a hardware cam for forwarding table lookups. And usually > (imho), you hit the platform limits like a truck running into a brick > wall. However, if I knew I was only going to have just a few gbps (3?), > I likely would be very interested doing a live deployment. However, with > that said, it certainly is interesting enough to investigate and I'd > love to see your writeup. At a minimum it sounds very useful and I may > use vMX for pre-deployment testing purposes. > > On your mx104 you said cpu was pegged at %100 - operationally does this > cause you any grief? How long does it take for your routes to recover > after a peer flaps? (eg: your sending traffic to a dead peer before > forwarding is updated to remove those). If you are logged in doing > normal network stuff like looking up routes or making minor config > updates, is the cli slogwash or can you move around and work? > > Thank you so much for the feedback! > > Mike- > > ___
Re: [j-nsp] Going Juniper
On 04/09/2018 08:07 PM, Chris via juniper-nsp wrote: > Hi, > > On 10/04/2018 9:45 AM, mike+j...@willitsonline.com wrote: >> I see there is a terrific amount of used mx104 and mx240 out there >> and the specs all seem great. What I'm looking to do is have 2x 10g >> feeds, route bgp, do flow exporting, and do a certain amount of ingress >> filtering to protect the network from ddos.Id even like to do cgnat for >> up to 5000 users but not sure if a single box setup would be wise. > > I can't speak for the MX240, but we have some deployments of the > MX104, MX80 and the vMX. > > For the MX104 (and the MX80) the main limitation they have is that the > CPU on the routing engine is terribly slow. This can be a problem for > you if you are taking multiple full tables with BGP. Even without > taking full tables, the RE CPU on the MX104's I have is basically > always at 100%. Commits are pretty slow as well. This shouldn't be > such an issue with the MX240 as it has a wider range of routing > engines available with much better specs. > > The MX104's (and MX80's) have the MS-MIC-16G installed. We use the > MS-MIC-16G for IPSEC, NAT and stateful firewalling (service filters > are used to only send certain traffic to the stateful firewall). So > far there has only been 1 issue that I have personally encountered > with the MS-MIC-16 - the card has crashed on a previous release of > JunOS when adding a large number of IPSEC peers. Since upgraded I have > not experienced the same issue though. > > I also have some vMX's deployed (they are running on top of Dell > R740's with 3 x Intel X710 cards to give 12 x 10G interfaces). The > painful part on getting the vMX to work was the host setup with KVM - > the documents are severly lacking on Junipers side (but I have written > up the exact instructions to get the most recent 18.1R1 release > working on CentOS with no issues). > > So far after getting the issues with the KVM host ironed out I have > been very happy with the performance of the vMX. Since 17.4R1 you can > deploy a virtual MS-MPC (which requires extra CPU resources) which > will give you NAT support as well as stateful firewalling support. > Since its virtualised and the RE runs as a seperate VM you can assign > more or less resources to it as needed - I have 16G of RAM allocated > with 6 cores and the time to process/install a full table is only a > few seconds. They have survived some DDoS attacks that were large > enough to fill up the transit links with no issues as well. The > biggest thing is to make sure you get NIC's that support SR-IOV and > make sure the CPU is fast enough/has enough cores for your > requirements (you cannot over-allocate the cores!). For my use case, I > don't think I will be buying any more physical MX's unless I have an > actual reason to need their hardware, the vMX suites my needs just > fine. Juniper does provide a (limited) demo of the vMX, happy to send > you the install guide I wrote up for getting it working on KVM with > CentOS 7.4 (Ubuntu is also supported for KVM but the install process > is basically terrible). I have a lot of experience and confidence running embedded linux as a router doing bgp/ospf and so forth. Also running pfsense in virtual machines for various features. Never knew juniper had a software only option, that is pretty interesting to me. I know it can be set up and run like a champ and do some (undefined) number of gigabits without issue. What concerns me is that there are performance limitations in these software only platforms based on your processor/bus/card choices, and of course the performance of a software hash vs a hardware cam for forwarding table lookups. And usually (imho), you hit the platform limits like a truck running into a brick wall. However, if I knew I was only going to have just a few gbps (3?), I likely would be very interested doing a live deployment. However, with that said, it certainly is interesting enough to investigate and I'd love to see your writeup. At a minimum it sounds very useful and I may use vMX for pre-deployment testing purposes. On your mx104 you said cpu was pegged at %100 - operationally does this cause you any grief? How long does it take for your routes to recover after a peer flaps? (eg: your sending traffic to a dead peer before forwarding is updated to remove those). If you are logged in doing normal network stuff like looking up routes or making minor config updates, is the cli slogwash or can you move around and work? Thank you so much for the feedback! Mike- ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
Mike, For 20K you can get a new MX204 (not to be confused with MX240). However, I don't think the MX204 support CGNAT if needed, but I could be wrong. But I wouldn't touch a MX80 or MX104 if buying new. On Mon, Apr 9, 2018 at 8:45 PM, wrote: > Greetings, > > I am looking for some advice concerning juniper as an edge router. > > I see there is a terrific amount of used mx104 and mx240 out there > and the specs all seem great. What I'm looking to do is have 2x 10g > feeds, route bgp, do flow exporting, and do a certain amount of ingress > filtering to protect the network from ddos.Id even like to do cgnat for > up to 5000 users but not sure if a single box setup would be wise. > > I just don't have a handle on the various juniper platforms and > route engine options. Love to keep this under $20,000 and get a load of > 10g interfaces. Anyone here can tell me what I should be looking for? > > Mike- > ___ > 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] Going Juniper
Hi, On 10/04/2018 11:07 AM, Chris via juniper-nsp wrote: I also have some vMX's deployed (they are running on top of Dell R740's with 3 x Intel X710 cards to give 12 x 10G interfaces). The painful part on getting the vMX to work was the host setup with KVM - the documents are severly lacking on Junipers side (but I have written up the exact instructions to get the most recent 18.1R1 release working on CentOS with no issues). I have received more than a couple of requests for the guide, if anyone else interested here is the steps I used for Ubuntu and CentOS as the host OS with KVM: https://gbe0.com/networking/juniper/vmx/centos-7-4-kvm-host-setup-for-juniper-vmx https://gbe0.com/networking/juniper/vmx/ubuntu-14-04-kvm-host-setup-for-juniper-vmx My guides are assuming that you are deploying a server with SR-IOV using the Intel x710 family of NIC's. The CentOS 7.4 guide was written a few days ago as I went through the install process from scratch for 18.1 to finally move all of the hosts I have the vMX deployed on away from Ubuntu to CentOS (personally I prefer Ubuntu but the old versions of things that are required don't give me confidence and I have had the odd kernel panic with Ubuntu running the vMX). I also have the startup scripts (systemd for CentOS and init for Ubuntu) included for the vMX so it will start on boot; surprisingly Juniper doesn't give any instructions. I didn't have time to mess with selinux on CentOS to get the systemd startup script to work so I disabled it (the host is dedicated to the vMX anyyway); if you do figure out a way to get it working I would love to know. Happy to help as well if you run into any issues deploying it. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
I have found the licensing costs on the MX104 to be pretty ridiculous. I can buy a brand new MX204 with plenty of 10Gbps interfaces for cheaper than it would be up upgrade the "base" MX104 (MX104-MX5 bundle) to enable the four of the built-in 10Gbps interfaces and additional chassis throughput. On Mon, Apr 9, 2018 at 9:59 PM, Michael Gehrmann wrote: > Hi Mike, > > An MX104 can certainly give you all those features. Be aware CGNAT needs an > MS-MIC and flow exports require a license. > > You might be able to get the base bundle under $20k but add the extras and > it will be over. > > Mike G > > On 10 April 2018 at 11:45, wrote: > > > Greetings, > > > > I am looking for some advice concerning juniper as an edge router. > > > > I see there is a terrific amount of used mx104 and mx240 out there > > and the specs all seem great. What I'm looking to do is have 2x 10g > > feeds, route bgp, do flow exporting, and do a certain amount of ingress > > filtering to protect the network from ddos.Id even like to do cgnat for > > up to 5000 users but not sure if a single box setup would be wise. > > > > I just don't have a handle on the various juniper platforms and > > route engine options. Love to keep this under $20,000 and get a load of > > 10g interfaces. Anyone here can tell me what I should be looking for? > > > > Mike- > > ___ > > juniper-nsp mailing list juniper-nsp@puck.nether.net > > https://urldefense.proofpoint.com/v2/url?u=https-3A__puck. > > nether.net_mailman_listinfo_juniper-2Dnsp&d=DwIF-g&c= > > wBUwXtM9sKhff6UeHOQgvw&r=iCARHrCSMVMu5fNENyuQGdvoQJpwI5 > > WIbiqe9jFEMFg&m=76Iq_HMUC-_qhnTMQNwsQYtv6_zHpaYrz1JHcq4e2TA&s=ih82hjO_ > > dKJ9XiujFPwdnu-60Io7nQumaSO99O3jkcc&e= > > > ___ > 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] Going Juniper
On Tue, Apr 10, 2018 at 11:07:06AM +0800, Chris via juniper-nsp wrote: > to need their hardware, the vMX suites my needs just fine. Juniper does > provide a (limited) demo of the vMX, happy to send you the install guide I > wrote up for getting it working on KVM with CentOS 7.4 (Ubuntu is also > supported for KVM but the install process is basically terrible). I suspect others would find it useful if you posted your guide. - Jared -- Jared Mauch | pgp key available via finger from ja...@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
I'm literally up working right now in a maintenance window throwing one of my cable modem cmts communities behind my pair of mx104's... I'm excited to finally start natting my cable modems... Previously I have natted all 6,000 of my dsl customers behind this same pair of mx104's. I do cgnat via mpls l3vpn's. it's quite nice as I inject a default route (2 of them) from each mx104, into the cgnat vrf domain, and all my PE's begin flowing all outbound traffic via the nat boxes. I understand the MS-MIC-16G cgnat module inside my mx104's can do about 7 million translations and about 7.5 gbps of cgnat throughput. X2 for both mx104's in my cgnat arechitecture. (so 15 gbps of nat44 total) I recall paying about $25k for each MX104 with single RE and one MS-MIC-16G module, and I think a license that allows for 20 gbps (two 10 gig) ports to be used. I simply agg-ether those 2 interfaces and plump them into the P core and do nat-on-a-stick via 20 gbps of link capacity. -Aaron p.s. ftth cgnat will be done via my new mx960's w/MS-MPC-128G's -Original Message- From: juniper-nsp [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of mike+j...@willitsonline.com Sent: Monday, April 9, 2018 8:45 PM To: juniper-nsp@puck.nether.net Subject: [j-nsp] Going Juniper Greetings, I am looking for some advice concerning juniper as an edge router. I see there is a terrific amount of used mx104 and mx240 out there and the specs all seem great. What I'm looking to do is have 2x 10g feeds, route bgp, do flow exporting, and do a certain amount of ingress filtering to protect the network from ddos.Id even like to do cgnat for up to 5000 users but not sure if a single box setup would be wise. I just don't have a handle on the various juniper platforms and route engine options. Love to keep this under $20,000 and get a load of 10g interfaces. Anyone here can tell me what I should be looking for? Mike- ___ 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] Going Juniper
Hi, On 10/04/2018 9:45 AM, mike+j...@willitsonline.com wrote: I see there is a terrific amount of used mx104 and mx240 out there and the specs all seem great. What I'm looking to do is have 2x 10g feeds, route bgp, do flow exporting, and do a certain amount of ingress filtering to protect the network from ddos.Id even like to do cgnat for up to 5000 users but not sure if a single box setup would be wise. I can't speak for the MX240, but we have some deployments of the MX104, MX80 and the vMX. For the MX104 (and the MX80) the main limitation they have is that the CPU on the routing engine is terribly slow. This can be a problem for you if you are taking multiple full tables with BGP. Even without taking full tables, the RE CPU on the MX104's I have is basically always at 100%. Commits are pretty slow as well. This shouldn't be such an issue with the MX240 as it has a wider range of routing engines available with much better specs. The MX104's (and MX80's) have the MS-MIC-16G installed. We use the MS-MIC-16G for IPSEC, NAT and stateful firewalling (service filters are used to only send certain traffic to the stateful firewall). So far there has only been 1 issue that I have personally encountered with the MS-MIC-16 - the card has crashed on a previous release of JunOS when adding a large number of IPSEC peers. Since upgraded I have not experienced the same issue though. I also have some vMX's deployed (they are running on top of Dell R740's with 3 x Intel X710 cards to give 12 x 10G interfaces). The painful part on getting the vMX to work was the host setup with KVM - the documents are severly lacking on Junipers side (but I have written up the exact instructions to get the most recent 18.1R1 release working on CentOS with no issues). So far after getting the issues with the KVM host ironed out I have been very happy with the performance of the vMX. Since 17.4R1 you can deploy a virtual MS-MPC (which requires extra CPU resources) which will give you NAT support as well as stateful firewalling support. Since its virtualised and the RE runs as a seperate VM you can assign more or less resources to it as needed - I have 16G of RAM allocated with 6 cores and the time to process/install a full table is only a few seconds. They have survived some DDoS attacks that were large enough to fill up the transit links with no issues as well. The biggest thing is to make sure you get NIC's that support SR-IOV and make sure the CPU is fast enough/has enough cores for your requirements (you cannot over-allocate the cores!). For my use case, I don't think I will be buying any more physical MX's unless I have an actual reason to need their hardware, the vMX suites my needs just fine. Juniper does provide a (limited) demo of the vMX, happy to send you the install guide I wrote up for getting it working on KVM with CentOS 7.4 (Ubuntu is also supported for KVM but the install process is basically terrible). ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] Going Juniper
Hi Mike, An MX104 can certainly give you all those features. Be aware CGNAT needs an MS-MIC and flow exports require a license. You might be able to get the base bundle under $20k but add the extras and it will be over. Mike G On 10 April 2018 at 11:45, wrote: > Greetings, > > I am looking for some advice concerning juniper as an edge router. > > I see there is a terrific amount of used mx104 and mx240 out there > and the specs all seem great. What I'm looking to do is have 2x 10g > feeds, route bgp, do flow exporting, and do a certain amount of ingress > filtering to protect the network from ddos.Id even like to do cgnat for > up to 5000 users but not sure if a single box setup would be wise. > > I just don't have a handle on the various juniper platforms and > route engine options. Love to keep this under $20,000 and get a load of > 10g interfaces. Anyone here can tell me what I should be looking for? > > Mike- > ___ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://urldefense.proofpoint.com/v2/url?u=https-3A__puck. > nether.net_mailman_listinfo_juniper-2Dnsp&d=DwIF-g&c= > wBUwXtM9sKhff6UeHOQgvw&r=iCARHrCSMVMu5fNENyuQGdvoQJpwI5 > WIbiqe9jFEMFg&m=76Iq_HMUC-_qhnTMQNwsQYtv6_zHpaYrz1JHcq4e2TA&s=ih82hjO_ > dKJ9XiujFPwdnu-60Io7nQumaSO99O3jkcc&e= > ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
