& cplSiteName &
Comments
Newest First  |  Oldest First  |  Threaded View        ADD A COMMENT
<<   <   Page 4 / 6   >   >>
andropat
andropat
12/5/2012 | 1:56:01 AM
re: Cisco Sprints Ahead With HFR
Mr. bannister,

I never said putting non-FRU things in a box was a good idea. I simply said as Tony has stated that the reality is that it does not really matter in the end. How many M40s has Juniper had to swap out of networks due to backplane failures? Or cisco? Or anyone else?

Hardware fails.. no doubt! But I will bet that spinning hard drives, flash drives, memory, etc., all go bad way before this "active" component on the backplane. Maybe you should go back to work for a vendor.

pat
Tony Li
Tony Li
12/5/2012 | 1:55:59 AM
re: Cisco Sprints Ahead With HFR
Reality, Tony is that you do not want to put electronics on the backplane which if they fail lead to replacements of the backplane - this is a hardware thing.
-------------


Let me try again: if you limit the number of components on the backplane and do the MTBF math, you can easily construct a backplane that has a theoretcial MTBF (after initial burn-in) that far exceeds the practical lifetime of the router. From that perspective, you can limit the size of this problem.

However, if you are the poor sot who gets the unlucky outlier that fails only one year into the system, this is NO condolence. And, if you design the system this way, the amount of disagreement that you will get from the customers will far exceed the benefits of having it on the backplane.

So.... while you COULD do it, it's not a good idea.

Tony
Douglas_Gourlay
Douglas_Gourlay
12/5/2012 | 1:55:58 AM
re: Cisco Sprints Ahead With HFR
I think one thing probably more impactful to customers is the type of components put into the 'active' backplane.

Passive Backplane- Copper traces, not much more.

Active Backplane- usually clocking chips of some sort.

Taking the availability and reliability arguments off the table based on the practical realities as discussed previously it seems that any form of clocking built into the backplane (as was common on the 7000/7500, Catalyst 5000, etc) has a more direct impact on limiting the customer's ability to upgrade the system forwarding capacities across the backplane (card ot card).

The move to passive backplanes has allowed systems vendors to design some element of future-proofing and investment protection into the systems so that a system could do 8, 20, or 40Gbps per slot today, and as newer SERDES come to market the customer can upgrade the interface module containing the switch fabric and increase the overall systems capability for forwarding traffic.

dg
truelight
truelight
12/5/2012 | 1:55:55 AM
re: Cisco Sprints Ahead With HFR
Dear Doug passive backplanes in communications systems have been deployed for many years, even before modern routers where invited, think Class 5 switches.

BTW on the passive backplane the problem in high speed Serdes is testign the backplanes are futuire proof. Many have tried to do this and have failed miserable, resulting in expensive upgrades i.e., CISCO

truelight
truelight
12/5/2012 | 1:55:55 AM
re: Cisco Sprints Ahead With HFR
So we agree then.

What would you say is the expected lifetime of a router ?

7 years, 15 years before they are they are replaced ?

Tony Li
Tony Li
12/5/2012 | 1:55:54 AM
re: Cisco Sprints Ahead With HFR

Agree completely.

Tony
jepovic
jepovic
12/5/2012 | 1:55:54 AM
re: Cisco Sprints Ahead With HFR
The economic lifetime of a router is more like 3 years, max 5, unfortunately. Not that they break or that their capacity is too low (you can always push them further out from the core), but new features only have so much backwards compatibility. Old Engine cards, old Juniper FPCs, have crappy QoS support for instance.

Of course, with the GSR you can upgrade pretty much everything, but then you have to spend money in the range of a new router (one could argue that it is in fact a new router). Also, the costs nowadays are in the IF cards anyway, so why bother?
null0
null0
12/5/2012 | 1:55:49 AM
re: Cisco Sprints Ahead With HFR
Can I infer from your comment

"Old Engine cards, old Juniper FPCs, have crappy QoS support for instance"

that you think that current generation C&J have good QoS?

To quote from the Juniper T-Series HOL Blocking thread...

"It's a fairly simple test to see the impact to adjacent ports when one port is oversubscribed. It doesn't require massive bandwidth or a fully loaded system. When I tested the GSR for this I could create over 50% loss on one port just by oversubscribing the neighboring port by 150%. A juniper T320 was a little better, but still had over 20% loss on neighboring ports. Another fact with juniper is that it is blocking on the FPC, so all of the PICs on the same FPC are subject to this issue."

I would bet my 401k that the M-Series performs better than the T when it comes to QoS.

Null0
echo2
echo2
12/5/2012 | 1:55:46 AM
re: Cisco Sprints Ahead With HFR
There's an important distinction to be made here between reality and perception. A system with active components on the backplane is *perceived* to be more problematic than one without. The reality of the situation, as evidenced by real statistics says that this is bunk.

However, if you want to sell to the carriers, you must deliver to both the perception AND the reality.
--------------------

The reason carriers are concerned with this is they want five 9's of availability. MTBF is only part of that equation. Mean time of repair is a more significant part. If you have a failure on a hot swap module, you can fix it in 5 minutes. If you have a failure of a component in the backplane, then mean time to repair is hours or days and the entire shelf is probably going off line.

That is just one example of why it is funny to watch the enterprise router guys try to sell to the carriers. The enterprise router guys think the carriers are too picky. The carriers think the enterprise router guys are incompetent.

echo2
durtyphiber
durtyphiber
12/5/2012 | 1:55:41 AM
re: Cisco Sprints Ahead With HFR
This is because if you do not enable any QoS, the packet memory for the entire outbound LC is shared by all of the ports.

If you wish to prevent this, just enable WRED or MDRR. This will cause the LC to allocate each port it's own set of queues.

This is specific to the GSR. Any LC above Engine 2 can perform WRED/MDRR w/o performance hit.

Hope this helps,

- durtyphiber
<<   <   Page 4 / 6   >   >>


Featured Video
Upcoming Live Events
October 22, 2019, Los Angeles, CA
November 5, 2019, London, England
November 7, 2019, London, UK
November 14, 2019, Maritim Hotel, Berlin
December 3-5, 2019, Vienna, Austria
December 3, 2019, New York, New York
March 16-18, 2020, Embassy Suites, Denver, Colorado
May 18-20, 2020, Irving Convention Center, Dallas, TX
All Upcoming Live Events