DHCP Snooping - Option 82

Marsh Posté le 23-06-2013 à 12:02:36

Bonjour,

J'aimerai des explications sur l'option 82 du DHCP snooping.

Voici la situation:

J'utilise un switch (Cisco 3550) sur lequel sont connectés plusieurs postes dans différent VLAN et un routeur (Cisco 1751) est connecté en trunk sur ce même switch.
Ce routeur fait office de serveur DHCP pour chaque VLAN.

Lorsque je configure le DHCP snooping je suis obligé de désactiver l'option 82 sinon mes postes ne reçoivent aucunes adresses.

J'ai cru comprendre que cela était du au fait que l'option 82 (activée par défaut) est utilisée pour retracer la provenance d'une trame DHCP.

Quelqu'un aurait plus d'explication ?

Merci

Reply

Marsh Posté le 23-06-2013 à 12:02:36

Reply

Marsh Posté le 23-06-2013 à 12:08:58

Ton problème vient peut etre de là :

Code :

As you know, DHCP relay is supposed to insert the “giaddr” field in the relayed DHCP packets, so that DHCP server may identify the pool to be used for the request. The choice of the pool is made based on the “giaddr” field or the incoming interface, if the “giaddr” is missing or zero . Option 82 serves as refinement to the request, allowing the DHCP server to select a “sub-range” in the pool. (Notice that by default Cisco IOS devices reject packets with zero “giaddr” and by default Cisco Catalyst switches use “giaddr” of zero when configured for DHCP snooping!)

Code :

However, at least the Cisco DHCP Server implementation in IOS performs a sanity check on received DHCP messages and it drops DHCP messages that contain the Option 82 but whose GIADDR field is set to 0.0.0.0 (i.e. unitialized). This can be seen the debug ip dhcp server packet output

Liens :
http://blog.ine.com/2009/07/22/und [...] option-82/
https://supportforums.cisco.com/thread/2060498

Message cité 1 fois
Message édité par HJ le 23-06-2013 à 12:12:38

Reply

Marsh Posté le 23-06-2013 à 12:11:27

Voici un extrait de ma running du switch:

Conf globale

ip dhcp snooping vlan 10-50
no ip dhcp snooping information option
ip dhcp snooping

Et interface

interface FastEthernet0/33
description RT Mother
switchport trunk encapsulation dot1q
switchport trunk native vlan 10
switchport mode trunk
switchport nonegotiate
ip dhcp snooping trust
end

Reply

Marsh Posté le 23-06-2013 à 12:22:48

HJ a écrit :

Ton problème vient peut etre de là :

Code :

As you know, DHCP relay is supposed to insert the “giaddr” field in the relayed DHCP packets, so that DHCP server may identify the pool to be used for the request. The choice of the pool is made based on the “giaddr” field or the incoming interface, if the “giaddr” is missing or zero . Option 82 serves as refinement to the request, allowing the DHCP server to select a “sub-range” in the pool. (Notice that by default Cisco IOS devices reject packets with zero “giaddr” and by default Cisco Catalyst switches use “giaddr” of zero when configured for DHCP snooping!)

Code :

However, at least the Cisco DHCP Server implementation in IOS performs a sanity check on received DHCP messages and it drops DHCP messages that contain the Option 82 but whose GIADDR field is set to 0.0.0.0 (i.e. unitialized). This can be seen the debug ip dhcp server packet output

Liens :
http://blog.ine.com/2009/07/22/und [...] option-82/
https://supportforums.cisco.com/thread/2060498

Ça me semble pas mal comme explication.

Je vais jeter un oeil sur le debug pour comparer avec et sans l'option 82.

Merci pour ta réponse

Reply

Marsh Posté le 23-06-2013 à 12:28:25

Bingo

Voici le debug en activant l'option 82

Mother#
02:02:35: DHCPD: inconsistent relay information.
02:02:35: DHCPD: relay information option exists, but giaddr is zero.

Alors qu'en la désactivant

Mother#
01:59:16: DHCPD: DHCPREQUEST received from client 0100.2318.7e0a.5a.
01:59:16: DHCPD: client has moved to a new subnet.
01:59:16: DHCPD: Sending DHCPNAK to client 0100.2318.7e0a.5a.
01:59:16: DHCPD: broadcasting BOOTREPLY to client 0023.187e.0a5a.
01:59:16: DHCPD: DHCPDISCOVER received from client 0100.2318.7e0a.5a on interface FastEthernet0/0.30.
01:59:16: DHCPD: Sending DHCPOFFER to client 0100.2318.7e0a.5a (192.168.30.20).
01:59:16: DHCPD: creating ARP entry (192.168.30.20, 0023.187e.0a5a).
01:59:16: DHCPD: unicasting BOOTREPLY to client 0023.187e.0a5a (192.168.30.20).
01:59:16: DHCPD: DHCPREQUEST received from client 0100.2318.7e0a.5a.
Mother#
01:59:16: DHCPD: Sending DHCPACK to client 0100.2318.7e0a.5a (192.168.30.20).
01:59:16: DHCPD: creating ARP entry (192.168.30.20, 0023.187e.0a5a).
01:59:16: DHCPD: unicasting BOOTREPLY to client 0023.187e.0a5a (192.168.30.20).
Mother#
01:59:20: DHCPD: DHCPINFORM received from client 0100.2318.7e0a.5a (192.168.30.20).
01:59:20: DHCPD: Sending DHCPACK to client 0100.2318.7e0a.5a (192.168.30.20).
01:59:20: DHCPD: unicasting BOOTREPLY to client 0023.187e.0a5a (192.168.30.20).

Reply

Marsh Posté le 23-06-2013 à 12:41:30

Je pensais également au DHCP relay, mais je ne voyais pas pourquoi cette notion entrait en ligne de compte avec ma topo, étant donné que mon serveur DHCP est en direct sur le switch.

J'imagine que le fait d'avoir plusieurs serveurs DHCP (un par VLAN) relié au switch en trunk reviens au même.

Reply

Marsh Posté le 23-06-2013 à 16:29:42

si tu veux une trace, un log des attributions dhcp, pourquoi ne le fais tu pas au niveau du serveur dhcp au lieu du switch?

Message cité 1 fois

Reply

Marsh Posté le 23-06-2013 à 18:31:00

trekker92 a écrit :

si tu veux une trace, un log des attributions dhcp, pourquoi ne le fais tu pas au niveau du serveur dhcp au lieu du switch?

Mon debug est bien au niveau du routeur qui est mon serveur DHCP.

Ça me paraissait plus pertinent de le faire sur le routeur.

Reply

DHCP Snooping - Option 82

Sujets relatifs:

Leave a Replay