DHCP / Vendor Class Identifier (Option 60)

Wenn man basierend auf dem Vendor Class Identifier (DHCP Option 60) Werte an einen Host zurückgeben will und Mikrotik (ROSv7) einsetzt, geht das wie im folgenden Beispiel gezeigt. Hier wird eine VLAN-ID an ein VoIP/SIP-Telefon übermittelt.

Mit ROSv6 kann leider nicht direkt über die „Vendor Classes“ eine Option/Option-Set zurückgegeben werden. Hier ist es nur möglich einen IP-Pool zu definieren, über die IP des Pools kann dann über „Networks“ eine Option/Option-Set gewählt werden. Ggf. muss so ein größeres Subnetz in keleinere Subnetze unterteilt werden.

Lab

Seit ROS v7.4 gingen die „Vendor Classes“ in die „Option Matcher“ auf.

Vendor-class-id matcher changes to generic matcher since RouterOS v7.4beta4.

https://help.mikrotik.com/docs/display/ROS/DHCP#DHCP-VendorClasses

Das Prinzip funktionier so:

Über einen „Option Matcher“ wird der Wert einer DHCP-Option ausgelesen (anhand dessen wird auf ein „Option-Set“ verwiesen)
Über ein „Option-Set“ wird auf eine oder mehrere Optionen verwiesen
Über die „Options“ werden die eigentlichen Werte definiert

Option Matcher:

Wichtig ist hier, dass der „finale“ DHCP-Pool angegeben wird (bzw. mehrere Option-Matcher genutzt werden, siehe unten)! Sonst wird das Telefon zwar im richtigen VLAN platziert, bekommt aber eine Adresse aus dem falschen Pool! VLAN 8 (DHCP-Pool-VLAN8) ist in diesem Fall der Pool für das VoIP-VLAN.

Der Wert „OptiIpPhone“ ist in diesem Fall der „Matcher“ auf den Option 60 zutreffen muss und darüber die weiteren Werte getriggert werden.

https://wiki.unify.com/wiki/VLAN_ID_Discovery_over_DHCP#Example_configuration_for_Vendor_Classes

Über die DHCP-Option 43 werden dann die Werte zurückgegeben, mit denen das Gerät konfiguriert werden kann.

Zuerst das „Option Set“, was recht unspektakulär ist:

Nun die eigentliche Option 43 mit der VoIP-VLAN-ID:

Hier darf nicht mehr Option 60 eingetragen werden!!

Der Wert (Value) lautet bei dem Telefon so:

0x01075369656D656E73020400000008ff

Aufgeschlüsselt ist folgendes kodiert:

0x = leitet einen Hex-String ein -> https://wiki.mikrotik.com/wiki/Manual:IP/DHCP_Server#Properties_3
01 = Code 1
07 = Länge von „Siemens“
5369656D656E73 = „Siemens“ in Hex
02 = Code 2
04 = Länge der VLAN-ID
00000008 = VLAN-ID „8“ in Hex
ff = Ende des Records

Die exakte Reihenfolge wie die Werte kodiert werden müssen legt der Hersteller fest:
https://wiki.unify.com/wiki/VLAN_ID_Discovery_over_DHCP

Im Wireshark zeigt sich dieser Wert im DHCP-Offer unter Option 43 wieder:

Das Telefon bezieht dann 2 IP-Adressen, zuerst eine IP-Adresse aus dem (Voice)-Pool, aber im falschen VLAN!
Mit der Übermittlung der richtigen VLAN-ID wird ein erneuter DHCP-Handshake im richtigen VLAN durchgeführt:

Hier zu sehen, zuerst antwortet der DHCP-Server (10.88.20.1) aus dem Netz 10.88.20.x mit einer Adresse aus dem VoIP-VLAN 10.92.0.x.
Hierüber wird die korrekte VID bezogen und es folgt ein erneuter DHCP-Handshake, wo nun der DHCP-Server aus dem richtigen VLAN antwortet (10.92.0.1).

Wie man sieht, wird zwischen dem ersten und zweiten Handshake kein DHCP-Release ausgelöst, was dazu führt, dass der Adressbedarf initial doppelt so hoch wie eigentlich notwendig ist. Das Telefon löst zwar einen Release aus, da es aber eine Unicast-Verbindung ist, kommt dieser Release nicht am Router an (es wurde eine IP aus dem VoIP-VLAN-Bereich vergeben, in dem initialen VLAN hat der Router aber kein solches Interface). Dies kann umgangen werden, indem man zwei Option-Matcher anlegt (dediziert für das/die VLAN(s) in denen das Telefon initial ist und für das/die VoIP-VLAN(s)):