Hallo zusammen,
Ich habe hier ein Problem mit folgendem Netzwerksetup:
Server mit 2 Netzwerkanschlüssen.
NIC 1 hängt ungetaggt an einem Access-Port im privaten LAN.
NIC 2 hängt getaggt an einem Trunk-Port mit mehreren VLANs.
vmbr1.90 ist noch ein überbleibsel, hat leider nicht richtig funktioniet.
Auf vmbr0 funktioniert alles soweit, wie es soll, sowohl in den Containern als auch in den VMs. Das gleiche gilt auch im vmbr1, wenn ich dort getaggte VLANs reinreiche.
Das gilt auch, wenn ich einen LXC-Container mit Debian Buster einrichte. Der Container ist dann sowohl über das LAN im vlbr0 erreichbar, als auch z.B. über eine Public IP im vmbr1.
Wenn ich das gleiche Setup mit zwei Interfaces nun für eine VM baue (vmbr0 ungetaggt, vmbr1 getaggte), dann funktioniert entweder vmbr0 oder vmbr1, aber nicht beides zusammen. Wenn ich ein Setup habe, bei dem vmbr0 (alo das private LAN) funktionirt, dann kann ich zwar mit tcpdump -i eth1 in der VM die Pakete, die im Server auf vmbr1 ankommen, in der VM sehen, aber die VM antwortet nicht. Das habe ich ausprobiert mit: Telefonanlagen, diversen Server-VMs und ein Test-Debian.
Habe ich irgendetwas übersehen?
Config Test-VM:

Ping auf die öffentliche IP:
ICMP-request ist zwar in der VM zu sehen, aber er antwortet nicht:
Was mach ich falsch?
Danke und Gruß,
Bytegetter
Ich habe hier ein Problem mit folgendem Netzwerksetup:
Server mit 2 Netzwerkanschlüssen.
NIC 1 hängt ungetaggt an einem Access-Port im privaten LAN.
NIC 2 hängt getaggt an einem Trunk-Port mit mehreren VLANs.
Code:
source /etc/network/interfaces.d/*
auto lo
iface lo inet loopback
iface eno4 inet manual
iface eno4 inet6 manual
iface eno3 inet manual
iface eno3 inet6 manual
auto vmbr0
iface vmbr0 inet static
pre-up ip addr flush dev eno4
address 172.16.6.30/24
gateway 172.16.6.1
bridge-ports eno4
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
auto vmbr1.90
iface vmbr.90 inet static
address 172.19.192.200/24
netmask 255.255.255.0
gateway 172.19.192.1
iface enp0s20f0u1u6 inet manual
auto vmbr1
iface vmbr1 inet manual
pre-up ip addr flush dev eno3
bridge-ports eno3
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
bridge-vids 2-4094
vmbr1.90 ist noch ein überbleibsel, hat leider nicht richtig funktioniet.
Auf vmbr0 funktioniert alles soweit, wie es soll, sowohl in den Containern als auch in den VMs. Das gleiche gilt auch im vmbr1, wenn ich dort getaggte VLANs reinreiche.
Das gilt auch, wenn ich einen LXC-Container mit Debian Buster einrichte. Der Container ist dann sowohl über das LAN im vlbr0 erreichbar, als auch z.B. über eine Public IP im vmbr1.
Wenn ich das gleiche Setup mit zwei Interfaces nun für eine VM baue (vmbr0 ungetaggt, vmbr1 getaggte), dann funktioniert entweder vmbr0 oder vmbr1, aber nicht beides zusammen. Wenn ich ein Setup habe, bei dem vmbr0 (alo das private LAN) funktionirt, dann kann ich zwar mit tcpdump -i eth1 in der VM die Pakete, die im Server auf vmbr1 ankommen, in der VM sehen, aber die VM antwortet nicht. Das habe ich ausprobiert mit: Telefonanlagen, diversen Server-VMs und ein Test-Debian.
Habe ich irgendetwas übersehen?
Config Test-VM:

Code:
bytegetter@debian:~$ 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: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 0a:f8:b0:d8:de:e0 brd ff:ff:ff:ff:ff:ff
inet 172.16.6.98/24 brd 172.16.6.255 scope global ens18
valid_lft forever preferred_lft forever
inet6 fe80::8f8:b0ff:fed8:dee0/64 scope link
valid_lft forever preferred_lft forever
3: ens19: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 02:92:84:b3:42:b6 brd ff:ff:ff:ff:ff:ff
inet 217.70.133.107/29 brd 217.70.133.111 scope global ens19
valid_lft forever preferred_lft forever
inet6 fe80::92:84ff:feb3:42b6/64 scope link
valid_lft forever preferred_lft forever
bytegetter@debian:~$ cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug ens18
iface ens18 inet static
address 172.16.6.98
netmask 255.255.255.0
gateway 172.16.6.1
allow-hotplug ens19
auto ens19
iface ens19 inet static
address 217.70.133.107
netmask 255.255.255.248
gateway 217.70.133.105
# skipped hwaddress since it is not supported by NGCP version mr9.2.1
#hwaddress BE:50:3C:7F:0B:A9
bytegetter@debian:~$
Ping auf die öffentliche IP:
Code:
root@de1:~# ping 217.70.133.107
PING 217.70.133.107 (217.70.133.107) 56(84) bytes of data.
^C
--- 217.70.133.107 ping statistics ---
8 packets transmitted, 0 received, 100% packet loss, time 7171ms
root@de1:~#
ICMP-request ist zwar in der VM zu sehen, aber er antwortet nicht:
Code:
root@debian:~# tcpdump -i ens19
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens19, link-type EN10MB (Ethernet), capture size 262144 bytes
11:35:54.614686 IP 89.248.165.200.55423 > 217.70.133.109.28111: Flags [S], seq 112136072, win 1024, length 0
11:35:58.079734 IP 193.27.228.57.58259 > 217.70.133.109.7383: Flags [S], seq 3827546475, win 1024, length 0
11:35:58.607349 IP mail.xx.de > 217.70.133.107: ICMP echo request, id 17260, seq 1, length 64
11:35:59.631326 IP mail.xx.de > 217.70.133.107: ICMP echo request, id 17260, seq 2, length 64
11:36:00.655361 IP mail.xx.de > 217.70.133.107: ICMP echo request, id 17260, seq 3, length 64
11:36:01.679241 IP mail.xx.de > 217.70.133.107: ICMP echo request, id 17260, seq 4, length 64
11:36:02.703322 IP mail.xx.de > 217.70.133.107: ICMP echo request, id 17260, seq 5, length 64
^C
7 packets captured
7 packets received by filter
0 packets dropped by kernel
root@debian:~#
Was mach ich falsch?
Danke und Gruß,
Bytegetter