How to identify NICs that are connected to the same switch from a Linux box?

Question

Initial Setup

As a Linux administrator you have installed a fresh Linux box with 6 NICs eth0 to eth5. The eth0 interface is correctly configured and all other interfaces are currently up but without IP address. The network guys have simply attached four cables to this box. Two LAN cables are used to connect the box to the production network and two are used to connect the box to a private network. You only know that eth0 is connected to the production net. But you do not know which other NIC is connected to the same switch as there are different server generations and/or the network guys use the wrong NICs for their connections.

Task at hand

As this setup is typical for your infrastructure, you want to automate the configuration of bonding interfaces. Now you have the task to detect which NICs are not connected at all and which NICs are linked to the same switch so they may be bonded. You have only access to Linux boxes and cannot query the switches.

Ideas

Detecting the link status is easy:

ethtool $device | grep 'Link detected' | cut -d ':' -f 2

But how to match the devices that are connected to the same switch?

In HP-UX there is a tool for that purpose called linkloop [1]. The official Linux tool is missing (there is an old SourceForce project, though).

Possible solutions that already have come to my mind are:

1. Listen on all interfaces with tcpdump. Craft and send an ICMP (broadcast) packet. The interfaces that see that packet need to be connected to the same switch. -> need suggestions of simple tools that may be used for that. I would like to use plain shell commands or Python for the scripting.

2. Try to talk to an external box via some easy protocol (HTTP?) and see if there is a response. -> Error prone and dependent on an external box.

Do you have further ideas or suggestions how to solve this task?

Thank you in advance for all comments!

[1] http://linux.die.net/man/1/linkloop

Solution 1

The switches may already be sending you the information you want. If they are Cisco switches, by default they will be using a process called CDP (Cisco Discovery Protocol) which will provide you information about the switch where it is connected.

You can use tcpdump to view this information with the following (substituting the appropriate interface):

tcpdump -nn -v -i eth0 -s 1500 -c 1 'ether[20:2] == 0x2000'

The standard based version of CDP is LLDP (link layer discovery protocol). Some vendors will have this on by default and others off, so your mileage will vary. There are some LLDP implementations for Linux, but if you want something similar to the above you can use this (set up LLDP on a Cisco switch and tested the below, which is more consistent with above):

tcpdump -nn -v -i eth0 -s 1500 -c 1 'ether proto 0x88cc'

Barring that, I would say that a modification of option 1 you provide might work, however, instead of sending out a broadcast ICMP, you can try a normal ICMP (to a host not in the ARP table) and capture the ARP packets. If ARP request is sent out eth0 and you receive it on eth1 and eth3, then you know those are on the same VLAN. Simplest command for that is as follows:

tcpdump -i eth0 arp

Solution 2

If the switch will communicate with you using LLDP, you may be able to run LLDP and find more information there.

Solution 3

If the switches are cisco devices you could maybe get CDP info, provided they are announcing / broadcasting cdp info

eg cdp tools or cdpr

Solution 4

Why not just download and build the linkloop tool? It's not that old...

Otherwise, I would just use some tool that will broadcast over layer 2 and verify that you receive it via tcpdump.

Sending a broadcast ICMP packet is easy ping -b 192.168.1.255

View more solutions

Comments

[voretaq7]

This REALLY smells like homework -- Is this an actual problem you're facing in a production environment?

[Reiner Rottmann]

Real problem and an annoying one, I might add. I am out of school for a long time...

[voretaq7]

OK - the reason I ask is way you phrased the question reminded me of the style of one of my networking textbooks :-)

[Reiner Rottmann]

Actually I went with this solution and wrote a little python script that runs tcpdumps as threads in the background and then I send out arp requests and see which interface receives arp packages from which src mac. Works but with all the timeouts it takes some time.

[Hack Saw]

I just tried to do this, and it failed here in 2016 on Ubuntu 14, so YMMV.