Description

This article describes a scenario in which the inet6 firewall filter, configured on loopback interface to block an IPv6 Neighbor Solicit packet from a specific IPv6 source, is not working even though it is successfully configured on the PFE.

Model: qfx5200-32c-32q
Junos: 20.2R3-S2.5
 

Symptoms

Topology :

IXIA (Sending NS packets)---- QFX5200

IXIA is sending neighbor solicits with the source-address of <source-ipv6-1> to the QFX5200 device. 

The below firewall filter is configured with the IPv6 source-address as a match term.

set firewall family inet6 filter block_unknown term 1 from source-address <source-ipv6-1>
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 <source-ipv6-1>
set firewall family inet6 filter block_unknown term 1 from destination-address <dest-ipv6-1>
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 bug is resolved through PR1662707.

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

Modification History

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