ASR 1000 does not run XR. You probably mean XE. The high availability features that requires maintaining state and stateful switch over never seem to work out of the box on early releases and need some time until the feature gets mature. I've found this across different vendors. The dual IOS process works best with two Routing Engines/ESPs on higher models. contact your local vendor engineering representatives asking them for more details on the the ASR1K High Availability features and they should tell you how it works in detail. Regards, Ahmed Sent using BlackBerry® from mobinil -----Original Message----- From: Mark Tinka <mtinka@globaltransit.net> Date: Mon, 23 Jan 2012 22:58:45 To: <nanog@nanog.org> Reply-To: mtinka@globaltransit.net Subject: Re: juniper mx80 vs cisco asr 1000 On Friday, January 20, 2012 04:34:56 AM Thomas Donnelly wrote:

The warm standby IOS is a nice feature for in service upgrades and crash avoidance.

Except that some times, it did lead to crash (for us anyway), because it eats up half the router's memory, and if you're running 3x full tables or more, you ran out of the other half and BOOM! And that was IOS XR 2, which is generally old now. We now turn off software redundancy now on all ASR1000 boxes that don't have a 2nd RP. Mark.

The ASR1000 series are like most Ciscos, they can be used for a lot of things. They are a swiss-army knife of routers and basically are the upgrade from the Cisco 7200 series. If you want low level LNS functionality, then the Cisco is the way to go as the Juniper MX80 does not have LNS functionality (and looks like it never will). But if you are looking for a beast of a border router for BGP and so on, then the MX80 (MX5/10/40/80) kick ass with their throughput. MX80 series are also supposed to be supporting Virtual Chassis at some point (was supposed to be now, but I hear it is delayed). We're deploying a variety of MX5, MX10's for different projects at the moment. The other thing is that the MX80 platform, comes in very cheap options like the MX5 - with 20Gb of TP and 20Gig interfaces at under 25k, that is awesome. The MX5/10/40 are the exact same hardware and you can just upgrade with a license. The base MX5 has 4 * 10GbE interfaces which aren't usable until you go to MX40 (2 of them) or MX80 (all 4). But in an MX10, with the second slot active, you can put in a 2 port 10GbE card which works just fine. …Skeeve On Fri, Jan 20, 2012 at 8:43 AM, Ariel Biener <ariel@post.tau.ac.il> wrote:

On 01/19/2012 11:40 PM, Leigh Porter wrote:

...

-----Original Message-----

...

From: jon Heise [mailto:jon@smugmug.com] Sent: 19 January 2012 21:37 To: nanog@nanog.org Subject: juniper mx80 vs cisco asr 1000

Does anyone have any experience with these two routers, we're looking to buy one of them but i have little experience dealing with cisco routers and zero experience with juniper.

I have lots of MX80s and they have all been fantastic. But if you have no experience of Juniper it will be a different learning curve (one that is, IMO, worth the effort).

I have not used the asr1000 but it looks like a capable box. You would do well to look at the MX80 fixed chassis, it comes with 48 1G interfaces and 4 10G interfaces. They are pretty good value, I think.

It well depends on your requirements (not talking about throughput). The ASR1000 series is a "services" box. It does more in terms of services (using license enablers) than the MX80 does, and it costs more.

So, it very much depends on what you want to do with the boxes.

--Ariel

...

-- Leigh Porter

______________________________**______________________________** __________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________**______________________________** __________

-- -- Ariel Biener e-mail: ariel@post.tau.ac.il PGP: http://www.tau.ac.il/~ariel/**pgp.html<http://www.tau.ac.il/~ariel/pgp.html>

-- *Skeeve Stevens, CEO* eintellego Pty Ltd skeeve@eintellego.net.au ; www.eintellego.net Phone: 1300 753 383 ; Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellego twitter.com/networkceoau ; www.linkedin.com/in/skeeve PO Box 7726, Baulkham Hills, NSW 1755 Australia The Experts Who The Experts Call Juniper - Cisco – Brocade - IBM

The MX80 license locked is not 5Gb The MX5 is 20Gb TP - 20 SFP ports card, only one MIC slot active The MX10 is 40Gb TP - 20 SFP ports card. both MIC slots active The MX40 is 60Gb TP - 20 SFP ports card, both MIC slots + 2 of the onboard 10GbE ports The MX80 is 80Gb TP - 20 SFP ports card, both MIC slots + all 4 of the onboard 10GbE ports The MX80-48T is 80Gb TP - 48 Copper ports, both MIC slots + all 4 of the onboard 10GbE ports Last year the licensed versions were called MX80-5G, MX8-10G and so on, but as on this month they've renamed them to MX5, MX10, MX40's - note that the old MX80 could come with or without -T timing support, the new ones ONLY have timing. …Skeeve On Sat, Jan 21, 2012 at 3:50 AM, PC <paul4004@gmail.com> wrote:

While the ASR1002 does offer more services, I generally disagree with some parts of this comparison.

Juniper has some very aggressive pricing on mx80 bundles license-locked to 5gb, which are cheaper and blow the performance specifications of the equivalent low end ASR1002 out of the water for internet edge BGP applications. Unlike the ASR, a simple upgrade license can unlock the boxes full potential.

Just my opinion as a customer of both vendors...

On Fri, Jan 20, 2012 at 1:14 AM, Saku Ytti <saku@ytti.fi> wrote:

...

On (2012-01-19 12:10 -0800), jon Heise wrote:

...

Does anyone have any experience with these two routers, we're looking to buy one of them but i have little experience dealing with cisco routers and zero experience with juniper.

It might be because of your schedule/timetable, but you are comparing apples to oranges.

MX80 is not competing against ASR1k, and JNPR has no product to compete with ASR1k. MX80 competes directly with ASR9001. Notable differences include:

ASR9001 has lot more memory (2GB/8GB) and lot faster control-plane ASR9001 has 120G of capacity, MX80 80G ASR9001 BOM is higher, as it is not fabricless design like MX80 (this shouldn't affect sale price in relevant way) ASR9001 does not ship just now

As others have pointed out ASR1k is 'high touch' router, it does NAPT, IPSEC, pretty much anything and everything, it is the next-gen VXR really.

ASR9001 and MX80 both do relatively few things, but at high capacity.

-- ++ytti

-- *Skeeve Stevens, CEO* eintellego Pty Ltd skeeve@eintellego.net.au ; www.eintellego.net Phone: 1300 753 383 ; Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellego twitter.com/networkceoau ; www.linkedin.com/in/skeeve PO Box 7726, Baulkham Hills, NSW 1755 Australia The Experts Who The Experts Call Juniper - Cisco – Brocade - IBM

On (2012-01-20 09:50 -0700), PC wrote:

Juniper has some very aggressive pricing on mx80 bundles license-locked to 5gb, which are cheaper and blow the performance specifications of the equivalent low end ASR1002 out of the water for internet edge BGP applications. Unlike the ASR, a simple upgrade license can unlock the boxes full potential.

ASR1002 list price is 18kUSD, MX5 list price is 29.5kUSD. Upgrade license for MX5 -> MX80 literally costs more than new MX80 (with all but jflow license, two psu and 20SFP MIC) Sure MX5 will do line rate on 20 SFP ports, vastly more than ASR1002, but this is little consolation if you need high touch services such as NAPT, IPSEC etc. So applications for these boxes are quite different. -- ++ytti

On Friday, January 20, 2012 04:14:35 PM Saku Ytti wrote:

MX80 is not competing against ASR1k, and JNPR has no product to compete with ASR1k.

And this is something I've been telling Juniper for years (not that they don't already know). The M7i and M10i have really done all they can - but trying to get an Ethernet box to do non-Ethernet things, while possible, is simply not economically viable for operators (FlexWAN's, SIP's, MX FPC's, anyone?). They really need to solve this one. The MX80 had no competition from Cisco, until the ASR9001 came out (and it supports 40Gbps line cards when they come out). Juniper are dropping the ball on this one. But hopefully, they're busy in the lab building a decent ASR1000 challenger. Mark.

On Tuesday, January 24, 2012 11:50:37 PM Matt Craig wrote:

They are competing in some things. There are differences that will make you choose ASR1000 over MX series, but alot of people are choosing either one of the other for many of the same jobs, mainly upgrading to straight-forward L3 1/10 gig aggregation. I know some people who've had ASR1000s and MXs on the plate and chose the MXs. I've also known some who's chosen the ASR1000s. It just really depends on what you need.

When it comes to peering or upstream boxes, we've always gone with smaller, multiple units rather than bigger, single ones, e.g., ASR1002 vs. CRS or MX80 vs. M120, sort of thing. As one wants to spread peering/upstream links across different boxes to enhance redundancy, one can't afford to be buying bigger boxes for each these links. What this has meant is that for a while now, we've been happy with the ASR1000 because at some point, it was more feature-ready than the MX80. However, the MX80 has now caught up, and is certainly a serious contender if we're looking at new purchases (but then, there is now the ASR9001, whenever it starts shipping). However, this only works if our connectivity arrangements are Ethernet. If we plan to have both Gig-E and non-Gig-E capacity in a router, and we need to be able to push a couple of Gbps through it (including one or more 10Gbps hook-ups), then the ASR1000 is still a winner. This is where the MX80 can't compete; and while the MX80 and ASR1000 are somewhat of an apples vs. oranges comparison, there really ins't anything coming from Juniper at all in this space. So one is forced to compare what comes closest.

Actually something as an alternative to both I am researching is the Brocade MLX series. They have different, more efficient, and refreshing architecture; and phenomenal cost (half the cost of ASR1000/MX or less). Gonna do a trial shortly to see if it all lives up to the marketing or if its too good to be true. I also know some peer institutions who have dumped both Cisco and Juniper for Brocade's Ethernet/IP lines. Not a single bad word so far.

We reviewd the MLX against the 7600 and M320 many years ago. These days it would be the MLX against the ASR9000 and MX240/480/960. It didn't have the feature set we needed, but that was a while back. Our national exchange point have been happy with them, using VPLS to run the fabric (I think AMS-IX do the same, too). But that's a relatively simple deployment. I know some large carriers using them extensively, but not intimately enough to tell you whether they're really happy or not. Mark.

On Wednesday, January 25, 2012 02:24:28 AM George Bonser wrote:

You might get by these days at a peering point with something smaller if you are a smaller network and don't need a lot of 10G. Something like a Brocade CER-RT series. A 1U box with 136 Gbps of throughput that will handle 1.5 million v4 routes in FIB and 256k v6 routes. Sips power, doesn't take up a lot of space, has up to 48 GigE ports but only 2x10G. If they had a model with 6x10G, it would be a killer little box.

We looked at their CER/CES line back in 2009/2010 when we were scoping for kit to deploy our MPLS In The Access topology. That time, the box only did 512,000 entries in the FIB, but clearly the newer iron has had an upgrade on the inside :-). This is good! Inevitably, we settled for Cisco's ME3600X, after realizing we didn't need to carry a full table in the Access (and could still provide IP Transit services in the Access easily), and at the time, even though the Cisco was much newer, the mid-term feature road map was better. Mark.

On 25/01/12 02:50, Matt Craig wrote:

Actually something as an alternative to both I am researching is the Brocade MLX series. They have different, more efficient, and refreshing architecture; and phenomenal cost (half the cost of ASR1000/MX or less). Gonna do a trial shortly to see if it all lives up to the marketing or if its too good to be true. I also know some peer institutions who have dumped both Cisco and Juniper for Brocade's Ethernet/IP lines. Not a single bad word so far.

Sorry I can't let a line like that slide. I used to use ServerIron's in my last job, and while generally wonderful they had two big issues that also occur on other Foundry kit like the MLX. 1. Multiple firmware files that must be upgraded in sync. While getting more common (I've seen kit from Extreme, Cisco, and Juniper that have done this to some extent), some of these boxes require on the order of four firmware files which must be upgraded in lock-step 2. Backspace doesn't work. Seriously (ok Ctrl-h works, and you can patch your terminal emulator for it, but it's the only hardware I've used in the last 15 years like that)

On 1/25/2012 10:50 AM, Nick Hilliard wrote:

On 25/01/2012 15:17, Julien Goodwin wrote:

...

2. Backspace doesn't work. Seriously (ok Ctrl-h works, and you can patch your terminal emulator for it, but it's the only hardware I've used in the last 15 years like that)

I ended up remapping backspace to <CTRL-H> too.

Yeah, seriously, this is totally bizarre dysfunction. There might have been some excuse for it in the late 1980s, maybe even the early 1990s. But the world moved on many, many years ago.

Same here... Likewise, up to a certain firmware version, the input would wrap to a second line making it difficult to backspace. Thankfully that is now fixed. The biggest issue I have now is modern security patched versions of putty just explode when talking to that gear with "type 2 (protocol error) Bad String Length" messages. It's one of those things where putty works fine with everything else as well as every other terminal program works fine with Brocade... so who's at fault? :-P I've got 4 of the XMR 4000's and been running them for years. Most of the problems have been firmware bugs... Early ones were killers and caused inconsistencies in the routing topology, but I haven't seen anything to that extent again. The last major issue I had was the management cards on two of the boxes, about 2500 miles apart, both decided to go insane within hours of each other. I think a line card crashed if I remember right, the boxes stayed up, the management module stopped responding. Some traffic was being black-holed while other traffic continued flowing. After we already fixed it, a Brocade tech said that it sounded like a bus hang or something of that nature which can usually be fixed by re-seating the fan tray(??!?) so you don't need to reboot. We simply power cycled both. Another annoying bug I ran into which prompted a call to Brocade in the middle of the night... I couldn't update the firmware via SSH (nor could they). It kept failing on committing one of the firmware files after it was transferred. Turns out it was a bug and the workaround was to use telnet. The fix was in the version I was upgrading to. <sigh> It also would have been nice to know that before the tech said just reboot it and it should be fine and we followed all the upgrade steps (despite the errors saying it failed)... the line card's firmware didn't match and wouldn't boot as a result. Luckily this XMR was two blocks from where I was sitting and I recovered it, but still annoying. This is what someone else mentioned about all the firmware files needed just to upgrade. There is a combo file, but it doesn't cover everything. One might try to seek out a Telehouse IIX engineer for another opinion. Being a customer of theirs on the NYIIX peering exchange, I know of many issues and outages that were all seemingly related to the MLXe's on which they now run the exchange. On the flip side, find some Hurricane Electric folk. I could be wrong, but I believe their entire backbone is built on the XMR. I know I've seen them in carrier hotels with their name on the equipment. One is two cabinets down from my own in the same cage. Personally, I like the products on paper. Using them in production slightly lowers my satisfaction with them, but you definitely get a lot for your money... bugs and all. -Vinny

On 25/01/12 18:57, George Bonser wrote:

I've noticed that though I think that is only on the hardware console port. Most of the work I do is via the management port. If I'm on the console serial port, then I am working manually and just deal with the ^H thing. I don't think that issue by itself is enough to prevent me from buying a piece of gear.

The CES (at least) does it via SSH, too. (I use the standard Gnome terminal, so we're talking the same application for serial and SSH/telnet use.) Annoyingly the Dell 5400 series switches do it on their console ports, too. Thankfully they don't once you're in via SSH. But no-one cares about those! Tom

On 25/01/12 20:14, Vinny Abello wrote:

On 1/25/2012 2:32 PM, Tom Hill wrote:

...

Annoyingly the Dell 5400 series switches do it on their console ports, too. Thankfully they don't once you're in via SSH. But no-one cares about those!

So do the 55xx's, unfortunately. I'm not sure about the other PowerConnect series. The firmware largely varies in syntax from one model to the next but the 54xx and 55xx seem largely the same. If I get some spare time, I'll look into digging up some contacts from the PowerConnect team and suggest they fix the backspace console issue.

I didn't have the same problem with the 62xx (or the lone 52xx I used, for that matter) but then, it's all Broadcom software; it doesn't matter how competent/understanding the guys at Dell are, Broadcom won't lift a finger without a smoking gun. I think of the three or four bugs that Dell passed through to Broadcom on my behalf (i.e. I'd had to convince at least one other person that it wasn't appropriate behaviour), only one was acknowledged and fixed. With that in mind, I wouldn't waste your time! Tom

On Thursday, January 26, 2012 02:57:59 AM George Bonser wrote:

If there is a hardware change, you might need to update the FPGA images. That is a second file but doesn't happen with every release. In fact, you might not even need it of they DO release a new one because the change might be for the addition of FPGA images or changes to an image for blade you don't even have. But again, it is one combined file for all blades.

The issue we have now with IOS XR-based systems is the SMU's. Most times, the SMU's need to reload bits of the hardware, and it will be different files making different updates that each need to reload bits of the hardware (fabric, line cards, e.t.c.). Needless to say, a software upgrade of the main OS on IOS XR systems is very lengthy. I'm yet to do it in less than one hour, particularly if you're doing SMU's at the same time. Here, Junos wins (although, in all fairness, the systems aren't the same so maybe not a proper comparison to begin with). But I understand Cisco are working on streamlining this in future releases of IOS XR, which would be welcome. While I prefer SMU's to ISSU, the majority of them are not entirely hitless (contrary to the documentation accompanying an SMU), although it will take a shorter time to update via an SMU than the main OS, as of today anyway. Mark.

On Saturday, January 28, 2012 01:42:54 PM Randy Bush wrote:

my fear is that issu is a very complex hack to cover that it takes a week to boot the turkey. and adding more complexity will not make things better in the long run, probably worse in fact.

True, and also to (well, in theory, anyway) not have to reload the box to launch new images in order to avoid any kind of downtime (even with a fixed boot process). The problem with ISSU is that it requires specific support across specific protocols, features and hardware in the router, which invariably means having to run the latest code that supports the features you feel need ISSU, and/or the latest hardware that meets the ISSU requirements per the vendor (it's like chasing your own tail). Since we schedule all maintenance in a maintenance window anyway (whether it's service-impacting or not), I see no point for ISSU. But to each their own. Mark.