cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
519
Views
0
Helpful
3
Replies

ASR9K DHCP issues - 10K BRAS migration to ASR9K

bbronning
Level 1
Level 1

Hello,

 

This past summer we migrated from a 10K to a 9K.  On the 10k we were using IP unnumbered sub-interfaces pointing to loopback and using helper addresses pointing to external DHCP.  During initial configuration of the 9k we were unable to use DHCP Relay as clients would get an IP but it wouldn't add the host route into routing table.  We were advised by TAC to use Proxy instead.  Proxy is working for the most part but is causing some headaches recently.  It appears that any time a client does a discover, the 9K is adding a DHCP RELEASE when proxy is communicating to DHCP server.  This is causing some ill effects with CPE devices and their IP's change with every discover.  We upgraded from 4.3.4 to 5.1.3 per TAC advice.  This is now causing more issues as some of the DHCP offers are getting sent to clients with garbled information like an IP from one subnet and a gateway address from another.  Multiple client reboots wont clear and I am having to manually clear proxy bindings to resolve.

My question is, is it possible to get Relay working with the 9K in our setup?  We don't use BNG but do we need some of those types of configs in order for the client host routes to be populated?  I am continuing to work with TAC but I don't foresee them changing proxy behavior anytime soon.

 

Thanks!

3 Replies 3

xthuijs
Cisco Employee
Cisco Employee

hi!

for xr bng to work, we need to have proxy as we need to maintain the binding for the forwarding.

what you are describing is somewhat of an interesting issue that I have not seen before! I would like to get some debugs to identify why that release is being sent, why the subnet and gateway are not in sync as directed by the dhcp server.

debugs of interest are:

debug subscriber manager policy/class

debug dhcp pack

debug dhcp proxy ev/er/pa

also a configuration would possibly help from especially the control policy, the access itnerface and the dhcp ipv4 section(s).

regards

xander

Hi,

 

Thanks for the reply!  We have a pretty basic setup.  No control policy, maps, etc.  We just use sub interfaces unnumbered pointing to loopback which contains all of our pools.  Our DHCP server is handling all the authentication.

 

profile dhcp proxy
  helper-address vrf default <address> giaddr <address>
  helper-address vrf default <address> giaddr <address>
  relay information option
  relay information policy keep
  relay information option allow-untrusted

interface Bundle-Ether1.101
 ipv4 point-to-point
 ipv4 unnumbered Loopback0
 arp learning disable
 encapsulation dot1q 101
 ipv4 access-group 180 ingress
 ipv4 access-group 181 egress

Since I posted this I heard back from TAC and they said that Proxy was designed to do the Release on purpose:

"When DISCOVER is received for an already ‘BOUND’ client, existing lease is released and fresh lease is initiated.  This is to accommodate any option’s value change in the new DISCOVER."

 

This is causing our DHCP server to issue a new IP every time.  This wouldn't be that much of an issue if there wasn't other outside factors adding to the amount of Discovers happening.  Any time a client modem has line issues and retrains or is rebooted a Discover happens.  Now since the 5.1.3, the garbled Offers are making things even worse.  Prior to 5.1.3 we were initially seeing modems lock up and the only common denominator was the 9K as this issue was never seen before its deployment.  The only logs we could see at the time were the IPs changing quite frequently.

Is it my understanding then that DHCP Relaying no longer works on the 9K like we are used to on the 10K, 7206, 6400, even a 1006?  We also just deployed a 1006 replacing a 7206 which is working wonderful.

 

 

The release on binding is indeed the implementation, which is key the proxy operation.

I am a bit concerned with the pool and gateway mixing, that I have never seen before, the debug dhcp ipv4 [proxy] err/ev/pa would be helpful for the analysis of that event.

We can do simple relay, that is no issue, the only thing is that you can't use unnumbered then in that case.

This because relay will not install a forwarding adj like what proxy does, so in order to make the relay work, you'd need to fix the address on that access interface/bundle you have there.

since you have a tac case maybe we can collect the debugs there so we can find out what is going on.

Or if you can sacrifice that unnumbered, relay is an option.

cheers

xander