Neutron+VLAN. Allow a trunk traffic between VMs - networking

Please tell me, how can I make it possible to transfer Trunk traffic at the user level in the Neutron Private Network?
Description
We have the following private, non-shared network without any Gateway:
I want to make sure that VMs can configure Trunk-VLAN connections to each other. At the same time, the creation of these connections was controlled at the OS level (the count of such connections and VMs is completely chaotic and random )
The problem is the following - if you make several VMs on, for example, Centos and try to set up the relationship of one VM to another through the Trunk port with ID, for example, 5, the Neutron network completely drop such traffic.
### Both VMs ###
[root#vlan-X centos]# modprobe bonding
[root#vlan-X centos]# modprobe 8021q
[root#vlan-X centos]# echo "8021q" > /etc/modules-load.d/8021q.conf
[root#vlan-X centos]# echo "bonding" > /etc/modules-load.d/bonding.conf
### VM1 ###
[root#vlan-1 centos]# vi /etc/sysconfig/network-scripts/ifcfg-eth1
NAME="eth1"
DEVICE="eth1"
ONBOOT="yes"
TYPE="Ethernet"
BOOTPROTO="none"
[root#vlan-1 centos]# vi /etc/sysconfig/network-scripts/ifcfg-eth1.5
ONBOOT=yes
VLAN=yes
DEVICE=eth1.5
BOOTPROTO=static
IPADDR=192.168.10.15
PREFIX=24
[root#vlan-1 centos]# systemctl restart network
### VM2 ###
[root#vlan-2 centos]# vi /etc/sysconfig/network-scripts/ifcfg-eth1
NAME="eth1"
DEVICE="eth1"
ONBOOT="yes"
TYPE="Ethernet"
BOOTPROTO="none"
[root#vlan-2 centos]# vi /etc/sysconfig/network-scripts/ifcfg-eth1.5
ONBOOT=yes
VLAN=yes
DEVICE=eth1.5
BOOTPROTO=static
IPADDR=192.168.10.16
PREFIX=24
[root#vlan-2 centos]# systemctl restart network
[root#vlan-2 centos]# ping 192.168.10.15
PING 192.168.10.15 (192.168.10.15) 56(84) bytes of data.
From 192.168.10.16 icmp_seq=1 Destination Host Unreachable
From 192.168.10.16 icmp_seq=2 Destination Host Unreachable
From 192.168.10.16 icmp_seq=3 Destination Host Unreachable
From 192.168.10.16 icmp_seq=4 Destination Host Unreachable
From 192.168.10.16 icmp_seq=5 Destination Host Unreachable
From 192.168.10.16 icmp_seq=6 Destination Host Unreachable
From 192.168.10.16 icmp_seq=7 Destination Host Unreachable
From 192.168.10.16 icmp_seq=8 Destination Host Unreachable
^C
--- 192.168.10.15 ping statistics ---
11 packets transmitted, 0 received, +8 errors, 100% packet loss, time 10001ms
pipe 4
At the same time, tcpdump looks like this - that is, VLAN was successfully accepted, but then even ARP is unsuccessful
[root#vlan-2 centos]# tcpdump -e -nvvvti eth1
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
fa:16:3e:8f:7f:df > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 5, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.10.15 tell 192.168.10.16, length 28
fa:16:3e:8f:7f:df > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 5, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.10.15 tell 192.168.10.16, length 28
fa:16:3e:8f:7f:df > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 5, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.10.15 tell 192.168.10.16, length 28
fa:16:3e:8f:7f:df > Broadcast, ethertype 802.1Q (0x8100), length 46: vlan 5, p 0, ethertype ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.10.15 tell 192.168.10.16, length 28
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel
At the same time, the same design on VirtualBox with an internal network works fine.
What I have tried to solve this problem:
I tried creating a network with option "--transparent-vlan" - nothing changed
I tried creating a network with option "--transparent-vlan --disable-port-security" - nothing changed
I tried to connect the "Trunk" option to Neutron and configure additional entities like "network trunk" and "subport" - nothing changed. I had a suspicion that this was all intended to set up communication between two VMs on different networks, and not many VMs on the same network.

In general, this option has one limitation - it only works with Linuxbridge
A worked configuration for me:
vi /etc/neutron/neutron.conf
...
[DEFAULT]
vlan_transparent = true
...
vi /etc/neutron/plugins/ml2/ml2_conf.ini
...
[ml2]
type_drivers = flat,vlan,vxlan,gre
tenant_network_types = vxlan
mechanism_drivers = linuxbridge
...
vi /etc/neutron/plugin.ini
...
[ml2]
type_drivers = flat,vlan,vxlan,gre
mechanism_drivers = linuxbridge
...
And only then I was able to create a network with option "vlan_transparent", but not through the CLI, but through the API:
$ curl -s -X POST http://internal.mystack.net:9696/v2.0/networks -H "X-Auth-Token: <TOKEN>" -H "Content-Type: application/json" -d '{"network": {"name": "test", "admin_state_up": true, "tenant_id": "56b0cfe82ef94b2b8a60c53d72921a8b", "vlan_transparent": true}}'
$ openstack network show test --debug
...
{"networks": [{"provider:physical_network": null, "ipv6_address_scope": null, "dns_domain": null, "revision_number": 4, "port_security_enabled": true, "provider:network_type": "vxlan", "id": "78af4991-1b50-4b8d-9299-3a5dfaf689a2", "router:external": false, "availability_zone_hints": [], "availability_zones": [], "ipv4_address_scope": null, "shared": false, "project_id": "56b0cfe82ef94b2b8a60c53d72921a8b", "status": "ACTIVE", "subnets": [], "private_dns_domain": "mcs.local.", "description": "", "tags": [], "updated_at": "2022-03-29T13:22:00Z", "provider:segmentation_id": 88, "name": "test", "admin_state_up": true, "tenant_id": "56b0cfe82ef94b2b8a60c53d72921a8b", "created_at": "2022-03-29T13:22:00Z", "mtu": 1400, "vlan_transparent": true}]}
That is, if you add any "openvswitch" or "l2population" to the configuration in the "mechanism_drivers", then all this will abruptly stop working
I didn't develop the experiment further. realized that it doesn't suit me

Related

Ubuntu Server can not connect ssh from outside

We have ubuntu server installed on our desktop machine. It is connected modem with ethernet port. We can access it with ssh via inside of our network. But can not from outside.
Here is what we've done so far:
We have static ip
My professor made this i dont know what it is
Our ubuntu server machine always picks 192.168.1.200
We have port forwarding
when I run ssh maviarge#213.XXXXXXX from our LAN which holds ubuntu server machine
maviarge#213.XXXXXXX's password:
Welcome to Ubuntu 20.04.4 LTS (GNU/Linux 5.4.0-104-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
System information as of Thu 10 Mar 2022 08:45:36 AM UTC
System load: 0.07 Processes: 166
Usage of /: 2.0% of 438.13GB Users logged in: 1
Memory usage: 2% IPv4 address for docker0: 172.17.0.1
Swap usage: 0% IPv4 address for enp3s0: 192.168.1.200
Temperature: 50.0 C
* Super-optimized for small spaces - read how we shrank the memory
footprint of MicroK8s to make it the smallest full K8s around.
https://ubuntu.com/blog/microk8s-memory-optimisation
0 updates can be applied immediately.
But when I run ssh -v maviarge#213.XXXXXXX from outside of our wifi.
OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2
debug1: Reading configuration data C:\\Users\\MaviArge/.ssh/config
debug1: Connecting to 213.XXXXXXX [213.XXXXXXX] port 22.
debug1: connect to address 213.XXXXXXX port 22: Connection timed out
ssh: connect to host 213.XXXXXXX port 22: Connection timed out
When I run ping 213.XXXXXXX from outside
Pinging 213.XXXXXXX with 32 bytes of data:
Reply from 213.XXXXXXX: bytes=32 time=67ms TTL=46
Reply from 213.XXXXXXX: bytes=32 time=97ms TTL=46
Reply from 213.XXXXXXX: bytes=32 time=107ms TTL=46
Reply from 213.XXXXXXX: bytes=32 time=124ms TTL=46
Ping statistics for 213.XXXXXXX:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 67ms, Maximum = 124ms, Average = 98ms
Saw this command on internet sudo lsof -i:22 and the output:
sudo lsof -i:22
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
sshd 3290 root 4u IPv4 38814 0t0 TCP maviarge:ssh->host-213.XXXXXXX.reverse.superonline.net:58124 (ESTABLISHED)
sshd 3375 maviarge 4u IPv4 38814 0t0 TCP maviarge:ssh->host-213.XXXXXXX.reverse.superonline.net:58124 (ESTABLISHED)
sshd 4057 root 3u IPv4 71589 0t0 TCP *:ssh (LISTEN)
sshd 4057 root 4u IPv6 71591 0t0 TCP *:ssh (LISTEN)
sshd 5662 root 4u IPv4 74261 0t0 TCP maviarge:ssh->host-213.XXXXXXX.reverse.superonline.net:60472 (ESTABLISHED)
sshd 5746 maviarge 4u IPv4 74261 0t0 TCP maviarge:ssh->host-213.XXXXXXX.reverse.superonline.net:60472 (ESTABLISHED)
Also nmap scan:
Starting Nmap 7.92 ( https://nmap.org ) at 2022-03-10 05:17 EST
Nmap scan report for host-213.XXXXXXX.reverse.superonline.net (213.XXXXXXX)
Host is up (0.14s latency).
Not shown: 96 closed tcp ports (reset)
PORT STATE SERVICE
22/tcp filtered ssh
25/tcp filtered smtp
5060/tcp filtered sip
5432/tcp open postgresql
Nmap done: 1 IP address (1 host up) scanned in 2.08 seconds
What's wrong?
have you try this
sudo ufw allow from any to any port 22 proto tcp
or
sudo ufw allow ssh

Terminal not seeing ping messages from TUN port

Hi I'm working on a project and I had a question involving ping commands and how they interface over network TUN ports.
Basically I'm sending out ping requests which are routed to my TUN port and the reply's are sent to the TUN port over the VPN. There are no other internet interfaces (i.e. no wifi/ethernet). Using wireshark and tcpdump I can see that the correct reply messages are seen on the TUN0 port but terminal does not see the replys and instead shows 100% drop rate. The issue seems to be that the TUN0 port is not properly linking back to the kernal? (total guess I'm quite new to IP routing).
The IP address of the TUN is 10.0.0.73 and I am pinging a computer with IP address 10.0.0.28
Bellow is a snippet from the tcpdump on TUN0 this is a request and reply that to my untrained eye should work:
23:08:52.257566 IP (tos 0x0, ttl 64, id 11185, offset 0, flags [DF], proto ICMP (1), length 84)
10.0.0.73 > 10.0.0.28: ICMP echo request, id 24667, seq 2, length 64
23:09:11.508002 IP (tos 0x0, ttl 64, id 13315, offset 0, flags [none], proto ICMP (1), length 84)
10.0.0.28 > 10.0.0.73: ICMP echo reply, id 24667, seq 2, length 64
Based on other posts I checked my ip route list and the output is as such
pi#raspberrypi:~$ sudo ip route list
10.0.0.0/24 dev tun0 proto kernel scope link src 10.0.0.73
and the ifconfig is this:
pi#raspberrypi:~$ ifconfig tun0
tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.0.0.73 P-t-P 10.0.0.73 Mask:255.255.255.0
...
Turns out the issue was that the replies were showing up in incorrect orders and greatly delayed, when I fixed the network connections this issue went away without changing any configurations in the iptables

Cannot ping gateway for external Openstack network

I installed Openstack Ansible, Pike version. There is a separate network controller and on it one physical network interface. We created VLAN 139 that leads the traffic to gateway. Config file for that part looks like:
/etc/network/interfaces
...
auto eno1.139
iface eno1.139 inet manual
vlan-raw-device eno1
# OpenStack Networking VLAN bridge
auto br-vlan
iface br-vlan inet manual
bridge_stp off
bridge_waitport 0
bridge_fd 0
bridge_ports eno1.139
We created an external Openstack network using:
openstack network create --external --share --provider-physical-network vlan --provider-network-type vlan --provider-segment 139 provider1
and all the other steps (subnet, router, etc)
As per documentation, first test should be pinging default gateway from router namespace. When I try that it is not working:
root#infra1-neutron-agents-container-e800e983:/# ip netns exec qrouter-eb842b12-9a35-4a93-baa9-38cc73531d9f ping 139.25.25.193
When I do TCP dump on physical network interface of controller node I can see packets going out without any problem:
openstackadmin#clcontroller:~$ sudo tcpdump -i eno1 --immediate-mode -e -n | grep 139.25.25.193
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eno1, link-type EN10MB (Ethernet), capture size 262144 bytes
16:30:09.182894 fa:16:3e:d4:b6:a1 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 50: vlan 139, p 0, ethertype 802.1Q, vlan 139, p 0, ethertype ARP, Request who-has 139.25.25.193 tell 139.25.25.200, length 28
I see ARP request getting to gateway that has 139.25.25.193 and I am trying to ping:
hpadmin#hos-gw01:~$ sudo tcpdump -i any --immediate-mode -e -n | grep 139.25.25.193
[sudo] password for hpadmin:
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
15:53:29.857281 B fa:16:3e:d4:b6:a1 ethertype 802.1Q (0x8100), length 62: vlan 139, p 0, ethertype 802.1Q, vlan 139, p 0, ethertype ARP, Request who-has 139.25.25.193 tell 139.25.25.200, length 38
15:53:29.857281 B fa:16:3e:d4:b6:a1 ethertype 802.1Q (0x8100), length 58: vlan 139, p 0, ethertype ARP, Request who-has 139.25.25.193 tell 139.25.25.200, length 38
but what is confusing is my gateway is not responding to those ARP requests.
If I try to do same thing from stand alone Linux machine connected to same network segment and same VLAN everything works perfect.
Any idea what the problem might be? Thanks in advance.
It seems that problem was that external OpenStack network was set up to be on VLAN 139. Once we changed it to be flat everything started working without any problems. I am still confused, though, why gateway did not sent ARP responses.

Need to Bridge Network Port from local machine to Vagrant VM

On my development machine, I can see the following DHCP traffic on eth1 port:
sudo tcpdump -i eth1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
09:51:58.785056 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP,
Request from 00:06:31:c7:1e:23 (oui Unknown), length 315
09:51:58.785384 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP,
Request from 00:06:31:c7:1e:23 (oui Unknown), length 315
09:51:59.786677 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP,
Request from 00:06:31:c7:1e:23 (oui Unknown), length 315
I want to see this same traffic in my Vagrant VM. So I want to bridge the eth1 port on my development machine to some port on my Vagrant VM. I also want to be able to send network traffic from my Vagrant VM back onto the eth1.
Using the answer in the following question:
https://superuser.com/questions/752954/need-to-do-bridged-adapter-only-in-vagrant-no-nat
I added this to my Vagrantfile:
config.vm.provision "shell",
run: "always",
inline: "route -A inet6 add deault gw fc00::1 eth1"
But I don't really know what this does, except that it seems to only route ipv6 traffic? Could someone help explain how to bridge eth1 to a port on my Vagrant VM?
I also tried the following in my Vagrantfile:
Vagrant::Config.run do |config|
config.vm.network :bridged
end
yet after I do vagrant up again, I still don't see any port (using ifconfig) in my VM that has the DHCP traffic.
After reading up on Vagrant, I found a solution that worked for me.
Firstly, I ran the following command on my host machine:
sudo ip route add 192.168.1.0/24 dev eth1
My understanding is that this routes traffic from eth1 physical port to 192.168.1.0 IP address.
Then, in my Vagrantfile I added the following under Vagrant.configure(2) do |config|:
config.vm.network “public_network”, bridge: “eth1”
config.vm.network “public_network”, ip: “192.168.1.0”
After doing vagrant destroy and vagrant up, I now see a new port in my vagrant VM (enp0s8), that if I do tcpdump on I see the DHCP traffic (and other traffic) that is arriving on my eth1 port on my host machine.
Not sure if this is the best solution, as I am still very new to vagrant and VirtualBox, but this worked for me.

libvirt DHCP fails from host

I am having trouble setting up a PXE VM. It is sending DHCP requests and the server is sending responses, but the VM does not appear to be processing the response. I am unsure as to the cause.
I did confirm physical machines are working just fine with the same DHCP and PXE settings and the DHCP requests and responses are the same as with the VM.
The DHCP server is provided by MaaS and is on the host.
Below is an image of the error.
The VM is created with: virt-install --name=maas-node-1 --connect=qemu:///system --ram=15360 --vcpus=8 --hvm --virt-type=kvm --pxe --boot network,hd --os-variant=ubuntu16.04 --graphics vnc --os-type=linux --accelerate --disk=/var/lib/libvirt/images/maas-node-1.qcow2,bus=virtio,format=qcow2,cache=none,sparse=true,size=60 --network=bridge:br0,model=virtio
The network are configured as:
auto br0
iface br0 inet static
address 192.168.10.2
network 192.168.10.0
broadcast 192.168.10.255
netmask 255.255.255.0
gateway 192.168.10.1
dns-nameservers 192.168.10.2
bridge_ports bond0
bridge_stp off
bridge_fd 0
bridge_maxwait 0
auto bond0
iface bond0 inet manual
mtu 1500
bond-miimon 100
bond-downdelay 200
bond-updelay 200
bond-mode 0
bond-slaves none
post-up ifenslave bond0 eno1 eno2 eno3 eno4
pre-down ifenslave bond0 eno1 eno2 eno3 eno4
...
DHCP request is:
steel.maas.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from 18:03:73:f8:ea:c9 (oui Unknown), length 257, xid 0xf97e014f, Flags [Broadcast] (0x8000)
Client-Ethernet-Address 18:03:73:f8:ea:c9 (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Client-ID Option 61, length 6: ieee1394 03:73:f8:ea:c9
Parameter-Request Option 55, length 3:
Default-Gateway, Subnet-Mask, Domain-Name-Server
DHCP Reply is:
steel.maas.bootps > 255.255.255.255.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0xf97e014f, Flags [Broadcast] (0x8000)
Your-IP steel.maas
Server-IP steel.maas
Client-Ethernet-Address 18:03:73:f8:ea:c9 (oui Unknown)
file "pxelinux.0"
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: steel.maas
Lease-Time Option 51, length 4: 600
Subnet-Mask Option 1, length 4: 255.255.255.0
Default-Gateway Option 3, length 4: 192.168.10.1
Domain-Name-Server Option 6, length 4: steel.maas
The problem was that ARP was not being responded to due to a trait of using bond-mode 0 with no trunking on the switch. Switching to balance-tlb fixed the issues.
This helped narrow the problem down: https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/785668

Resources