For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

rlvcosta's avatar
rlvcosta
Icon for Nimbostratus rankNimbostratus
Sep 08, 2022

BigIP VE KVM VM network interface mapping into tmsh Interfaces logic

I could not find any other KB, F5 document or ticket with an answer for this very basic question about how BigIP VE maps its OS level to tmsh Interface convention. As reference, a regular Linux like...
application delivery
CA_Valli's avatar
CA_Valli
Icon for MVP rankMVP
Sep 09, 2022

Hi, according to K12149 , starting from BIG-IP v15.1.0 the enumeration of multiple network interfaces number the interfaces in an orderly manner. 

/etc/ethmap should be the file that outputs interfaces mapping on the BIG-IP system.

K17283 details a known issue with deleting/renumbering the VE virtual NICs. It also states that it's a problem seen up to v15.1.0 as well. 

Hope this helps

CA

rlvcosta's avatar
rlvcosta
Icon for Nimbostratus rankNimbostratus
Sep 12, 2022

Hi, I had seen those KB documents but first one id K12149 is related to VMWare, not KVM, and I noticed that apparently this enumerated is related with MAC address ordering, but nowhere there is an explicity BigIP documentation explaining it.

It could be ordering in terms of PCI slot, what woiuld be the best, but apparently it is not.

The problem arises since BigIP SW is misbehaving when creating Trunks, or Port Channel aggregates. It does not setup the hypervisor network interfaces with the same MAC, causing the Trunk not to work properly. Then some workarounds is to setup the hypervisor network interfaces with the same MAC address.

Then problem occurs since if BigIP VE is rebooted, it changes the network ordering, creating then issues in all Trunks and all Load Blance logic. This could also be seen as a Backup restore and a reboot.

So the problem is to know exactly the network mapping logic, so I can try to create a proper workaround to another problem related to Trunk ports not having the MAC address setup properly by BigIP VE.

On Linux this is very  simple to see,  or "Consistent Network Device Naming". I hope BigIP VE starts to use much more modern mappings like "Consistent Network Device Naming", But actually it is not clear how it does this mapping.

If somene can give more hints on this, I would appreciate. Eventuially I could create udev scripts, but not sure if those would be propagated, like on Backups or Upgrades. And I could also violate some logic, creating some issues on tmsh processing.

But the real goal I have is BigIP VE properly work with Trunks, or setup the same MAC address at Hypervision "physical like" network interface at BigIP VE ethX interfaces, so I would not need to put the same MAC on different interfaces component of each Trunk I have.

Once I put the same MAC on the interfaces to try to fix Trunks, on the boot it maps interfaces in completly different order. The only way to fix it again, after restore the intial MAC, is like in the 2nd link, execute:

  1. Log in to the command line.
  2. Remove the MCPD database by typing the following command:

    rm /var/db/mcpd*

  3. Restart the system by typing the following command:

    reboot

Any comments would be great since a basic function like Port Channel(Trunk) is not working properly.