1793VA DSL-1: Broadcast statt Unicast

[Dr.Einstein]

Herausfinden, wieso das Ziel Frame 00:00:00:00:00:00 nicht am Lancom auf DSL-1 ankommt. Der vorgeschaltete Switche sollte dieses Frame auf alle Ports auskoppeln.

Wo steht das? Ich habe diesbezüglich keine Ahnung, von daher sag mir doch mal bitte, ob irgendwo steht, dass die MAC-Adresse 00:00:00:00:00:00 eine spezielle MAC-Adresse ist, die Deiner Meinung nach ("alle Ports") wie die ff:ff:ff:ff:ff:ff zu behandeln ist? Ich habe dazu nichts gefunden, aber auch nicht lange gesucht, deswegen zweifel ich das an. Wie ich im anderen Thread schon schrieb, ich weiß gar nicht, wie sich so ein Switch in dem Fall verhalten muss.

00:00:00:00:00:00 ist eine ganz normale MAC-Adresse. Wenn also ein Client einen Frame an 00:00:00:00:00:00 schickt, dieses Frame einen Switch passiert, wird dieser Switch diese Ziel MAC-Adresse nicht kennen. Folglich koppelt er das Frame auf alle anderen Ports aus, bis auf dem Empfangsport. Das ist normales L2-Switching. Erst wenn der Switch die MAC-Adresse auf einem Port gelernt hat, werden ausschließlich Unicast-Frames geschickt. 00:00:00:00:00:00 MAC-Adressen passieren leider ab und zu auch in der Praxis wenn Geräte aus der Fabrik kommen, aber eine Geräte-Charge mal vergessen wurde mit MACs-Adressen zu flashen. Dann kannst du manchmal wirklich sowas wie 00:00:00:00:00:00 / ge1-10 in einer Switchtabelle lesen. Seltenes Phänomen kommt aber vor. Deswegen ist ja meine Vermutung, dass der Switch mit dem Frame nicht klar kommt, weil zusätzlich noch VLAN-Header existieren, es sich aber noch um einen nicht VLAN-fähigen Switch handelt. Vermutlich kommt hier etwas durcheinander mit der Broadcast-Umsetzung bei der ihm noch unbekannten MAC-Adresse.

Ich weiß gar nicht, ob der Lancom Router auf seiner DSL-Schnittstelle die benutzerdefiniert konfigurierte MAC-Adresse "00:00:00:00:00:00" erlaubt. Vllt bekommt man so den vorgeschalteten Switch dazu, die MAC des Lancoms zu erlernen, weshalb dann auch das OFFER-Paket trotz VLAN Header richtig adressiert werden würde.

[Jirka]

Dr. Einstein, danke für die ausführliche und gute Erklärung, jetzt habe ich verstanden, was Du meinst. Und letztlich bestätigt das in Teilen auch, was mein Eindruck war, dass es sich nämlich bei 00:00:00:00:00:00 um eine normale MAC-Adresse handelt. Na gut, in der Theorie. In der Praxis ist es so, wie Du schon schreibst. Es gibt mitunter mal Clients, die haben keine Adresse gesetzt und rutschen dann in diese erste aller Adressen, weswegen sie vermutlich von Xerox (Inhaber des OUI 00:00:00) auch nie vergeben wurde.
Der Workaround-Lösungsansatz ist in der Tat auch eine gute Idee, damit passt man sich quasi den Gegebenheiten an...

Es bleibt dann aber die Frage offen, wie Du sie hier ja schon formuliert hast, und ich im anderen Thread auch, wieso das DHCP-Offer mit Ziel MAC 00:00:00:00:00:00 nicht auch auf dem Ethernet-Port des Switches rauskommt, der an den LANCOM DSL-1 geht. Ist das also noch ein Bug im Switch? In die MAC-Adress-Table des Switches kann man ja leider nicht schauen bei so einem unmanaged-Teil. Im Trace sieht man keinen Absender mit einer MAC-Adresse 00:00:00:00:00:00.

[Dr.Einstein]

Es bleibt dann aber die Frage offen, wie Du sie hier ja schon formuliert hast, und ich im anderen Thread auch, wieso das DHCP-Offer mit Ziel MAC 00:00:00:00:00:00 nicht auch auf dem Ethernet-Port des Switches rauskommt, der an den LANCOM DSL-1 geht. Ist das also noch ein Bug im Switch? In die MAC-Adress-Table des Switches kann man ja leider nicht schauen bei so einem unmanaged-Teil. Im Trace sieht man keinen Absender mit einer MAC-Adresse 00:00:00:00:00:00.

Wie hast du das geprüft, z.B. mittels ETH-Trace am Lancom Router, tr # eth @ dsl-1? Auf einen DHCP Trace würde ich mich hier nicht verlassen, weil der eine Ebene danach ist.

[schiffeg]

VMware (auch einer der ganz Großen) schreibt in einem Troubbleshooting Bericht:

- -> DHCP client is set to initiate Discover with Broadcast flag set

LANCOM müsste also nur (wie z.B. Cisco) den DHCP-Client einen (bzw. 2) Radio-Button(s) (oder so ähnlich) hinzufügen:

- Broadcast flag set: Yes/No

Dann wäre der Drops gelutscht ...


Die Änderung LCOS 10.80 Client-Setup (->MAC)

LCOS 10.80 - MAC.jpg

.
bingt keine Verbesserung ...

[schiffeg]

Die rel. kurze Cisco (Beispiel-) Config für das bintec (/Teldat) 4Ge-LE LTE-Modul:
.

Cisco Router mit 4Ge-LE.pdf

.

Ohne Switch dazwischen, da WAN als Sub-Schnittstelle mit VLAN 463

[Dr.Einstein]

Es gibt glaube noch eine Tricklösung falls das mit DSL Gegenstelle 00:00:00:00:00:00 nicht klappen sollte.

Folgende Bauweise:

ETH-1: dein LAN-1
ETH-2: LAN-2 - Kabel zum Bintec
ETH-3: LAN-2 - Kabel auf ETH-4
ETH-4: DSL-1 - Kabel auf ETH-3

Du konfigurierst dein Netzwerk, was für die DHCP-Konfig des Bintecs zuständig ist um auf LAN-2 + vergibst eine VLAN ID, z.B. 100. Du schaltest das VLAN-Modul im Lancom ein, und hinterlegst für das LAN-2 VLAN 100+463, Tagging Mode Hybrid, PVID 100. Denk an dein LAN-1. Du brauchst hier auch eine interne VLAN-ID, bzw am IP-Netzwerk LAN-1 ebenfalls.

[schiffeg]

hinterlegst für das LAN-2 VLAN 100+463, Tagging Mode Hybrid, PVID 100.

1793VA_LAN-2_VLAN.jpg

.
Ist das so korrekt?

VLAN 100+463 in der VLAN-Tabelle 2 Einträge erzeugen, richtig?

Du brauchst hier auch eine interne VLAN-ID, bzw am IP-Netzwerk LAN-1 ebenfalls.

.
Nur ein Eintrag in der Port-Tabelle für LAN-1, z.B. VLAN 20, und kein Eintrag in der VLAN-Tabelle für LAN-1, richtig?

Noch 2 Fragen:
- Pakete auf diesem Port erlauben, die zu anderen VLANs gehören: J/N
- Private Mode für die Eth-Ports Ein/Aus
.

Vielen Dank !!

[Dr.Einstein]

Ist das so korrekt?

VLAN 100+463 in der VLAN-Tabelle 2 Einträge erzeugen, richtig?

korrekt. VLAN-100 LAN-2; VLAN-463 LAN-2. Andere VLANs erlauben: nein

Nur ein Eintrag in der Port-Tabelle für LAN-1, z.B. VLAN 20, und kein Eintrag in der VLAN-Tabelle für LAN-1, richtig?

Doch doch, LAN-1 in der Porttabelle füllen als Access, PVID 20, und unter der Netzwerktabelle VLAN 20 LAN-1. Dann daran denken, dass du unter IPv4-Netzwerke dein lokales LAN auch mit VLAN 20 versiehst, zeitgleich, sonst sperrst du dich aus.

Noch 2 Fragen:
- Pakete auf diesem Port erlauben, die zu anderen VLANs gehören: J/N
- Private Mode für die Eth-Ports Ein/Aus

- Pakete auf diesem Port erlauben, die zu anderen VLANs gehören: J/N -> N
- Private Mode für die Eth-Ports Ein/Aus -> Testweise aus. ETH-2/3 MUSS aus sein.

[schiffeg]

Hi Dr. Einstein,

der OFFER vom 4Ge-LE kommt zwar beim LAN-3 an, nicht aber beim DSL-1 ...
LAN-3 und DSL-1 scheinen nicht miteinander zu kommunizieren ...

Anbei die beiden Traces. PW für Konfig habe ich Dir per PN geschickt.

Vielen Dank!

[Dr.Einstein]

Kannst du mal im Firewall Trace schauen, ob die Pakete geblockt werden? Endlich taucht nämlich die richtige MAC-Adresse auf, d.h. dein Switch hat die vorher aufgegessen ...

Und zusätzlich Wechsel mal den Netzwerktyp auf Intranet statt DMZ.

[schiffeg]

Hi Dr.Einstein,

der Firewall-Trace zeigt nix an ...

Ich gehe davon aus, dass sowohl der (unmanaged) Switch als auch der LANCOM ein Problem mit der leeren MAC-Adresse (00:00:00:00:00:00) haben.

DA die 179§VA noch nicht gekauft sind (abgesehen von 1 Test-Router 1793VA) werde ich mal mit lANCOM über das Braodcast Flag sprechen. Das sprichwörtliche Bit (0 oder 1) entscheidet dann letztendlich über den Kauf (J/N) ...

Vielen Dank für Deine / Eure Unterstützung bisher !!!

[Dr.Einstein]

Hm aber da ist doch dieses mal eine MAC-Adresse, siehe Bild. Das kann dann eigentlich nur eine Kleinigkeit sein, wieso es von DSL-1 auf ETH-2 rausgeht, aber von ETH-2 nicht mehr zurück auf DSL-1. Vllt mal im VLAN Trace schauen (tr # vlan). Ich würde darauf tippen, dass Jirka das jetzt in <10 Minuten repariert bekommt. Irgendwas mit LAN-3 muss in einer Bridgegruppe sein oder so ein Quatsch.

[schiffeg]

[VLAN] 2023/11/15 13:30:23,361 Devicetime: 2023/11/15 13:30:38,677
VLAN ingress filter for packet received from 02:a0:57:54:ad:a4 (LANCOM (local-0) 54:ad:a4) via port LAN-3 destined to ff:ff:ff:ff:ff:ff (Broadcast) Type 0x0800
Frame Tag: full (network 463, prio 0)

[VLAN] 2023/11/15 13:30:23,361 Devicetime: 2023/11/15 13:30:38,682
VLAN ingress filter for packet received from d2:7e:d9:28:05:08 (locally-adm.) via port LAN-3 destined to 00:00:00:00:00:00 Type 0x0800
Frame Tag: full (network 463, prio 0)


Der DISCOVER von DSL-1 (02:a0:57:54:ad:a4) geht über LAN-3 raus (ohne Broadcast Flag) und wird auch vom 4Ge-LE beantwortet; die Antwort kommt dann auch wieder bei LAN-3 an, jedoch mit leerer MAC-Adresse, die dann nicht weiter zugestellt werden kann ...
Dann geht das Spiel von vorne los: DISCOVER ... OFFER, der nicht von LAN-3 an DSL-1 zugestellt werden kann.

[backslash]

Hi

DA die 179§VA noch nicht gekauft sind (abgesehen von 1 Test-Router 1793VA) werde ich mal mit lANCOM über das Braodcast Flag sprechen. Das sprichwörtliche Bit (0 oder 1) entscheidet dann letztendlich über den Kauf (J/N) ...

wie wäre es, wenn du statt mit LANCOM mit Bintec darüber sprechen würdest, denn Bintec verhält sich falsch!

Das Broadcast-Flag ist nur ein Hinweis für den Server, daß der Client auch per Unicast angesprochen werden KANN. Niemand verbietet dem Server das Flag zu ignorieren und per Broadcast zu antworten. Wenn er das Flag aber auswertet, dann MUSS er auch korrekt antworten. LANCOM jedenfalls wird das Bit nicht ändern

Gruß
Backslash

[Dr.Einstein]

Der Workaround-Lösungsansatz ist in der Tat auch eine gute Idee, damit passt man sich quasi den Gegebenheiten an...

Lancom ignoriert einfach den selbst eingetragenen Wert von 000000000000 und ersetzt diesen im Hintergrund automatisch mit seiner 00:a0:57er Adresse, leider. Was mir dabei auch aufgefallen ist: Lancom will nach Änderung der MAC-Adresse immer einen Neustart haben. Furchtbar. ETH und/oder DSL Port aus-/einschalten ohne Erfolg.

Es bleibt dann aber die Frage offen, wie Du sie hier ja schon formuliert hast, und ich im anderen Thread auch, wieso das DHCP-Offer mit Ziel MAC 00:00:00:00:00:00 nicht auch auf dem Ethernet-Port des Switches rauskommt, der an den LANCOM DSL-1 geht. Ist das also noch ein Bug im Switch? In die MAC-Adress-Table des Switches kann man ja leider nicht schauen bei so einem unmanaged-Teil. Im Trace sieht man keinen Absender mit einer MAC-Adresse 00:00:00:00:00:00.

Ich konnte es zwar umbiegen, dass Frames mit dem Ziel 00:00:00:00:00:00 entsprechend an den DSL Port weitergeleitet werden, jedoch greift hier die normale Netzwerkkartenlogik: Verwerfe Frames, die nichts mit mir zutun haben. D.h. alles ungleich eigener MAC-Adresse oder Broadcast wird verworfen, noch bevor du diese im Wireshark oder Ethernet Trace siehst.

Gibt wohl keine andere Lösung als über den Lancom Vertrieb unter entsprechender Mengenangabe ein Feature Request zu erstellen oder halt die Bintec Teile rauszuwerfen. Ein Ticket beim Hersteller lohnt sich meiner Ansicht nach nicht. Das Teil wurde seit bestehen noch nie gepatcht, Firmware ist 4 Jahre alt. Aber klar, wenn du die nerven hast, probier es aus.