Loopback Interface speed is 10 Mbps but Incoming and Outgoing Traffic is in Gbps

Question

I am writing a script which mails interface data to network admin. For this I'm using LibreNMS and RRDTool to gather data. On inspecting one of the loopback interfaces, I found that the interface speed is 10 Mbps but the traffic speed is 1.67 Gbps. Can anyone explain how this works? Thanks.[

Answer 1

A loopback interface is a logical construct. It doesn't have any physical link speed.

Usually, a nominal link speed is indicated for table completeness only, especially when inspected using SNMP or similar protocols. The speed is often either the highest or the lowest link speed the device supports. That indicated speed bears no significance.

Answer 2

An answer from a slightly Cisco skewed perspective:

Here's a Loopback interface from a Nexus 3164Q, a L3 Switch with 64 QSFP 40G ports and a backplane rated for 5.12Tbit/sec. It has no QoS configurations nor any performance tuning or anything of that kind.

Looking at the output, one of its Loopback interface seems to have a bandwidth of a measly 8Mbit/s.

spine11# show int lo101
loopback101 is up
admin state is up,
  Hardware: Loopback
  Internet Address is 10.mm.nn.11/32
  MTU 1500 bytes, BW 8000000 Kbit, DLY 5000 usec
  reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation LOOPBACK, medium is broadcast
  Auto-mdix is turned off
    0 packets input 0 bytes
    0 multicast frames 0 compressed
    0 input errors 0 frame 0 overrun 0 fifo
    0 packets output 0 bytes 0 underruns
    0 output errors 0 collisions 0 fifo
    0 out_carrier_error

Generally, on Cisco devices, an interface's reported "bandwidth" does not relate to the achievable throughput with/through that interface.

The "bandwidth" parameter is cosmetic at first glance; it is configurable (even separately for receive/transmit), but it does not have a (direct) influence on traffic forwarding or performance.

However, other config items and services of the given switch or router pick up the given value and base their actions on it. Examples (there may be more...)

• Dynamic routing protocols such as OSPF and EIGRP use an interface's bandwidth to calculate the "cost" of a network path. Sometimes, we see network admins tuning the bandwidth parameter of an interface to adjust routing preferences (which is the wrong way to do it, becaus.. see the next statements)
• SNMP pollers and traffic graphers such as MRTG, PRTG, Solardwinds (and certainly LibreNMS, too) and many others use the value to have a reference of 100% utilization for the given interface. It is important to keep this in mind: A 100Mbit/s switch port will show a slight "green" load of 20% for 20Mbit/s traffic. At the same time, the 20Mbit/s WAN circuit connected there might actually be utterly congested, and should appear as glowing red hot in your traffic grapher...
• the value serves as upper limit in Cisco's concept of rxload/txload (see output of interface above). Probably less important today, but back in the days of ISDN, Multilink-PPP and dial-on-demand Routing, rxload/txload were important metrics to make a decision whether to add an ISDN channel or not.
• (perhaps most importantly and of actual impact of traffic flows) an interface's bandwidth parameter serves as the 100% reference for QoS configurations (scheduling, congestion management) of the given interface. QoS configurations can be based on relative values (like "10% LLQ+policing for voice, 1% WRED for bulk traffic, 5% tail-drop for signaling/control ...") instead of absolute values of Bit/sec; in such a case, a misconfigured bandwidth parameter can lead to things like 10% of 100Mbit/s instead of 10% of 1Gbit/s, and have detrimental effect on the applications.

You didn't state what platform you are working on. I presume that it does handle an interface's "bandwitdh" property in a similar fashion as Cisco devices do.