From: Scott Morris (swm@emanon.com)
Date: Wed Jan 28 2004 - 23:09:27 GMT-3
It's acutally very interesting... (But this is a really long messge for
those who don't care!)
The initial request when "ip address dhcp" is enabled:
emanon-3550-1#
16w4d: DHCPD: DHCPDISCOVER received from client
0063.6973.636f.2d30.3031.302e.3762.3435.2e30.6133.312d.4574.312f.30 on
interface Vlan30.
emanon-3550-1#
16w4d: DHCPD: DHCPDISCOVER received from client
0063.6973.636f.2d30.3031.302e.3762.3435.2e30.6133.312d.4574.312f.30 on
interface Vlan30.
emanon-3550-1#
16w4d: DHCPD: DHCPDISCOVER received from client
0063.6973.636f.2d30.3031.302e.3762.3435.2e30.6133.312d.4574.312f.30 on
interface Vlan30.
emanon-3550-1#
This would explain why your client-id portion in the DHCP server config
would be what worked. You can change this with extra parameters on the
client side to use a MAC address:
Emanon-R9(config-if)#ip address dhcp client-id ethernet 1/0
This is noted in the docs:
http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_command_refe
rence_chapter09186a0080087376.html#1049289
Once this is done, it doesn't get much better though!
emanon-3550-1#
16w4d: DHCPD: DHCPDISCOVER received from client 0100.107b.450a.31 on
interface Vlan30.
emanon-3550-1#
16w4d: DHCPD: DHCPDISCOVER received from client 0100.107b.450a.31 on
interface Vlan30.
emanon-3550-1#
16w4d: DHCPD: DHCPDISCOVER received from client 0100.107b.450a.31 on
interface Vlan30.
emanon-3550-1#
The MAC address for the interface in question is actually 0010.7b45.0a31.
The leading "01" denotes ethernet style request. I haven't got a clue why
this is part of what is seen...
Even when changing the dhcp-server side of things:
hardware-address 0100.107b.450a.31
It still doesn't actually match anything. Things that make you go Hmmmmm...
However... When watching the debug (previously I was looking at "debug ip
dhcp server packet") it gave the above information. More information was
obtained by adding "debug ip dhcp server event" to the fray!
emanon-3550-1#sh deb
DHCP server packet debugging is on.
DHCP server event debugging is on.
emanon-3550-1#
16w4d: DHCPD: DHCPDISCOVER received from client 0100.107b.450a.31 on
interface Vlan30.
16w4d: DHCPD: there is no address pool for 30.30.30.30.
emanon-3550-1#
16w4d: DHCPD: DHCPDISCOVER received from client 0100.107b.450a.31 on
interface Vlan30.
16w4d: DHCPD: there is no address pool for 30.30.30.30.
emanon-3550-1#
16w4d: DHCPD: DHCPDISCOVER received from client 0100.107b.450a.31 on
interface Vlan30.
16w4d: DHCPD: there is no address pool for 30.30.30.30.
emanon-3550-1#
30.30.30.30 in my case was the "default-router" option in the dhcp pool
configuration. So, even though it was manually set on the dhcp
server/router's interface, I created a pool for giggles.
!
ip dhcp pool vlan30
host 30.30.30.5 255.255.255.0
hardware-address 0100.107b.450a.31
default-router 30.30.30.30
!
ip dhcp pool vlan30-main
network 30.30.30.0 255.255.255.0
default-router 30.30.30.30
!
As soon as this was done, things magically worked! Amazing stuff...
emanon-3550-1#
16w4d: DHCPD: DHCPDISCOVER received from client 0100.107b.450a.31 on
interface Vlan30.
emanon-3550-1#
16w4d: %IP-4-DUPADDR: Duplicate address 30.30.30.30 on Vlan30, sourced by
0002.1651.1621
emanon-3550-1#
16w4d: DHCPD: assigned IP address 30.30.30.1 to client 0100.107b.450a.31.
16w4d: DHCPD: Sending DHCPOFFER to client 0100.107b.450a.31 (30.30.30.1).
16w4d: DHCPD: broadcasting BOOTREPLY to client 0010.7b45.0a31.
16w4d: DHCPD: DHCPDISCOVER received from client 0100.107b.450a.31 on
interface Vlan30.
16w4d: DHCPD: Sending DHCPOFFER to client 0100.107b.450a.31 (30.30.30.1).
16w4d: DHCPD: broadcasting BOOTREPLY to client 0010.7b45.0a31.
16w4d: DHCPD: DHCPDISCOVER received from client 0100.107b.450a.31 on
emanon-3550-1# interface Vlan30.
16w4d: DHCPD: Sending DHCPOFFER to client 0100.107b.450a.31 (30.30.30.1).
16w4d: DHCPD: broadcasting BOOTREPLY to client 0010.7b45.0a31.
16w4d: DHCPD: DHCPREQUEST received from client 0100.107b.450a.31.
16w4d: DHCPD: Sending DHCPACK to client 0100.107b.450a.31 (30.30.30.1).
16w4d: DHCPD: broadcasting BOOTREPLY to client 0010.7b45.0a31.
emanon-3550-1#
But it didn't really...
emanon-3550-1#sh ip dhcp bind
IP address Hardware address Lease expiration Type
30.30.30.2 0100.107b.450a.31 Jun 26 1993 05:06 AM Automatic
30.30.30.5 0010.7b45.0a31 Infinite Manual
The .5 was manually assigned, the other automatically. Back to that drawing
board. :)
So I put in an excluded range for giggles (to start at 100). Cleared the
bindings and all that jazz...
emanon-3550-1#clear ip dhcp bind *
emanon-3550-1#sh ip dhcp bind
16w4d: DHCPD: returned 30.30.30.2 to address pool vlan30-main.
emanon-3550-1#sh ip dhcp bind
IP address Hardware address Lease expiration Type
30.30.30.5 0100.107b.450a.31 Infinite Manual
emanon-3550-1#
And when the other router was reset...
emanon-3550-1#
16w4d: DHCPD: DHCPDISCOVER received from client 0100.107b.450a.31 on
interface Vlan30.
emanon-3550-1#
16w4d: %IP-4-DUPADDR: Duplicate address 30.30.30.30 on Vlan30, sourced by
0002.1651.1621
emanon-3550-1#
16w4d: DHCPD: assigned IP address 30.30.30.100 to client 0100.107b.450a.31.
16w4d: DHCPD: Sending DHCPOFFER to client 0100.107b.450a.31 (30.30.30.100).
16w4d: DHCPD: broadcasting BOOTREPLY to client 0010.7b45.0a31.
16w4d: DHCPD: DHCPDISCOVER received from client 0100.107b.450a.31 on
interface Vlan30.
16w4d: DHCPD: Sending DHCPOFFER to client 0100.107b.450a.31 (30.30.30.100).
16w4d: DHCPD: broadcasting BOOTREPLY to client 0010.7b45.0a31.
16w4d: DHCPD: DHCPDISCOVER received from client 0100.107b.450a
emanon-3550-1#.31 on interface Vlan30.
16w4d: DHCPD: Sending DHCPOFFER to client 0100.107b.450a.31 (30.30.30.100).
16w4d: DHCPD: broadcasting BOOTREPLY to client 0010.7b45.0a31.
16w4d: DHCPD: DHCPREQUEST received from client 0100.107b.450a.31.
16w4d: DHCPD: Sending DHCPACK to client 0100.107b.450a.31 (30.30.30.100).
16w4d: DHCPD: broadcasting BOOTREPLY to client 0010.7b45.0a31.
emanon-3550-1#sh ip dhcp bind
IP address Hardware address Lease expiration Type
30.30.30.5 0100.107b.450a.31 Infinite Manual
30.30.30.100 0100.107b.450a.31 Jun 26 1993 05:13 AM Automatic
emanon-3550-1#
Identical addresses, one manual, one not. Whether the pool includes the
bound range or not doesn't seem to matter.
Fun stuff though. :)
I'll take a better look at it when I get home and can stick a sniffer on
things to see if I can figure out why it's not correlating the two! In the
meantime, I'm going to watch The Apprentice even though I'm pretty sure who
will get canned. Heheheheh... Cheers!
Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, CISSP,
JNCIS, et al.
IPExpert CCIE Program Manager
IPExpert Sr. Technical Instructor
swm@emanon.com/smorris@ipexpert.net
http://www.ipexpert.net
-----Original Message-----
From: Tom Lijnse [mailto:Tom.Lijnse@globalknowledge.nl]
Sent: Wednesday, January 28, 2004 7:58 AM
To: Scott Morris; ccielab@groupstudy.com
Subject: RE: DHCP Manual Binding
Hi Scott,
That would sure seem to be a lot easier. The only problem is that in my
experience it just doesn't seem to work like that :(
I have never been able to get a router to assign a specific ip address to
another router via DHCP using the 'hardware-address' command. I've always
had to resort to the strange client-id's described in the previous posts.
If you have working configurations using the 'hardware-address' command I
would be very interested, as it would definitely make life a lot easier when
doing this kind of thing.
Thanks,
Tom Lijnse
CCIE # 11031
Global Knowledge Netherlands
-----Original Message-----
From: Scott Morris [mailto:swm@emanon.com]
Sent: Wednesday, January 28, 2004 1:23 PM
To: Tom Lijnse; 'William Chen'; ccielab@groupstudy.com
Subject: RE: DHCP Manual Binding
It would seem to be a whole lot easier to use the 'hardware-address' command
and just put the MAC! :)
You can also use 'client-name' to indicate the name of the PC/Host machine
for further marking (if supported on the device).
Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, CISSP,
JNCIS, et al.
IPExpert CCIE Program Manager
IPExpert Sr. Technical Instructor
swm@emanon.com/smorris@ipexpert.net
http://www.ipexpert.net
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Tom
Lijnse
Sent: Wednesday, January 28, 2004 2:53 AM
To: William Chen; ccielab@groupstudy.com
Subject: RE: DHCP Manual Binding
Hi William,
The default client-identifier that a cisco router uses is
"cisco-MAC-ADDRESS-INTF", where "MAC-ADDRESS" is the interface mac-address
and "INTF" is the interface descriptor.
For instance, if you take the client-identifier that you are using and
convert it to ascii (leaving off the leading two zeroes) you get
"cisco-0000.0c8e.ded4-Et0".
For more details look at:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fipr
as_r/1rfdhcp.htm#1049289
Regards,
Tom Lijnse
CCIE #11031
Global Knowledge Netherlands
-----Original Message-----
From: William Chen [mailto:kwchen@netvigator.com]
Sent: Wednesday, January 28, 2004 1:43 AM
To: Tim Fletcher; ccielab@groupstudy.com
Subject: Re: DHCP Manual Binding
Hi,
Thanks, it works if I use the client-identifier. However, really don't
understand how cisco comes to the client identifier.
ip dhcp pool R3
host 192.168.0.30 255.255.255.0
client-identifier
0063.6973.636f.2d30.3030.302e.3063.3865.2e64.6564.342d.4574.30
bootfile R3.txt
option 150 ip 192.168.0.3
!
Best Regards,
William Chen
----- Original Message -----
From: "Tim Fletcher" <groupstudy@fletchmail.net>
To: "William Chen" <kwchen@netvigator.com>; <ccielab@groupstudy.com>
Sent: Wednesday, January 28, 2004 2:36 AM
Subject: Re: DHCP Manual Binding
> William,
>
> What you are seeing is perfectly normal. Here's an excerpt from RFC 2131:
>
> DHCP defines a new 'client identifier' option that is used to pass an
> explicit client identifier to a DHCP server. This change eliminates
> the overloading of the 'chaddr' field in BOOTP messages, where
> 'chaddr' is used both as a hardware address for transmission of BOOTP
> reply messages and as a client identifier. The 'client identifier'
> is an opaque key, not to be interpreted by the server; for example,
> the 'client identifier' may contain a hardware address, identical to
> the contents of the 'chaddr' field, or it may contain another type of
> identifier, such as a DNS name.
>
> I don't know how they come up with the particular client ID that they
> use, but it doesn't really matter as long as it's unique.
>
> -Tim Fletcher
>
> At 01:48 AM 1/28/2004 +0800, William Chen wrote:
> >Dear all,
> >
> > I try to configure and test the manual binding of DHCP. I am
> > running
the
> >DHCP sever in R5 (a 2500 router) and I simulate a client with another
2500
> >router. After I shutdown and no shutdown the client, the following
message
> >is display in the DHCP server. It seems the debug message is so
> >strange
that
> >the client hardware address is wired. Any idea?
> >
> >R5#
> >01:12:56: DHCPD: DHCPDISCOVER received from client
> >0063.6973.636f.2d30.3030.302e.3063.3865.2e64.6564.342d.4574.30 on
interface
> >Ethernet0.
> >01:12:56: DHCPD: there is no address pool for 192.168.0.100.
> >01:12:59: DHCPD: DHCPDISCOVER received from client
> >0063.6973.636f.2d30.3030.302e.3063.3865.2e64.6564.342d.4574.30 on
interface
> >Ethernet0.
> >01:12:59: DHCPD: there is no address pool for 192.168.0.100.
> >01:13:02: DHCPD: DHCPDISCOVER received from client
> >0063.6973.636f.2d30.3030.302e.3063.3865.2e64.6564.342d.4574.30 on
interface
> >Ethernet0.
> >...
> >01:15:20: DHCPD: there is no address pool for 192.168.0.100.
> >01:15:21: DHCPD: DHCPDISCOVER received from client 0100.c002.b682.67
> >on interface Ethernet0.
> >01:15:21: DHCPD: there is no address pool for 192.168.0.100.
> >01:15:22: DHCPD: BOOTREQUEST received from BOOTP client
> >00c0.02b6.8267 on interface Ethernet0.
> >
> >Best Regards,
> >William Chen
> >
> >_____________________________________________________________________
> >__ Please help support GroupStudy by purchasing your study materials
> >from:
> >http://shop.groupstudy.com
> >
> >Subscription information may be found at:
> >http://www.groupstudy.com/list/CCIELab.html
>
> ______________________________________________________________________
> _ Please help support GroupStudy by purchasing your study materials
> from:
> http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Mon Feb 02 2004 - 09:07:51 GMT-3