Article Detail

Description

This article describes an issue noticed in 20.2R3-Sx versions on QFX5200 platforms, where IPv6 Neighbor solicit packets are going into ARP asic-queue (queue 34) even when have a separate ndpv6 asic-queue (queue 16).

FPC0(qfx5200 vty)# show halp-pkt asic-queues
------ --------- -------- -------- ------------------------------
CMICQ Channel bwidth burst Qlen Proto(s)
------ ---------- -------- -------- --------- ------------------------------
16 3 500 200 200 ndpv6
34 2 500 200 200 arp

Symptoms

Incoming packet (check monitor traffic interface)

14:42:32.480887 In
Juniper PCAP Flags [Ext, In], PCAP Extension(s) total length 16
Device Media Type Extension TLV #3, length 1, value: Ethernet (1)
Logical Interface Encapsulation Extension TLV #6, length 1, value: Ethernet (14)
Device Interface Index Extension TLV #1, length 2, value: 653
Logical Interface Index Extension TLV #4, length 4, value: 814
-----original packet-----
Reverse lookup for fe80::ba81:e0c6:21af:4acd failed (check DNS reachability).
Other reverse lookup failures will not be reported.
Use <no-resolve> to avoid reverse lookups on IP addresses.

00:10:94:00:00:02 > 33:33:ff:29:06:dd, ethertype IPv6 (0x86dd), length 124: (hlim 255, next-header: ICMPv6 (58), length: 70) fe80::ba81:e0c6:21af:4acd > ff02::1:ff29:6dd: [icmp6 sum ok] ICMP6, neighbor solicitation, length 70, who has ff02::1:ff29:6dd[ndp opt]

If there are multiple such packets, we can see ARP DDOS queue being violated (which ideally should be NDPv6 queue)

{master:0}
lab@qfx5200> show ddos-protection protocols violations
Packet types: 45, Currently violated: 1

Protocol Packet Bandwidth Arrival Peak Policer bandwidth
group type (pps) rate(pps) rate(pps) violation detected at
arp aggregate 500 844520 844520 2023-10-27 17:06:44 IST
Detected on: FPC-0

FPC0(qfx5200 vty)# show halp-pkt pkt-stats

PKT TX STATS:
tx_req : 370
tx_success : 370
tx_arr_req : 369
tx_arr_success : 369
tx_with_tx_pbmp : 370

PKT RX STATS:
rx_req : 15641
rx_success : 15513
rx_buf_alloc : 16599
rx_pkt_ipv6 : 15513
rx_pkt_vxlan_not_found_encap_pkt : 15513

RX PER QUEUE STATS:
rx queue 34 : rxq_req 15513 rxq_success 15513 <<<<

Another issue that we see in this case is with the firewall configuration to block these received NS packets even though the firewall is correctly programmed onto the PFE. The issue is seen with any IPv6 address (Link-local/unicast IPv6 addresses)
Below is the firewall filter configuration with the IPv6 source-address as a match term.

set firewall family inet6 filter block_unknown term 1 from source-address fe80::ba81:e0c6:21af:4acd/128
set firewall family inet6 filter block_unknown term 1 then count blocked_packets
set firewall family inet6 filter block_unknown term 1 then discard <<<< to discard specific IPV6 packets
set firewall family inet6 filter block_unknown term 2 then accept <<< To accept all other packets
set firewall family inet6 filter block_unknown term 2 then count accepted_packets

set interfaces lo0 unit 0 family inet6 filter input block_unknown

{master:0}
lab@qfx> show firewall

Filter: block_unknown
Counters:
Name Bytes Packets
blocked_packets 0 0
accepted_packets                                       0                   0

>> From the above output, we can see that the packets are not accepted by any term which proves that firewall filter is not hit/invoked at all.

PFE filter programming

FPC0(qfx vty)# show filter hw
======================
Filter index : 1
======================

- Filter name : block_unknown

+ Hardware Instance : 1
+ Hardware key (struct brcm_dfw_hw_key_t):
- Type : IRACL
- Vlan id : 0
- Direction : ingress
- Protocol : 6 (IPv6)
- Port class id : 0
- Class id : 0
- Loopback : 1
- Port : 0(xe-1)
- Vlan tag : 0
- Non-overflow : 1
+ FP usage info (struct brcm_dfw_fp_t):
- Group : IFP iRACL group (33)
- My Mac : 00:00:00:00:00:00
- Loopback Reference Count : 00000001
- IFL Type : unknown (0)
+ List of tcam entries : [ total: 8; ]
- Pipe: 0; [3557 3561 3565 3569 3573 3577 3581 3585 ]
- Pipe: 1; [3558 3562 3566 3570 3574 3578 3582 3586 ]
- Pipe: 2; [3559 3563 3567 3571 3575 3579 3583 3587 ]
- Pipe: 3; [3560 3564 3568 3572 3576 3580 3584 3588 ]
+ List of ranges : [ total: 0; ]
- Pipe: 0 []
- Pipe: 1 []
- Pipe: 2 []
- Pipe: 3 []
+ List of interface match entries : [ total: 0; ]
- Pipe: 0 []
- Pipe: 1 []
- Pipe: 2 []
- Pipe: 3 []
+ List of dot1q-tag match entries : [ total: 0; ]
- Pipe: 0 []
- Pipe: 1 []
- Pipe: 2 []
- Pipe: 3 []
- List of l3 ifl index entries : [ total: 0; ]
+ List of vfp tcam entries : [ total: 0; ]
- Pipe: 0 []
- Pipe: 1 []
- Pipe: 2 []
- Pipe: 3 []
+ Misc info (struct brcm_dfw_misc_info_t):
- List of <anlz_id, entry_id> : [ total: 0; ]
+ Bind point info (union brcm_dfw_bind_point_info_t):
+ Loopback : CPU Traffic
  + Programmed: YES
+ BD ID : 224

Though the firewall filter is configured on the PFE, the filter terms are never hit and impacts all other terms as well leading to an unexpected outage.

The only available workaround is to configure destination-address as a match term. Though this is not feasible solution as there could be multiple neighbor solicits for different destination-addresses, however it is an only known workaround at the moment on the specified version.

set firewall family inet6 filter block_unknown term 1 from source-address fe80::ba81:e0c6:21af:4acd/128
set firewall family inet6 filter block_unknown term 1 from destination-address ff02::1:ff29:6dd:/128
set firewall family inet6 filter block_unknown term 1 then count blocked_packets
set firewall family inet6 filter block_unknown term 1 then discard
set firewall family inet6 filter block_unknown term 2 then accept
set firewall family inet6 filter block_unknown term 2 then count accepted_packets

set interfaces lo0 unit 0 family inet6 filter input block_unknown

lab@qfx> show firewall

Filter: block_unknown
Counters:
Name Bytes Packets
blocked_packets 9024377984 70502953 <<<<<
accepted_packets                                       0                   0

Solution

The NS packet should be punted to CPU via Q16 which is getting set/handled by dynamic filter -ipv6-ns-na (These dynamic filters are configured on PFE by default and are responsible to classify the data and put it on respective queues before forwarding it to the RE). In this case, the default dynamic filter configured on the PFE, is not hitting and hence, via CPU_COS_MAP setting, the NS packet is going to CPU Q34 which is ARP.

Since the NS packet is not landing in the correct queue (queue 16) at the CPU, the configured inet6 firewall filter is not invoked. This is a bug and is resolved through PR1662707. The issue is resolved in below versions.

Junos OS 20.3R3-S5, 20.4R3-S4, 21.1R3-S4, 21.2R3-S2, 21.3R3-S1, 21.4R3, 22.1R2, 22.1R3, 22.2R1-S1, 22.2R2, 22.3R1, 22.4R1

https://prsearch.juniper.net/problemreport/PR1662707

Modification History

2023-11-15 : Initial Publication
2024-07-29 - Visibility modified