R/S giaddr

From: Hasse <eriksson.hans_at_gmail.com>
Date: Wed, 28 Mar 2012 11:56:49 +0200

Topology:
R1-DHCP-Server------SW1---------SW2-------R3-CLIENT
                                        |
                                R2-Client

R1 DHCP Server connected to SW1
R2 DHCP Client connected to SW1
R3 DHCP Client Connected to SW2
SW1 and SW2 dot1q trunk
Vlan 10 on all

Question 1:
Where or when does DHCP snooping interrupt and write to the Snooping DB?
Does Snooping place a place holder in the DB when the switch see the DHCPREG?
and writing the DB when seeing the ACK?

Question 2:

When using a cisco router as a DHCP server in my case R1 connected to
SW1 and Client R2.
I recive the following error:
*Mar 28 07:37:53.462: DHCPD: inconsistent relay information.
*Mar 28 07:37:53.462: DHCPD: relay information option exists, but
giaddr is zero.
Why?
My options are as follow

1) Turn off option 82 on the switch
    (no ip dhcp snooping information option)
2) On the DHCP server R1
    (ip dhcp relay information trusted)
3) ?
4) ?

Question 3:
I do not understand this problem fully, about giaddr.

This server and Client are sitting on the same subnet. That is why I
get the error. According to RFC I should be able to use following.

The server SHOULD select the IP address the server is using for
communication on that subnet as the 'server identifier'.

Giaddr = Relay agent ip address used in booting via a relay agent.

Giaddr from RFC 2131

      If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on
      the same subnet as the server. The server MUST
      broadcast the DHCPNAK message to the 0xffffffff broadcast address
      because the client may not have a correct network address or subnet
      mask, and the client may not be answering ARP requests.
      Otherwise, the server MUST send the DHCPNAK message to the IP
      address of the BOOTP relay agent, as recorded in 'giaddr'. The
      relay agent will, in turn, forward the message directly to the
      client's hardware address, so that the DHCPNAK can be delivered even
      if the client has moved to a new network.

   The 'server identifier' field is used both to identify a DHCP server
   in a DHCP message and as a destination address from clients to
   servers. A server with multiple network addresses MUST be prepared
   to to accept any of its network addresses as identifying that server
   in a DHCP message. To accommodate potentially incomplete network
   connectivity, a server MUST choose an address as a 'server
   identifier' that, to the best of the server's knowledge, is reachable
   from the client. For example, if the DHCP server and the DHCP client
   are connected to the same subnet (i.e., the 'giaddr' field in the
   message from the client is zero), the server SHOULD select the IP
   address the server is using for communication on that subnet as the
   'server identifier'. If the server is using multiple IP addresses on
   that subnet, any such address may be used. If the server has
   received a message through a DHCP relay agent, the server SHOULD
   choose an address from the interface on which the message was
   recieved as the 'server identifier' (unless the server has other,
   better information on which to make its choice). DHCP clients MUST
   use the IP address provided in the 'server identifier' option for any
   unicast requests to the DHCP server.

   DHCP messages broadcast by a client prior to that client obtaining
   its IP address must have the source address field in the IP header
   set to 0.

On R1 DHCP Server

*Mar 28 07:37:57.462: DHCPD: inconsistent relay information.
*Mar 28 07:37:57.462: DHCPD: relay information option exists, but
giaddr is zero.
*Mar 28 07:38:15.462: DHCPD: inconsistent relay information.
*Mar 28 07:38:15.462: DHCPD: relay information option exists, but
giaddr is zero.
*Mar 28 07:38:18.462: DHCPD: inconsistent relay information.
*Mar 28 07:38:18.462: DHCPD: relay information option exists, but
giaddr is zero.
*Mar 28 07:38:22.462: DHCPD: inconsistent relay information.
*Mar 28 07:38:22.462: DHCPD: relay information option exists, but
giaddr is zero.

On Switch1
0x52 0x12 0x1 0x6 0x0 0x4 0x0 0xA 0x1 0x4 0x2 0x8 0x0 0x6 0x0 0x1A
0xE3 0x31 0xF 0x0
*Mar 6 15:13:28.826: DHCP_SNOOPING_SW: bridge packet get invalid mat
entry: FFFF.FFFF.FFFF, packet
 is flooded to ingress VLAN: (10)
*Mar 6 15:13:32.358: DHCPSNOOP(hlfm_set_if_input): Setting if_input
to Fa1/0/2 for pak. Was not set
*Mar 6 15:13:32.358: DHCPSNOOP(hlfm_set_if_input): Clearing if_input
for pak. Was Fa1/0/2
*Mar 6 15:13:32.358: DHCPSNOOP(hlfm_set_if_input): Setting if_input
to Fa1/0/2 for pak. Was not set
*Mar 6 15:13:32.358: DHCP_SNOOPING: received new DHCP packet from
input interface (FastEthernet1/0/2)
*Mar 6 15:13:32.366: DHCP_SNOOPING: process new DHCP packet, message
type: DHCPDISCOVER, input interface: Fa1/0/2, MAC da: ffff.ffff.ffff,
MAC sa: 001d.46d1.fc68, IP da: 255.255.255.255, IP sa: 0.0.0.0, DHCP
ciaddr: 0.0.0.0, DHCP yiaddr: 0.0.0.0, DHCP siaddr: 0.0.0.0, DHCP
giaddr: 0.0.0.0, DHCP chaddr: 001d.46d1.fc68
*Mar 6 15:13:32.366: DHCP_SNOOPING: add relay information option.
*Mar 6 15:13:32.366: DHCP_SNOOPING_SW: Encoding opt82 CID in
vlan-mod-port format
*Mar 6 15:13:32.366: DHCP_SNOOPING_SW: Encoding opt82 RID in MAC address format
*Mar 6 15:13:32.366: DHCP_SNOOPING: binary dump of relay info option,
length: 20 data:
0x52 0x12 0x1 0x6 0x0 0x4 0x0 0xA 0x1 0x4 0x2 0x8 0x0 0x6 0x0 0x1A
0xE3 0x31 0xF 0x0
*Mar 6 15:13:32.366: DHCP_SNOOPING_SW: bridge packet get invalid mat
entry: FFFF.FFFF.FFFF, packet is flooded to ingress VLAN: (10)
*Mar 6 15:13:36.359: DHCPSNOOP(hlfm_set_if_input): Setting if_input
to Fa1/0/2 for pak. Was not set
*Mar 6 15:13:36.359: DHCPSNOOP(hlfm_set_if_input): Clearing if_input
for pak. Was Fa1/0/2
*Mar 6 15:13:36.359: DHCPSNOOP(hlfm_set_if_input): Setting if_input
to Fa1/0/2 for pak. Was not set
*Mar 6 15:13:36.359: DHCP_SNOOPING: received new DHCP packet from
input interface (FastEthernet1/0/2)
*Mar 6 15:13:36.359: DHCP_SNOOPING: process new DHCP packet, message
type: DHCPDISCOVER, input interfac

Blogs and organic groups at http://www.ccie.net
Received on Wed Mar 28 2012 - 11:56:49 ART

This archive was generated by hypermail 2.2.0 : Sun Apr 01 2012 - 07:56:52 ART