Description

This KB addresses the issue where the client has an IPv6 assigned by DHCPv6 server configured in the network and is working fine. Due to any reason, if the laptop reboots/gets disconnected and reconnected, it sends out a CONFIRM packet (once the client comes back up again) to verify its IPv6 address, and it receives a response from the server. However, it is still unable to access the network.

Symptoms

Due to any reason, if the laptop reboots/gets disconnected and reconnected, it sends out a CONFIRM packet (once the client comes back up again) to verify its IPv6 address, and it receives a response from the server.

Solution

CONFIRM PACKET :

A DHCPv6 Client sends a CONFIRM message to any available DHCPv6 Server to determine whether the IPv6 addresses it was assigned is still appropriate to the link to which the DHCPv6 Client is connected.

 

REPLY PACKET :

A DHCPv6 Server sends a REPLY message in response to a CONFIRM message confirming or denying that the IPv6 addresses assigned to the DHCPv6 Client are appropriate to the link to which the DHCPv6 Client is connected.

 

UNDERSTANDING OF THE ISSUE :

  • EX3400 is configured as L2 switch with dhcp-snooping enabled for concerned vlan using the below configuration :

 

set vlans vlan401 forwarding-options dhcp-security arp-inspection

set vlans vlan401 forwarding-options dhcp-security ip-source-guard

set vlans vlan401 forwarding-options dhcp-security neighbor-discovery-inspection

 

  • Once the client gets reboot or will be disconnected from the network, the dhcp-security binding will be deleted from the snooping device.
  • Post that when the client comes back up, it would send out a CONFIRM packet to retain the same IPv6 IP it was using prior to the reboot.
  • The snooping switch was forwarding these CONFIRM packet to the server without checking the dhcp snooping bindings.
  • The server responds with a REPLY packet if the requested IP address is available.
  • The EX3400 creates a new DHCP snooping binding based on the REPLY packet from the server and forward the packet towards the client.
  • However, as per the RFC standard, the CONFIRM reply packet does not contain a lease time. Hence, the EX3400 sets the lease time to 0 for the binding.
  • With a lease time of 0, the DHCP snooping entry is immediately deleted from the switch's database.
  • The client receives the REPLY packet and assumes it can use the same IP address without adjusting the lease timer (continue to use the lease time left prior to the reboot).
  • Now, all the packets were getting dropped on snooping switch with NDI failure log messages, since the entry got deleted due to lease timer.
  • The client will send 3 RENEW and 3 REBIND packets and would have to wait for the lease timer to get expired before restarting the SARR process.
  • Once the SARR process will be completed, the client will get an IP and snooping switch will recreate the entry with lease time offered by the server. 
  • Post that, the client would be able to reach the network as expected.

 

LOGS FROM LAB :

Below is the output for “show dhcp-security ipv6 binding | refresh 1” 

 

---(refreshed at 2024-03-16 11:38:01 IST)---

---(refreshed at 2024-03-16 11:38:04 IST)---

IPv6 address         MAC address        Vlan    Expires State  Interface

fe80::zzzz:zzzz:zzzz:zzzz zz:zz:zz:zz:zz:zz vlan401 0      BOUND  ge-0/0/1.0         <<< the Expiry is 0 as expected since the confirm reply didn't have lease time.

yyyy:yyy:yyyy::yy    zz:zz:zz:zz:zz:zz  vlan401 0     BOUND  ge-0/0/1.0         

---(refreshed at 2024-03-16 11:38:07 IST)---

---(refreshed at 2024-03-16 11:38:10 IST)---

 

RESOLUTION OF THE ISSUE :

 

The issue is addressed via an internal PR, and will be resolved in below releases :

junos:21.4R3-S8 , junos:22.2R3-S4 , junos:22.3R3-S3 , junos:22.4R3-S2 , junos:23.2R2-S1 , junos:23.4R2 , junos:24.2R1 , junos:24.3R1


 

  • When there is no entry for the client in the DHCP snooping database, the snooping switch will drop CONFIRM packets from the client. As a result, the client will not receive a reply and will need to restart the SARR (Solicit, Advertise, Request, Reply) process after sending out 3-4 CONFIRM packets.
  • If there is an existing entry in the DHCP snooping table for the client, the snooping switch will forward the CONFIRM packet to the DHCPv6 server. Upon receiving the REPLY packet from the server, the snooping switch will not change the lease timer and will continue to use the remaining time that was left before receiving the CONFIRM packet.

Modification History

2024-07-04 : Article Created

2026-09-30 : Updated and Externalized