Description

This article describes the issue of wrong configuration of the firewall filter leading to an unstable OSPF network.

Even if firewall filter allows the passing of OSPF traffic, drop action may drop the OSPF traffic because of the wrong configuration. If the filter has been set on an OSPF interface or RE, then the LSA does not reach to kernel and the OSPF network will be unstable.

Symptoms

The destination-port statement of the firewall filter simply checks the 2nd two byte just after the IP header; it does not check the protocol field in the IP header.


alt
alt


So if you need to filter HTTP,  the configuration should specified as a protocol:

firewall {
    filter drop_HTTP {
    term 1 {
    from {
    protocol [ tcp udp ];
destination-port http;
}
then {
    discard;
}
}
term 2 {
    then accept;
}
}
}

If there is no protocol statement:
firewall {
    filter drop_HTTP {
    term 1 {
    from {
    destination-port http;
}
then {
    discard;
}
}
term 2 {
    then accept;
}
  }
    }

this filter only checks the 2nd two byte just after the IP header and evaluates if the traffic is HTTP or not.

The OSPF traffic has the OSPF packet length field at the same position with the port field of TCP/UDP.


alt


if an LSA is has the value - 80 in the OSPF packet length , the packet is treated as HTTP and hit in term 1. The LSA  is then discarded and the OSPF network will be unstable.

This is not only HTTP; any application which is specified as the destination port must be configured with this protocol.

Note : This behavior affects not only OSPF, but also all other IP protocols. 


Solution

this is a simple configuration issue and caused by lack of protocol type.

Specify the following protocol type with the destination-port:

firewall {
    filter drop_HTTP {
     term 1 {
      from {
     protocol [ tcp udp ];
destination-port http;
}
then {
        discard;
}
  }
term 2 {
    　  then accept;
}
}
}

Modification History

2025-06-26: Minor, non-technical update

2011-12-17: Article created