# Re-numbering network interfaces



## joeso (Oct 19, 2011)

Is it possible to re-number network interfaces in FreeBSD 8.2?  I am setting up a firewall on a HP DL360 G7 server with two quad-Ethernet cards and the problem is that the enumeration of the network interfaces is a bit backwards physically.  Here is what the Ethernet ports look like from left to right on the back of the server:



```
|----| |----| |----| |----| |----| |----| |----| |----|
|igb4| |igb5| |igb6| |igb7| |igb0| |igb1| |igb2| |igb3| 
|----| |----| |----| |----| |----| |----| |----| |----|
```

Here is what I would like to change it to so it is a bit more logical:


```
|----| |----| |----| |----| |----| |----| |----| |----|
|igb0| |igb1| |igb2| |igb3| |igb4| |igb5| |igb6| |igb7| 
|----| |----| |----| |----| |----| |----| |----| |----|
```

I know this is possible in OpenSUSE 11.4 by editing /etc/udev/rules.d/70-persistent-net.rules and in Solaris 10 by editing /etc/path_to_inst but I can't seem to find the equivalent in FreeBSD.  I tried playing around with /boot/device.hints and it ended up creating 8 higher-numbered (igb7-14) interfaces instead.  I also tried re-naming all the devices in /etc/rc.conf with 
	
	



```
ifconfig_igb0_name=eth0
```
 but that doesn't seem to work quite right either.


----------



## SirDice (Oct 19, 2011)

joeso said:
			
		

> I also tried re-naming all the devices in /etc/rc.conf with
> 
> 
> 
> ...


That would be my suggestion.


> but that doesn't seem to work quite right either.


Why not?


----------



## mix_room (Oct 19, 2011)

joeso said:
			
		

> I tried playing around with /boot/device.hints and it ended up creating 8 higher-numbered (igb7-14) interfaces instead.



Did it also create the low numbered interfaces? Perhaps the spaces are being occupied before you have a chance to get into /boot/device.hints. 
Have you tried unloading the driver from the kernel and then manually loading it afterwards. Not a pretty solution, but it might work.


----------



## geodni (Oct 19, 2011)

Hi,

May I suggest using double quotes for value ?

```
ifconfig_igb0_name="eth0"
```
Or try manually and check after
`# ifconfig igb0 name eth0`
`# ifconfig eth0`


----------



## joeso (Oct 19, 2011)

SirDice said:
			
		

> That would be my suggestion.
> 
> Why not?



It looks like I had a brain fart and forgot to change ifconfig_igb0= to ifconfig_eth0= in rc.conf so obviously it couldn't assign assign an IP address.  Renaming the interfaces to eth0-7 works fine, but it would be nice to retain the device driver name instead.



			
				mix_room said:
			
		

> Did it also create the low numbered interfaces? Perhaps the spaces are being occupied before you have a chance to get into /boot/device.hints.
> Have you tried unloading the driver from the kernel and then manually loading it afterwards. Not a pretty solution, but it might work.


It didn't create the low numbered interfaces.  Here is what I added to /boot/device.hints:

```
hint.igb.0.at="pci0:6:0:3:"
hint.igb.1.at="pci0:6:0:2:"
hint.igb.2.at="pci0:6:0:1:"
hint.igb.3.at="pci0:6:0:0:"
hint.igb.4.at="pci0:9:0:0:"
hint.igb.5.at="pci0:9:0:1:"
hint.igb.6.at="pci0:9:0:2:"
hint.igb.7.at="pci0:9:0:3:"
```
After rebooting, it creates igb8-15 instead.  How would I unload the driver from the kernel?  I compiled the kernel with the igb driver so I don't think there is a way to do unload it without recompiling.


----------



## phoenix (Oct 19, 2011)

Go into the BIOS.  Go to the page with the PCI options.  Change the order for device enumeration.  

That way, your current igb4-7 will show up as igb0-3.


----------



## mix_room (Oct 20, 2011)

joeso said:
			
		

> It didn't create the low numbered interfaces.  Here is what I added to /boot/device.hints:


Maybe there is something you can add to devd.conf. 



> After rebooting, it creates igb8-15 instead.  How would I unload the driver from the kernel?  I compiled the kernel with the igb driver so I don't think there is a way to do unload it without recompiling.


Without re-compiling - no idea either. I would have suggested recompiling without the driver. And also have a look at dmesg to see what happens during boot. It might very well be that the igb{0,...,7} devices are being created and then being changed to igb{8,...,15}


----------



## geodni (Oct 20, 2011)

Maybe what I say is stupid but why not try : use /etc/rc.conf to rename igb* with a temporary name and rename them again as you want to using /etc/rc.local, doing some kind of permutation. But I don't know if the original interface name is preserved somewhere when it's renamed that's why it might be stupid...


----------



## phoenix (Oct 20, 2011)

If you're going to go the manual route like that, then you are better off writing your own script to:

list the MAC addresses
rename the interfaces to some temp name
rename the interfaces to the "correct" igbX name, based on the MAC address
Then insert that into the boot order before the netif script runs.  See rcorder(8) and rc() for details on how to do that.


----------



## Eric A. Borisch (Feb 10, 2017)

Sorry to post on such an old thread, but just wanted to (for anyone landing here from a search) share a script to perform boot-time (MAC-based) ethernet device renaming: https://github.com/eborisch/ethname ... It's been discussed briefly on the mailing lists and submitted for inclusion as a port.


----------



## genneko (Apr 28, 2020)

Eric A. Borisch said:


> Sorry to post on such an old thread, but just wanted to (for anyone landing here from a search) share a script to perform boot-time (MAC-based) ethernet device renaming: https://github.com/eborisch/ethname



Me too but I would like to say thank you for sharing your script.
It's so useful and helps me solve my problem on several systems.
Thanks a lot!


----------



## 0clue (Aug 28, 2020)

I found this thread with a google search, but I did not see the answer to this section, and wanted to include an answer so other people finding this thread can gain from an answer to this:



joeso said:


> It looks like I had a brain fart and forgot to change ifconfig_igb0= to ifconfig_eth0= in rc.conf so obviously it couldn't assign assign an IP address.  Renaming the interfaces to eth0-7 works fine, but it would be nice to retain the device driver name instead.
> 
> 
> It didn't create the low numbered interfaces.  Here is what I added to /boot/device.hints:
> ...



I ran into this.
Command-line tool "pciconf -l" shows a list of PCI addresses for many devices, including network devices. Most show a trailing ":" (colon) character.

Including this trailing ":" (colon) character in the /boot/device.hints values appears to not work. (It likely breaks the pattern check for devices with matching PCI addresses.)

When the trailing ":" was included in /boot/devices.hints assignments, the network devices named described are not found based on the provided PCI bus address.
This reservation and match failure results in the next available numbered value for that NIC-driver-name is the next free after those reserved names.
Drop the trailing ":" and rebooting, and the NIC are assigned names based on PCI address.

For your machine, try changing from this:

```
hint.igb.0.at="pci0:6:0:3:"
hint.igb.1.at="pci0:6:0:2:"
hint.igb.2.at="pci0:6:0:1:"
hint.igb.3.at="pci0:6:0:0:"
hint.igb.4.at="pci0:9:0:0:"
hint.igb.5.at="pci0:9:0:1:"
hint.igb.6.at="pci0:9:0:2:"
hint.igb.7.at="pci0:9:0:3:"
```
to this:

```
hint.igb.0.at="pci0:6:0:3"
hint.igb.1.at="pci0:6:0:2"
hint.igb.2.at="pci0:6:0:1"
hint.igb.3.at="pci0:6:0:0"
hint.igb.4.at="pci0:9:0:0"
hint.igb.5.at="pci0:9:0:1"
hint.igb.6.at="pci0:9:0:2"
hint.igb.7.at="pci0:9:0:3"
```

One item of caution. We have a server which had 18 interfaces. We wanted to keep the present assignments after we added another 4 interfaces. We expected the PCI address assignment to remain tightly tied with each slot, just as we found with another server. This was not the case with this server. After statically assigning all of the names for the 18 interfaces before adding the new card with 4 more, then shutting down and adding the next card, on boot, the PCI address for one card with 4 interfaces moved to the new slot and a different collection of PCI addresses was assigned to the card previously using those now re-assigned addresses.

I suspect this is a "BIOS"/firmware issue, and PCI Bus address assignments per slot could be made static for some motherboards.
Hopefully this won't happen to you.
If it does, maybe this helps you. 

-0clue


----------



## olli@ (Aug 28, 2020)

0clue said:


> One item of caution. We have a server which had 18 interfaces. We wanted to keep the present assignments after we added another 4 interfaces. We expected the PCI address assignment to remain tightly tied with each slot, just as we found with another server. This was not the case with this server. After statically assigning all of the names for the 18 interfaces before adding the new card with 4 more, then shutting down and adding the next card, on boot, the PCI address for one card with 4 interfaces moved to the new slot and a different collection of PCI addresses was assigned to the card previously using those now re-assigned addresses.


The order in which buses and devices are probed depends on a lot of things and is generally _unreliable_. Removing or adding hardware can change the order in unexpected ways, as you experienced. Even a BIOS update can change the order.

Therefore it is not advisable to rely on it. As has been mentioned earlier in this thread, naming interfaces based on the MAC addresses is a better approach.


----------



## Eric A. Borisch (Nov 12, 2020)

Of note: my script is now available in the ports tree: sysutils/ethname.


----------

