Interface addition - is this a bug?
-
Hi,
I've got a pair of pFsense VMs in CARP with a WAN (vmx3), LAN (vmx0), DMZ (vmx1), and Pfsync (vmx2) interface configured.
I've now got a fifth NIC installed in the ESXi servers and as soon as I booted up pFsense I lost the WAN connection. It turns out that vmx3 had become vmx4 with the new NIC taking vmx3. This was repeatable, and if I removed the new NIC from the VM the WAN connection reverted to vmx3. I was under the impression that the MAC address from the vNIC (which hasn't changed) would be the key by which the interface was assigned, hence I was expecting vmx4 to be allocated to the newly added NIC.Thanks,
Mike. -
I've had similar with ESXI and other VM's. Now if I add interfaces, I always check the assignment before booting the VM. It does seem to vary depending on what order the interfaces are assigned in the original VM.
-
@Pentangle said in Interface addition - is this a bug?:
I've now got a fifth NIC installed in the ESXi servers
Is it of the same type as the others?
-
@viragomann Yes, VMXNET3, like the others are. I've since noticed that actually ALL my interface assignments aside from the LAN were screwed and needed re-setting.
-
pfSense generally adds the devices in the order of the hardware bus and device numbers, which is given by the host:
So maybe ESXi gives the new device a number less than an already existing.
Possibly there is a way to change it in ESXi. -
@viragomann in which case then wouldn't it be more desirable to add the existing devices based on MAC address and then add new devices afterwards in whatever order they see fit? i.e. i'd view it as a bug that adding a new NIC breaks old NIC assignments. Wouldn't you?
-
@Pentangle said in Interface addition - is this a bug?:
in which case then wouldn't it be more desirable to add the existing devices based on MAC address
The MAC address of a NIC is primarily a property which connected devices can see and take account of if necessary. E.g. for MAC filtering.
@Pentangle said in Interface addition - is this a bug?:
i'd view it as a bug that adding a new NIC breaks old NIC assignments.
Possilby in ESXi.
In KVM I can manually set the hardware bus numbers if needed, but I don't know how to do in ESXi.
-
@viragomann said in Interface addition - is this a bug?:
be ESXi gives the new device a number less than an already existing.
Possibly there is a way to change it in ESXi.https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198406
-
@heper
That concerns to VLAN and FreeBSD 10.1. The TO didn't mention the use of VLANs.Besides, that bug should be fixed long ago I think, isn't it?
-
@viragomann I don't know either!
-
it's not a bsd bug, it's an esxi thing ... it appears to still be relevant. the bug is indeed related to vlans, but the issue of the reordering is addressed aswell
esxi has been reordering interfaces after >4 Vnics of the same type, for as long as i can remember. that's one of the reasons i prefer to let the VM handle the vlans and not the host.
-
@viragomann I've actually got VLANs configured on one of the NICs from a previous network arrangement but i'm not using them.
-
It's just how ESXI probes NICs.
<4 is: 1,2,3,4
If you have 8, it becomes: 1,5,2,6,3,7,4,8Check the MACs, reassign the networks and/or interfaces to match what you want in pfSense.
-
@jimp Can't you do something cleverer then? It was just blind luck that my LAN assignment was NIC1 otherwise i'd have lost access.
-
Not without a ton of work to try to make NICs persist or be matched by their original hardware address. Gets tricky fast. There is a feature request out there for that, but in practice it's a rare need.
-
@jimp said in Interface addition - is this a bug?:
Not without a ton of work to try to make NICs persist or be matched by their original hardware address. Gets tricky fast. There is a feature request out there for that, but in practice it's a rare need.
On a regular (non VM) pfSense maching i'd hate Mac-mapped nics.
Would make "cloning" a config to a new machine "ugly"/Bingo
-
@bingo600 I'm not advocating that as the only method, just a small table lookup for existing MAC addresses with a failover to the current way of working if not in the table. A clone would therefore work as before since none of the MAC addresses would exist.