x
Optical/IP

Cisco's HFR Gets Mod

Cisco Systems Inc.'s (Nasdaq: CSCO) forthcoming Huge Fast Router (HFR) will mark a departure from the company's IOS software, and that change represents a major shift in Cisco's high-end product offerings, sources say.

As impressive as its hardware might be -- 640 Gbit/s per rack, with OC768 interfaces, according to sources -- the software makes HFR an even bigger deal. Those who've gotten an early look at HFR say it's a major development for Cisco.

"It's not just a bigger router. It's just a piece in the puzzle," says consultant and IP guru Peter Lothberg.

Industry watchers presume Cisco is announcing the HFR at an event scheduled for May 25, as noted by an analyst on yesterday's earnings call (see Cisco Delivers, Sees 5% Growth in Q4). CEO John Chambers ducked the analyst's question about the event, though.

HFR -- or whatever is happening May 25 -- is going to get the Cisco spotlight for the rest of the year. "[May 25] is going to be just the beginning of a series of rolling-thunder types of announcements from Cisco," said Charles Giancarlo, Cisco's senior vice president of product development, in a post-earnings-call interview with Light Reading.

Sources confirm that HFR will use modular software, a key element that's been assumed for some time (see Source: Cisco's HFR Tips the Scales). It will still retain a command-line interface to resemble IOS, but the software architecture is meant to make up for shortcomings of IOS in carrier networks.

Modular software is important because it provides the ability to make changes in pieces, rather than having to redo the software as a whole. "The concept is like blade servers -- you can run different software in different places," says Debra Mielke, principal analyst with Treillage Network Strategies Inc.. "It allows you to have a very resilient machine that has a lot of flexibility."

The HFR also opens Cisco to the possibility of distributing code among processors. For example, that means new software can sit on its own processor, segregated from the live code. "With router code in general, you can't do that. So what you have with HFR is something really powerful," Mielke says. The overall architecture could open an avenue for other software vendors: "I believe, in the end, you'll see third-party software running on those processors," she says.

Bringing new software to market is difficult, and the HFR's scope doesn't make the task any easier. If the software doesn't work, the HFR's market impact could go from mercury to molasses.

"New operating systems frequently require a year of production operation before they are completely stable and therefore Cisco will likely incur an extended sales cycle throughout the first year after the release, except with the beta customers that tested it beforehand," writes analyst Erik Suppiger of Pacific Growth Equities Inc., in a note released yesterday.

Sprint Corp. (NYSE: FON) is presumed to be among those beta customers, and AT&T Corp. (NYSE: T) has been mentioned as well (see Cisco Sprints Ahead With HFR). But Cisco's arriving late to the party. Avici Systems Inc. (Nasdaq: AVCI; Frankfurt: BVC7) already has a multichassis router on the market; and Juniper Networks Inc. (Nasdaq: JNPR) has been staking a claim at the high end with its T640, the basis of its next-generation offering. Suppiger notes the T640 has been shipped to 60 carriers during the last two years, nabbing a nice chunk of the high-end market.

The HFR may also have to contend with pesky startups entering this space, such as Chiaro Networks Inc. and Procket Networks Inc., both of which claim to be making headway.

"While Cisco’s HFR appears to bring Cisco close to parity with Juniper in terms of a high-end offering, we believe that Cisco is late to the market and the company will need to convince carriers that Cisco’s next generation won’t be two years behind," Suppiger writes.

Software aside, the HFR might have some awkward moments with its hardware. Suppiger and other sources note the HFR's first model fits a rack 23 inches wide, not the conventional 19 inches. That means the box requires a literal forklift upgrade, which could turn away some potential customers. Multiple HFR versions are planned however; one source notes that a 19-inch-rack version is slated for release 10 months after HFR's initial launch.

And, while it's not exactly "rolling thunder," at least one of the future HFRs will be a smaller-capacity box, a half-sized version aimed at spreading HFR to a larger market (see Sources: Cisco Building 'Son of HFR').

— Craig Matsumoto, Senior Editor, Light Reading

Page 1 / 6   >   >>
Tony Li 12/5/2012 | 1:48:01 AM
re: Cisco's HFR Gets Mod
Modular software refers to the internal architecture of the system and its ability to be divided into cleanly separated subsystems. A car is a modular system: if you need to replace the gas cap, then you don't have to take apart the motor.

Software that is designed to run on multiple processors is called 'distributed'. Distributed systems are more complex to architect, engineer and maintain. They can be very robust to single point failures. They can also be very fragile when there are 'genetic' failures as all nodes may be running the exact same code and have the exact same bug. Routing protocols are the best example of distributed systems that work (FSVO work).

The ability to run code on a processor in the system that is not 'live' is of dubious value. If it is not in production and influencing the behavior of the system, then it is not truly being tested. This is not violently different than having a separate router that just isn't passing production traffic. It does make a fine mechanism for debugging the infrastructure of the distributed system and it sounds like Cisco is trying to market its debugging tools. I wonder how many customers are going to care.

Third party software running inside a router is a concept that has been explored before and generally found lacking. If the application doesn't affect the behavior of the router, then it doesn't really need to be running on the router and there are frankly much cheaper ways of supporting the application. If the application does affect the behavior of the router, then it is likely to be tightly coupled to the hardware of the router for performance reasons and will hardly qualify as 'portable' and able to take advantage of the distributed nature of the HFR control plane simultaneously. The area where it is possible to provide third party enhancements are functionalities in the control plane, such as signaling protocols. These generally don't require a separate processor anyhow.

Tony
coreghost 12/5/2012 | 1:48:00 AM
re: Cisco's HFR Gets Mod Software that is designed to run on multiple processors is called 'distributed'. Distributed systems are more complex to architect, engineer and maintain. They can be very robust to single point failures. They can also be very fragile when there are 'genetic' failures as all nodes may be running the exact same code and have the exact same bug. Routing protocols are the best example of distributed systems that work (FSVO work).


I agree with most of what you said. But
Technically, I would define a distributed system
as being different processors and different
memory. Multiprocessor systems (SMP systems)
which I would guess cisco is talking about are
in the grey area between. But its a whole
lot easier to deal with a shared memory multiprocessor
system than a true distributed system.

Caspian and Pluris are the only people I've
seen brave (or foolish) enough to do real
distributed systems. And I think that the
conclusion from both efforts is that real
distributed systems don't work well for routers
for the reasons you mention. The distributed
systems also have a sick tendancy to start
morphing into routers within routers.

SMP systems have their own set of problems in
unless they are carefully designed, they choke
to death on blocking events and end up with
no better performance than a single processor.




coreghost 12/5/2012 | 1:48:00 AM
re: Cisco's HFR Gets Mod The description of the modular software on the
HFR is incorrect. Cisco isn't offering anything
in terms of modularity beyond what Juniper
delivered years ago. Its resiliancy will be
(at best) no better than Juniper. Given the
track-record of cisco, it could be worse.

In terms of customers. Being honest, nobody likes
the HFR. Sprint has the HFR because sprint does
what its told by Cisco. SBC will probably end
up buying lots of them for similar reasons.

As for ATT, if ATT is even out looking at the
HFR that probably means that Avici is in trouble
at its only real customer. If ATT is seriously
looking at the HFR, it makes nortel's alliance
with Avici even harder to comprehend.

Cisco can sell the HFR into its closed channels
like sprint which are not competitive anyway,
but beyond that the whole appeal of the thing
is questionable. Its also questionable given
Cisco's inability to keep "one" set of software
(IOS) working and fully-featured how cisco is now
going to keep two wholly different sets of
software going. Its an expensive proposition
because it means more engineers, more support
staff and more of everything.

And all for unproven software and an unproven
platform that gets them at best equal to juniper
after years of being behind.




Pete Baldwin 12/5/2012 | 1:47:59 AM
re: Cisco's HFR Gets Mod Tony's right; I criss-crossed "modular" and "distributed". I've taken another shot at it -- thanks for spotting that, Tony.
uguess 12/5/2012 | 1:47:59 AM
re: Cisco's HFR Gets Mod >The description of the modular software on the
>HFR is incorrect. Cisco isn't offering anything
>in terms of modularity beyond what Juniper
>delivered years ago. Its resiliancy will be
>(at best) no better than Juniper. Given the
>track-record of cisco, it could be worse.

It seems that the modular software on HFR will be better than Juniper's from an architecture point of view, because it allows per protocol upgrade, i.e. upgrade BGP only, etc. While Juniper's routing protocols are bundled into one process, and there is no memory protection between protocols.

uguess
Tony Li 12/5/2012 | 1:47:59 AM
re: Cisco's HFR Gets Mod Technically, I would define a distributed system
as being different processors and different
memory. Multiprocessor systems (SMP systems)
which I would guess cisco is talking about are
in the grey area between.


Cisco is really talking about the distributed systems approach. At this scale it's a necessity. You need at one processor per chassis just for housekeeping reasons.

Tony
coreghost 12/5/2012 | 1:47:58 AM
re: Cisco's HFR Gets Mod Just curious, what do you have to back this up?


Comments from people, some thirdhand,
whose names I can't give.
The lack of any enthusiasm about
it from those who have been briefed about it
continuously over several years. The beta
sites where cisco put it and how it got put
in those places.

But its all buyer beware. Your not going to
get public comments from anyone bashing the
HFR because anyone who actually has one or
knows the details of it can't say anything
about it let alone give a public opinion.

AutoDog 12/5/2012 | 1:47:58 AM
re: Cisco's HFR Gets Mod >In terms of customers. Being honest, nobody likes
>the HFR.

CG,

Just curious, what do you have to back this up?

-AD
coreghost 12/5/2012 | 1:47:57 AM
re: Cisco's HFR Gets Mod It seems that the modular software on HFR will be better than Juniper's from an architecture point of view, because it allows per protocol upgrade, i.e. upgrade BGP only, etc. While Juniper's routing protocols are bundled into one process, and there is no memory protection between protocols.


- per-protocol upgrade isn't as good as you
might think. It creates a nightmare of
dependences and releases of components that
may or may not have been tested together. I
upgrade BGP, then I try to upgrade multicast
and find out that the multicast upgrade I need
has not been tested with the BGP upgrade. A
couple months go on and I eventually get into
a configuration that cisco has not tested together
and the software crashes. I think that some
components can be upgraded as modules, but
drawing module lines around BGP given the
cross-dependencies in other modules will
probably not work. What cisco is talking
about sounds good, but operationally in a carrier
its a nightmare.

- As far as memory protection, what good is BGP
being up if OSPF is offline? One takes down
the other usually. Anything that puts routes
in the routing table can't really be well protected as a module.
uguess 12/5/2012 | 1:47:55 AM
re: Cisco's HFR Gets Mod - per-protocol upgrade isn't as good as you
might think. It creates a nightmare of
dependences and releases of components that
may or may not have been tested together. I
upgrade BGP, then I try to upgrade multicast
and find out that the multicast upgrade I need
has not been tested with the BGP upgrade. A
couple months go on and I eventually get into
a configuration that cisco has not tested together
and the software crashes. I think that some
components can be upgraded as modules, but
drawing module lines around BGP given the
cross-dependencies in other modules will
probably not work. What cisco is talking
about sounds good, but operationally in a carrier
its a nightmare.

Well, I guess it depends on the detailed design. It is possible to make it work. Some start-ups can do this today.

- As far as memory protection, what good is BGP
being up if OSPF is offline? One takes down
the other usually. Anything that puts routes
in the routing table can't really be well protected as a module.

I am afraid that I can not agree with you. To give a couple of examples that require control plane separation, IPv4/IPv6 dual-stack, unicast/multicast. Should an IPv6 problem affect your IPv4 traffic? Should a PIM crash bring down your IGP and BGP?

uguess
Page 1 / 6   >   >>
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE