tl;dr - a renamed dummy interface is not persisting across reboots on Cent6.
I have a situation where I need to rename a dummy interface on my system.
I have a total of 3 dummy interfaces:
dummy0 dummy1 adummy0
I've been doing some puppet testing in a vbox VM to get this all sorted out to deploy to a group of boxes. Every time I reboot my VM, it comes up WITHOUT adummy0, but I notice there is now an unconfigured dummy2.
I've tried everything from adding aliases to /etc/modprobe.d/dummyopts.conf to renaming the interface via "ip" (ip link set dummy2 name adummy0). This is all fine during use, even during a network restart. But as soon as I restart the VM, it comes back up broken.
I for the life of me have been unable to figure out why. I could use some help in narrowing down why this won't persist across reboots. I can write a startup script to deal with it, but it doesn't seem like a good solution.
Thanks, Frank
On Wed, May 27, 2015 at 1:37 AM, Frank Even lists+centos.org@elitists.org wrote:
tl;dr - a renamed dummy interface is not persisting across reboots on Cent6.
I have a situation where I need to rename a dummy interface on my system.
I have a total of 3 dummy interfaces:
dummy0 dummy1 adummy0
I've been doing some puppet testing in a vbox VM to get this all sorted out to deploy to a group of boxes. Every time I reboot my VM, it comes up WITHOUT adummy0, but I notice there is now an unconfigured dummy2.
I've tried everything from adding aliases to /etc/modprobe.d/dummyopts.conf to renaming the interface via "ip" (ip link set dummy2 name adummy0). This is all fine during use, even during a network restart. But as soon as I restart the VM, it comes back up broken.
I for the life of me have been unable to figure out why. I could use some help in narrowing down why this won't persist across reboots. I can write a startup script to deal with it, but it doesn't seem like a good solution.
Thanks, Frank
Anybody have any insights?
Frank Even wrote:
On Wed, May 27, 2015 at 1:37 AM, Frank Even lists+centos.org@elitists.org wrote:
tl;dr - a renamed dummy interface is not persisting across reboots on Cent6.
I have a situation where I need to rename a dummy interface on my system.
I have a total of 3 dummy interfaces:
dummy0 dummy1 adummy0
I've been doing some puppet testing in a vbox VM to get this all sorted out to deploy to a group of boxes. Every time I reboot my VM, it comes up WITHOUT adummy0, but I notice there is now an unconfigured dummy2.
I've tried everything from adding aliases to /etc/modprobe.d/dummyopts.conf to renaming the interface via "ip" (ip link set dummy2 name adummy0). This is all fine during use, even during a network restart. But as soon as I restart the VM, it comes back up broken.
I for the life of me have been unable to figure out why. I could use some help in narrowing down why this won't persist across reboots. I can write a startup script to deal with it, but it doesn't seem like a good solution.
Anybody have any insights?
What's in /etc/udev/rules.d/70-persistant-net.rules?
mark
On Wed, May 27, 2015 at 2:21 PM, m.roth@5-cent.us wrote:
Frank Even wrote:
On Wed, May 27, 2015 at 1:37 AM, Frank Even lists+centos.org@elitists.org wrote:
tl;dr - a renamed dummy interface is not persisting across reboots on Cent6.
I have a situation where I need to rename a dummy interface on my system.
I have a total of 3 dummy interfaces:
dummy0 dummy1 adummy0
I've been doing some puppet testing in a vbox VM to get this all sorted out to deploy to a group of boxes. Every time I reboot my VM, it comes up WITHOUT adummy0, but I notice there is now an unconfigured dummy2.
I've tried everything from adding aliases to /etc/modprobe.d/dummyopts.conf to renaming the interface via "ip" (ip link set dummy2 name adummy0). This is all fine during use, even during a network restart. But as soon as I restart the VM, it comes back up broken.
I for the life of me have been unable to figure out why. I could use some help in narrowing down why this won't persist across reboots. I can write a startup script to deal with it, but it doesn't seem like a good solution.
Anybody have any insights?
What's in /etc/udev/rules.d/70-persistant-net.rules?
Nothing that seems to be related to the issue:
# PCI device 0x8086:0x100e (e1000) (custom name provided by external tool) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="08:00:27:96:5d:9c", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
I'm beginning to wonder if there has been some different handling introduced into the latest updates as I had this working just fine on a physical box, but I just ran a "yum -y update" and am now running into the same problems.
What I need to be able to do is source a default route off of an IP attached to a dummy interface. But, for that source route to work off of the routes declared in route-bond0, the dummy interface that has the address I need to source needs to be up prior to bond0. In picking apart how networking brings up devices, it appears that it simply orders them alphabetically. So I created a dummy interface called "adummy0" and attached my IP to it and all was working well. Now, upon a reboot after updating to latest, the system refuses no matter how I create the interface (adding alias/modprobes to /etc/modprobe.d/dummyopts.conf or creating via "ip link" commands) to maintain my "adummy0" interface across reboots.