Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
New Member

Snooping problem - Hardware Code Type 0

Hi all ,

 

I would like to ask you do you know or did someone meet whit this issue on CMTS 7246VXR  IOS : ubr7200-ik9su2-mz.123-23.BC10.bin

Issue is that CMTS sends DHCP packet with Hardware Code Type 0  and it should be 1 , so that huawei router reports this  error message.

 

 

Line 24887: Sep 11 2014 01:24:47+02:00 DST PG-NPE1 %%01SNOOPING/4/HTYPEERR(l)[342123]:Slot=5,Vcpu=0;The type of hardware address in DHCP packet received from interface GigabitEthernet5/0/1.1001 VLAN 1001 was wrong!

 

 

 

RFC 2131          Dynamic Host Configuration Protocol         March 1997

 

 

   DHCP clarifies the interpretation of the 'siaddr' field as the

   address of the server to use in the next step of the client's

   bootstrap process.  A DHCP server may return its own address in the

   'siaddr' field, if the server is prepared to supply the next

   bootstrap service (e.g., delivery of an operating system executable

   image).  A DHCP server always returns its own address in the 'server

   identifier' option.

 

   FIELD      OCTETS       DESCRIPTION

   -----      ------       -----------

 

   op            1  Message op code / message type.

                    1 = BOOTREQUEST, 2 = BOOTREPLY

   htype         1  Hardware address type, see ARP section in "Assigned

                    Numbers" RFC; e.g., '1' = 10mb ethernet.

   hlen          1  Hardware address length (e.g.  '6' for 10mb

                    ethernet).

 

 

Is this already know bug ?

KR 

VZ

 

2 REPLIES
New Member

I don't see the problem based

I don't see the problem based on RFC2132 or RFC5494.

In RFC2132:

The client identifier MAY consist of type-value pairs similar to the
   'htype'/'chaddr' fields defined in [3]. For instance, it MAY consist
   of a hardware type and hardware address. In this case the type field
   SHOULD be one of the ARP hardware types defined in STD2 [22].  A
   hardware type of 0 (zero) should be used when the value field
   contains an identifier other than a hardware address (e.g. a fully
   qualified domain name).

May be the CMTS is doing a DHCP Inform request with is FQDN in the adresse instead of hardware address.

Could you do packet capture on the DHCP packet?

 

 

New Member

Debug from CMTS : *Nov  4 04

Debug from CMTS :

 

*Nov  4 04:33:26.959: DHCPD: forwarding BOOTREPLY to client 0021.27e3.4deb.
*Nov  4 04:33:26.959: DHCPD: validating relay information option.
*Nov  4 04:33:26.959: DHCPD: broadcasting BOOTREPLY to client 0021.27e3.4deb.
*Nov  4 04:33:26.967: DHCPD: cannot load local addresses for Bundle1.1.
*Nov  4 04:33:26.967: DHCPD: cannot load local addresses for Bundle1.1.
*Nov  4 04:33:26.967: DHCPD: cannot load local addresses for Bundle1.1.
*Nov  4 04:33:26.971: DHCPD: setting giaddr to 10.7.0.1.
*Nov  4 04:33:26.971: DHCPD: adding relay information option.
*Nov  4 04:33:26.971: DHCPD: BOOTREQUEST from 0100.1cea.8077.ad forwarded to x.x.x.x.
*Nov  4 04:33:26.975: DHCPD: forwarding BOOTREPLY to client 001c.ea80.77ad.
*Nov  4 04:33:26.975: DHCPD: validating relay information option.
*Nov  4 04:33:26.975: DHCPD: creating ARP entry (10.7.6.153, 001c.ea80.77ad).
*Nov  4 04:33:26.975: DHCPD: unicasting BOOTREPLY to client 001c.ea80.77ad (10.7.6.153).
*Nov  4 04:33:27.031: DHCPD: setting giaddr to 10.7.0.1.
*Nov  4 04:33:27.031: DHCPD: adding relay information option.
*Nov  4 04:33:27.031: DHCPD: BOOTREQUEST from 0100.1cea.7cb5.b2 forwarded to x.x.x.x.
*Nov  4 04:33:27.031: DHCPD: forwarding BOOTREPLY to client 001c.ea7c.b5b2.
*Nov  4 04:33:27.031: DHCPD: validating relay information option.
*Nov  4 04:33:27.031: DHCPD: creating ARP entry (10.7.5.248, 001c.ea7c.b5b2).
*Nov  4 04:33:27.031: DHCPD: unicasting BOOTREPLY to client 001c.ea7c.b5b2 (10.7.5.248).
*Nov  4 04:33:27.039: DHCPD: setting giaddr to 10.7.0.1.
*Nov  4 04:33:27.039: DHCPD: adding relay information option.
*Nov  4 04:33:27.039: DHCPD: BOOTREQUEST from ff26.ec78.5200.0300.01c8.fb26.ec78.52 forwarded to x.x.x.x
*Nov  4 04:33:27.043: DHCPD: forwarding BOOTREPLY to client c8fb.26ec.7852.
*Nov  4 04:33:27.043: DHCPD: validating relay information option.
*Nov  4 04:33:27.043: DHCPD: creating ARP entry (10.7.2.3, c8fb.26ec.7852).
*Nov  4 04:33:27.043: DHCPD: unicasting BOOTREPLY to client c8fb.26ec.7852 (10.7.2.3).
*Nov  4 04:33:27.051: DHCPD: cannot determine client hardware address.
*Nov  4 04:33:27.051: DHCPD: excessive retransmissions from client .
*Nov  4 04:33:27.051: DHCPD: switching to relay address 109.72.96.1.
*Nov  4 04:33:27.051: DHCPD: setting giaddr to 109.72.96.1.
*Nov  4 04:33:27.051: DHCPD: adding relay information option.
*Nov  4 04:33:27.051: DHCPD: BOOTREQUEST from  forwarded to x.x.x.x.
*Nov  4 04:33:27.051: DHCPD: invalid opcode (0).
*Nov  4 04:33:27.063: DHCPD: setting giaddr to 10.7.0.1.
*Nov  4 04:33:27.063: DHCPD: adding relay information option.
*Nov  4 04:33:27.063: DHCPD: BOOTREQUEST from 0100.1cea.4a3e.64 forwarded to x.x.x.x.
*Nov  4 04:33:27.067: DHCPD: forwarding BOOTREPLY to client 001c.ea4a.3e64.
*Nov  4 04:33:27.067: DHCPD: validating relay information option.
*Nov  4 04:33:27.067: DHCPD: creating ARP entry (10.7.0.58, 001c.ea4a.3e64).
*Nov  4 04:33:27.067: DHCPD: unicasting BOOTREPLY to client 001c.ea4a.3e64 (10.7.0.58).
*Nov  4 04:33:27.075: DHCPD: setting giaddr to 10.7.0.1.
*Nov  4 04:33:27.075: DHCPD: adding relay information option.
*Nov  4 04:33:27.075: DHCPD: BOOTREQUEST from 0100.1cea.7cbc.3f forwarded to x.x.x.x.
*Nov  4 04:33:27.079: DHCPD: forwarding BOOTREPLY to client 001c.ea7c.bc3f.
*Nov  4 04:33:27.079: DHCPD: validating relay information option.
*Nov  4 04:33:27.079: DHCPD: creating ARP entry (10.7.4.80, 001c.ea7c.bc3f).
*Nov  4 04:33:27.079: DHCPD: unicasting BOOTREPLY to client 001c.ea7c.bc3f (10.7.4.80).
*Nov  4 04:33:27.103: DHCPD: setting giaddr to 10.7.0.1.
*Nov  4 04:33:27.103: DHCPD: adding relay information option.
*Nov  4 04:33:27.103: DHCPD: BOOTREQUEST from 0100.1cea.7cbf.1b forwarded to x.x.x.x

x.x.x.x is the DHCP server.

 

Is this bug ?

 

KR

VZ

139
Views
0
Helpful
2
Replies
CreatePlease to create content