[SOLVED] Interfaces tauschen ständig MAC

[MrPurple]

Hi Proxmox-Forum,

Eigentlich dachte ich, dass ich irgendwann dahinter komme, aber es ist nach wie vor ein Rätsel für mich:
Kein aktues Problem, nur trotzdem seltsam. Ich habe einige Proxmox Server laufen und auch ein Freenas durch welches ich erst aufmerksam wurde. Und zwar reportet mir das Freenas ständig folgendes:

arp: 192.168.10.22 moved from 00:00:00:d5:c4:82 to 00:00:00:d5:c4:84 on bge0
arp: 192.168.10.22 moved from 00:00:00:d5:c4:84 to 00:00:00:d5:c4:82 on bge0
arp: 192.168.10.22 moved from 00:00:00:d5:c4:82 to 00:00:00:d5:c4:84 on bge0

(MAC's etwas verändert)
und zwar bekomm ich das für alle meine Proxmox Server die zwei aktive Interfaces nutzen. Anbei die Konfig der Interfaces.

Was passiert hier und wieso?

 

[Stoiko Ivanov]

soweit das aus dem screenshot ersichtlich ist, haben beide vmbr eine IP aus demselben IP-subnetz - das funktioniert selten so wie gewünscht - es gilt normalerweise immer nur die erste route, die gesetzt wird, die andere findet ueblicherweise keine Verwendung.

bitte vom PVE das output von:
`ip link`
`ip addr`
`ip route`
sowie die VM-config (`qm config $VMID`)
posten
und aus der freenas-vm das output von
`ifconfig`
`netstat -rn`

 

[MrPurple]

Ich habe mich vielleicht etwas falsch ausgedrückt: Freenas läuft nicht in einer VM, ist einfach ein random Host im Netzwerk welcher diese changes mitbekommt. Daher würde ich meinen, dass dies nichts mit Routen zu tun hat?

 

[Stoiko Ivanov]

ahh - sorry das habe ich falsch verstanden.

dennoch ist das verhalten wahrscheinlich darauf zurückzuführen, dass 2 ips aus dem selben subnetz auf 2 interfaces gebunden sind.
wofür soll das dienen?
Wenn es um Redundanz geht müsste ein Bond angelegt werden (LACP oder active-passive)

Für weitere Diagnose bräuchten wir dennoch:
das output von:
`ip link`
`ip addr`
`ip route`
und von der freenas das output von
`ifconfig`
`netstat -rn`

 

[MrPurple]

Das hat erstmal keinen besonderen Zweck. Ein Bond ist eh geplant, nur will ich auch gleichzeitig auf VLAN umbauen und da bin ich noch am recherchieren wie ich am besten die interfaces aufeinenader-stacke. Gibt ja echt viele Ansätze.

$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr1 state UP mode DEFAULT group default qlen 1000
    link/ether 00:00:00:d5:c4:84 brd ff:ff:ff:ff:ff:ff
3: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr0 state UP mode DEFAULT group default qlen 1000
    link/ether 00:00:00:d5:c4:82 brd ff:ff:ff:ff:ff:ff
4: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 00:00:00:d5:c4:82 brd ff:ff:ff:ff:ff:ff
5: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 00:00:00:d5:c4:84 brd ff:ff:ff

# ip addr
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: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr1 state UP group default qlen 1000
    link/ether 00:00:00:d5:c4:84 brd ff:ff:ff:ff:ff:ff
3: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr0 state UP group default qlen 1000
    link/ether 00:00:00:d5:c4:82 brd ff:ff:ff:ff:ff:ff
4: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:00:00:d5:c4:82 brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.22/24 brd 192.168.10.255 scope global vmbr0
       valid_lft forever preferred_lft forever
    inet6 fe80::21e:bff:fed5:c482/64 scope link
       valid_lft forever preferred_lft forever
5: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:00:00:d5:c4:84 brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.23/24 brd 192.168.10.255 scope global vmbr1
       valid_lft forever preferred_lft forever
    inet6 fe80::21e:bff:fed5:c484/64 scope link
       valid_lft forever preferred_lft forever

# ip route
default via 192.168.10.1 dev vmbr0 onlink
192.168.10.0/24 dev vmbr0 proto kernel scope link src 192.168.10.22
192.168.10.0/24 dev vmbr1 proto kernel scope link src 192.168.10.23

Freenas:

# ip route
default via 192.168.10.1 dev vmbr0 onlink
192.168.10.0/24 dev vmbr0 proto kernel scope link src 192.168.10.22
192.168.10.0/24 dev vmbr1 proto kernel scope link src 192.168.10.23

# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.10.1    0.0.0.0         UG        0 0          0 vmbr0
192.168.10.0    0.0.0.0         255.255.255.0   U         0 0          0 vmbr0
192.168.10.0    0.0.0.0         255.255.255.0   U         0 0          0 vmbr1

ich seh schon, dass ist nicht optimal. scheinbar baut Proxmox den iSCSCI Link abwechselnd über die interfaces auf. Trotzdem leuchtet mir nicht ein, wie die MAC für ein Interface wechseln sollte.

 

[HBO]

Ich habe gleiches "Problem" und bezieht sich auch nur auf Linux Systeme. Bei mir spuckt die ARP Meldungen mein PfSense aus.
Soweit ich das aber beobachten konnte wird immer die korrekte Netzwerkkarte angesprochen?!

Da gleiches Setup mal eine kleine Bond Frage:
Ich habe in diesem Falle 3 Netzwerkkarten (2x 1Gbit und 1x 10Gbit).
Ist es nun möglich ein LACP Bond auf die 2x 1Gbit zu legen und anschließend ein active-backup auf die 10Gbit sowie das LACP Bond Interface?

 

[Stoiko Ivanov]

Freenas:

# ip route

hm - ich dachte Freenas basiert auf FreeBSD und hat demnach keine iproute2 utils?

Aber abseits dessen - ich nehme an, dass die wechsel zw. den interfaces einzig und alleine darauf zurueckzufuehren sind, dass 2 interfaces IPs aus dem selben subnetz haben:
* entweder, wenn das tatsaechlich gewollt wird - entscheiden welche destinations mit welcher der source-ips angesprochen werden soll und dementsprechend spezifische routen setzen
* oder beide ips auf ein interface konfigurieren
* oder einen bond konfigurieren (ist wirklich nicht so kompliziert - siehe https://pve.proxmox.com/pve-docs/pve-admin-guide.html#sysadmin_network_configuration)

hoffe das hilft weiter!

 

[Ingo S]

Die Erklärung ist, das beide Interfaces im gleichen Subnetz liegen und du damit für das gleiche Netz zwei verschiedene Routen dorthin hast. Jede Route hat eine Metrik, das ist das Gewicht und bestimmt die Priorität nach der die Route für das Ziel verwendet wird. Diese Metrik kann sich ändern z.B. wenn der Netzwerk Stack feststellt das ein Host wider Erwarten über die erste Route nicht erreichbar ist. Dann wird die Metrik sehr hoch gesetzt und die andere Route wird genutzt. Ich weiß nicht ob das möglich ist, aber es kann auch sein das die Metrik beider Routen gleich ist. Dann würde ich sagen es hängt vom Zufall ab, welche Route gerade genutzt wird und damit kann der Ursprung der Pakete spontan wechseln ohne das ein Problem vorliegt.
Da dein FreeNAS im gleichen Subnetz liegt, sieht es die MAC Adresse und stellt fest, das sich für den Host die MAC Adresse geändert hat, weil die Pakete jetzt von der anderen NIC kommen.

Das ist keine gute Konfiguration und kann zu merkwürdigen Effekten führen, wie z.B. das die Maschine andere Geräte im Netz sporadisch nur sehr schlecht erreichen kann etc. Ich würde eine der beiden NIC abschalten, bis du dir im Klaren bist welche Konfiguration du bauen möchtest.

Ich empfehle dazu ein LACP:
eth0+eth1 -> bond0 -> vmbr0
Am Switch dann ebenfalls zwei Ports mit LACP bündeln und fertig. VLAN ist davon unabhängig. Du kannst VLANs genauso über ein Bond schicken wie über jedes andere Interface.
Das gute ist, du kannst auch ein Bond erstellen und erstmal nur ein Interface rein hängen. Ich habe das in unserem Cluster grundsätzlich so gemacht, damit ich eine zusätzliche Abstraktionsschicht habe und Interfaces ohne Auswirkungen auf die nach außen Sichtbare Konfiguration wie Routen und IP Adressen, und nach innen (für die VMS), ändern kann.

 

[Ingo S]

Da gleiches Setup mal eine kleine Bond Frage:
Ich habe in diesem Falle 3 Netzwerkkarten (2x 1Gbit und 1x 10Gbit).
Ist es nun möglich ein LACP Bond auf die 2x 1Gbit zu legen und anschließend ein active-backup auf die 10Gbit sowie das LACP Bond Interface?

Klar, als Backup-Slave gibts du dann kein eth Interface an, sondern das jeweilige bond Interface.

 

[MrPurple]

Danke für die Antworten. Ich habe nun auch einen LACP (802.3ad) Bond gemacht. Musste allerdings auch "bridge_stp on" am Bridge-Interface setzen. Weiters kommts mir vor, dass es ewig dauert, bis der Link wieder steht wenn man "den Stecker zieht". (also einen von zwei).

 

[Stoiko Ivanov]

hmm ... LACP braucht auch eine LACP fähige Gegenseite. Das feature heißt bei unterschiedlichen Switchherstellern unterschiedlich (PortChannel, LinkAggregation, Trunk (bei HP war das zumindest mal LACP, auch wenn es bei anderen bedeutet, dass mehrere VLANs verfügbar sind) ....) .

bridge_stp on und eine hohe convergence rate (langes dauern, bis ein Link down erkannt wird) klingt eher danach, als wäre vorher ein Loop gesteckt, und es wird mittels stp einer der Links auf down gesetzt (klassisches stp kann recht langsam sein, bis es wieder einen stabilen zustand erreicht).

Falls der Switch nicht LACP fähig ist würde sich ein active-backup bond anbieten.

Hoffe das hilft weiter!

 

[MrPurple]

hmm ... LACP braucht auch eine LACP fähige Gegenseite. Das feature heißt bei unterschiedlichen Switchherstellern unterschiedlich (PortChannel, LinkAggregation, Trunk (bei HP war das zumindest mal LACP, auch wenn es bei anderen bedeutet, dass mehrere VLANs verfügbar sind) ....) .

bridge_stp on und eine hohe convergence rate (langes dauern, bis ein Link down erkannt wird) klingt eher danach, als wäre vorher ein Loop gesteckt, und es wird mittels stp einer der Links auf down gesetzt (klassisches stp kann recht langsam sein, bis es wieder einen stabilen zustand erreicht).

Falls der Switch nicht LACP fähig ist würde sich ein active-backup bond anbieten.

Hoffe das hilft weiter!

also "lange". ich rede von 2sek ca. Ist ein Netgear48-Port Smart Managed Pro Switch. Habe eine LAG-Gruppe für die beiden Ports gebildet und den Typ auf LACP gesetzt. ich kann dann noch den STP-Modus Deaktivieren und den Adminstrator-Modus aktivieren bzw. deaktivieren. Viel mehr kann ich eigentlich nicht konfigurieren.

wenns so weiterhin funktionier bin ich eh happy

 

[Ingo S]

Wenn auf einer Schnittstelle STP aktiv ist, muss bei jeder Änderung eines Links der zu dem Spanning Tree gehört, der Tree neu aufgbaut werden. Da bist du mit 2s noch schnell dabei.
Bei Cisco Switches bist du mit dem normalen STP schnell mal bei 30s oder länger bei großen Netzen. Dafür gibts dann rapid spanning tree und tausend andere varianten.

Wenn das LACP aber korrekt funktioniert ist STP nicht nötig, der Bond wird wie ein einzelner Link behandelt und kann daher keinen Loop erzeugen. Die Tatsache das das erst mit STP funktioniert klingt für mich danach das der Bond noch nicht okay ist.
Beide Seiten, Switch UND Server müssen das selbe bonding Protokoll sprechen.

 

[MrPurple]

hab STP auf beiden Seiten deaktiviert. Scheint zu laufen. Danke