Contributed by Paul Morgan
If you’re not sure which physical interface is eth0 and which is eth1 (or eth2), run:
ethtool -p eth0 5
This blinks the LED on the interface for five seconds–without interrupting network traffic.
Red Hat’s acclaimed training programs offer a lifetime of experience in a week’s worth of class instruction. And a good portion of the credit for that success goes to the Red Hat Certified Instructors that make a Red Hat training course something special. They have the best tips, and the trickiest tricks. So we thought we’d ask ‘em to share. The information provided in this article is for your information only. The origin of this information may be internal or external to Red Hat. While Red Hat attempts to verify the validity of this information before it is posted, Red Hat makes no express or implied claims to its validity.
This entry was posted by The editorial team
on Wednesday, September 5th, 2007 at 2:26 pm and is filed under tips and tricks.
You can follow any responses to this entry through the RSS 2.0 feed.
Both comments and pings are currently closed.
September 6th, 2007 at 3:29 am
tip: use peth0 if you’re running it on a Xen dom0
September 6th, 2007 at 7:43 am
Nice tip but what about when it doesn’t work? Any troubleshooting tips? I tried this on my Kubuntu machine, and even tho the ethtool is there and the flags are the same in the man pages, I still get errors:
lefty@lefty:~$ ifconfig
eth0 Link encap:Ethernet HWaddr XXXXXXX
inet addr:192.168.1.102 Bcast:192.168.1.255
Mask:255.255.255.0
…..
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
….
lefty@lefty:~$ sudo ethtool -p eth0 5
Password:
Cannot identify NIC: Operation not supported
lefty@lefty:~$
September 6th, 2007 at 9:46 am
It doesn’t work for me. What does ethtool look for?
Cannot identify NIC: Operation not supported
September 6th, 2007 at 10:04 am
What if my server is 3000 miles away? I’ll flash it all day long, but I still can’t see which card and port it is.
September 6th, 2007 at 10:13 am
lefty.crupps: Really? Shouldn’t you be looking for help at some, say, more (K)Ubuntu oriented site..?
Besides, the thingy works like a charm…
September 7th, 2007 at 6:18 am
On Fedora 7, this somewhat works for me – the LEDs stop shining at all. But then the man page says “initiates adapter-specific action” (Marvell 88E8001, skge), “Typically … involves blinking one or more LEDs on the specific ethernet port.”:))
Still, thanks, I never even considered such a functionality.
September 9th, 2007 at 4:14 am
Looks like it is supported only by the following drivers:
ewrk3
s2io
sky2
tg3
e100
pcnet32
bnx2
skge
e1000
sk98lin
ixgb
September 14th, 2007 at 11:53 pm
The same message as “mookie” appeared to me
September 18th, 2007 at 3:20 pm
Ahh, the lost art of reading the man page: “-p initiates adapter-specific action intended to enable an operator to easily identify the adapter by sight. Typically this involves blinking one or more LEDs on the specific ethernet port.”
The “adapter-specific” part is important. This only works for adapters/drivers that supply this functionality. Works great on a lot of server ethernet chipsets as Kir pointed out (and, it so happens, my Thinkpad), but not for everything.
September 19th, 2007 at 2:04 am
Another useful trick it to use “ethtool -i eth0″ – this gives you the PCI slot location of the card on the last line. You can then use “lspci -tv” to see where in the device hierarchy the card is. Usually the vendor hardware documentation will provide the information to map this to a physical location. This can then be written up in a procedure, or codified, to give to the hardware folks in the data-centre and will scale better than having an SA flashing lights which whilst useful for the odd task does not scale to data-centre wide remediations.
September 19th, 2007 at 7:12 am
AloneInAlaska wrote: “what if my server is 3000 miles away?”
Well in that case, it’s not really an issue, is it? You must be equipped with extremely long arms, if you’re going to attach a cable to the server or sth. similar at that distance
lol
September 19th, 2007 at 7:55 am
In some situations you can look at the hwconf file in /etc to see what adaptor is associated with what eth number. If you know you have an on-board NIC made by broadcom and added a Intel e1000 card later, you will see which is bonded to eth0 and which eth1.
September 19th, 2007 at 2:18 pm
Nice trick. I’ve always used mii-tool. It should give you an output like this:
[root@bart ~]# mii-tool
eth0: negotiated 100baseTx-HD, link ok
eth1: no link
Also using the -w option will watch the connection and report any status changes. Very useful for those trial-and-error days.
September 20th, 2007 at 10:10 am
dmesg | grep eth0
lspci
September 20th, 2007 at 4:41 pm
I am trying to install ORacle Cluster and try to find out which one is eth0 and eth1. But ethtool didn’t work. It returns folowing message.
How to resolve it ?
Cannot identify NIC: Operation not supported
September 21st, 2007 at 11:12 am
On my F7 box, it requires root privilege to execute, just as most if-related tasks to.
October 2nd, 2007 at 8:46 pm
Yes, well – the blink idea is a great first cust at the solution – but frankly, it’s a bit rudimentary to be truly useful in all caes.
Try using a link state trick, plug and replug your NICs into any layer 2 link – and use this script to iteratively identify them – run it from the console. Some guru can probably compact the code:
#!/bin/bash
while true; do
clear
ifconfig -s | grep -Ev “Iface|lo” | awk ‘{print “echo ” $1 “; ethtool ” $1 ” | grep Link”}’ | sh | awk ‘{print
$0 ” “}’ > /tmp/link.$$
cat /tmp/link.$$ | sed ’1,$s/Link detected://g’ | tr -d ‘\n’ | awk ‘
{
for (i=1; i
October 2nd, 2007 at 8:49 pm
Full script didn’t post, so here it is simplified:
ifconfig -s | grep -Ev “Iface|lo” | awk ‘{print “echo ” $1 “; ethtool ” $1 ” | grep Link”}’ | sh | awk ‘{print
$0 ” “}’
Put some variant of this snippet into a while; true do loop with a sleep at the end.
October 17th, 2007 at 3:49 pm
simply work with me that very nice