No connectivity to/from VM because the underlying interface is down

[Nobuto Murata]

By following the multi-node tutorial:
https://microstack.run/docs/multi-node

I used enp1s0 as the management interface, and prepared enp9s0 as a dedicated network interface for the OVS external port.

By answering to questions like follows, the enp9s0 interface was plugged into OVS.

  external_network:
    nic: enp9s0
    cidr: 10.0.123.0/24
    gateway: 10.0.123.1
    start: 10.0.123.51
    end: 10.0.123.80
    network_type: flat # or vlan
    #segmentation_id:
  user:
    remote_access_location: remote
    run_demo_setup: true
    username: demo
    password: demo
    cidr: 192.168.1.0/24
    nameservers: 10.0.123.1
    security_group_rules: true

$ sudo openstack-hypervisor.ovs-vsctl show
5f28ece6-9f47-4a2c-bd92-51944b79230e
    Bridge br-ex
        datapath_type: system
        Port br-ex
            Interface br-ex
                type: internal
        Port enp9s0
            Interface enp9s0
        Port patch-provnet-2c6b47a3-ceaa-4354-9f46-a0ea4bc1f651-to-br-int
            Interface patch-provnet-2c6b47a3-ceaa-4354-9f46-a0ea4bc1f651-to-br-int
                type: patch
                options: {peer=patch-br-int-to-provnet-2c6b47a3-ceaa-4354-9f46-a0ea4bc1f651}

...

However, there was no connectivity from/to VMs. And when trying to capture the packets to see where it's dropped, it told me the interface is not up. After marking it as up by hand, the traffic went through the port successfully.

ubuntu@sunbeam-2:~$ sudo tcpdump -elnv -i enp9s0
tcpdump: enp9s0: That device is not up

ubuntu@sunbeam-2:~$ sudo ip link set up enp9s0

ubuntu@sunbeam-2:~$ sudo tcpdump -elnv -i enp9s0
tcpdump: listening on enp9s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
14:36:32.174815 52:54:00:8e:30:0b > 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 150: (hlim 1, next-header Options (0) payload length: 96) fe80::5054:ff:fe8e:300b > ff02::16: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok] ICMP6, multicast listener report v2, 4 group record(s) [gaddr ff02::1:ff00:0 to_ex, 0 source(s)] [gaddr ff02::1:ff8e:300b to_ex, 0 source(s)] [gaddr ff05::2 to_ex, 0 source(s)] [gaddr ff02::2 to_ex, 0 source(s)]

14:36:32.618832 52:54:00:8e:30:0b > 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 90: (hlim 1, next-header Options (0) payload length: 36) fe80::5054:ff:fe8e:300b > ff02::16: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok] ICMP6, multicast listener report v2, 1 group record(s) [gaddr ff02::1:ff00:0 to_ex, 0 source(s)]
14:36:33.742483 fa:16:3e:08:a5:7a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.123.1 tell 10.0.123.70, length 28
14:36:33.742633 fa:16:3e:08:a5:7a > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.123.1 tell 10.0.123.70, length 28

[Nobuto Murata (nobuto)]

ovn-chassis charm (and underlying charm-helpers) does the job of bringing up the interface always.

https://github.com/openstack-charmers/charm-layer-ovn/blob/b5c4ae335fac5325ad1e0704ce9ddad818d5206a/lib/charms/ovn_charm.py#L1318

https://github.com/juju/charm-helpers/blob/807f705d1d132bedb62b2eb743403e1d5867360f/charmhelpers/contrib/network/ovs/__init__.py#L242-L246

[Nobuto Murata (nobuto)]

In the meantime, the snap doesn't do ip link set up other than ovs-vsctl add-port.

https://github.com/canonical/snap-openstack-hypervisor/blob/8988719d53dc2b003d40a64bd6b8dec5400dda45/openstack_hypervisor/hooks.py#L652-L674

[James Page (james-page)]

Scratched my head as to why we did not do this to start with - decided no good reason so:

https://github.com/canonical/snap-openstack-hypervisor/pull/31

[Nobuto Murata (nobuto)]

I wonder if the proposed patch takes effect even after the host reboot. If it doesn't survive after the reboot, then we might be hiding it from the initial deployment and postpone it to fire in the operation phase.

And if snap-openstack drops a snippet of netplan files, we might want to disable accept-ra together not to have an IP address on the underlying interface which prevent an IPv6 provider networking from wroking.
ref: https://bugs.launchpad.net/charm-ovn-chassis/+bug/1968355