Fluke devices.

My colleagues were kind enough to let me borrow a Fluke Linkrunner Pro and a Fluke Service Provider Assistant for the weekend , to let me get familiar with them. Since this kind of gear is unaffordable for a home lab, I took the opportunity to do some tests on my equipment.

The Linkrunner Pro (left on the picture) can provide several details about a network connection. It shows the cable length of any Ethernet cable you connect it to, even if that cable isn’t connected on the other end! It also indicates when one or more of the eight internal wires are damaged, and detects PoE, again telling what is delivered through which wire.
Some initial tests indicated the wire from my lab to my ISP uplink is 28 meters, my 3560 uses PoE mode A, and a 4 meter long cable I patched myself had one disconnected pair.

The Service Provider Assistant can be connected both by Ethernet and an SPF module for fiber connections. It can do ping, tracert, perform jitter tests, and in combination with the Linkrunner Pro it can do a throughput test. This is a useful test: you connect the Linkrunner on one end, give it an IP and set it to ‘reflect’, and on the other end of the network, you connect the SP Assistant and let it generate traffic to the Linkrunner’s IP, up to 1 Gbps.

First thing I wanted to know was whether my 2970 switch could really reach gigabit speeds. I connected both devices to the switch, gave them an IP in the same subnet, and started a throughput test. I let it run for 10 minutes because the switch only shows average throughput over 5 minutes. I did several tests, using different ports, and each time ended up with an effective throughput of 980-985 Mbps, using an MTU of 1518. Not exactly one gigabit, but 98.5% is close enough. I also monitored CPU during the test, which averaged at 4%, about the same when completely idle, proving that switching is done in hardware on the device.

Next, I connected the devices on the 3560 switch in different subnets, with the 3560 providing the routing using SVIs. Strangely, the Service Provider Assistant was recognized as an unsupported class 7 PoE device, and after a second automatic negotiation received class 0 PoE power, 15.4 Watt. The device did not charge from it however, and contrary to the Linkrunner Pro it doesn’t have any PoE diagnostics, leaving me in the dark about the meaning of it. Most likely it needs an 802.3at capable PoE device to be able to charge. (If you’re not following the PoE talk, I’ve explained things here.)
The 3560 has 100 Mbps ports, and the throughput test between two ports in different VLANs (and subnets) gave a result of 97 Mbps. CPU idled at 5%, because routing is done in hardware using Cisco Express Forwarding or CEF, a multi-layer switching technology. However, when forcing the routing to software with the ‘no ip route-cache’ command on the SVIs, things changed slightly. Throughput was still 97 Mbps, but the CPU went up to 8%, with a few peaks that weren’t there before. That 3% difference isn’t much, but I’m just congesting two ports. Following this logic, 24 ports routed in software at 100 Mbps should use about 40% CPU, and 48 ports 75% CPU, not including other processes such as routing protocols, spanning-tree, access-lists,… This makes clear that routing in hardware can really make a difference by increasing switch stability.

Finally, I also tested frames with 64 bytes of payload instead of the MTU of 1518. While supposedly this takes a higher toll on the switch’s resources compared to large frames, I didn’t note any differences in my simple tests.