DHCP-Client auf Bridge (VLAN)

Ausgangssituation

Soll in einem VLAN-Setup einer Bridge per DHCP eine IP zugewiesen werden, liegt es nahe die Bridge und das physikalische Netzwerkinterface tagged einzutragen (natürlich nur, wenn die Frames mit Tag eingehen).

Hier im Beispiel wird per VLAN-Trunk tagged die VID100 an den Client übermittelt. In diesem Netz befindet sich auch ein DHCP-Server.

DHCP-Client: bridge1 tagged

 

DHCP-Client: admit only VLAN tagged + Ingress Filtering

Dieses Vorgehen wäre logisch und ist von Mikrotik auch so beschrieben.
Allerdings wird dort nicht darauf eingegangen, dass die Bridge selbst ein Interface sein kann.

Wie beschrieben löst dies auf dem DHCP-Server wie auf dem DHCP-Client nichts aus.

 


Problemlösung

Die Bridge selbst kann nur untagged per IP angesprochen werden!
Es kann nur eine PVID definiert werden (untagged ingress), jedoch keine VID (tagged egress).

Daraus ergeben sich folgende Kombinationen:

  • Wenn nur die Bridge (untagged) angesprochen werden sollte, wäre „admit all“ oder „admit only untagged and priority tagged“ möglich.
  • Wenn die Bridge (untagged) und VLAN-Interfaces (tagged) gemeinsam vorliegen muss „admit all“ gewählt werden.
  • Wenn nur VLAN-Interfaces (tagged) anliegen, wäre „admit all“ oder „admit only VLAN tagged“ möglich.
DHCP-Client: Bridge auf „untagged“

 

Dies löst im DHCP-Server eine „Offer“ aus (Client: egress = tagged).
Der Rückweg zum Bridge-Interface findet aber (Client-intern) ebenfalls tagged statt, weshalb die „Offer“ verhallt:

DHCP-Server: „offered“ da im Client die Bridge noch tagged ist!

 

Paketmitschnitt des Bridge-Interfaces (Client):

DHCP-Client: Bridge kann mit tagged-Frames nicht umgehen!
Bitte VID1 als VID100 betrachten (Bild wurde später eingefügt)!

 

Paketmitschnitt des ETH-Interfaces (Server):

DHCP-Server: Discover-Frame mit VLAN-Tag des Clients (da ether3 = tagged).
Bitte VID1 als VID100 betrachten (Bild wurde später eingefügt)!

Die Bridge des Clients muss auf „untagged“ konfiguriert sein:

DHCP-Client: physikalisches Interface: tagged | Bridge-Interface: untagged

 

Erst wenn die Bridge auf untagged steht, wird die „Offer“ vom Client angenommen:

DHCP-Server

 

Paketmitschnitt des Bridge-Interfaces (Client):

DHCP-Client: Ohne VLAN-Tag kann die Bridge die Frames verarbeiten.

 

Paketmitschnitt des ETH-Interfaces (Server):

DHCP-Server: Discover-Frame mit VLAN-Tag des Clients (da ether3 = tagged).
Bitte VID1 als VID100 betrachten (Bild wurde später eingefügt)!

 

Und daraufhin der DHCP-Client (Bridge selbst) adressiert wird:

DHCP-Client

 


Zusammenfassung

Wenn einzig die Bridge als IP-Interface verwendet werden soll (keine weiteren Interfaces):

  • Die Bridge des DHCP-Clients muss auf „admit all“ oder „admit only untagged and priority tagged frames“ stehen (Bridge -> Bridge)
  • Die Bridge des DHCP-Clients muss auf „untagged“ konfiguriert sein (Bridge -> VLANs)

 

Die Kombination aus „admit only VLAN tagged“ oder „admit all“ (Bridge -> Bridge) und „tagged“ (Bridge -> VLANs) funktioniert nicht.

 


Ergänzung

Wenn in der Kombination Bridge (selbst als Interface) + VLAN-Interfac(es) gearbeitet werden soll, muss die Bridge des Clients auf „admit all“ stehen!

Andernfalls hätte entweder die Bridge keine Konnektivität (bei „admit only VLAN tagged“), oder die VLAN-Interfaces hätten keine Konnektivität (bei „admit only untagged and priority tagged frames“). Die Bridge fungiert als sogenannter CPU-Port (tagged) – als Schnittstelle zum Router – als auch als eigenständiges Interface (untagged).

DHCP-Client

 

DHCP-Client: VLAN100 und 200

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert