In earlier versions 'mii-tool' would iterate over interfaces and show which have link up. In 6.x it wants an interface as a parameter. What is the appropriate way to find which of some number of of interfaces are connected? Better yet, what is the least typing to get the mac addresses of those interfaces?
Les Mikesell wrote:
In earlier versions 'mii-tool' would iterate over interfaces and show which have link up. In 6.x it wants an interface as a parameter. What is the appropriate way to find which of some number of of interfaces are connected? Better yet, what is the least typing to get the mac addresses of those interfaces?
ethtool, or even lshw.
mark
On Thu, Dec 15, 2011 at 2:56 PM, m.roth@5-cent.us wrote:
Les Mikesell wrote:
In earlier versions 'mii-tool' would iterate over interfaces and show which have link up. In 6.x it wants an interface as a parameter. What is the appropriate way to find which of some number of of interfaces are connected? Better yet, what is the least typing to get the mac addresses of those interfaces?
ethtool, or even lshw.
How do you make ethtool iterate over the available interfaces?
Les Mikesell wrote:
On Thu, Dec 15, 2011 at 2:56 PM, m.roth@5-cent.us wrote:
Les Mikesell wrote:
In earlier versions 'mii-tool' would iterate over interfaces and show which have link up. In 6.x it wants an interface as a parameter. What is the appropriate way to find which of some number of of interfaces are connected? Better yet, what is the least typing to get the mac addresses of those interfaces?
ethtool, or even lshw.
How do you make ethtool iterate over the available interfaces?
I suppose that would be a script. lshw - which is clearer than just dmidecode, would do it.
Dumb question: in /etc/sysconfig/network-scripts, do the ifcfg-* have HWADDRs?
mark
On Thu, Dec 15, 2011 at 3:39 PM, m.roth@5-cent.us wrote:
In earlier versions 'mii-tool' would iterate over interfaces and show which have link up. In 6.x it wants an interface as a parameter. What is the appropriate way to find which of some number of of interfaces are connected? Better yet, what is the least typing to get the mac addresses of those interfaces?
ethtool, or even lshw.
How do you make ethtool iterate over the available interfaces?
I suppose that would be a script. lshw - which is clearer than just dmidecode, would do it.
Dumb question: in /etc/sysconfig/network-scripts, do the ifcfg-* have HWADDRs?
They do, but the case I want to cover is where an existing server is cloned, or the disk has been moved from a failed chassis to a spare. And in this case the existing files will be wrong, and the nics will be named more or less randomly. Assume the hands-on operators don't know much about linux and you can't actively help until they get at least one of the right IP's on the right NIC.
With 5.x I'd use mii-tool to find the connected interface (connecting one wire at a time if necessary), then ifconfig on that interface to get the hwaddr, then edit that into the ifcfg-* file for the names I want the active NICs to have, and reboot. That's awkward enough to ask someone to do who already prefers windows, and it looks like it just got harder by having to explicitly run mii-tool for each possible interface (and we always have 4 to 6 per box). There has to be a better way. I thought 6.1 was going to have a new NIC name convention but I haven't had time to look into it and have to make something work now.
On Thursday 15 December 2011 16:04:35 Les Mikesell wrote:
On Thu, Dec 15, 2011 at 3:39 PM, m.roth@5-cent.us wrote:
In earlier versions 'mii-tool' would iterate over interfaces and show which have link up. In 6.x it wants an interface as a parameter. What is the appropriate way to find which of some number of of interfaces are connected? Better yet, what is the least typing to get the mac addresses of those interfaces?
Dumb question: in /etc/sysconfig/network-scripts, do the ifcfg-* have HWADDRs?
They do, but the case I want to cover is where an existing server is cloned, or the disk has been moved from a failed chassis to a spare. And in this case the existing files will be wrong, and the nics will be named more or less randomly. Assume the hands-on operators don't know much about linux and you can't actively help until they get at least one of the right IP's on the right NIC.
With 5.x I'd use mii-tool to find the connected interface (connecting one wire at a time if necessary), then ifconfig on that interface to get the hwaddr, then edit that into the ifcfg-* file for the names I want the active NICs to have, and reboot. That's awkward enough to ask someone to do who already prefers windows, and it looks like it just got harder by having to explicitly run mii-tool for each possible interface (and we always have 4 to 6 per box). There has to be a better way. I thought 6.1 was going to have a new NIC name convention but I haven't had time to look into it and have to make something work now.
Your situation is the "textbook usecase" example for biosdevname (http://linux.dell.com/biosdevname). It is a way to consistently name the network devices according to their physical location in a computer. For example, a typical NIC would not have a name "eth1", but "p2p3" (which means "port 3 of the NIC in PCI slot 2") or "em2" (which is "2nd ethernet port on the motherboard"). So once the hands-on operator plugs a cable into a particular port, you immediately know the corresponding interface name that the system will use for that connection. And in addition, this is MAC-address independent, so moving the hard drive from one box to the other requires basically no reconfiguration (as long as the operator plugs the same cables into the same sockets).
The biosdevname was first introduced in Fedora 15 (http://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming), ie. only after RHEL 6 was already rolled out. Apparently, it has to cooperate intimately with the kernel, udev, initscripts, dracut, anaconda, kickstart, etc., --- so it is not just a userland app which one could yum install in a trivial way.
Therefore, somehow I doubt that CentOS 6 will ever see biosdevname implemented (maybe in the CentOSplus kernel and a "use at your own risk" label?), since it involves too many system changes and breaks backward compatibility. But RHEL 7 is almost certainly going to have it, since this is actually the proper (and permanent) solution to the problem you have.
HTH, :-) Marko
On Fri, Dec 16, 2011 at 11:23 AM, Marko Vojinovic vvmarko@gmail.com wrote:
On Thursday 15 December 2011 16:04:35 Les Mikesell wrote:
On Thu, Dec 15, 2011 at 3:39 PM, m.roth@5-cent.us wrote:
In earlier versions 'mii-tool' would iterate over interfaces and show which have link up. In 6.x it wants an interface as a parameter. What is the appropriate way to find which of some number of of interfaces are connected? Better yet, what is the least typing to get the mac addresses of those interfaces?
Dumb question: in /etc/sysconfig/network-scripts, do the ifcfg-* have HWADDRs?
They do, but the case I want to cover is where an existing server is cloned, or the disk has been moved from a failed chassis to a spare. And in this case the existing files will be wrong, and the nics will be named more or less randomly. Assume the hands-on operators don't know much about linux and you can't actively help until they get at least one of the right IP's on the right NIC.
With 5.x I'd use mii-tool to find the connected interface (connecting one wire at a time if necessary), then ifconfig on that interface to get the hwaddr, then edit that into the ifcfg-* file for the names I want the active NICs to have, and reboot. That's awkward enough to ask someone to do who already prefers windows, and it looks like it just got harder by having to explicitly run mii-tool for each possible interface (and we always have 4 to 6 per box). There has to be a better way. I thought 6.1 was going to have a new NIC name convention but I haven't had time to look into it and have to make something work now.
Your situation is the "textbook usecase" example for biosdevname (http://linux.dell.com/biosdevname). It is a way to consistently name the network devices according to their physical location in a computer. For example, a typical NIC would not have a name "eth1", but "p2p3" (which means "port 3 of the NIC in PCI slot 2") or "em2" (which is "2nd ethernet port on the motherboard"). So once the hands-on operator plugs a cable into a particular port, you immediately know the corresponding interface name that the system will use for that connection. And in addition, this is MAC-address independent, so moving the hard drive from one box to the other requires basically no reconfiguration (as long as the operator plugs the same cables into the same sockets).
The biosdevname was first introduced in Fedora 15 (http://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming), ie. only after RHEL 6 was already rolled out. Apparently, it has to cooperate intimately with the kernel, udev, initscripts, dracut, anaconda, kickstart, etc., --- so it is not just a userland app which one could yum install in a trivial way.
Therefore, somehow I doubt that CentOS 6 will ever see biosdevname implemented (maybe in the CentOSplus kernel and a "use at your own risk" label?), since it involves too many system changes and breaks backward compatibility. But RHEL 7 is almost certainly going to have it, since this is actually the proper (and permanent) solution to the problem you have.
I thought I saw it mentioned in release notes for RHEL 6.1 but it said something about support being limited to certain Dell models. I'm not sure it is going to be perfect anyway, since most of the machines in question have Broadcom NICs on the motherboards and the ones we actually use are on Intel cards that may not exactly match types or slot positions. But I'd settle for something that had something to do with the slot position...
On 12/17/2011 05:33 AM, Les Mikesell wrote:
On Fri, Dec 16, 2011 at 11:23 AM, Marko Vojinovicvvmarko@gmail.com wrote:
On Thursday 15 December 2011 16:04:35 Les Mikesell wrote:
On Thu, Dec 15, 2011 at 3:39 PM,m.roth@5-cent.us wrote:
> In earlier versions 'mii-tool' would iterate over interfaces and > show > which have link up. In 6.x it wants an interface as a parameter. > What is the appropriate way to find which of some number of of > interfaces are connected? Better yet, what is the least typing > to > get the mac addresses of those interfaces?
Dumb question: in /etc/sysconfig/network-scripts, do the ifcfg-* have HWADDRs?
They do, but the case I want to cover is where an existing server is cloned, or the disk has been moved from a failed chassis to a spare. And in this case the existing files will be wrong, and the nics will be named more or less randomly. Assume the hands-on operators don't know much about linux and you can't actively help until they get at least one of the right IP's on the right NIC.
With 5.x I'd use mii-tool to find the connected interface (connecting one wire at a time if necessary), then ifconfig on that interface to get the hwaddr, then edit that into the ifcfg-* file for the names I want the active NICs to have, and reboot. That's awkward enough to ask someone to do who already prefers windows, and it looks like it just got harder by having to explicitly run mii-tool for each possible interface (and we always have 4 to 6 per box). There has to be a better way. I thought 6.1 was going to have a new NIC name convention but I haven't had time to look into it and have to make something work now.
Your situation is the "textbook usecase" example for biosdevname (http://linux.dell.com/biosdevname). It is a way to consistently name the network devices according to their physical location in a computer. For example, a typical NIC would not have a name "eth1", but "p2p3" (which means "port 3 of the NIC in PCI slot 2") or "em2" (which is "2nd ethernet port on the motherboard"). So once the hands-on operator plugs a cable into a particular port, you immediately know the corresponding interface name that the system will use for that connection. And in addition, this is MAC-address independent, so moving the hard drive from one box to the other requires basically no reconfiguration (as long as the operator plugs the same cables into the same sockets).
The biosdevname was first introduced in Fedora 15 (http://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming), ie. only after RHEL 6 was already rolled out. Apparently, it has to cooperate intimately with the kernel, udev, initscripts, dracut, anaconda, kickstart, etc., --- so it is not just a userland app which one could yum install in a trivial way.
Therefore, somehow I doubt that CentOS 6 will ever see biosdevname implemented (maybe in the CentOSplus kernel and a "use at your own risk" label?), since it involves too many system changes and breaks backward compatibility. But RHEL 7 is almost certainly going to have it, since this is actually the proper (and permanent) solution to the problem you have.
I thought I saw it mentioned in release notes for RHEL 6.1 but it said something about support being limited to certain Dell models. I'm not sure it is going to be perfect anyway, since most of the machines in question have Broadcom NICs on the motherboards and the ones we actually use are on Intel cards that may not exactly match types or slot positions. But I'd settle for something that had something to do with the slot position...
http://www.pkje.net/meander/?p=115 - this may help on the device ordering for 6.x if you know the mac addresses then you can fix the names of the interfaces
On Sun, Dec 18, 2011 at 6:18 PM, Philip Manuel phil@zomojo.com wrote:
I thought I saw it mentioned in release notes for RHEL 6.1 but it said something about support being limited to certain Dell models. I'm not sure it is going to be perfect anyway, since most of the machines in question have Broadcom NICs on the motherboards and the ones we actually use are on Intel cards that may not exactly match types or slot positions. But I'd settle for something that had something to do with the slot position...
http://www.pkje.net/meander/?p=115 - this may help on the device ordering for 6.x if you know the mac addresses then you can fix the names of the interfaces
The scenario I really want to handle is sending a disk or clonezilla image to meet up with a new chassis in a remote location, minimizing anything the remote operators have to know/do to get it to a point where it is up on the network.
>> which have link up. In 6.x it wants an interface as a parameter. >> What is the appropriate way to find which of some number of of >> interfaces are connected? Better yet, what is the least typing >> to >> get the mac addresses of those interfaces?
Dumb question: in /etc/sysconfig/network-scripts, do the ifcfg-* have HWADDRs?
biosdevname is in RHEL 6.1 and thus is in CentOS 6.1 but is only enabled by default for certain pieces of Dell hardware that could gain the most benefit from it. If you are running 6.1 and want to force biosdevname to be used, you can pass biosdevname=1 on the kernel line in the grub config, but don't plan on switching between the two. For those with paid RHN access, this is explained further in https://access.redhat.com/kb/docs/DOC-53612
Barry
Am 15.12.2011 22:13, schrieb Les Mikesell:
On Thu, Dec 15, 2011 at 2:56 PM, m.roth@5-cent.us wrote:
Les Mikesell wrote:
In earlier versions 'mii-tool' would iterate over interfaces and show which have link up. In 6.x it wants an interface as a parameter. What is the appropriate way to find which of some number of of interfaces are connected? Better yet, what is the least typing to get the mac addresses of those interfaces?
ethtool, or even lshw.
How do you make ethtool iterate over the available interfaces?
How about following?
for i in /sys/class/net/eth*; do echo "${i##*/}: " cat $i/{carrier,address} done
Alexander
On 12/15/2011 12:45 PM, Les Mikesell wrote:
In earlier versions 'mii-tool' would iterate over interfaces and show which have link up. In 6.x it wants an interface as a parameter. What is the appropriate way to find which of some number of of interfaces are connected? Better yet, what is the least typing to get the mac addresses of those interfaces
/sbin/ip link ls
On Thu, Dec 15, 2011 at 4:03 PM, Benjamin Franz jfranz@freerun.com wrote:
On 12/15/2011 12:45 PM, Les Mikesell wrote:
In earlier versions 'mii-tool' would iterate over interfaces and show which have link up. In 6.x it wants an interface as a parameter. What is the appropriate way to find which of some number of of interfaces are connected? Better yet, what is the least typing to get the mac addresses of those interfaces
/sbin/ip link ls
That looks promising. And '/sbin/ip addr' shows both the state and the mac address - even better.
On Dec 15, 2011, at 3:45 PM, Les Mikesell lesmikesell@gmail.com wrote:
In earlier versions 'mii-tool' would iterate over interfaces and show which have link up. In 6.x it wants an interface as a parameter. What is the appropriate way to find which of some number of of interfaces are connected? Better yet, what is the least typing to get the mac addresses of those interfaces?
In 5 an 'ifconfig' without parameters would only list up interfaces and one would have to do an 'ifconfig -a' to see all interfaces. Maybe still true in 6?
-Ross
On Thu, Dec 15, 2011 at 5:16 PM, Ross Walker rswwalker@gmail.com wrote:
In earlier versions 'mii-tool' would iterate over interfaces and show which have link up. In 6.x it wants an interface as a parameter. What is the appropriate way to find which of some number of of interfaces are connected? Better yet, what is the least typing to get the mac addresses of those interfaces?
In 5 an 'ifconfig' without parameters would only list up interfaces and one would have to do an 'ifconfig -a' to see all interfaces. Maybe still true in 6?
That's not just 'link up' though. Those are ones that are 'administratively up' with an address assigned. That would be the same set with the default configuration and DHCP service available on all subnets, but we don't have that.
-
Alexander Dalloz -
Barry Brimer -
Benjamin Franz -
Les Mikesell -
m.roth＠5-cent.us -
Marko Vojinovic -
Philip Manuel -
Ross Walker