- DHCPv6-SOLICIT sent by the DHCPv6 client is correctly relayed by the routers located on the client side (routers generate a DHCP-RELAY packet to the DHCPv6 server)

- The DHCPv6 Server receives this packet correctly and replies with a DHPCv6-RELAY-REPLY

- The first router attached to the DHCP server receives this DHPCv6-RELAY-REPLY. It is an IPv6 unicast packet with destination = "Relaying router address". For some reason, the first router attached to the DHPCv6 server does not route this packet as it should: instead of routing it as any unicast packet and sending it back to the relaying router, it "snoops" the DHPCv6 packet, interprets somehow the information in it, and send locally, using Link-local addresses, the DHPCv6 Advertise. As the client is not attached directly to this router, the packet never reaches the client which never gets its IPv6 address.

Note: When we replace QFX10008 with QFX5120 the issue is not seen.

On QFX10008 platforms, DHCPv6 will filter relay-reply packets towards the DHCP client.

On QFX10008 platforms with Junos OS software and DHCPv6 configured, relay-reply packets will be filtered due to no-snoop being disabled. This causes the IPv6 address assignment to be rejected by the customer,so the client won't receive any valid IP address.

During the DHCPv6 relay process, the IPv6 address assignment will fail due to packet relay-reply gests dropped, by enabling the traceoptions for DHCP and noticed that DHCPv6 relay-reply[advertise] packet is being snooped by QFX10008 DHCP-relay switch

This issue might be seen if the following conditions are met:

* QFX10008 platforms

* DHCv6 relay configuration.

To stop the snooping process, the below CLI knob is introduced through PR1819269 from junos:24.2R2, 24.4R1, 25.1R1which will be a fix for this issue:

#set routing-instances <RI-name> forwarding-options dhcp-relay no-snoop.