Re: Cisco ASR 9006 – IOS XR 5.1.3 with DHCP Proxy = address flopping

[perl-list]

They are flopping with every reboot. The two addresses are not necessarily coming from different members of the failover pair. The specific example packet capture we did with test equipment at the customer site both addresses came from the same device (DHCP-1). 

> From: "Patrick Trapp" <ptrapp at nex-tech.com>
> To: "Users of ISC DHCP" <dhcp-users at lists.isc.org>
> Sent: Thursday, February 26, 2015 2:54:28 PM
> Subject: RE: Cisco ASR 9006 – IOS XR 5.1.3 with DHCP Proxy = address flopping

> Is it flopping with every reboot?

> Are they getting the different addresses from the different members of the
> failover pair? That is, is x.x.x.12 coming from DHCP-1 while x.x.x.42 is
> provided by DHCP-2?

> From: dhcp-users-bounces at lists.isc.org [dhcp-users-bounces at lists.isc.org] on
> behalf of perl-list [perl-list at network1.net]
> Sent: Thursday, February 26, 2015 11:52 AM
> To: Users of ISC DHCP
> Subject: Cisco ASR 9006 – IOS XR 5.1.3 with DHCP Proxy = address flopping

> Folks,

> A customer of mine has a problem where if a user device discovers due to reboot
> or whatever, they will not get the same IP they had previously (even tho
> current lease is still active).

> Scenario:

> 1) Reboot device - release / discover / offer / request / ack - get ip x.x.x.12

> 2) renews happen no problem - lease still active.

> 3) reboot device - release / discover / offer / request / ack - get ip x.x.x.42

> 4) renews happen no problem - lease still active.

> 5) reboot device - release / discover / offer / request / ack - get ip x.x.x.12
> (note that it went back to the original IP).

> 6) renews happen no problem - lease still active.

> 7) reboot device - release / discover / offer / request / ack - get ip x.x.x.42
> (note that it went back to IP obtained in step 3 above).

> Specifics:

> This configuration is with a Cisco 9k router with DHCP Proxy as noted by their
> network admin:

> "Cisco ASR 9006 – IOS XR 5.1.3
> We are using sub-interfaces configured with IP unnumbered pointing to loopback
> which contains all dynamic pools.
> DHCP Proxy is a profile type created within the DHCP configuration and is
> configured to point to the DHCP servers. This profile is applied to each
> sub-interface. Proxy is also responsible for host route management."

> What we have observed is the the Cisco with DHCP Proxy is sending a Release
> before sending the discover (please note that the client DID NOT send a
> release). I don't know if that has anything to do with it or not.

> Also - there are two DHCP servers in a failover pair. Each running 4.2.5-P1.
> According to documentation that we have found (and what i've always
> understood), they should get the same address again. The customer does not want
> the address to flop like this as it is causing other problems. I am at a loss
> as to why this is happening.

> It should also be noted that we have a packet capture from both sides of the
> router and that there doesn't really seem to be any difference in the packet
> content (aside from the added release packet that was never sent by the client
> device). Actually, there was one thing that I was unsure about from the packet
> capture.. the release packet had the same transaction ID as the subsequent
> discover / offer / request / ack packets according to Wireshark. I don't know
> if that is a problem or not, however.

> Also - the client device (a modem / router) is not sending the Client Identifier
> option (nor is the Cisco inserting it).

> Cisco tells them that the release sent before the discover is a feature of DHCP
> Proxy and cannot be changed.

> They cannot use normal DHCP relay (ip helper address x.x.x.x;) due to their
> network configuration (or so Cisco said).

> This whole thing was not previously a problem when they had a Cisco 10k router
> using normal DHCP relay.

> Thoughts as to this address flopping? Anyway to stop it?

> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20150226/a665f7f5/attachment.html>