Frage Die dhcp-snooping-Option 82 löscht gültige DHCP-Anfragen auf Procurve-Switches der 2610-Serie


Wir beginnen langsam, Dhcp-Snooping auf unseren Switches der HP ProCurve 2610-Serie zu implementieren, die alle die R.11.72-Firmware ausführen. Ich sehe ein merkwürdiges Verhalten, bei dem Dhcp-Request- oder Dhcp-Reneven-Pakete fallengelassen werden, wenn sie von "Downstream" -Schaltern aufgrund "nicht vertrauenswürdiger Relay-Informationen vom Client" stammen.

Der vollständige Fehler:

Received untrusted relay information from client <mac-address> on port <port-number>

Genauer gesagt haben wir einen 48 Port HP2610 (Switch A) und einen 24 Port HP2610 (Switch B). Der Switch B ist "downstream" von Switch A aufgrund einer DSL-Verbindung zu einem der Switch-A-Ports. Der DHCP-Server ist mit Switch A verbunden. Die relevanten Bits sind wie folgt:

Schalter A 

dhcp-snooping
dhcp-snooping authorized-server 192.168.0.254
dhcp-snooping vlan 1 168
interface 25
    name "Server"
    dhcp-snooping trust
exit


Schalter B

dhcp-snooping
dhcp-snooping authorized-server 192.168.0.254
dhcp-snooping vlan 1
interface Trk1
   dhcp-snooping trust
exit

Die Switches sind so eingestellt, dass sie sowohl dem Port, an den der autorisierte dhcp-Server angeschlossen ist, als auch seiner IP-Adresse vertrauen. Das ist alles gut und gut für die Clients, die an Switch A angeschlossen sind, aber die an Switch B angeschlossenen Clients werden aufgrund des Fehlers "nicht vertrauenswürdige Relay-Informationen" abgelehnt. Dies ist aus einigen Gründen komisch: 1) dhcp-relay ist auf keinem Switch konfiguriert, 2) das Layer-3-Netzwerk ist hier flach, dasselbe Subnetz. DHCP-Pakete sollten kein modifiziertes Attribut der Option 82 haben.

dhcp-relay scheint jedoch standardmäßig aktiviert zu sein:

SWITCH A# show dhcp-relay
  DHCP Relay Agent         : Enabled 
  Option 82                : Disabled
  Response validation      : Disabled
  Option 82 handle policy  : append
  Remote ID                : mac  


  Client Requests       Server Responses

  Valid      Dropped    Valid      Dropped   
  ---------- ---------- ---------- ----------
  0          0          0          0         

SWITCH B# show dhcp-relay
  DHCP Relay Agent         : Enabled 
  Option 82                : Disabled
  Response validation      : Disabled
  Option 82 handle policy  : append
  Remote ID                : mac  


  Client Requests       Server Responses

  Valid      Dropped    Valid      Dropped   
  ---------- ---------- ---------- ----------
  40156      0          0          0         

Und interessanterweise scheint der DHCP-Relay-Agent auf Switch B sehr beschäftigt zu sein, aber warum? Soweit ich das beurteilen kann, gibt es keinen Grund, warum Dhcp-Anfragen ein Relay mit dieser Topologie benötigen. Außerdem kann ich nicht sagen, warum der Upstream-Switch legitime DHCP-Anfragen für nicht vertrauenswürdige Relay-Informationen löscht, wenn der betreffende Relay-Agent (auf Switch B) die Option 82-Attribute sowieso nicht modifiziert.

Hinzufügen der no dhcp-snooping option 82 on Switch A ermöglicht, dass der DHCP-Verkehr von Switch B durch Switch A genehmigt wird, indem nur diese Funktion ausgeschaltet wird. Was sind die Auswirkungen von nicht Validierung der Option 82 modifizierten DHCP-Verkehr? Wenn ich die Option 82 für alle meine "Upstream" -Schalter deaktiviere - werden sie Dhcp-Verkehr von jedem Downstream-Switch unabhängig von der Berechtigung dieses Datenverkehrs weiterleiten?

Dieses Verhalten ist Client-Betriebssystem Agnostisch. Ich sehe es mit Windows- und Linux-Clients. Unsere DHCP-Server sind entweder Windows Server 2003- oder Windows Server 2008 R2-Computer. Ich sehe dieses Verhalten unabhängig vom Betriebssystem des DHCP-Servers.

Kann jemand etwas Licht auf das, was hier passiert, werfen und mir einige Empfehlungen geben, wie ich mit der Einstellung der Option 82 fortfahren sollte? Ich habe das Gefühl, dass ich das DHCP-Relaying und die Optionen der Option 82 nicht vollständig geknackt habe.


8
2018-02-28 01:54


Ursprung


Sind die DHCP-Server im selben Subnetz oder werden sie von einem Router weitergeleitet? Ich weiß Cisco Router / L3-Schalter erfordern IP-DHCP-Relay-Informationen Trust-All-Befehl, wenn sie die DHCP-Forward tun. - Bad Dos
Sie sind im selben Subnetz. Alles ist völlig flach von einer Schicht-3-Perspektive. - kce
Funktioniert DHCP ordnungsgemäß, wenn Sie einen Laptop in den Switch stecken, der direkt mit dem DHCP-Server verbunden ist? Möglicherweise ist einer der Uplinks in Ihrer Switch-Topologie nicht vertrauenswürdig. - Bad Dos
Ja. Es funktioniert, wenn der Computer mit demselben Switch wie der DHCP-Server verbunden ist. Ich vertraue dem Uplink-Port auf dem Upstream-Switch nicht. Sie vertrauen nur Ports, von denen die DHCPOFFER- oder DHCPACK-Pakete stammen - der Port, an den der DHCP-Server angeschlossen ist. Wenn ich dem Trunk-Port des Upstream-Switches vertraute, würde der Switch einem DHCP-Server erlauben, über diesen Uplink zu seinen Clients zu antworten. FWIW, ich habe eine Supportanfrage in der mit HP und sie scheinen ähnlich verwirrt zu sein. - kce
Ich bin mit HP nicht vertraut, aber in Cisco würden Sie dem Uplink-Port auf dem Zugriffsschalter vertrauen, aber der Switch, mit dem es sich verbindet, würde diesem Port nicht vertrauen. Dies stellt sicher, dass DHCP-Angebote zu dem Zugriffsschalter hinunter fließen können, dass jedoch nichts von dem Zugriffsschalter kommt und auch keine anderen Ports auf dem Zugriffsschalter vertrauenswürdig sind. - Bad Dos


Antworten:


Du hast gesagt, dass "dhcp relay nicht aktiviert ist" ... aber klar ist es, basierend auf deiner show dhcp-relay output.

Versuchen Sie es explizit zu deaktivieren; aufgrund der obigen Kommentare vermute ich, dass dein Problem verschwinden wird :)


1
2018-01-02 21:29





Tatsächlich wird das Paket auf Switch A heruntergefahren, weil Sie ein DHCP-Client-Paket mit Option82 auf einem nicht vertrauenswürdigen Port erhalten haben. Diese Option-82 wird vom SwitchB eingefügt.

Ich denke unten sollte funktionieren -

An, SchalterB - Deaktivieren Sie Option 82, damit diese Optionen nicht eingefügt werden. Markieren Sie die Schnittstelle-25 als vertrauenswürdig, damit das DHCP-Server-Paket zum Server fließen kann.

Ein, SwitchA- Sie können Option-82 hier aktivieren / deaktivieren. es sollte nicht wichtig sein. Markieren Sie den Port, der mit SwitchB verbunden ist, als nicht vertrauenswürdig. Markieren Sie den Port, der mit dem DHCP-Server verbunden ist, als vertrauenswürdig.


1
2017-12-02 06:32





Ich denke, Sie könnten die Idee eines vertrauenswürdigen Ports falsch interpretieren. Ich stimme zu, dass das Vertrauen in die Ports, von denen die Angebote kommen, intuitiv ist, aber mein Verständnis ist, dass Sie auch dem Trunk-Port von Switch A vertrauen müssen. Sie markieren vertrauenswürdige Ports, die mit Geräten verbunden sind, die Sie kennen und denen Sie vertrauen. Nur weil Sie den Trunk auf Switch A als vertrauenswürdig markieren, bedeutet das nicht, dass Sie zulassen, dass ein bösartiger DHCP-Server auf Switch B existiert. Bei korrekter Konfiguration traut Switch B keinem anderen Port als dem Trunk haben noch verhindert, dass ein bösartiger DHCP-Server auf Switch B sitzt und Angebote an Clients auf Switch A sendet.

Kurz gesagt, Sie sollten Ports vertrauen, die mit Ihren eigenen DHCP-Servern und Ports verbunden sind, die mit anderen Switches verbunden sind, die Sie verwalten (Sie können also sicher sein, dass es keine anderen vertrauenswürdigen Ports gibt).


0
2017-07-12 17:52