Cisco's HFR Gets Mod

COMMENTS

Newest First | Oldest First | Threaded View

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

Reply | Post Message | MESSAGES LIST | START A BOARD

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.

Reply | Post Message | MESSAGES LIST | START A BOARD

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.

Reply | Post Message | MESSAGES LIST | START A BOARD

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.

Reply | Post Message | MESSAGES LIST | START A BOARD

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

Reply | Post Message | MESSAGES LIST | START A BOARD

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

Reply | Post Message | MESSAGES LIST | START A BOARD

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.

Reply | Post Message | MESSAGES LIST | START A BOARD

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

Reply | Post Message | MESSAGES LIST | START A BOARD

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.

Reply | Post Message | MESSAGES LIST | START A BOARD

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

Reply | Post Message | MESSAGES LIST | START A BOARD

Page 1 / 6 > >>