LANforge RFC Support
LANforge is an extremely flexible tool. It's support of specific RFCs
is documented below, but LANforge can do much more. If you have a question
about a feature you would like to have supported, contact Candela Technologies
and we will be happy to give you any details you require.
RFC 2544: Benchmarking Methodology
RFC 2544 specifies the goals that
Network Equipment test sets should aspire to meet. As the authors note, it is unlikely
that any given piece of test equipment can meet all of the goals at once. Below you
will find some information about how LANforge supports (or does not support) each
bullet item in the RFC. Some sections pertain more to the users of the system or the
Device Under Test (DUT), and they have been left out of this comparison.
- Section 6: Test setup
This section envisions a piece of test equipment that has both sending
and receiving ports, and a way to verify sent traffic matches received
traffic. LANforge supports this by providing 32-bit Checksum support for
packets it generates. It also calculates dropped packets based on gaps in
sequence numbers and the difference between the number of packets sent
by one side of the system and the number received by the other.
- Section 6.1: Multiple Media types
LANforge supports 10/100/1000 and 10G ethernet, both copper and fibre
interfaces. It also supports 802.11a/b/g wireless ethernet,
802.1q VLANs, PPP-over-T1 and Token-Ring. For ATM (MPOA) or other interface support,
please contact Candela Technologies.
- Section 8: Frame Formats
LANforge offers a wide choice of frame formats and protocols, including
Custom ethernet frames, UDP/IP, TCP/IP, HTTP, HTTPS (SSL), VOIP (SIP, RTP),
and FTP. These protocols are stateful, in that LANforge is generating the
traffic using the standard API and stacks for the host OS. LANforge also has
a graphical protocol builder for Ethernet, TCP and UDP packets, and the user
can always specify their own packet if desired. LANforge supports command
line Linux tools such as ping and traceroute for added flexibility.
- Section 9: Frame Sizes
LANforge supports frame sizes from 64 bytes to the MTU of the underlying
device (typically 1514 (1518 counting CRC) for Ethernet, and up
to 9k for GigE). LANforge
can also be configured to generate frames of a random size.
- Section 9.1, 9.2: See above, all valid frame sizes are supported.
- Section 9.3: FDDI not supported at this time.
- Section 9.4: Disparate MTUs.
LANforge supports MTUs of different sizes on different interfaces
with no problem.
- Section 10.0: Verify received frames.
LANforge will detect LANforge packets sent to the wrong interface, but
it will not mark errors for non-LANforge packets received on the wrong
ports. However, by looking at the packet-received counters on the interfaces,
or by using the built-in Wireshark packet sniffer, a clever tester can
deduce mis-directed packets.
- Section 11.1: Broadcast frames.
LANforge can be configured to send out broadcast frames at any rate
the user desires. Normal ARP packets will be sent by the OS as needed.
- Section 11.2: Management frames.
LANforge has a Command Line Interface (CLI) that can be scripted. In
this manner, LANforge can easily be integrated with a tool such as
snmptalk or snmpwalk (which can be installed on a LANforge machine)
to generate appropriate management data. Candela Technologies can
provide help with designing and implementing scripts to suit customer's
specific needs.
- Section 11.3: Routing update frames.
LANforge uses subnet based routing and does not generate routing update frames
in normal use. It also supports an advanced 'Virtual Routing' setup that
allows the user to create virtual OSPF routers. These routers negotiate with
themselves and can also speak OSPF to external routers.
- Section 12: Protocol addresses.
Using LANforge's scripting capabilities, it is easy to generate traffic against
an arbitrary amount of protocol ports and addresses. The Armageddon LANforge
feature allows line-speed packet generation with fixed or randomized source
and destinations addresses.
- Section 14: Bi-directional traffic.
LANforge generates bi-directional traffic, and each flow can be adjusted individually
to simulate virtually any real-world condition.
- Section 15, 16: Single stream path, multi-stream path.
LANforge supports and coordinates testing of multiple endpoints, including
many-to-one, one-to-one, and one-to-many.
- Section 17, 18: Multiple protocols, multiple frame sizes.
LANforge supports Ethernet, UDP/IP, TCP/IP, HTTP, HTTPS (SSL), GOPHER, TELNET,
VoIP (SIP, RTP, RTCP), FTP, and other protocols like
ping (ICMP). It can generate this traffic in any combination, and with any frame
size supported by the underlying protocols and hardware. If you are interested in
a particular protocol not listed here, contact Candela Technologies.
- Section 19: Testing beyond a single Device Under Test (DUT).
LANforge is very flexible and can test and coordinate results for any
number of DUTs.
- Section 20: Maximum frame rate.
LANforge can now generate and receive line speed traffic (97 Mbps) on 100 Mbps networks,
and 999 Mbps on Gigabit Ethernet interfaces. On 100bt, it can
generate more than 140,000 packets per second, and more than 600,000 packets
per second on gigabit ethernet. With 10G ethernet, maximum rate is about 9.99 Gbps
transmit and receive on two ports on a single machine. For the same machine a transmit
and receive packet rate of over 1.17 million packets per second is attainable. Further benchmarks
can be done if you have specific needs not mentioned here.
- Section 21: Bursty traffic.
LANforge supports bursty traffic rates.
- Section 25: Address Resolution (ARP).
LANforge supports ARP protocols as part of the standard Linux and/or Windows
networking stacks.
- Section 26: Benchmarking.
LANforge can be used for benchmarking, both by generating line speed UDP/IP traffic
with the Armageddon feature, and by generating more real-world traffic patterns
with the standard LANforge feature set.
LANforge can report throughput (Mbps), latency (miliseconds & micro-seconds),
and frame-loss-rate. It can also be used to test system recovery, both under
external load, and with more passive means such as tcp connections.