x
Optical/IP

Laurel, Redback Score in Router Test

Light Reading today published the results of its independent test of high-end edge routers, equipment that aims to help telecom operators make money by rolling out next-generation IP services using MPLS virtual private networks (see LR Publishes Edge Router Test Results).

The results demonstrate that at least two edge routers -- the ST200 from Laurel Networks Inc. and the SmartEdge 800 from Redback Networks Inc. (Nasdaq: RBAK) -- have got what it takes.

Both boxes handle huge numbers of Layer 2 and Layer 3 MPLS VPNs. In fact, they handle more Layer 2 VPN tunnels than we were able to measure, and our test bed was no toy. It broke all records in terms of pushing edge routers to the limit. The tests themselves -- conducted by Network Test using equipment and specially designed test software from Spirent Communications -- took nine months to complete and involved 40 staff.

Apart from demonstrating the ability to handle massive numbers of VPNs, the tests also measured: throughput and latency when handling different packet sizes; the time needed to restore 500,000 routes after a network failure; enforcement of quality-of-service requirements; and capacity in handling routing protocols.

In the report giving the full results of the tests (see Metro Edge Router Test), David Newman, president of Network Test, highlights three particular findings:
  • Using Layer 3 MPLS VPNs, both boxes emulated more than 2,400 virtual routers and handled hundreds of routes per customer.

  • Layer 2 MPLS VPNs scaled even higher, with both products forwarding traffic through nearly 40,000 tunnels. As far as we’re aware, both boxes set new records for public tests of MPLS VPN scaleability.

  • Routing capacity tests for both boxes produced absurdly high numbers, typically one or even two orders of magnitude beyond today’s levels.
As both boxes turned in excellent results, picking a winner was particularly tricky. "If we had to choose between the Laurel and Redback routers, we’d give the edge to Laurel’s ST200, while noting that good arguments can be made for either router," says Newman.

"Laurel’s product fared better in the baseline throughput and failover tests, and it scaled much higher in the Layer 3 MPLS VPN tests. For its part, Redback’s SmartEdge router did better in some baseline latency and routing scaleability tests (though not by meaningful margins on the latter, in our view)."

The most disappointing aspect of the test was that other players declined to participate. More than 20 were invited.

The absence of Cisco Systems Inc. (Nasdaq: CSCO) is understandable, according to Newman. Cisco is thought to have a new edge router in the pipeline, and its existing products probably wouldn't have stacked up well against Laurel's and Redback's.

The same cannot be said of the other market leader, Juniper Networks Inc. (Nasdaq: JNPR), according to Newman. Juniper had two strong candidates -- its own M40e and the ERX for which it bought Unisphere -- and yet it pulled out of the tests, having originally agreed to take part (prior to the Unisphere acquisition). Juniper cites lack of resources for its decision, but other reasons are suspected. "Clearly it was politics, not products, that prevented Juniper from putting its best foot forward," writes Newman in his report.

The focus of the test on high-end routers might explain why some vendors declined to participate, according to Giles Heron, principal network architect at PacketExchange Ltd., a service provider deploying Layer 2 MPLS VPNs in Europe. "The big cutoff point was the use of OC48 (2.5 Gbit/s) versus OC12 (622 Mbit/s) interfaces," writes Newman. "This did preclude some of the smaller folk like CoSine Communications Inc. (Nasdaq: COSN), but none of the bigger fish like Cisco, Juniper, Alcatel SA (NYSE: ALA; Paris: CGEP:PA), or Riverstone Networks Inc. (Nasdaq: RSTN)," he says. "None of the major players in this space have a legitimate beef on that point."

As noted, these tests were totally independent -- they were paid for by Light Reading. The importance of this was underscored in Testing Testing, a poll of readers taken earlier this year.

— Peter Heywood, Founding Editor, Light Reading
www.lightreading.com
Page 1 / 8   >   >>
Holy Grail 12/4/2012 | 9:13:04 PM
re: Laurel, Redback Score in Router Test
Tim

Most operators will probably have similar numbers of VPN customers per chassis as yourself, but this number is likley not so much a design goal, it just that most are running with Cisco PE devices and they cannot put any more customers than this on a single box. (They also probably won't ask the box to do anything other than support VPN customers, so the device is not exactly being used efficiently either!).

Problem is that whilst this is good news for Cisco(they sell more boxes), it's bad news for operator capex and opex, and profits. In today's ecomomic environment operators are looking at moving to more efficient and reliable edge devices, and ones that can walk, talk and chew gum without falling over.

They are also looking for devices that can stay in the network for longer (longer asset depreciation period) and generate more revenues over a longer period.

I think that the high numbers of VPN's achieved in this test shows:-

1) Opportunity to move to a more capex/opex efficient network architecture with significantly fewer devices to purchase and worry about.

2) Opportunity to purchase a device today that has a good chance of still being useful in 5-10 years. IP VPN's are popular and growing strongly.

3) Whoever wrote the routing code on the Laurel box sure knows routing and how to make it rock, these are kick ass numbers, I think Juniper managed 440000 customer VPN routes in the BT Exact tests, so Laurel at 2.18 Million is over 5 times Juniper and 3 times Redback.

I guess we know now why Level(3) bought Laurel!

Be interested to know what others think on the above.

Holy Grail.

photon_tim 12/4/2012 | 9:13:04 PM
re: Laurel, Redback Score in Router Test Hi all,

I am just curious whether a high scaling number for VPNs is really a big deal. In our network we have an average of approx. 40-60 VPNs per chassis.

We designed the network to not go beyond 200 VPNs per chassis. Just in case somebody drops his coke in the chassis and takes 1000s of customers out.

Is anybody actually putting more than a few hundred VPN customers on a single box? I am asking for design advice .. not scalability limitations of Vendor X or Y or C*.

Live long and prosper
photon_tim 12/4/2012 | 9:13:04 PM
re: Laurel, Redback Score in Router Test Hi Pierre,

at a very high level and omitting many details:

With a Layer3 VPN the Service provider takes the packet from a customer connection, strips of the layer 2 (Frame Relay/VLAN/ATM) header and routes the packet based on the IP-header. The most common way to do this is described in RFC2547bis. The advantage is that it is very scalable - or at least perceived to be very scalable. The disadvantage is that the end-customer actually needs to share its routing information with the Service provider.

A Layer2 VPN on the other hand .. takes a customer packet (e.g. Frame Relay) and forwards the packet including the Layer2 header. This means it can carry any protocol not just IP. The most common way is to use a control word (as defined in the Martini encapsulation drafts).
In its simplest form this is just a point-to-point tunnel.

edgecore 12/4/2012 | 9:13:04 PM
re: Laurel, Redback Score in Router Test
Can I ask someone to describe the difference?

Thanks,

-Pierre

Peter Heywood 12/4/2012 | 9:13:02 PM
re: Laurel, Redback Score in Router Test Layer 2 VPNs merely act like pipes in the same way that frame relay virtual connections do.

Layer 3 VPNs provide the equivalent of a router network - ie, they have virtual routers within them that read packets and forward them.

Check out Geoff Bennett's tutorial on the subject:

http://www.lightreading.com/do...

beetlejuice 12/4/2012 | 9:12:58 PM
re: Laurel, Redback Score in Router Test L3 works with fast MIM !
skeptic 12/4/2012 | 9:12:58 PM
re: Laurel, Redback Score in Router Test 3) Whoever wrote the routing code on the Laurel box sure knows routing and how to make it rock, these are kick ass numbers, I think Juniper managed 440000 customer VPN routes in the BT Exact tests, so Laurel at 2.18 Million is over 5 times Juniper and 3 times Redback.

================
But can they actually forward on the 2.18 million
number. The test isn't really clear that the
routes were forwardable. And their other
capacity numbers (BGP) suggest that they don't
have that much capacity in hardware.
photon_tim 12/4/2012 | 9:12:56 PM
re: Laurel, Redback Score in Router Test To Steve

You wrote:
"Packets were sent to all of the VPN routes during the test. All 2.18 million routes were stored in the ST200's hardware based FIB. Forwarding to each of the 2.18 million routes occurs at wire-speed (unless policing or rate limiting are enabled)."

- - - - -

Why will policing or rate limiting make a difference in a hardware/asic assisted forwarding architecture? Isn't that done in the Asic/FPGA/Custom IC?

Tim
sjvog 12/4/2012 | 9:12:56 PM
re: Laurel, Redback Score in Router Test But can they actually forward on the 2.18 million
number. The test isn't really clear that the
routes were forwardable. And their other
capacity numbers (BGP) suggest that they don't
have that much capacity in hardware.

===================

Yes, we can.

Packets were sent to all of the VPN routes during the test. All 2.18 million routes were stored in the ST200's hardware based FIB. Forwarding to each of the 2.18 million routes occurs at wire-speed (unless policing or rate limiting are enabled).

This is possible on the ST200 because of its distributed architecture. Unlike core routers that usually have a central FIB, the ST200 uses a distributed FIB. Since the Internet routing table is common across all interface it is replicated in the distributed FIBs. However, VPN routes are unique to each customer interface and are only stored in the FIB(s) used by interfaces on the particular VPN. So, for VPNs our distributed architecture increases the total number of routes supported in the FIB.

This is one of many architectural advantages that we incorporated into the ST200 design to optimize for PE applications.

Steve Vogelsang
jamesbond 12/4/2012 | 9:12:55 PM
re: Laurel, Redback Score in Router Test Steve Vogelsang:

However, VPN routes are unique to each customer interface and are only stored in the FIB(s) used by interfaces on the particular VPN.

------------------------------

Steve,

This is true if reasonably low number of VPN
customers are terminated on your interface. For
e.g. you have an ATM OC-48 interface, imagine
how many T1s can be terminated on that. And you
would need to support that many FIBs on that
line card.

Also I am not sure what you mean by distributed
v/s central FIBs. Are you telling us that
Juniper/Cisco routers don't have FIBs local to
line cards?
Page 1 / 8   >   >>
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE