Skip to content
This repository has been archived by the owner on Mar 25, 2021. It is now read-only.

1NIC VE Failed to set MTU for virtual NIC mgmt: Invalid argument #78

Open
vincentmli opened this issue Oct 2, 2017 · 2 comments
Open
Assignees
Labels

Comments

@vincentmli
Copy link

I patched the VE image with

#./patch-image.sh -s ../lib/f5_image_prep/startup.tar -f /var/tmp/BIGIP-13.0.0.2.0.1671.qcow2

then created the VE instance with this image with only one NIC interface

#openstack server create --flavor f5-all --image bigip-13.0.0-hf2 --nic net-id=04d24182-856d-47ab-8ce8-41adad01c724 --security-group default --key-name mykey bigip1300hf2-selfservice-instance

when the virtual instance started up, it complains base configuration error as below:

[root@host-172-16-1-12:INOPERATIVE:Standalone] config # tmsh load sys config base

Loading system configuration...
/defaults/asm_base.conf
/defaults/config_base.conf
/defaults/ipfix_ie_base.conf
/defaults/ipfix_ie_f5base.conf
/defaults/low_profile_base.conf
/defaults/low_security_base.conf
/defaults/policy_base.conf
/defaults/wam_base.conf
Loading configuration...
/config/bigip_base.conf
/config/bigip_user.conf
010718de:3: Failed to set MTU for virtual NIC mgmt: Invalid argument <==================
Unexpected Error: Loading configuration process failed.

[root@host-172-16-1-12:INOPERATIVE:Standalone] config # ip link list
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,ALLMULTI,PROMISC,UP,LOWER_UP> mtu 1400 qdisc pfifo_fast master mgmt state UP qlen 1000
link/ether fa:16:3e:e9:0f:b7 brd ff:ff:ff:ff:ff:ff
3: mgmt: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UP
link/ether fa:16:3e:e9:0f:b7 brd ff:ff:ff:ff:ff:ff
4: tmm: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9282 qdisc noqueue state UNKNOWN
link/ether 00:98:76:54:32:10 brd ff:ff:ff:ff:ff:ff
5: tmm_bp: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
link/ether 02:01:23:45:00:fe brd ff:ff:ff:ff:ff:ff

I don't have the problem if I am not including startup.tar, I suspect the openstack-network.sh may have something to do with this issue.

@ssorenso
Copy link

ssorenso commented Oct 3, 2017

Hello @vincentmli,

Thanks for the question!

Suggestions Moving Forward:

So I have not booted up a 13.0.0.2.0 image; however, what I do know is that there's generally a mgmt interface and an eth0 interface and these are often bridged together. What you might try is either:

  • Modify the prep code to only change the MTU on the mgmt interface
  • Disable the MTU modification altogether and see if things work passed licensing
    • The MTU modification was mostly to get passed to the licensing server within our lab network

Either of these might work just fine for you on only 1 interface.

As far as interfaces go, it attempts to bridge ETH0 and MGMT to assure a connection to the control plane, so I don't think that having just one interface should be a problem for tinkering around with the BIG-IP image as an instance on its own.

How-Tos for These Suggestions

Before I begin, changing the MTU is likely to alter your connectivity across your ethernet connection. This is done by modifying the packet sizes.

Disabling

./lib/f5_image_prep/startup:

diff --git a/lib/f5_image_prep/startup b/lib/f5_image_prep/startup
index 54096d2..18bbf7e 100755
--- a/lib/f5_image_prep/startup
+++ b/lib/f5_image_prep/startup
@@ -137,7 +137,7 @@ function main() {
137      # is on a tunnel and the meta-data
138      # or user-data is larger then 1500
139      # bytes, it will fail. This fixes it.
140 -    force_mgmt_mtu
141 +    # force_mgmt_mtu

     # This is not really a test since we are forcing the ID, but maybe this should check if
     # this is an OpenStack instance running on Nova.
Modifying

./lib/f5_image_prep/os-functions/openstack-network.sh:

--- a/lib/f5_image_prep/os-functions/openstack-network.sh
+++ b/lib/f5_image_prep/os-functions/openstack-network.sh
@@ -351,11 +351,11 @@ function force_mgmt_mtu() {
351             if [[ $mgmt_mtu =~ ^[0-9]+$ ]]; then
352                         # Yes, honor it.
353                 log "Setting Management interface MTU per DHCP to $mgmt_mtu"
354 -               ip link set eth0 mtu $mgmt_mtu
355 +               ip link set mgmt mtu $mgmt_mtu
356             else
357                         # No, use a smaller sized MTU
358                 log "Setting Management interface MTU to default $mgmt_mtu"
359 -               ip link set eth0 mtu $OS_MGMT_MTU
360 +               ip link set mgmt mtu $OS_MGMT_MTU
361             fi
362  }
Conclusion

Please let me know if you have any further questions and whether or not the above works for you.

Cheers!
@ssorenso

@vincentmli
Copy link
Author

it looks ' ip link set mgmt mtu $mgmt_mtu' fixed the 1NIC problem base configuration error, both eth0 and mgmt has MTU set to 1500, is that ok? I thought mgmt or eth0 MTU should be 1400/1450 if the eth0/mgmt is going through vxlan tunnel.

I also started a 2NIC instance, the first reboot mgmt would get the right DHCP assigned IP, but second reboot, the mgmt would get default management ip 192.168.1.245, I had to run config command manually to change the mgmt IP to DHCP assigned ip, then tmsh save sys config, then reboot again and the DHCP assigned ip is saved and assigned to mgmt, is that expected behavior ?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants