Product Affected

This issue affects the EX4300 platform running Junos OS.
Medium
5.3 (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N)

Problem

On the EX4300 platform, a firewall filter applied on the lo0 interface may not work as expected.  OSPF adjacencies form irrespective of the source-address.
The adjacency should never form using the configuration below. It should only form if the correct source-address is used in the OSPF_NEIGHBORS term, in this case, the 192.168.1.x/24 subnet.

This same configuration works on the EX4200 as expected. The adjacency does not form until the incorrect source-address is replaced with the correct one.

In below example, an incorrect source-address 172.16.1.x/32 subnet is used intentionally in the OSPF_NEIGHBOR term.
The term should not match and it should go to the next term - DENY_ANY term, where the action is count and discard.
However, the adjacency forms regardless of the source-address in the OSPF_NEIGHBOR term.
It is not discarded or counted by DENY_ANY term as indicated by the formation of a Full adjacency and DENIED_TRAFFFIC counter.

JTAC Lab setup Details

This limitation is reproduced in the JTAC lab using EX4300.

EX4300-1 - ge-0/0/15 ------------ ge-0/0/15 - EX4300-2

Configuration 

{master:0} root@ospf-1> show configuration | display set set version 13.2X51-D37.1 set system host-name ospf-1
set system root-authentication encrypted-password "$1$QKgKM4mj$SjcxtW9i/ILQQYLK2IMzF1"
set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.1/24
set interfaces lo0 unit 0 family inet filter input OSPF_FILTER
set interfaces lo0 unit 0 family inet address 1.1.1.1/32
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
set firewall family inet filter OSPF_FILTER term OSPF_NEIGHBOR from source-address 172.16.1.2/32
set firewall family inet filter OSPF_FILTER term OSPF_NEIGHBOR from protocol ospf
set firewall family inet filter OSPF_FILTER term OSPF_NEIGHBOR then log
set firewall family inet filter OSPF_FILTER term OSPF_NEIGHBOR then accept
set firewall family inet filter OSPF_FILTER term DENY_ANY then count DENIED_TRAFFIC
set firewall family inet filter OSPF_FILTER term DENY_ANY then discard


{master:0}
root@ospf-2> show configuration | display set
set version 14.1X53-D30.3
set system host-name ospf-2
set system root-authentication encrypted-password "$1$m0KUv05.$jkU1qDmiRaEuW5zTQxNm80"
set interfaces ge-0/0/0 unit 0 family inet address 192.168.1.2/24
set interfaces lo0 unit 0 family inet filter input OSPF_FILTER
set interfaces lo0 unit 0 family inet address 2.2.2.2/32
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
set firewall family inet filter OSPF_FILTER term OSPF_NEIGHBOR from source-address 172.16.1.1/32
set firewall family inet filter OSPF_FILTER term OSPF_NEIGHBOR from protocol ospf
set firewall family inet filter OSPF_FILTER term OSPF_NEIGHBOR then log
set firewall family inet filter OSPF_FILTER term OSPF_NEIGHBOR then accept
set firewall family inet filter OSPF_FILTER term DENY_ANY then count DENIED_TRAFFIC
set firewall family inet filter OSPF_FILTER term DENY_ANY then discard

Solution

Root Cause

In a nutshell, EX4200 and EX4300 use different chipsets and hence there are changes in the way these (multicast destination IP – 224.0.0.X) packets are handled.
OSPF packets are making it to CPU due to implicit rule to allow IP reserved Multicast packets which is placed before last discard term. This is needed to allow all multicast transit packets to not get discarded. We are basically running into chipset limitations. To handle limitations/behaviors, our design expects user to add explicit discard term for the kind of packets that are not needed to be trapped to CPU. The last discard term discards regular L3 data packets (except destination IP=224.0.0.x packets) and control packets which are L3 routed and not explicitly accepted by terms before.

We are basically dealing with below limitations:
  1. Chipset on the EX4300 platform sets destination port as CPU port even for transit multicast packets
  2. The EX4300 platform chipset's action resolution engine, Discard wins over any action and hence in the absence of implicit term to allow reserved multicast packets, protocol packets would get discarded if user does not configure explicit term for each and every packet which is not scalable.
  3. The EX4300 platform chipset does not treat TTL expired packets as routed packets and loopback filter being applied on family inet, it is expected to act only on L3 routed packets

Solution

To overcome this limitation, it is required to configure explicit discard term for unwanted OSPF packets as below to overcome specific chipset limitations. 
root@ospf-2# show | compare
[edit firewall family inet filter OSPF_FILTER]
term OSPF_NEIGHBOR { ... }
+ term OSPF_tmp {
+ from {
+ source-address {
+ 192.168.1.1/32;
+ }
+ protocol ospf;
+ }
+ then {
+ count intersted_SA;
+ discard; <---------
+ }
+ }
term DENY_ANY { ... }

root@ospf-2> show ospf neighbor
(no output returned)

This is specific to the packets with multicast destination IP – 224.0.0.X address. Since OSPF hello uses 224.0.0.5 address, it requires explicit discard for unwanted source IP addresses.
Any other terms which do not use this address should not be impacted. For example, SSH and IPV6 traffic is not affected by this limitation.
 
 

Workaround

See Solution section above.
 

Modification History

2016-04-26: Initial publication
2016-05-02: Removed software version reference.  Affects all versions of Junos OS.
2017-03-05: Category restructure.
2018-03-19: Clarified that issue only affects EX4300 platform.