x
Optical/IP Networks

Internet Core Router Test

Core router vendors claim their boxes are the building blocks of the next-generation Net. That made our task easy: All we had to do was build a testbed that simulated the conditions likely to be found out there in Tomorrowland. Any box that didn’t melt down or spontaneously combust was probably up to the challenge.

So with fire extinguishers at the ready, we sketched out a few guiding principles:

  • Everyone knows the Internet, which now comprises some 96,000 networks, is only going to get bigger. So we decided to test with routing tables that represent more than 200,000 nets. Then we did a few back-of-the-envelope calculations and realized that at its current growth rate, the Net could readily double in size in 18 to 24 months. So we ripped up the envelope and extended the routing tables used in some tests beyond 2 million networks — more than 25 times the number core routers currently contend with.

  • Size isn’t everything, of course. To make sure we didn’t slight the speed freaks out there, we blasted those new OC192 (10-Gbit/s) interfaces from Cisco and Juniper with more than 270 million packets per second (pps).

  • Performance problems? MPLS (multiprotocol label switching) is supposed to make them a thing of the past by letting service providers set up “tunnels” across their networks. When we weren’t ramping up router tables or pumping packets, we’d have to dig into the behavior of this Layer 2 technology.

    At this point, any sane test team would have started looking for work in the service industry. Instead, we cranked up the espresso maker and got ready to build a testbed — or, as it turned out, to build two.

  • Previous Page
    2 of 15
    Next Page
    Page 1 / 44   >   >>
    gereizt 12/5/2012 | 3:17:16 PM
    re: Internet Core Router Test Goto any looking glass and show the ip routing table. As for ACL rules, forget about it. You are asking someone to show you the addresses they allow and block and what, how and why. You aren't going to get it from a major provider and shouldn't get it from anyone with any kind of security sense.

    Tony Li 12/5/2012 | 1:21:24 AM
    re: Internet Core Router Test In fact, both matter, but the packets/sec is harder to achieve. Consider that for each packet, a router has to perform an IP lookup, make a switching decision and get the packet to the correct output interface with the correct encapsulation.

    The amount of work is the same regardless of the size of the packet. This leads some manufacturers to skimp on the processing power for packet processing, so they will underperform when tested with small packets. With large packets, the packet processing rate is lower, so it's simply a matter of bandwidth. Most players get that right, or come arbitrarily close.

    Tony
    rsunkara 12/5/2012 | 1:21:24 AM
    re: Internet Core Router Test Hi,

    I am interested in knowing why the router performance is measured in packets/sec and not bits/sec??

    Thanks
    bgopi 12/5/2012 | 12:57:39 AM
    re: Internet Core Router Test Hi,

    Is there any place where i can get the typical core router' routing table dump and the ACL rules dump of the same?

    Can someone help me in this regard.

    Please mail me at [email protected]
    Thanks
    Gopi
    Mathew Orman 12/5/2012 | 12:19:04 AM
    re: Internet Core Router Test http://www.ultra-faster-than-l...
    Mathew Orman 12/5/2012 | 12:19:04 AM
    re: Internet Core Router Test http://www.ultra-faster-than-l...
    Chughster 12/4/2012 | 11:22:58 PM
    re: Internet Core Router Test Can some one explain the possible causes of the following trend:

    With NAT enabled throughput for larger sized packets is lower than the throughput for smaller sized packets. That is, Packet streams with 64 byte size packets have a higher throughput compared to packets with 1500 byte size packets. The media is Fast ethernet. I am not sure if this is related to NAT in any way or if it is just an inherent switching performance any general router. Anyone with packet-switching knowledge please comment. The router is of VXR(NPE400). The MTU size is standard 1500 bytes for the interfaces.

    What could be a logical explanation of this trend?

    Janus Chu
    metrodude 12/4/2012 | 11:03:20 PM
    re: Internet Core Router Test Hello David,

    A would like to suggest/request from Network Test
    and LR for any future testing scenario's that
    you please revisit the methodologies, tools if required, Etc..

    Have you looked at what a Spirent "Smartbits" unit
    actually puts on the wire with a protocol analyzer ? It does some things that may effect
    the validity of what your trying to accomplish.

    What is your criteria for selecting test equipment?

    How about very detailed representation in the tests and criteria that is defined by standards to acomplish these.

    Spreadsheet format. With nothing to guess at, or missing from the equation.

    You will find that not all test equipment is created equal.


    jit 12/4/2012 | 10:59:20 PM
    re: Internet Core Router Test I know this isn't a multicast thread, but does anyone know if Juniper really supports dvmrp. I think Cisco refuses to and Juniper says they do, but I wonder if there are any real dvmrp networks out there. I couldn't see that tested here. Maybe there should be a multicast test given the growing use.
    skeptic 12/4/2012 | 10:59:19 PM
    re: Internet Core Router Test I know this isn't a multicast thread, but does anyone know if Juniper really supports dvmrp. I think Cisco refuses to and Juniper says they do, but I wonder if there are any real dvmrp networks out there. I couldn't see that tested here. Maybe there should be a multicast test given the growing use.
    ------------------

    If there was a multicast test, it should be on
    PIM sparse-mode rather than DVMRP or anything
    else.

    I think cisco supports some sort of DVMRP
    "interoprability mode". Juniper I think support
    more, but I've never used multicast on a
    juniper system. But (its an old story) just
    because a vendor claims to have something is
    no reason to trust that they really have it or
    that it works (especially in the case of multicast).
    Page 1 / 44   >   >>
    HOME
    Sign In
    SEARCH
    CLOSE
    MORE
    CLOSE