From: Scott Morris (swm@emanon.com)
Date: Thu Jan 29 2004 - 09:44:45 GMT-3
You mean we HAVE to read RFCs? Man... Maybe I don't want this job after
all. :)
Although, your own pulls from the RFC states "The 'client identifier' is an
opaque key, not to be interpreted by the server;" which pretty clearly tells
me that Cisco's doing something they aren't supposed to.
I don't see a "may" or "should" or any other selectively-vague word there.
Oh well, it's been educational anyway. :)
Scott
-----Original Message-----
From: Tom Lijnse [mailto:Tom.Lijnse@globalknowledge.nl]
Sent: Thursday, January 29, 2004 3:15 AM
To: Scott Morris; asadovnikov; ccielab@groupstudy.com
Subject: RE: DHCP Manual Binding
Since we're trying to uncover all the gory details anyway, I figured I might
as well add the following quotes 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. The 'client identifier' chosen by a
DHCP client MUST be unique to that client within the subnet to which
the client is attached. If the client uses a 'client identifier' in
one message, it MUST use that same identifier in all subsequent
messages, to ensure that all servers correctly identify the client. "
" A DHCP server needs to use some unique identifier to associate a
client with its lease. The client MAY choose to explicitly provide
the identifier through the 'client identifier' option. If the client
supplies a 'client identifier', the client MUST use the same 'client
identifier' in all subsequent messages, and the server MUST use that
identifier to identify the client. If the client does not provide a
'client identifier' option, the server MUST use the contents of the
'chaddr' field to identify the client. "
So basically it seems that the 'hardware-address' command would mainly be
used for BOOTP clients (which DHCP servers should still support since DHCP
is a BOOTP extension).
Real DHCP clients will probably always use the 'client-id' option (at least
Windows and IOS clients do). According to the second quote the server should
always prefer the 'client-id' over the 'hardware-address' option if it is
present. As both you and Alexei already noted the behavior of the IOS client
can be changed to resemble the behavior of windows clients (client-id = 01
followed by the mac-address), which basically means that you use the
hardware address as the client-id, but you would still have to use the
'client-id' command to configure it on the IOS server.
It looks like we should all have read the RFC first since it clearly states
what we all figured out doing our debugs, but hey, that's what we're
engineers for... ;-)
Have a good one,
Tom Lijnse
CCIE #11031
Global Knowledge Netherlands
-----Original Message-----
From: Scott Morris [mailto:swm@emanon.com]
Sent: Thursday, January 29, 2004 6:09 AM
To: 'asadovnikov'; ccielab@groupstudy.com
Subject: RE: DHCP Manual Binding
Actually, if you read through the ramblings in my e-mail, you will find that
you can indeed specify an interface to us as the hardware address... With
that, it was registering via the MAC address, it was just looked at and
viewed in a very strange fashion.
Although, taking a slightly different viewpoint to that... (making sure I
understand your point) that on the client, even specifying an interface and
watching the MAC address come in instead of the big-long-ugly client ID,
that the Cisco DHCP client actually sends this within the "client id" field
instead of the hardware address field.
And to that same end, on my DHCP server, I added "client-identifier
0100.107b.450a.31", which will automatically take out the previously
configured "hardware-address" command.
And guess what? It worked. :)
emanon-3550-1#
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.5).
16w4d: DHCPD: child pool: 30.30.30.5 / 255.255.255.0 (Host)
16w4d: DHCPD: parent pool: 30.30.30.0 / 255.255.255.0 (Final)
16w4d: DHCPD: child pool: 30.30.30.0 / 255.255.255.0 (Final)
16w4d: DHCPD: pool Final has no parent.
16w4d: DHCPD: child pool: 30.30.30.5 / 255.255.255.0 (Host)
16w4d: DHCPD: parent pool: 30.30.30.0 / 255.255.255.0 (
emanon-3550-1#Final)
16w4d: DHCPD: child pool: 30.30.30.0 / 255.255.255.0 (Final)
16w4d: DHCPD: pool Final has no parent.
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.5).
16w4d: DHCPD: child pool: 30.30.30.5 / 255.255.255.0 (Host)
16w4d: DHCPD: parent pool: 30.30.30.0 / 255.255.255.0 (Final)
16w4d: DHCPD: child pool: 30.30.30.0 / 255.255.255.0 (Final)
16w4d:
emanon-3550-1#DHCPD: pool Final has no parent.
16w4d: DHCPD: child pool: 30.30.30.5 / 255.255.255.0 (Host)
16w4d: DHCPD: parent pool: 30.30.30.0 / 255.255.255.0 (Final)
16w4d: DHCPD: child pool: 30.30.30.0 / 255.255.255.0 (Final)
16w4d: DHCPD: pool Final has no parent.
16w4d: DHCPD: broadcasting BOOTREPLY to client 0010.7b45.0a31.
emanon-3550-1#
So the router got the IP I wanted it to. When I get home and can connect a
host into that switch/vlan, I will test it out from a PC's perspective and
see if it responds to the hardware address fields correctly. Determining
once and for all whether it's a client or server problem!
Cool stuff to note though. Although if you are in the actual lab, and have
to set something like that up, I guess watch the wording. :) Assuming that
it works for hosts (will find out later, 'cause it's bugging me now!), the
hardware-address will be the way to go. We can see in the "show ip dhcp
binding" command that it was set up manually for that specific MAC address.
Interesting stuff though. TV was good. News is boring. DHCP isn't really
that much more exciting! (smirk)
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
asadovnikov
Sent: Wednesday, January 28, 2004 11:45 PM
To: 'Scott Morris'; ccielab@groupstudy.com
Subject: RE: DHCP Manual Binding
Scott,
I have to start my message by saying that most of what I am going to say
already was said in the thread... I unfortunately was busy with something
to contribute earlier. So I will leave some details out hoping that it will
easy seeing the picture :).
In my experience, if a "client ID" option is present in DHCP request Cisco
IOS DHCP server will want to concentrate on matching this option for the
purposes of assigning the lease. It will not match it to hardware address,
only to client id. (Going back to RFC it does not believe it is allowed to
try to figure it out, if you will.) Cisco IOS DHCP server will continue to
honor hardware address, but only when client id is not present in the
request (which only devices I seen recently to do it were older HP
printers).
Windows OS will form client ID by appending 01 in front of hardware address,
so will IOS client DHCP under certain conditions. There is a mention is
command reference about Widows behavior.
Client ID and hardware address are not interchangeable options, at least as
far as IOS DHCP server is concerned. For a fixed lease it will go by client
id (if present) or by hardware address (if client id is not present).
By default Cisco IOS DHCP client will use client id of
"cisco-[mac]-interface" although it can be modified with command options.
There is not way I know about to get IOS dhcp client not to use client id,
so when used in combination with IOS dhcp server, hardware address can not
be used.
Best regards,
Alexei
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Scott Morris
Sent: Wednesday, January 28, 2004 9:09 PM
To: 'Tom Lijnse'; ccielab@groupstudy.com
Subject: RE: DHCP Manual Binding
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