Juniper OSPF Inter-Area Filtering

Right now I'm on a bit of a break with my CCIE studies but I'm still playing with routers.  As it's been a little while since I've played with Junos and I'm planning on attempting the JNCIP-SP in the next couple of months, I have been getting familiar again using Olives which will really only allow a subset of the blueprint to be tested because things like QoS and VPLS cant really be tested on it but it's still quite a reasonable platform.  I'm not going to discuss much on Olives, there is plenty of guides and so on available which your favourite search engine may assist with.

For those people interested in learning Junos but are really only have an IOS background.  There is some free online training material from Juniper called Junos as a Second Language


The routers I'm playing with at the moment have all have interface em1 connected to the same virtual switch.  Point to point links are established using VLANs.  R3 is the OSPF ABR with only it's loopback interface in OSPF Area 0

R1 (OSPF Area 13)
root@R1> show configuration | display set
set system host-name R1
set interfaces em1 vlan-tagging
set interfaces em1 unit 13 vlan-id 13
set interfaces em1 unit 13 family inet address 10.1.13.1/24
set interfaces lo0 unit 0 family inet address 1.1.1.1/32
set routing-options router-id 1.1.1.1
set protocols ospf area 0.0.0.13 interface lo0.0
set protocols ospf area 0.0.0.13 interface em1.13

R2 (OSPF Area 23)
root@R2> show configuration | display set
set system host-name R2
set interfaces em1 vlan-tagging
set interfaces em1 unit 23 vlan-id 23
set interfaces em1 unit 23 family inet address 10.1.23.2/24
set interfaces lo0 unit 0 family inet address 2.2.2.2/32
set routing-options router-id 2.2.2.2
set protocols ospf area 0.0.0.23 interface em1.23
set protocols ospf area 0.0.0.23 interface lo0.0

R3 (ABR)
root@R3> show configuration | display set
set system host-name R3
set interfaces em1 vlan-tagging
set interfaces em1 unit 13 vlan-id 13
set interfaces em1 unit 13 family inet address 10.1.13.3/24
set interfaces em1 unit 23 vlan-id 23
set interfaces em1 unit 23 family inet address 10.1.23.3/24
set interfaces lo0 unit 0 family inet address 3.3.3.3/32
set routing-options router-id 3.3.3.3
set protocols ospf area 0.0.0.0 interface lo0.0
set protocols ospf area 0.0.0.13 interface em1.13
set protocols ospf area 0.0.0.23 interface em1.23

Let's check that our adjacencies are up:

root@R1> show ospf neighbor
Address          Interface              State     ID               Pri  Dead
10.1.13.3        em1.13                 Full      3.3.3.3          128    39

root@R2> show ospf neighbor
Address          Interface              State     ID               Pri  Dead
10.1.23.3        em1.23                 Full      3.3.3.3          128    36

root@R3> show ospf neighbor
Address          Interface              State     ID               Pri  Dead
10.1.23.2        em1.23                 Full      2.2.2.2          128    34
10.1.13.1        em1.13                 Full      1.1.1.1          128    34

Lets have a look at the routing table and ospf databases

 root@R1> show route terse

inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* 1.1.1.1/32         D   0                       >lo0.0
* 2.2.2.2/32         O  10          2            >10.1.13.3
* 3.3.3.3/32         O  10          1            >10.1.13.3
* 10.1.13.0/24       D   0                       >em1.13
* 10.1.13.1/32       L   0                        Local
* 10.1.23.0/24       O  10          2            >10.1.13.3
* 224.0.0.5/32       O  10          1             MultiRecv


In this mode which is the basic way to see the routing table, we cant tell what kind of OSPF routes are present as we can in IOS - however there's a different command "show ospf route" which can help out in that regard:



root@R1> show ospf route
Topology default Route Table:

Prefix             Path  Route      NH       Metric NextHop       Nexthop
                   Type  Type       Type            Interface     Address/LSP
3.3.3.3            Intra Area BR    IP            1 em1.13        10.1.13.3
1.1.1.1/32         Intra Network    IP            0 lo0.0
2.2.2.2/32         Inter Network    IP            2 em1.13        10.1.13.3
3.3.3.3/32         Inter Network    IP            1 em1.13        10.1.13.3
10.1.13.0/24       Intra Network    IP            1 em1.13
10.1.23.0/24       Inter Network    IP            2 em1.13        10.1.13.3

root@R2> show ospf route
Topology default Route Table:

Prefix             Path  Route      NH       Metric NextHop       Nexthop
                   Type  Type       Type            Interface     Address/LSP
3.3.3.3            Intra Area BR    IP            1 em1.23        10.1.23.3
1.1.1.1/32         Inter Network    IP            2 em1.23        10.1.23.3
2.2.2.2/32         Intra Network    IP            0 lo0.0
3.3.3.3/32         Inter Network    IP            1 em1.23        10.1.23.3
10.1.13.0/24       Inter Network    IP            2 em1.23        10.1.23.3
10.1.23.0/24       Intra Network    IP            1 em1.23

root@R3> show ospf route
Topology default Route Table:

Prefix             Path  Route      NH       Metric NextHop       Nexthop
                   Type  Type       Type            Interface     Address/LSP
1.1.1.1            Intra Router     IP            1 em1.13        10.1.13.1
2.2.2.2            Intra Router     IP            1 em1.23        10.1.23.2
1.1.1.1/32         Intra Network    IP            1 em1.13        10.1.13.1
2.2.2.2/32         Intra Network    IP            1 em1.23        10.1.23.2
3.3.3.3/32         Intra Network    IP            0 lo0.0
10.1.13.0/24       Intra Network    IP            1 em1.13
10.1.23.0/24       Intra Network    IP            1 em1.23


The "show ospf route" command are from the router's point of view.  When the router is an OSPF ABR because we are serving multiple areas, what is considered an intra network route may be correct for one area, while being inter-network routes for other areas and therfore the "show ospf database" may be of more help here.

root@R3> show ospf database

    OSPF database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Router  *3.3.3.3          3.3.3.3          0x80000004    36  0x22 0x67a3  36
Summary *1.1.1.1          3.3.3.3          0x80000002    36  0x22 0x922   28
Summary *2.2.2.2          3.3.3.3          0x80000003    36  0x22 0xd84d  28
Summary *10.1.13.0        3.3.3.3          0x80000003    36  0x22 0x17fe  28
Summary *10.1.23.0        3.3.3.3          0x80000021    35  0x22 0x6c81  28

    OSPF database, Area 0.0.0.13
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Router   1.1.1.1          1.1.1.1          0x80000007    37  0x22 0x6973  48
Router  *3.3.3.3          3.3.3.3          0x80000007    36  0x22 0x2eaf  36
Network *10.1.13.3        3.3.3.3          0x80000003    36  0x22 0x9d63  32
Summary *2.2.2.2          3.3.3.3          0x80000003    36  0x22 0xd84d  28
Summary *3.3.3.3          3.3.3.3          0x80000003    36  0x22 0xa082  28
Summary *10.1.23.0        3.3.3.3          0x80000006    35  0x22 0xa266  28

    OSPF database, Area 0.0.0.23
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Router   2.2.2.2          2.2.2.2          0x8000002e    37  0x22 0xc88   48
Router  *3.3.3.3          3.3.3.3          0x8000002c    36  0x22 0xc0e3  36
Network *10.1.23.3        3.3.3.3          0x80000002    36  0x22 0x6390  32
Summary *1.1.1.1          3.3.3.3          0x80000002    36  0x22 0x922   28
Summary *3.3.3.3          3.3.3.3          0x80000003    36  0x22 0xa082  28
Summary *10.1.13.0        3.3.3.3          0x80000003    36  0x22 0x17fe  28

Lets add an extra internal network on R1 to be advertised in OSPF - we can do this by adding another IP Address on the loopback interface.

root@R1> configure
Entering configuration mode

[edit]
root@R1# set interfaces lo0 unit 0 family inet address 111.111.111.111/24
root@R1# commit and-quit

root@R1> show route terse | match 111
* 111.111.111.0/24   D   0                       >lo0.0
* 111.111.111.111/32 L   0                        Local


root@R2> show route terse | match 111
* 111.111.111.0/24   O  10          2            >10.1.23.3
* 111.111.111.111/32 O  10          2            >10.1.23.3

Seeing two routes associated was a little unexpected, however I suspect this is due to the type "L" local route.

Interestingly Junos appears to advertise both of these into OSPF rather than treating the loopback interface with a network mask the same as a host route (as per page 128 of RFC2328) - it seems to do a bit of a hybrid of the point-to-point network type and host-route

root@R1> show ospf database router lsa-id 1.1.1.1 detail

    OSPF database, Area 0.0.0.13
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Router  *1.1.1.1          1.1.1.1          0x8000000c   463  0x22 0xb6f4  72
  bits 0x0, link count 4
  id 10.1.13.3, data 10.1.13.1, Type Transit (2)
    Topology count: 0, Default metric: 1
  id 1.1.1.1, data 255.255.255.255, Type Stub (3)
    Topology count: 0, Default metric: 0
  id 111.111.111.111, data 255.255.255.255, Type Stub (3)
    Topology count: 0, Default metric: 0
  id 111.111.111.0, data 255.255.255.0, Type Stub (3)
    Topology count: 0, Default metric: 0
  Topology default (ID 0)
    Type: Transit, Node ID: 10.1.13.3
      Metric: 1, Bidirectional

If we specifically set the ospf network interface type of the loopback to to point-to-point maybe that brings things back to what I would expect to see.

root@R1> configure
Entering configuration mode

[edit]
root@R1# set protocols ospf area 13 interface lo0.0 interface-type p2p

[edit]
root@R1# show protocols ospf
area 0.0.0.13 {
    interface lo0.0 {
        interface-type p2p;
    }
    interface em1.13;
}

[edit]
root@R1# commit and-quit
commit complete
Exiting configuration mode
root@R1> show ospf database router lsa-id 1.1.1.1 detail

    OSPF database, Area 0.0.0.13
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Router  *1.1.1.1          1.1.1.1          0x8000000e    25  0x22 0x3d3a  60
  bits 0x0, link count 3
  id 10.1.13.3, data 10.1.13.1, Type Transit (2)
    Topology count: 0, Default metric: 1
  id 111.111.111.0, data 255.255.255.0, Type Stub (3)
    Topology count: 0, Default metric: 0
  id 1.1.1.1, data 255.255.255.255, Type Stub (3)
    Topology count: 0, Default metric: 0
  Topology default (ID 0)
    Type: Transit, Node ID: 10.1.13.3
      Metric: 1, Bidirectional

root@R2> show ospf database netsummary

    OSPF database, Area 0.0.0.23
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Summary  1.1.1.1          3.3.3.3          0x80000004  1073  0x22 0x524   28
Summary  3.3.3.3          3.3.3.3          0x80000004  1091  0x22 0x9e83  28
Summary  10.1.13.0        3.3.3.3          0x80000004   905  0x22 0x15ff  28
Summary  111.111.111.0    3.3.3.3          0x80000001  1073  0x22 0x8d54  28
 

root@R2> show route terse | match 111
* 111.111.111.0/24   O  10          2            >10.1.23.3

Yes it does.  Okay now things are as expected, now lets filter the 111.111.111.0/24 route from appearing in R2's routing table and ospf database.

Lets check the OSPF database for the different area on the ABR with the summary routes for 111.111.111.0/24

root@R3> show ospf database | match "Area|111"
    OSPF database, Area 0.0.0.0
Summary *111.111.111.0    3.3.3.3          0x80000001  1428  0x22 0x8d54  28
    OSPF database, Area 0.0.0.13
    OSPF database, Area 0.0.0.23
Summary *111.111.111.0    3.3.3.3          0x80000001  1428  0x22 0x8d54  28

Inter-Area filtering can be done to limit the flow of Type 3 (Summary) LSAs on the ABR using routing policy, in this case we will be stopping 111.111.111.0/24 from being exported from OSPF Area 0 into OSPF Area 23:

root@R3> configure
Entering configuration mode

[edit]
root@R3# set policy-options policy-statement ToArea23 term 10 from route-filter 111.111.111.0/24 exact
root@R3# set policy-options policy-statement ToArea23 term 10 then reject
root@R3# set policy-options policy-statement ToArea23 term 20 then accept
root@R3# set protocols ospf area 0.0.0.23 network-summary-export ToArea23
root@R3# commit and-quit

Let's make sure the ABR still has the route available

root@R3> show route terse 111.111.111.0/24

inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* 111.111.111.0/24   O  10          1            >10.1.13.1

And lets compare the ospf database output and see if 111.111.111.0/24 is no longer in area 23

root@R3> show ospf database | match "Area|111"
    OSPF database, Area 0.0.0.0
Summary *111.111.111.0    3.3.3.3          0x80000001  1546  0x22 0x8d54  28
    OSPF database, Area 0.0.0.13
    OSPF database, Area 0.0.0.23

Nope, one last final verification

root@R2> show route terse 111.111.111.0/24

root@R2> show ospf database netsummary

    OSPF database, Area 0.0.0.23
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Summary  1.1.1.1          3.3.3.3          0x80000004  1547  0x22 0x524   28
Summary  3.3.3.3          3.3.3.3          0x80000004  1565  0x22 0x9e83  28
Summary  10.1.13.0        3.3.3.3          0x80000004  1379  0x22 0x15ff  28

Cool.  So we've tried an export policy, lets quickly test an import policy doing a similar job.  This time lets add 222.222.222.222/16 to R2's loopback and stop it from being advertised to R1.



root@R2> configure
Entering configuration mode

[edit]
root@R2# set interfaces lo0 unit 0 family inet address 222.222.222.222/16

root@R2# set protocols ospf area 23 interface lo0.0 interface-type p2p

root@R2# commit and-quit

root@R1> show route terse | match 222
* 222.222.0.0/16     O  10          2            >10.1.13.3

root@R3> show ospf database | match "Area|222"

    OSPF database, Area 0.0.0.0
Summary *222.222.0.0      3.3.3.3          0x80000001     5  0x22 0x75fc  28
    OSPF database, Area 0.0.0.13
Summary *222.222.0.0      3.3.3.3          0x80000001     5  0x22 0x75fc  28
    OSPF database, Area 0.0.0.23

root@R3> show ospf database router lsa-id 2.2.2.2 detail

    OSPF database, Area 0.0.0.23
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Router   2.2.2.2          2.2.2.2          0x80000032  1292  0x22 0x7052  60
  bits 0x0, link count 3
  id 10.1.23.3, data 10.1.23.2, Type Transit (2)
    Topology count: 0, Default metric: 1
  id 2.2.2.2, data 255.255.255.255, Type Stub (3)
    Topology count: 0, Default metric: 0
  id 222.222.0.0, data 255.255.0.0, Type Stub (3)
    Topology count: 0, Default metric: 0
  Topology default (ID 0)
    Type: Transit, Node ID: 10.1.23.3
      Metric: 1, Bidirectional


In this case, we're using an import policy on the ABR to stop the route associated Type 1 LSA from being turned into a Type 3 LSA
 
root@R3> configure
Entering configuration mode

[edit]
root@R3# set policy-options policy-statement FromArea23 term 10 from route-filter 222.222.0.0/16 exact
root@R3# set policy-options policy-statement FromArea23 term 10 then reject
root@R3# set policy-options policy-statement FromArea23 term 20 then accept
root@R3# set protocols ospf area 0.0.0.23 network-summary-import FromArea23

root@R2# commit and-quit

Let's make sure the ABR still has the route (which it will have due to one of the interfaces being in OSPF area 23)

root@R3> show route terse | match 222
* 222.222.0.0/16     O  10          1            >10.1.23.2

Now lets see if there are any Type 3 LSAs associated with 222.222.0.0/16

root@R3> show ospf database | match "Area|222"
    OSPF database, Area 0.0.0.0
    OSPF database, Area 0.0.0.13
    OSPF database, Area 0.0.0.23

Nope - our policy is doing it's job, so there shouldn't be a route for 222.222.0.0/16 on R1 either:

root@R1> show route terse | match 222

Which is what we wanted to see.

So there you go.