Linux Identifying ~ Which NIC Is Which – Which NIC is eth0?

by on January 17, 2008 · 11 comments· LAST UPDATED January 17, 2008

in , ,

From my mailbag the other day I received an interesting question about network interface:

I've 4 network card installed in my server and I need to find out which NIC is which? How do I tell which physical card is eth0 and which one is eth1 and so on using command line options? If my server is 5000 miles away, how do I tell which NIC is eth0 w/o interrupting network traffic?

I've got some thoughts on this myself such as:
[a] use ping command - Easy to use

[b] udev persistent-net rules - See /etc/udev/rules.d/*persistent-net.rules

[c] ethtool -p eth0 5 - It will 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. But, it will not work with all drivers

Anyway, I thought that it would be interesting to throw this to you the reader to comment on.

TwitterFacebookGoogle+PDF versionFound an error/typo on this page? Help us!

{ 11 comments… read them below or add one }

1 Reo Strong January 17, 2008 at 2:49 pm

The only way that I’ve found is using ifup and ifdown and just unplugging the cables to see which one works/fails under the right circumstances.

If you know the MAC addresses, you can simply do it with ifconfig. Unfortunately, I’ve never thought far enough ahead to annotate the MACs when I’m building the server.

Reply

2 xiao_haozi January 17, 2008 at 4:23 pm

Well off the top head, if you have physical access and can afford to have it offline for a few moments, you could use ifconfig and list all of the interfaces, take them all down, and one by one turn them on and ping and see which card’s transfer light flashes. Crude, I know.

Reply

3 mastrboy January 17, 2008 at 5:59 pm

by my experience, if you know which the physical NIC is, then it’s easy to identify in linux (atleast in a tower cabinet)

Let me elaborate with a picture:
http://img178.imageshack.us/my.php?image=prtmb9bnt7.jpg

though this may not always be the case…

Reply

4 tomdeb January 18, 2008 at 9:28 am

I use tcpdump on each interface to see which one sees any broadcast or arp requests.

Reply

5 nixCraft January 18, 2008 at 9:45 am

@Reo, we need to find out w/o interrupting network traffic

@tomdeb, good suggestion

Appreciate all of your posts.

Reply

6 Bob Weber January 19, 2008 at 8:19 pm

masterboy,

Don’t think that always works. I’ve noticed eth assignments will change with different kernel builds. For example, my recent upgrade from Slackware 10.2 to Slackware 12 resulted in my eth numbers being re-assigned, I had to change my iptables configurations to get everything working again.

I’ve never understood why this is, if anyone has an explaination I would be interested to hear it.

Reply

7 nixCraft January 19, 2008 at 8:37 pm

Bob,

Look at udev configuration file. I’ve also documented my RHEL / CentOS experience here

HTH

Reply

8 rowell January 29, 2009 at 9:55 am

the ethtool commande helped me..

Reply

9 bic September 26, 2009 at 6:25 am

Well, this is pretty obvious. If you have network connectivity to a machine 5000 miles away, you have network access. Just assign addresses to you your interfaces, if you haven’t done so already and then from eth0 ping your home server with ten packets. Next, ping your home server from eth1 on the remote machine twenty times. From eth2, thirty times. etc.

It would solve the question, right?

Reply

10 bic September 26, 2009 at 6:27 am

In that way you can identify which network the external interface you just pinged from routes traffic through.

Reply

11 zhchen August 20, 2013 at 10:00 am

`ethtool -p ethx` just blink the data led, which is not easy to identify (yellow led, also blink in normal time), so turn off all leds or blink the link led(the green one) is a better way.
here is a simple script
t=ethx; ethtool -i $t; while true; do ifconfig $t down; sleep 4; ifconfig $t up; done

Reply

Leave a Comment

Previous post:

Next post: