Support Support Downloads Knowledge Base Juniper Support Portal Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[QFX] Transit OSPF packets received on L2 interface are directed to RE with no OSPF or IRB configuration

0

0

Article ID: KB37552 KB Last Updated: 19 Nov 2021Version: 1.0
Summary:

On QFX5000 series switches using an L2 (layer-2 i.e. configured with "family ethernet-switching") switch, transit OSPF packets may be redirected to the RE while they are switched to corresponding interfaces in the same VLAN.  TCPDUMP on ports configured as pure L2 would show transit OSPF packets that are being sent to RE.  Hence, any excess multicast traffic destined to 224.0.0.5 (OSPF Hello) received on a QFX L2 interface could cause RE CPU spike and Latency issues.

Symptoms:

On a QFX5000 series switch, when multicast traffic destined to 224.0.0.5(OSPF Hello) is received on an L2 interface with no IRB or OSPF configuration, the OSPF packets are directed to the RE.

Topology:

MX (L3)-----ae15----(L2 trunk)QFX(L2 trunk) ge-0/0/94-----ge-0/0/46 EX4300
OSPF is between MX and EX4300.  QFX is a transit L2 switch


Note: This issue is seen when the port is configured as a single physical port or LAG.

root@MX960> show ospf neighbor 
Address          Interface              State     ID               Pri  Dead
110.1.1.2        ae15.0                 Full      192.168.185.20   128    32

root@EX4300> show ospf neighbor 
Address          Interface              State     ID               Pri  Dead
110.1.1.1        ge-0/0/46.0            Full      10.85.173.182    128    36

root@QFX-DUT> show configuration interfaces ae15         
unit 0 {
    family ethernet-switching {
        interface-mode trunk;
        vlan {
            members [ vlan1 vlan2 ];
        }
    }
}

root@QFX-DUT> show configuration interfaces ge-0/0/94    
unit 0 {
    family ethernet-switching {
        interface-mode trunk;
        vlan {
            members [ vlan1 vlan2 ];
        }
    }
}

root@QFX-DUT> show configuration vlans 
vlan1 {
    vlan-id 100;
}
vlan2 {
    vlan-id 200;
}

root@QFX-DUT> monitor traffic interface ae15.0 no-resolve 
verbose output suppressed, use <detail> or <extensive> for full protocol decode
Address resolution is OFF.
Listening on ae15.0, capture size 96 bytes

14:52:28.739414  In IP 110.1.1.1 > 224.0.0.5: OSPFv2, Hello, length 60
14:52:36.472854  In IP 110.1.1.1 > 224.0.0.5: OSPFv2, Hello, length 60
14:52:44.618814  In IP 110.1.1.1 > 224.0.0.5: OSPFv2, Hello, length 60
14:52:52.679959  In IP 110.1.1.1 > 224.0.0.5: OSPFv2, Hello, length 60


These transit packets are being treated as OSPF and redirected to RE as per the below dynamic filter. The OSPF dynamic filter counter increments for each packet (OSPF) destined to 224.0.0.5 and the filter action for this is to copy-to-cpu.

FXPC0(vty)# sh filter hw dynamic all brief non_zero_only 0
...
41 U:  0 G:10 E:     66 H:0 A:CRV stat (id   66 val 0x00000001EF8440B2) P:00000001 I4: COSQ 36 -ospf-pkts <---
41 U:  0 G:10 E:     67 H:0 A:CRV stat (id   67 val 0x00000000000011AA) P:00000001 I4: COSQ 36 -ospf-pkts
...

FXPC0(vty)# sh filter hw dynamic all brief non_zero_only 0
...
41 U:  0 G:10 E:     66 H:0 A:CRV stat (id   66 val 0x00000001EF8440B3) P:00000001 I4: COSQ 36 -ospf-pkts <---
41 U:  0 G:10 E:     67 H:0 A:CRV stat (id   67 val 0x00000000000011AA) P:00000001 I4: COSQ 36 -ospf-pkts
...

FXPC0(vty)# sh filter hw dynamic all brief non_zero_only 0
...
41 U:  0 G:10 E:     66 H:0 A:CRV stat (id   66 val 0x00000001EF8440B4) P:00000001 I4: COSQ 36 -ospf-pkts <---
41 U:  0 G:10 E:     67 H:0 A:CRV stat (id   67 val 0x00000000000011AA) P:00000001 I4: COSQ 36 -ospf-pkts
...

TFXPC0(vty)# set dc bc "fp show entry 66"                     

HW (unit 0)
EID 0x00000042: gid=0xa,
         slice=4, slice_idx=0x4d, part =0 prio=0x1, flags=0x10602, Installed, Enabled
              tcam: color_indep=1024, 
 DstIp6 
    Offset: 8 Width: 128 
    DATA=0xe0000005 
    MASK=0xffffffff 
 InPorts 
    DATA=0x00000000000000000000000000000000000001fffffffffffffffffffffffffe
    MASK=0x00000000000000000000000000000000000001ffffffffffffffffffffffffff
 Drop 
    Offset: 157 Width: 1 
    DATA=0x00000000 
    MASK=0x00000001 
 StageIngress 
 Stage 
 SrcVirtualPortValid 
    Offset: 141 Width: 1 
    DATA=0x00000000 
    MASK=0x00000001 
 IngressStpState 
    Offset: 245 Width: 2 
    DATA=0x00000003 
    MASK=0x00000003 
         slice=5, slice_idx=0x4d, part =1 prio=0x1, flags=0x10204, Installed, Enabled
              tcam: color_indep=0, 
 EtherType 
    Offset: 24 Width: 16 
    DATA=0x00000800 
    MASK=0x0000ffff 
         action={act=CosQCpuNew, param0=36(0x24), param1=0(0x0), param2=0(0x0), param3=0(0x0)}
         action={act=RedirectVlan, param0=0(0x0), param1=0(0x0), param2=0(0x0), param3=0(0x0)}
         policer=
         statistics={stat id 66  slice = 4 idx=9 entries=1} 
Cause:

The dynamic filters for OSPF are installed during the init time when chassis/FPC is restarted, so the installation of these dynamic filters for OSPF are not configuration driven.

This is a platform limitation for QFX5000 series switches.

Solution:

As a workaround, use lo0 filter to drop the transit OSPF packets on DUT when there is no OSPF configuration.

root@QFX-DUT# show interfaces lo0
unit 0 {
    family inet {
        filter {
            input ospf-block;
        }
    }
}

root@QFX-DUT# show firewall family inet filter ospf-block
term BLOCK-OSPF {
    from {
        protocol ospf;
    }
    then {
        discard;
    }
}
term ALL {
    then accept;
}
 

In a scenario where QFX has other L3 ports with OSPF configured, to ensure the above lo0 filter does not discard the real OSPF Hellos, modify EITHER to include another term to accept OSPF Hellos from the real OSPF peer (or) configure an interface filter instead of lo0 filter to discard the OSPF Hellos received on L2 port.

Include the other term in the above filter before BLOCK-OSPF to accept OSPF Hello from real OSPF peers:

root@QFX-DUT# show firewall family inet filter ospf-block 
term PERMIT-OSPF {
    from {
        source-address {
            100.1.1.1/32;
        }
        protocol ospf;
    }
    then {
        count accept-ospf;
        accept;
    }
}
term BLOCK-OSPF {
    from {
        protocol ospf;
    }
    then {
        count discard-ospf;
        discard;
    }
}
term ALL {
    then accept;
}

Configure an L2 filter and apply inbound on the interface instead of lo0 filter to block the OSPF Hellos:

​root@QFX-DUT# show firewall family ethernet-switching filter blk-ospf-onL2 
term BLOCK-OSPF {
    from {
        ip-destination-address {
            224.0.0.5/32;
        }
    }
    then discard;
}
term ALL {
    then accept;
}
root@QFX-DUT# show interfaces ae15 
unit 0 {
    family ethernet-switching {
        interface-mode trunk;
        vlan {
            members [ vlan1 vlan2 ];
        }
        filter {
            input blk-ospf-onL2;
        }
    }
}
Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search