This article provides an example of blocking the Type 3 OSPF LSAs or interarea routes on the SRX series.

There are situations when it is required in the network to block the interarea routes from being learned by other areas. For example, in the following setup we have three devices that are running OSPF and using the policy-options statement (called in the OSPF area using instance import/export). This doesn't work for inter-area routes.

    SRX1(ge-0/0/0.0)---------------(ge-0/0/0.0)SRX2(ge-0/0/1.0)---------------(ge-0/0/1.0)SRX3
           area 0 (192.168.1.0/24)                         area 10(192.168.4.0/24)

Router-IDs:
SRX1 : 1.1.1.1
SRX2 : 2.2.2.2
SRX3 : 3.3.3.3

root@SRX1# show protocols
ospf {
      export pol1;
      area 0.0.0.0 {
                       interface ge-0/0/0.0;
                       interface lo0.1;       >>>> lo0.1 (11.11.11.11/32) interface route which would be Type 3 LSA, for other areas will be blocked at SRX2
                            }
        }

root@SRX2# show protocols
ospf {
   area 0.0.0.0 {
                interface ge-0/0/0.0;
                        }
  area 0.0.0.10 {
              interface ge-0/0/1.0;
                          }
     }

root@SRX3# show protocols
ospf {
    area 0.0.0.10 {
               interface ge-0/0/1.0;
                           }
       }

On the SRX3, we see the Network Summary LSA being sent and learned in the OSPF routes:

Prefix Path Route NH Metric NextHop Nexthop
Type           Type          Type Interface Address/LSP
11.11.11.11/32 Inter Network IP 2 ge-0/0/1.0 192.168.4.2
area 0.0.0.10, origin 2.2.2.2, priority medium

On the SRX2 (it being the ABR) applied the policy-options statement to reject the route from being exported to Area 10:

root@SRX2# show policy-options
policy-statement pol1 {
                   term 1 {
                       from {
                          protocol ospf;
                          route-filter 11.11.11.11/32 exact;
                            }
                       then reject;
                      }
                  term 2 {
                      then reject;
                         }
                     }

root@SRX2# show protocols
ospf {
   export pol1;
   area 0.0.0.0 {
           interface ge-0/0/0.0;
                }
  area 0.0.0.10 {
          interface ge-0/0/1.0;
                }
     }

However checking OSPF database of Area 10 , we still see LSA being sent and hence Type 3 LSAs are not blocked using policy-options.

root@SRX3# run show ospf database

OSPF database, Area 0.0.0.10
Type     ID         Adv Rtr     Seq    Age  Opt   Cksum Len
Router  2.2.2.2     2.2.2.2 0x80000010 113  0x22 0x81b0 36
Router *3.3.3.3     3.3.3.3 0x80000006 614  0x22 0x4ee7 36
Network 192.168.4.2 2.2.2.2 0x80000003 2045 0x22 0x4864 32
Summary 11.11.11.11 2.2.2.2 0x80000001 440  0x22 0x5bac 28   >>> LSA still being sent to SRX3
Summary 192.168.1.0 2.2.2.2 0x80000003 2473 0x22 0x9631 28
ASBRSum 1.1.1.1     2.2.2.2 0x80000003 1188 0x22 0x1716 28

The policy-options statement, when used with instance import/export in the OSPF protocol configuration, is only meant to block the external routes. Type 3 LSAs, being interarea routes, cannot be blocked using the same method.

In order to block the interarea routes, Type 3, or network summary LSAs on the SRX, use the network-summary-export/network-summary-import option under the specific area. In the example above , we want the Type 3 LSA from area 0 not to be sent to area 10. On SRX1, lo0.1 has IP 11.11.11.11/32 configured as participating in the OSPF and hence it will be advertised as a Type 3 LSA (interarea route) by SRX2 (ABR) to area 10.

On SRX2, it being the ABR, we give the following config: