cancel
Showing results for 
Search instead for 
Did you mean: 

DHCPv6 and the Cisco interface disconnect 'bug'

MJN
Pro
Posts: 1,314
Thanks: 161
Fixes: 5
Registered: ‎26-08-2010

DHCPv6 and the Cisco interface disconnect 'bug'

For those people using a Cisco box to run IPv6 over PPP there is a fairly well documented issue with IOS related to what happens when the PPP session is for whatever reason terminated and how Cisco handles DHCPv6 renewal, or not:
Quote
When the PPPoE session is established for the first time, the DHCPv6 client configured on the dialer interface sends a request (including IA_PD option) to BRAS and receives an IPv6 prefix that can be used on the LAN. Like any other DHCP allocation, the prefix has a lifetime that is usually measured in hours or even days.
If the PPPoE session is terminated for any reason (some ISPs, like the one I’m using, love to terminate PPPoE sessions every 24 hours just to annoy the users), the virtual access interface on BRAS goes down and the static route toward the DHCPv6-assigned prefix is gone. The DHCPv6 bindings on BRAS stay intact (so the CPE could reclaim the same prefix for a while).
However, the DHCPv6 client in the CPE router does not detect a link loss. While the virtual access interface does change state to down, the dialer interface doesn’t... and the DHCPv6 client is monitoring the dialer interface. The CPE router keeps using the old delegated prefix, which is no longer reachable (as the static route on BRAS is gone and the client did not send a renewal request yet).

(copied from http://blog.ioshints.info/2010/10/dhcpv6-over-pppoe-total-disaster.html)
I have hitherto solved this by using a common workaround (read: kludge) of using an EEM applet to monitor (in the logs) for the virtual access interface coming back up and forcing a DHCPv6 rebind:
Quote
event manager applet MONITOR-IPV6-DHCP-APPLET
event syslog pattern "DIALER-6-BIND"
action 1.0 cli command "enable"
action 1.1 cli command "clear ipv6 dhcp client Dialer 1"
action 2.0 syslog priority debugging msg "Refreshed DHCPv6 lease due to PPP session renewal"

For a period of time this worked well and everything was hunkydory, however I have noticed for some time now (not sure how long) that it is no longer working and I am wondering if anything has happened at Plusnet's end that may explain why not?
It is something of stab in the dark but I have found something that may help shed some light... The DHCPv6 address of the BRAS appears to be different between PPP sessions - has this always been the case? For example, taking a look at my current DHCPv6 delegation shows FE80::90:1A00:2A3:7791 as the DHCPv6 server address:
Quote
Cisco877#sh ipv6 dhcp int dialer 1
Dialer1 is in client mode
 State is OPEN (1)
 Information refresh timer expires in 23:43:37
 Renew will be sent in 7w0d
 List of known servers:
   Reachable via address: FE80::90:1A00:2A3:7791
   DUID: 000200000A4C453332302F373435414333334558322F02
   Preference: 0
   Configuration parameters:
     IA PD: IA ID 0x000E0001, T1 INFINITY, T2 INFINITY
       Prefix: 2A02:16C8:2000:600::/56
               preferred lifetime INFINITY, valid lifetime INFINITY
     DNS server: 2001:470:20::2
     Information refresh time: 0
 Prefix name: MYPLUSNETPREFIX
 Rapid-Commit: disabled

...and with this configuration I can renew the DHCPv6 lease without any problem:
Quote
Cisco877#clear ipv6 dhcp client dial 1
Cisco877#sh ipv6 dhcp int dialer 1    
Dialer1 is in client mode
 State is OPEN (1)
 Information refresh timer expires in 23:59:59
 Renew will be sent in 7w0d
 List of known servers:
   Reachable via address: FE80::90:1A00:2A3:7791
<snip>

However, following a PPP session renewal I (or the applet) cannot renew the lease:
Quote
Cisco877#clear ipv6 dhcp client dial 1
Cisco877#sh ipv6 dhcp int dial 1
Dialer1 is in client mode
 State is SOLICIT (7)
 Retransmission timer expires in 00:00:28
 Rapid-Commit: disabled
<it sits in this state ad infinitum>

And I think this is the reason why: the DHCPv6 server address has changed as can be seen by cycling the dialer interface:
Quote
Cisco877#clear int dial 1
Cisco877#sh ipv6 dhcp int dialer 1
Dialer1 is in client mode
 State is OPEN (4)
 Information refresh timer expires in 23:58:42
 Renew will be sent in 7w0d
 List of known servers:
   Reachable via address: FE80::90:1A00:3A2:7668
<snip>

My assumption is that given I am now getting my IPv6 prefix from another BRAS that I cannot simply request a renewal of my previous DHCPv6 prefix because the new BRAS does not have knowledge of the old BRAS's bindings...?
Has anyone else seen this behaviour? What's intriguing is that it used to work in the early days (June '11) and so I am wondering if anything has changed on Plusnet's side in the interim?
Mathew
3 REPLIES 3
paulmh5
Plusnet Alumni (retired)
Plusnet Alumni (retired)
Posts: 170
Registered: ‎11-04-2011

Re: DHCPv6 and the Cisco interface disconnect 'bug'

Hi MJN
Nothing has changed on our side in regards to the IPv6 config in a while (that I know of).  We did alter peoples IPs a little bit back but I think you were working after that stage.
Plusnet Staff - Lead Network Design/Delivery Engineer
MJN
Pro
Posts: 1,314
Thanks: 161
Fixes: 5
Registered: ‎26-08-2010

Re: DHCPv6 and the Cisco interface disconnect 'bug'

Thanks for the clarification Paul.
Would you mind explaining the reasoning behind the changing source address of the DHCP server? Is it because following a PPP reconnect a different BRAS is (/may be) used?
I've modified my EEM applet to renew the address in a different but will await the next PPP failure before reporting on that. That said, something about 'A watched kettle...'  springs to mind as ever since posting I've not lost the PPP session once!  Wink
Mathew
MJN
Pro
Posts: 1,314
Thanks: 161
Fixes: 5
Registered: ‎26-08-2010

Re: DHCPv6 and the Cisco interface disconnect 'bug'

Just a quick update, not least in case someone else makes the same mistake...
It would appear that my problem was down to a buggy IOS... I've been using IOS's from the test series, in particular Advanced IP Services 12.4.15T7 as I did not have enough flash to fit anything newer in. Now that I've stuck more memory in and loaded 12.4.24T6 the DHCP renewals using the EEM workaround in the first post work without a hitch.
Mathew