Re: [j-nsp] MX80 Opinions
that is right 64 bit Junos only supports more than 3 Gb RAM SMP support had to come from moving to newer free bsd version. Regards Abhijeet.C - Original Message - From: Richard A Steenbergen r...@e-gerbil.net To: Doug Hanks dha...@juniper.net Cc: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net Sent: Friday, June 3, 2011 7:44 AM Subject: Re: [j-nsp] MX80 Opinions On Thu, Jun 02, 2011 at 07:11:31PM -0700, Doug Hanks wrote: The new MX REs run 64-bit Junos. 64-bit JUNOS != SMP enabled. The only difference is the amount of ram it can address, those fancy quad-core CPUs only run on a single core. :) -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ 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] MX80 Opinions
And then there was vyatta... Sent from my iPhone On Jun 2, 2011, at 10:10 PM, Richard A Steenbergen r...@e-gerbil.net wrote: On Thu, Jun 02, 2011 at 09:59:15PM -0400, jnprb...@gmail.com wrote: Although expensive, you can buy the JCS1200 with 64-bit Junos to run as a standalone RR. It's probably more economical if you could also benefit from VPNv4 RRs for MPLS VPN deployments. Price aside, anyone who wants a 12U RE needs to have their head examined. :) How freaking hard can it be to take an off-the-shelf 1U PC, slap a Juniper logo on the front, mark it up 20x like everything else, and sell it to us as a fully supported RR? I'm still confused how this has managed to escape their attention. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ 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] MX80 Opinions
10.4R4 seems usable on MX960 with mixed DPC/MPC. There is a packet discard bug on MX80 though - it randomly mistakes non-first fragments as L2TP packets and as no L2TP service is configured, discards those packets. Would you happen to have the PR for this? ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 Opinions
On Sat, Jun 04, 2011 at 01:57:43PM -0400, Keegan Holley wrote: 10.4R4 seems usable on MX960 with mixed DPC/MPC. There is a packet discard bug on MX80 though - it randomly mistakes non-first fragments as L2TP packets and as no L2TP service is configured, discards those packets. Would you happen to have the PR for this? PR/611029, fix targetted for 10.4R6, 11.1R3, 11.2R1, 11.3R1 Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 Opinions
I've had 10.4r4 in my lab MX960 for a couple of weeks now with no real issues, but not much test traffic either. I'm planning to deploy it later this summer to prep for MS-DPC's that are on the way. I do have an odd case of a nat service breaking a filter based policer, but on for Nat'd traffic. However, I don't know if it's simply due to the implementation or the code yet. On Jun 4, 2011, at 3:33 PM, Daniel Roesen wrote: On Sat, Jun 04, 2011 at 01:57:43PM -0400, Keegan Holley wrote: 10.4R4 seems usable on MX960 with mixed DPC/MPC. There is a packet discard bug on MX80 though - it randomly mistakes non-first fragments as L2TP packets and as no L2TP service is configured, discards those packets. Would you happen to have the PR for this? PR/611029, fix targetted for 10.4R6, 11.1R3, 11.2R1, 11.3R1 Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 ___ 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] MX80 Opinions
On Friday, June 03, 2011 10:10:04 AM Richard A Steenbergen wrote: Price aside, anyone who wants a 12U RE needs to have their head examined. :) How freaking hard can it be to take an off-the-shelf 1U PC, slap a Juniper logo on the front, mark it up 20x like everything else, and sell it to us as a fully supported RR? I'm still confused how this has managed to escape their attention. I tend to agree - it simply doesn't make sense. We looked at them and ended up buying M120's for this simply because the cheaper options from Cisco didn't support the MCAST-MVPN AFI we needed. We considered a combination of M7i's + 7201's, but it does present its own set of soft, operational hassles. The M7i's alone wouldn't have been enough since it can only do 1.5GB of RAM (and less, effectively, if you include Junos's own requirements and other shared memory bits). However, now that there's a new RE coming out for the M7i/M10i, maybe it would be worth considering as a proper route reflector from Juniper in the future. On the Cisco side, the new ASR1001 would make a fine route reflector. 16GB of control plane memory is certainly enough to tickle anyone. But we can only consider it if Cisco add support for the extra AFI's that we need. FIB-wise, the ASR1001 is restricted to 512,000 IPv4 entries (which baffles my mind), but that shouldn't be an issue if it's a dedicated route reflector, although troubleshooting from the box could be difficult if you see the route in the BGP RIB, but the router can't get to it. Decisions, decisions. Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 Opinions
Hello, Would it be possible for you to share what code version you recommend for Trio? We've had a few MX80s in Prod with 10.2S6 for a while now. We need to add MPC cards to our MX960s and are struggling what version to go with. Continue with 10.2 or move to 10.4? We're also planning on adding alot more MX80s. Thanks, Serge - Original Message From: Richard A Steenbergen r...@e-gerbil.net To: Doug Hanks dha...@juniper.net Cc: juniper-nsp@puck.nether.net juniper-nsp@puck.nether.net Sent: Thu, June 2, 2011 9:10:19 PM Subject: Re: [j-nsp] MX80 Opinions On Thu, Jun 02, 2011 at 04:26:54PM -0700, Doug Hanks wrote: Daniel, I have nothing but good things to say about the MX80. I have almost nothing but good things to say, now that 90-95% of the cripling Trio-specific bugs have been worked out of the current code. The integrated RE is probably the biggest design limitation. For example, we just got bit by a bad flash drive on one, which caused the kernel to lock up when writing to the disk. This required a physical power cycle to bring the box back every time it happened, left no evidence in the logs (so we had to catch it actually happening on console to know what was going on), and required a complete RMA of the chassis to fix. The lack of redundant REs severely limits the potential of this otherwise excellent little box. Oh and don't forget, a single RE will make your upgrade process take a lot longer too. Juniper would really do well to introduce a 1U small/simple external RE which can be connected over Ethernet, to redundantize a box like the MX80, and to be a reasonably sized BGP route reflector. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ 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] MX80 Opinions
On Fri, Jun 03, 2011 at 08:31:51AM -0700, Serge Vautour wrote: Hello, Would it be possible for you to share what code version you recommend for Trio? We've had a few MX80s in Prod with 10.2S6 for a while now. We need to add MPC cards to our MX960s and are struggling what version to go with. Continue with 10.2 or move to 10.4? We're also planning on adding alot more MX80s. As of right now we're doing 10.4R4 on new deployments/upgrades of MX80 and MPC, and it's working reasonably well. It's not perfect of course, we have a few fixes already in the queue for 10.4R5 and just found a new rpd coredump the other day, but it's a hell of a lot better than any previous 10.4 builds, and now seems to be the right time to pick up the EEoL release. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 Opinions
On Friday, June 03, 2011 11:31:51 PM Serge Vautour wrote: Would it be possible for you to share what code version you recommend for Trio? We've had a few MX80s in Prod with 10.2S6 for a while now. We need to add MPC cards to our MX960s and are struggling what version to go with. Continue with 10.2 or move to 10.4? We're also planning on adding alot more MX80s. For the chassis-based MX's, we've generally found happiness in staying current for Junos 10.4 (now at 10.4R4.5). This has fixed random PFE crashes, FPC reboots, e.t.c., since the boxes shipped with 10.4R1. We're actively staying away from Junos 11 for now. One thing to think seriously about is whether you're going to run your MX's with a mixture of DPC's and MPC's. Depending on which features you need to turn on, you may not be able to boot DPC cards if you have MPC's installed as well. I'd seriously suggest checking with your SE before turning up any features if you're going to mix DPC's and MPC's, or if certain features for the MPC's seem kinky. We've had too much pain for some items. Cheers, Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 Opinions
On Sat, Jun 04, 2011 at 12:04:09AM +0800, Mark Tinka wrote: One thing to think seriously about is whether you're going to run your MX's with a mixture of DPC's and MPC's. Depending on which features you need to turn on, you may not be able to boot DPC cards if you have MPC's installed as well. I'd seriously suggest checking with your SE before turning up any features if you're going to mix DPC's and MPC's, or if certain features for the MPC's seem kinky. We've had too much pain for some items. Agreed 100%, plus getting line-rate out of a mixed DPC/MPC environment is a real bitch for a number of reasons, so you'll be MUCH better off if you convert a whole chassis at a time. Though I will say that 10.4R4 didn't give us ANY grief when doing mixed DPC/MPC during the actual conversion maintenance, which is a first for the dozen or so places where we've done this already. :) -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 Opinions
Hello, Interesting comments. We've just finished a full suite of tests on an MX960 Lab box running combo DPC (4x10G 40x1G) and MPC (20x1G and 2x10G MIC) on 10.4R4. We uncovered a few bugs during the testing. Most notable: -DPC R-Q ports report passed + dropped traffic under show int when using a TCP with a shaper. show int queue has the correct data. Known bug. -We use a common templates VPLS BUM policer. Normally when it's applied to sub-interfaces on a port, each sub-interface (VLAN) gets it's own instance and polices traffic independently. Under MPC cards, all VLANs share the same instance. JTAC case pending. Other than that, things seem to be working OK. Thanks for the heads up. Serge - Original Message From: Mark Tinka mti...@globaltransit.net To: juniper-nsp@puck.nether.net; Serge Vautour se...@nbnet.nb.ca Cc: Richard A Steenbergen r...@e-gerbil.net Sent: Fri, June 3, 2011 1:04:09 PM Subject: Re: [j-nsp] MX80 Opinions On Friday, June 03, 2011 11:31:51 PM Serge Vautour wrote: Would it be possible for you to share what code version you recommend for Trio? We've had a few MX80s in Prod with 10.2S6 for a while now. We need to add MPC cards to our MX960s and are struggling what version to go with. Continue with 10.2 or move to 10.4? We're also planning on adding alot more MX80s. For the chassis-based MX's, we've generally found happiness in staying current for Junos 10.4 (now at 10.4R4.5). This has fixed random PFE crashes, FPC reboots, e.t.c., since the boxes shipped with 10.4R1. We're actively staying away from Junos 11 for now. One thing to think seriously about is whether you're going to run your MX's with a mixture of DPC's and MPC's. Depending on which features you need to turn on, you may not be able to boot DPC cards if you have MPC's installed as well. I'd seriously suggest checking with your SE before turning up any features if you're going to mix DPC's and MPC's, or if certain features for the MPC's seem kinky. We've had too much pain for some items. Cheers, Mark. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 Opinions
On Saturday, June 04, 2011 12:17:15 AM Richard A Steenbergen wrote: Agreed 100%, plus getting line-rate out of a mixed DPC/MPC environment is a real bitch for a number of reasons, so you'll be MUCH better off if you convert a whole chassis at a time. Though I will say that 10.4R4 didn't give us ANY grief when doing mixed DPC/MPC during the actual conversion maintenance, which is a first for the dozen or so places where we've done this already. :) It's unfortunate that the issue we faced is one of those I can't freely talk about - but in our case, the solution to have maximum support for a feature we needed under Junos 10.4R4.5 was to go for an all-DPC design. Obviously, it doesn't help that all our MX480's shipped with MPC's :-). Native support for the feature we wanted meant going for Junos 11, but we still had the restriction that we couldn't use DPC's even if we wanted to. So with the extra headache of having to run Junos 11, we opted to stay on 10.4 with a workaround that gives us what we want, but means we have to change our topology to suit the situation, restrict what we can do, and never be able to run DPC's in the chassis. Moral of the story: check with your SE before you buy. Things are no longer like they were back in the ol' days :-). Mark. signature.asc Description: This is a digitally signed message part. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 Opinions
2011/6/2 Richard A Steenbergen r...@e-gerbil.net On Thu, Jun 02, 2011 at 09:59:15PM -0400, jnprb...@gmail.com wrote: Although expensive, you can buy the JCS1200 with 64-bit Junos to run as a standalone RR. It's probably more economical if you could also benefit from VPNv4 RRs for MPLS VPN deployments. Price aside, anyone who wants a 12U RE needs to have their head examined. :) How freaking hard can it be to take an off-the-shelf 1U PC, slap a Juniper logo on the front, mark it up 20x like everything else, and sell it to us as a fully supported RR? I'm still confused how this has managed to escape their attention. And then there was Vyatta ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 Opinions
Thats a very good point. Vyatta is a solid product. From: Keegan Holley keegan.hol...@sungard.com To: Richard A Steenbergen r...@e-gerbil.net Cc: juniper-nsp@puck.nether.net Sent: Friday, June 3, 2011 12:44 PM Subject: Re: [j-nsp] MX80 Opinions 2011/6/2 Richard A Steenbergen r...@e-gerbil.net On Thu, Jun 02, 2011 at 09:59:15PM -0400, jnprb...@gmail.com wrote: Although expensive, you can buy the JCS1200 with 64-bit Junos to run as a standalone RR. It's probably more economical if you could also benefit from VPNv4 RRs for MPLS VPN deployments. Price aside, anyone who wants a 12U RE needs to have their head examined. :) How freaking hard can it be to take an off-the-shelf 1U PC, slap a Juniper logo on the front, mark it up 20x like everything else, and sell it to us as a fully supported RR? I'm still confused how this has managed to escape their attention. And then there was Vyatta ___ 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] MX80 Opinions
On Fri, Jun 03, 2011 at 08:31:51AM -0700, Serge Vautour wrote: Would it be possible for you to share what code version you recommend for Trio? We've had a few MX80s in Prod with 10.2S6 for a while now. We need to add MPC cards to our MX960s and are struggling what version to go with. Continue with 10.2 or move to 10.4? We're also planning on adding alot more MX80s. 10.4R4 seems usable on MX960 with mixed DPC/MPC. There is a packet discard bug on MX80 though - it randomly mistakes non-first fragments as L2TP packets and as no L2TP service is configured, discards those packets. Best regards, Daniel -- CLUE-RIPE -- Jabber: d...@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 Opinions
Daniel, I have nothing but good things to say about the MX80. It's based on the Trio chipset which means that the data plane is all ASIC based. I use it personally for creating complex logical topologies using the logical-systems feature. The MX80 is more than enough to meet your requirements below. The only downside I can think of is that it doesn't have dual routing engines. If that's a requirement you have to move up to the MX240 and above. Thank you, Doug Hanks Systems Engineer JNCIP-M/T #1441 -Original Message- From: juniper-nsp-boun...@puck.nether.net [mailto:juniper-nsp-boun...@puck.nether.net] On Behalf Of Daniel Faubel Sent: Thursday, June 02, 2011 4:09 PM To: juniper-nsp@puck.nether.net Subject: [j-nsp] MX80 Opinions Hello all, Could I get some of your opinions about the MX80 platform? I'm looking for positive and negative opinions. Any gotchas I should know about? I've always used the Cisco type of CLI, so there will be a learning curve there. The traffic volume for this application will be 10-15g/sec of v4 and v6. Full BGP tables of each. And there will be some MPLS needed. ___ 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] MX80 Opinions
On Thu, Jun 02, 2011 at 04:26:54PM -0700, Doug Hanks wrote: Daniel, I have nothing but good things to say about the MX80. I have almost nothing but good things to say, now that 90-95% of the cripling Trio-specific bugs have been worked out of the current code. The integrated RE is probably the biggest design limitation. For example, we just got bit by a bad flash drive on one, which caused the kernel to lock up when writing to the disk. This required a physical power cycle to bring the box back every time it happened, left no evidence in the logs (so we had to catch it actually happening on console to know what was going on), and required a complete RMA of the chassis to fix. The lack of redundant REs severely limits the potential of this otherwise excellent little box. Oh and don't forget, a single RE will make your upgrade process take a lot longer too. Juniper would really do well to introduce a 1U small/simple external RE which can be connected over Ethernet, to redundantize a box like the MX80, and to be a reasonably sized BGP route reflector. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 Opinions
On 03/06/11 10:10, Richard A Steenbergen wrote: The integrated RE is probably the biggest design limitation. For example, we just got bit by a bad flash drive on one, which caused the kernel to lock up when writing to the disk. This required a physical That's the bigger problem. As I understand it, the flash is soldered on similar to the EX's instead of just using an internal CF or SD slot which would have helped. -- Julien Goodwin Studio442 Blue Sky Solutioneering 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] MX80 Opinions
Or build a redundant re in it. They can make the boards small it enough if they want to... On Jun 2, 2011 8:15 PM, Richard A Steenbergen r...@e-gerbil.net wrote: On Thu, Jun 02, 2011 at 04:26:54PM -0700, Doug Hanks wrote: Daniel, I have nothing but good things to say about the MX80. I have almost nothing but good things to say, now that 90-95% of the cripling Trio-specific bugs have been worked out of the current code. The integrated RE is probably the biggest design limitation. For example, we just got bit by a bad flash drive on one, which caused the kernel to lock up when writing to the disk. This required a physical power cycle to bring the box back every time it happened, left no evidence in the logs (so we had to catch it actually happening on console to know what was going on), and required a complete RMA of the chassis to fix. The lack of redundant REs severely limits the potential of this otherwise excellent little box. Oh and don't forget, a single RE will make your upgrade process take a lot longer too. Juniper would really do well to introduce a 1U small/simple external RE which can be connected over Ethernet, to redundantize a box like the MX80, and to be a reasonably sized BGP route reflector. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ 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] MX80 Opinions
I think Juniper's answer to redundancy with the MX80s is to setup 2x MX80's and use routing protocols to switch over from one to the other. For a fully loaded box, it probably edges up on making an MX280 a better deal, but for the smaller software-limited MX80's I could see it being an ok deal. ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 Opinions
Juniper would really do well to introduce a 1U small/simple external RE which can be connected over Ethernet, to redundantize a box like the MX80, and to be a reasonably sized BGP route reflector. If there was a like button on j-nsp, I'd click it about this.. Outside of a few bugs we've been really happy with the MX80.. We have 6 or 7 in production now.. -- Tim ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 Opinions
On 03/06/11 10:10, Richard A Steenbergen wrote: Juniper would really do well to introduce a 1U small/simple external RE which can be connected over Ethernet, to redundantize a box like the MX80, and to be a reasonably sized BGP route reflector. There was talk of a VC-like implementation for the MX80, although I don't know if that went anywhere. Now that they have the XRE200 what about letting us install Junos64 on it and making it a reflector platform. -- Julien Goodwin Studio442 Blue Sky Solutioneering 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] MX80 Opinions
On Fri, Jun 03, 2011 at 11:47:30AM +1000, Julien Goodwin wrote: There was talk of a VC-like implementation for the MX80, although I don't know if that went anywhere. Now that they have the XRE200 what about letting us install Junos64 on it and making it a reflector platform. We actually tested the XRE200 for RR use (since it's a hell of a lot more sane than a JCS), but they specifically lock it down so you can't run BGP on it directly. This is the only JUNOS platform which is SMP enabled right now, and from what I've heard the regular kernel krt isn't thread safe, so my theory is to make it do SMP they may have had to disable some of the normal routing operations and only make it capable of controlling other EX chassis. I'm sure it would make a fine, if very overpriced, Olive though. :) -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 Opinions
On Thu, Jun 02, 2011 at 09:59:15PM -0400, jnprb...@gmail.com wrote: Although expensive, you can buy the JCS1200 with 64-bit Junos to run as a standalone RR. It's probably more economical if you could also benefit from VPNv4 RRs for MPLS VPN deployments. Price aside, anyone who wants a 12U RE needs to have their head examined. :) How freaking hard can it be to take an off-the-shelf 1U PC, slap a Juniper logo on the front, mark it up 20x like everything else, and sell it to us as a fully supported RR? I'm still confused how this has managed to escape their attention. -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 Opinions
On 6/2/11 7:06 PM, Richard A Steenbergen r...@e-gerbil.net wrote: We actually tested the XRE200 for RR use (since it's a hell of a lot more sane than a JCS), but they specifically lock it down so you can't run BGP on it directly. This is the only JUNOS platform which is SMP enabled right now, and from what I've heard the regular kernel krt isn't thread safe, so my theory is to make it do SMP they may have had to disable some of the normal routing operations and only make it capable of controlling other EX chassis. I'm sure it would make a fine, if very overpriced, Olive though. :) The new MX REs run 64-bit Junos. -- Doug Hanks, JNCIP-M/T #1441 Systems Engineer Juniper Networks ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] MX80 Opinions
On Thu, Jun 02, 2011 at 07:11:31PM -0700, Doug Hanks wrote: The new MX REs run 64-bit Junos. 64-bit JUNOS != SMP enabled. The only difference is the amount of ram it can address, those fancy quad-core CPUs only run on a single core. :) -- Richard A Steenbergen r...@e-gerbil.net http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
