Access-Listen und DHCPOFFER

Vorgestern hatte ich ein interessantes Thema, bei dem ein Access-Point mit einer input-address-list und output-address-list auf dem Dot11Radio-Interface bei dem ein Windows Server mit DHCP-Rolle keine IP Adressen an Clients im WLAN verteilt hat.

Der Grund war, dass auf dem Dot11Radio-Interface die identische Access-Liste gebunden, welche keine Broadcasts durchließ. Warum? Der Grund liegt hinter der Idee von den entsprechenden ACL’s. Diese stellen nicht die Richtung dar sondern ob source (input) oder destination (output) Address.

Die Lösung letztendlich war denkbar übersichtlich, zwei verschiedene Access-Listen zu erstellen.

interface Dot11Radio0
! […]
bridge-group 1 input-address-list 700
bridge-group 1 output-address-list 701
! […]
access-list 700 permit 6067.20aa.1234 0000.0000.0000
access-list 700 deny 0000.0000.0000 ffff.ffff.ffff
access-list 701 permit 6067.20aa.1234 0000.0000.0000
access-list 701 permit 0000.0000.0000 0000.0000.0000
access-list 701 permit ffff.ffff.ffff 0000.0000.0000
access-list 701 deny 0000.0000.0000 ffff.ffff.ffff

Übrigens in einer Laborumgebung habe ich das nochmal mit einem Cisco Router als DHCP-Server getestet. Hier hat es auch ohne Broadcastadresse in der zweiten ACL Funktioniert.

Der Grund liegt in der Verteilung des DHCPOFFERS vom DHCP-Server. Windows Server nutzen hier abhängig vom Broadcast Bit im DHCPDISCOBVER Broadcast zur Verteilung, siehe KB169289 (http://support.microsoft.com/kb/169289/en-us).

Da obiges Beispiel im Layer 2 spielt ist die Broadcast- oder Unicast-Implementierung abhängig vom Hersteller.

Weiterführende Infos: http://www.ietf.org/rfc/rfc2131.txt

Schreibe einen Kommentar

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

Time limit is exhausted. Please reload CAPTCHA.