
Mac-Adressen, die mit „55:a3“ und „56:2a“ enden, landen ebenfalls im letzten Pool
123 match if binary-to-ascii(16,8,":",substring(hardware, 5, 6)) = "55:a3";
124 }
125
126 class "esx67" {
127 match if binary-to-ascii(16,8,":",substring(hardware, 5, 6)) = "56:2a";
128 }
129
130 shared-network 20-30 {
131 subnet 20.30.0.0 netmask 255.255.0.0 {
132 option domain-name "nsbucqesystem.test";
133 option domain-name-servers 20.30.0.1;
134 option routers 20.30.0.1;
135 default-lease-time 2592000;
136 max-lease-time 2592000;
137 ping-check true;
138 }
139 pool {
140 allow members of "esx65";
141 range 20.30.1.1 20.30.1.254;
142 }
143 pool {
144 allow members of "esx67";
145 range 20.30.2.1 20.30.2.254;
146 }
147 pool {
148 deny members of "esx67";
149 deny members of "esx65";
150 range 20.30.3.1 20.30.254.254;
151 }
152 }
Kann jemand einen Fehler in dieser Konfiguration aufzeigen?
Antwort1
Das Problem liegt in der Verwendung des hardware
Filters.
In der Dokumentation heißt es:
Der Hardware-Operator gibt einen Datenstring zurückdessen erstes Element der Typ der Netzwerkschnittstelle ist, der im betrachteten Paket angegeben ist, und dessen nachfolgende Elemente die Link-Layer-Adresse des Clients sind. Wenn kein Paket vorhanden ist oder das RFC2131-hlen-Feld ungültig ist, ist das Ergebnis null. Zu den Hardwaretypen gehören Ethernet (1), Token-Ring (6) und FDDI (8). Hardwaretypen werden von der IETF angegeben. Einzelheiten zur Definition der Typnummern finden Sie in RFC2131 (in der ISC-DHCP-Distribution ist dies im Unterverzeichnis doc/ enthalten).
Mit anderen Worten, hardware, 5, 6
es werden nicht das 5. und 6. Oktett der MAC-Adresse zurückgegeben, wie Sie vielleicht erwarten, sondern das 4. und 5., da das erste Element der Typ ist (0x01, da es sich um Ethernet handelt).