L'opzione dhcp-snooping 82 elimina le richieste dhcp valide sugli switch Procurve serie 2610

Stiamo lentamente iniziando a implementare lo snooping dhcp sui nostri switch HP ProCurve serie 2610, tutti con il firmware R.11.72. Sto vedendo uno strano comportamento in cui i pacchetti dhcp-request o dhcp-renew vengono eliminati quando provengono da switch "downstream" a causa di "informazioni di relay non attendibili dal client".

L'errore completo:

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

Più in dettaglio, abbiamo un HP2610 a 48 porte (Switch A) e un HP2610 a 24 porte (Switch B). Lo switch B è "a valle" dello switch A in virtù di una connessione DSL a una delle porte dello switch A. Il server dhcp è collegato allo switch A. I bit rilevanti sono i seguenti:

Interruttore A

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

Interruttore B

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

Gli switch sono impostati in modo da fidarsi di ENTRAMBE la porta a cui è collegato il server dhcp autorizzato e il suo indirizzo IP. Questo va bene per i client collegati allo Switch A, ma i client collegati allo Switch B vengono negati a causa dell'errore "informazioni di relè non attendibili". Questo è strano per alcuni motivi 1) dhcp-relay non è configurato su nessuno dei due switch, 2) la rete Layer-3 qui è piatta, stessa sottorete. I pacchetti DHCP non dovrebbero avere un attributo opzione 82 modificato.

dhcp-relay sembra essere abilitato di default comunque:

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         

E abbastanza interessante l'agente dhcp-relay sembra molto impegnato su Switch B, ma perché? Per quanto ne so, non vi è alcun motivo per cui le richieste DHCP abbiano bisogno di un relè con questa topologia. Inoltre, non riesco a capire perché lo switch upstream stia rilasciando richieste dhcp legittime per informazioni di relay non attendibili quando l'agente di relay in questione (su Switch B) non sta modificando comunque gli attributi dell'opzione 82.

L'aggiunta dell'interruttore no dhcp-snooping option 82A attivo consente al traffico dhcp proveniente dall'interruttore B di essere approvato dall'interruttore A, semplicemente disattivando tale funzione. Quali sono le ripercussioni della mancata convalida dell'opzione 82 traffico dhcp modificato? Se disabilito l'opzione 82 su tutti i miei switch "upstream", passeranno il traffico dhcp da qualsiasi switch downstream indipendentemente dalla legittimità di quel traffico?

Questo comportamento è indipendente dal sistema operativo client. Lo vedo con client Windows e Linux. I nostri server DHCP sono macchine Windows Server 2003 o Windows Server 2008 R2. Vedo questo comportamento indipendentemente dal sistema operativo dei server DHCP.

Qualcuno può far luce su ciò che sta accadendo qui e darmi alcuni consigli su come dovrei procedere con la configurazione dell'opzione 82? Mi sento come se non avessi completamente grokked dhcp-relaying e l'opzione 82 attributi.

Hai detto che "dhcp relay non è abilitato" ... ma chiaramente lo è, in base al tuo show dhcp-relay output.

Prova a disabilitarlo esplicitamente; in base ai commenti sopra sospetto che il tuo problema scompaia :)

In realtà, il pacchetto sullo switch A si sta abbassando perché hai ricevuto un pacchetto client DHCP con option82 su una porta non attendibile. Questa opzione-82 viene inserita dallo switchB.

Penso che sotto dovrebbe funzionare -

On, SwitchB - disabilita l'opzione 82 in modo che non inserisca queste opzioni. contrassegnare l'interfaccia-25 come attendibile per consentire al pacchetto del server DHCP di scorrere verso il basso.

On, SwitchA- Qui è possibile abilitare / disabilitare l'opzione-82. non dovrebbe importare. contrassegnare la porta connessa a switchB come non attendibile. contrassegnare la porta che è connessa al server dhcp come attendibile.

Penso che potresti interpretare erroneamente l'idea di una porta affidabile. Sono d'accordo sul fatto che fidarsi solo delle porte da cui provengono le offerte sia intuitivo, ma capisco che è necessario fidarsi anche della porta trunk sullo Switch A. Contrassegni le porte come affidabili che sono connesse ad apparecchiature che conosci e di cui ti fidi. Solo perché si contrassegna il trunk sullo switch A come attendibile non significa che si consentirà l'esistenza di un server DHCP non valido sullo switch B. Se impostato correttamente, lo switch B non si fida di alcuna porta diversa dal suo trunk, quindi hanno ancora impedito a un server DHCP non autorizzato di passare sullo switch B e di inviare offerte ai client sullo switch A.

In breve, dovresti fidarti delle porte connesse ai tuoi server DHCP e delle porte connesse ad altri switch che gestisci (quindi puoi essere sicuro che non ci siano altre porte fidate).