electrocucaracha/openstack-multinode

"Using the management network interface as Neutron External can result in losing external connectivity"

MrLinks75 opened this issue · 4 comments

MrLinks75 commented

Hi,

Hope you're doing well.

I've tried to run the install.sh for the All-in-one configuration using the command :
curl -fsSL https://raw.githubusercontent.com/electrocucaracha/openstack-multinode/master/install.sh | OS_KOLLA_NETWORK_INTERFACE=eno1 bash

and getting the error
ERROR: Using the management network interface as Neutron External can result in losing external connectivity

After checking, the script gets mgmt_nic from ip route get 8.8.8.8 | grep "^8." | awk '{ print $5 }' which indeed is eno1.

Vagrant has been installed using the vagrant setup provided in https://bit.ly/initVagrant

Here are my current NICs :

ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp23s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 5c:62:8b:c4:ad:99 brd ff:ff:ff:ff:ff:ff
    inet 169.254.84.73/16 brd 169.254.255.255 scope link noprefixroute enp23s0
       valid_lft forever preferred_lft forever
    inet6 fe80::a5c2:36bf:3788:7fb2/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
3: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether cc:96:e5:15:30:92 brd ff:ff:ff:ff:ff:ff
    altname enp0s31f6
    inet 192.168.137.202/24 brd 192.168.137.255 scope global noprefixroute eno1
       valid_lft forever preferred_lft forever
    inet6 fe80::ac0b:b2f4:db38:974e/64 scope link noprefixroute
       valid_lft forever preferred_lft forever
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 52:54:00:24:71:ec brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
       valid_lft forever preferred_lft forever

eno1 being the NIC directly attached to my gateway.

enp23s0 being a secondary NIC that was used in a previous manual kolla-ansible deployment to be used by Neutron for networking so it remained IPless. (It has been enabled here for testing purposes).

Should I just force enp23s0 to be the default management NIC as hard coded value?

A bit confused here,

Thanks in advance !

electrocucaracha commented

Hi @MrLinks75,

Foremost, thanks for using this project and most important, for reporting this issue. More likely, I need to improve the documentation. The idea to consume the install.sh script directly is for bare metal deployments, I have some CI coverage of that here resulting in an execution like this one, I have to recognize that the IP management discovery process needs to be improved, specially in those cases where ip route provides a non-expected output (like more than one default route, or different IP address column).

If you installed Vagrant (my preference), you can try the different setups running vagrant up from the different samples folder, like All-in-One.

In order to specify the secondary NIC in a bare metal deployment and avoid that error, you can use the OS_KOLLA_NEUTRON_EXTERNAL_INTERFACE variable, which in your case is enp23s0. So the one-liner command should be like:

 curl -fsSL https://raw.githubusercontent.com/electrocucaracha/openstack-multinode/master/install.sh | OS_KOLLA_NETWORK_INTERFACE=eno1 OS_KOLLA_NEUTRON_EXTERNAL_INTERFACE=enp23s0 bash
MrLinks75 commented

Hi @electrocucaracha,
Thanks for the quick response !

I'm interested in the project for my PhD project in cybersecurity to deploy security tools such as SIEMs or UEBAs with machine-learning capabilities for monitoring NB-IoT in "production"-like environment.

I'm currently investigating multiple methods of deployment for an entire Openstack environment and your method is extremely interesting and faster than a manual deployment.

I indeed did as you recommended and used directly the vagrant file within the samples folder, especially AIO.

The deployment went without a problem.

If a need to re-deploy everything arises I will try to do it through the install.sh since I'm working on bare metal.

However, I was wondering if it was possible to apply routing rules directly through the vagrant file?

I've encountered a networking issue in the past (specifically instances not being able to ping or access external networks / internet) on manual but also automated deployments

Could commands such as :

sudo ifconfig br-ex $EXT_NET_GATEWAY netmask 255.255.255.0 up  
sudo iptables -t nat -D POSTROUTING -s $EXT_NET_CIDR -o enp23s0 -j MASQUERADE  
sudo iptables -D FORWARD -o enp23s0 -i br-ex -j ACCEPT  
sudo iptables -D FORWARD -i enp23s0 -o br-ex -j ACCEPT

Be doable out of curiosity?

Regards,

MrLinks

electrocucaracha commented

All depends, if those instructions have to run on the host machine, they need to be adapted to Vagrant like these ones, but if they have to run as part of the provisioning method, there are multiple places to place them:

  • To apply in all the nodes here
  • To apply only in All-in-One setup before Kolla execution here
MrLinks75 commented

Excellent, thanks a lot for the valuable help !
And yeah the instructions are mostly for the host machine so it allows me to ping the external network.

Thanks again, and great project, I'll close the issue as resolved.

  • ❤️1