<html><body><div style="font-family: Andale Mono; font-size: 10pt; color: #000000"><div style="font-family: Andale Mono; font-size: 10pt; color: #000000">see responses inline below<br><br><hr id="zwchr" data-marker="__DIVIDER__"><div data-marker="__HEADERS__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"John Wobus" <jw354@cornell.edu><br><b>To: </b>"Users of ISC DHCP" <dhcp-users@lists.isc.org><br><b>Sent: </b>Friday, February 27, 2015 11:31:38 AM<br><b>Subject: </b>Re: Cisco ASR 9006 – IOS XR 5.1.3 with DHCP Proxy = address flopping<br></blockquote></div><div data-marker="__QUOTED_TEXT__"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;">Re my impression/recollection of how dhcpd works:<br><br>-You say the lease is still active, but in your scenario, you show a <br>release. Wouldn't that terminate the lease?</blockquote><div>That is true - the lease is terminated by the release that is sent by the Cisco 9k on behalf of the router (NOT by the client, however, *Grumble* Cisco).</div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><br>-On the other hand, if a lease is still active, isn't a discover a <br>request for another IP? A MAC address is allowed to have multiple IPs <br>by doing additional discovers. dhcpd can be configured to refuse to <br>give more than one IP address to any specific MAC address but I don't <br>recall what it does to an additional discover in that case.</blockquote><div>We have one lease per client set. An additional discover will give them only the same IP. This works in all other scenarios. The client's are discovering because they were rebooted. They should get the same IP again, yet they don't. Perhaps because of the release, but I think only someone familiar with the source code could comment on that.</div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><br>-Does dhcpd take some time to bring a lease back to the "offerable" <br>state when a lease terminates?</blockquote><div>I don't know ... someone familiar with the source code would need to comment on that. The Release is sent only a few milliseconds (like less than 20) before the discover comes. This is because the Cisco 9k got the discover from the client and then sent a release to the server and then sent the discover.</div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><br><br>The symptoms suggest the lease isn't eligible to be offered at the <br>desired moment so a different free lease is offered, perhaps because <br>the lease is still active and the server interprets the discover as a <br>request for another address. I assume these are dynamic, e.g. in a <br>pool. For dynamic addresses, the lease file is essentially a short- <br>term change log for leases and you may be able to locate the <br>successive changes to the lease state for each IP to get a more <br>detailed view of what is happening.</blockquote><div>That may well be the case. There may be some short period of time after a release in which the IP address isn't available (especially in failover). If that is the case, then it would make sense why it offers the older IP. Maybe an ISC DHCP developer could wait on this.</div><div><br data-mce-bogus="1"></div><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><br><br>John Wobus<br>Cornell IT<br><br>On Feb 26, 2015, at 12:52 PM, perl-list wrote:<br><br>> Folks,<br>><br>> A customer of mine has a problem where if a user device discovers <br>> due to reboot or whatever, they will not get the same IP they had <br>> previously (even tho current lease is still active).<br>><br>> Scenario:<br>><br>> 1) Reboot device - release / discover / offer / request / ack - get <br>> ip x.x.x.12<br>><br>> 2) renews happen no problem - lease still active.<br>><br>> 3) reboot device - release / discover / offer / request / ack - get <br>> ip x.x.x.42<br>><br>> 4) renews happen no problem - lease still active.<br>><br>> 5) reboot device - release / discover / offer / request / ack - get <br>> ip x.x.x.12 (note that it went back to the original IP).<br>><br>> 6) renews happen no problem - lease still active.<br>><br>> 7) reboot device - release / discover / offer / request / ack - get <br>> ip x.x.x.42 (note that it went back to IP obtained in step 3 above).<br>><br>><br>> Specifics:<br>><br>> This configuration is with a Cisco 9k router with DHCP Proxy as <br>> noted by their network admin:<br>><br>> "Cisco ASR 9006 – IOS XR 5.1.3<br>> We are using sub-interfaces configured with IP unnumbered pointing <br>> to loopback which contains all dynamic pools.<br>> DHCP Proxy is a profile type created within the DHCP configuration <br>> and is configured to point to the DHCP servers. This profile is <br>> applied to each sub-interface. Proxy is also responsible for host <br>> route management."<br>><br>> What we have observed is the the Cisco with DHCP Proxy is sending a <br>> Release before sending the discover (please note that the client DID <br>> NOT send a release). I don't know if that has anything to do with <br>> it or not.<br>><br>> Also - there are two DHCP servers in a failover pair. Each running <br>> 4.2.5-P1. According to documentation that we have found (and what <br>> i've always understood), they should get the same address again. <br>> The customer does not want the address to flop like this as it is <br>> causing other problems. I am at a loss as to why this is happening.<br>><br>> It should also be noted that we have a packet capture from both <br>> sides of the router and that there doesn't really seem to be any <br>> difference in the packet content (aside from the added release <br>> packet that was never sent by the client device). Actually, there <br>> was one thing that I was unsure about from the packet capture.. the <br>> release packet had the same transaction ID as the subsequent <br>> discover / offer / request / ack packets according to Wireshark. I <br>> don't know if that is a problem or not, however.<br>><br>> Also - the client device (a modem / router) is not sending the <br>> Client Identifier option (nor is the Cisco inserting it).<br>><br>> Cisco tells them that the release sent before the discover is a <br>> feature of DHCP Proxy and cannot be changed.<br>><br>> They cannot use normal DHCP relay (ip helper address x.x.x.x;) due <br>> to their network configuration (or so Cisco said).<br>><br>> This whole thing was not previously a problem when they had a Cisco <br>> 10k router using normal DHCP relay.<br>><br>> Thoughts as to this address flopping? Anyway to stop it?<br>> _______________________________________________<br>> dhcp-users mailing list<br>> dhcp-users@lists.isc.org<br>> https://lists.isc.org/mailman/listinfo/dhcp-users<br><br>_______________________________________________<br>dhcp-users mailing list<br>dhcp-users@lists.isc.org<br>https://lists.isc.org/mailman/listinfo/dhcp-users</blockquote></div></div><br></div></body></html>