Junos single-area OSPF

In: Juniper

In this blog post, I will go through Junos Single area OSPF configuration and verification using Juniper vLAB Sandbox. Interfaces and OSPF configurations are already done for us, so we can jump straight into exploring and understanding various Junos OSPF features.  

Kudos to Juniper for providing such great resources. You can access the Sandbox by visiting https://jlabs.juniper.net/vlabs/

Assumptions

  • You are already familiar with Junos CLI
  • You have a basic understanding of OSPF

Summary

  • Single-area OSPF
  • OSPF Network Types
  • OSPF Database
  • Type-1 Router LSA
  • Type-2 Network LSA
  • OSPF Authentication
  • OSPF Routes

Diagram

vlab diagram

Let me SSH into vMX1 and check the OSPF configurations.

jcluser@vMX1> show configuration protocols ospf 
area 0.0.0.0 {
    interface ge-0/0/0.0;
    interface ge-0/0/1.0;
    interface ge-0/0/2.0;
    interface lo0.0;
}

jcluser@vMX1> show ospf neighbor 
Address          Interface              State           ID               Pri  Dead
10.100.12.2      ge-0/0/0.0             Full            10.100.100.2     128    39
10.100.14.2      ge-0/0/1.0             Full            10.100.100.4     128    35
10.100.13.2      ge-0/0/2.0             Full            10.100.100.3     128    34

As you can see above, all four interfaces are placed into Area 0. vMX1 has neighbourship with the other 3 routers, perfect.

OSPF Database

Since we have a single OSPF area, we would only see Type-1 and Type-2 LSAs. As you can see below there are four Router LSAs (Type-1) and six Network LSAs (Type-2) in the OSPF database.

jcluser@vMX1> show ospf database summary 
Area 0.0.0.0:
   4 Router LSAs
   6 Network LSAs
Externals:
Interface ge-0/0/0.0:
Area 0.0.0.0:
Interface ge-0/0/1.0:
Area 0.0.0.0:
Interface ge-0/0/2.0:
Area 0.0.0.0:
Interface lo0.0:
Area 0.0.0.0:

Type-1 Router LSA

Type 1 LSAs are sent between routers in the same area and helps OSPF build the full picture of the network. The LSA lists its own interfaces and neighbours. vMX1 has three interfaces in Area 0. However, it only creates a single Router LSA and within the LSA it describes the three links.

The output of the show ospf database router on vMX1 is shown below. Looking at the output we can confirm that there are four routers in  Area 0.

jcluser@vMX1> show ospf database router                                  

    OSPF database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Router  *10.100.100.1     10.100.100.1     0x80000009  2034  0x22 0x365b  72
Router   10.100.100.2     10.100.100.2     0x80000008  2035  0x22 0x95d   72
Router   10.100.100.3     10.100.100.3     0x8000000b     6  0x22 0x3415  72
Router   10.100.100.4     10.100.100.4     0x8000000a   163  0x22 0xc77a  72

Let's have a look at the Type-1 LSA generated by vMX1. Please note that I have changed the network type between vMX1 & vMX2 as P2P.

jcluser@vMX1# set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 interface-type p2p

jcluser@vMX2# set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 interface-type p2p 
jcluser@vMX1> show ospf database router lsa-id 10.100.100.1 extensive    

    OSPF database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Router  *10.100.100.1     10.100.100.1     0x80000007     4  0x22 0x4967  84
  bits 0x0, link count 5
  id 10.100.100.2, data 10.100.12.1, Type PointToPoint (1)
    Topology count: 0, Default metric: 1
  id 10.100.12.0, data 255.255.255.0, Type Stub (3)
    Topology count: 0, Default metric: 1
  id 10.100.14.2, data 10.100.14.1, Type Transit (2)
    Topology count: 0, Default metric: 1
  id 10.100.13.2, data 10.100.13.1, Type Transit (2)
    Topology count: 0, Default metric: 1
  id 10.100.100.1, data 255.255.255.255, Type Stub (3)
    Topology count: 0, Default metric: 0
  Topology default (ID 0)
    Type: Transit, Node ID: 10.100.13.2
      Metric: 1, Bidirectional
    Type: Transit, Node ID: 10.100.14.2
      Metric: 1, Bidirectional
    Type: PointToPoint, Node ID: 10.100.100.2
      Metric: 1, Bidirectional
  Gen timer 00:49:55
  Aging timer 00:59:55
  Installed 00:00:04 ago, expires in 00:59:56, sent 00:00:02 ago
  Last changed 00:00:04 ago, Change count: 6, Ours

As you can see above, the Router LSA on vMX1 describes the three physical interfaces and one loopback interface in Area 0. Let's discuss about the three "Types" showing in the output.

PointToPoint

  id 10.100.100.2, data 10.100.12.1, Type PointToPoint (1)
    Topology count: 0, Default metric: 1
  id 10.100.12.0, data 255.255.255.0, Type Stub (3)
    Topology count: 0, Default metric: 1

Type P2P defines that the link is a P2P link and there is an OSPF neighbour connected to it. If you look closely,  we see 2 x entries for the link between vMX1 & vMX2. First entry identifies the neighbour and the link IP. The second entry which is showing as stub shows the network and subnet mask. Now all the routers in the area 0 know that 10.100.12.0/24 is reachable via vMX1.

Transit

Transit type defines that the link is a multiaccess/LAN network which has a Designated Router. As you can see there is no subnet mask mentioned in the output. So, how do other routers know about the network and subnet mask? Well, DR will send out the information.This is shown in the next section.

id 10.100.14.2, data 10.100.14.1, Type Transit (2)
    Topology count: 0, Default metric: 1

Stub

Stub is when there is no neighbour in the link. This is a loopback interface so, of course there is no neighbour.

id 10.100.100.1, data 255.255.255.255, Type Stub (3)
    Topology count: 0, Default metric: 0

Type-2 Network LSA

In a broadcast/LAN network, all the routers in the area have full adjacency with DR/BDR. So, in a network where DR is elected, the DR needs to originate Type-2 LSAs and send them out to all other routers.

The network type between vMX1 & vMX3 is LAN. We can verify this by using show ospf interface command

jcluser@vMX1> show ospf interface ge-0/0/2.0 extensive 
Interface           State   Area            DR ID           BDR ID          Nbrs
ge-0/0/2.0          BDR     0.0.0.0         10.100.100.3    10.100.100.1       1
  Type: LAN, Address: 10.100.13.1, Mask: 255.255.255.0, MTU: 1500, Cost: 1
  DR addr: 10.100.13.2, BDR addr: 10.100.13.1, Priority: 128
  Adj count: 1
  Hello: 10, Dead: 40, ReXmit: 5, Not Stub
  Auth type: None
  Protection type: None
  Topology default (ID 0) -> Cost: 1

Let's check the network LSAs on vMX1

jcluser@vMX1> show ospf database network 

    OSPF database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Network  10.100.13.2      10.100.100.3     0x80000002   510  0x22 0xcd6e  32
Network  10.100.14.2      10.100.100.4     0x80000001  1673  0x22 0xc871  32
Network  10.100.23.2      10.100.100.3     0x80000001  1675  0x22 0x6fc2  32
Network  10.100.24.2      10.100.100.4     0x80000002   739  0x22 0x66c7  32
Network  10.100.34.2      10.100.100.4     0x80000002    50  0x22 0x61d   32

Why are we seeing five Network LSAs? Well, there are six links and one of them is configured as P2P.

DR election takes place based on OSPF router priority. Default priority is 128. If there is a tie,the router with highest router-id is elected the DR.

  • vMX1 and vMX2 have the lowest router-id, so they are not elected as DR for any of the LAN segment.
  • vMX3 is DR for vMX1-vMX3 & vMX2-vMX3 segment.
  • vMX4 has the highest router-id so, it is elected as DR with all three neighbours.

Let's have a look at the Type-2 LSA generated by vMX4 for the LAN segment vMX4-vMX2. We can see the network and mask information about 10.100.24.0/24 network. Now all the routers on area 0 knows that 10.100.24.0/24 is reachable via vMX4.

jcluser@vMX1> show ospf database network lsa-id 10.100.24.2 extensive 

    OSPF database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Network  10.100.24.2      10.100.100.4     0x80000002  1513  0x22 0x66c7  32
  mask 255.255.255.0
  attached router 10.100.100.4
  attached router 10.100.100.2
  Topology default (ID 0)
    Type: Transit, Node ID: 10.100.100.2
      Metric: 0, Bidirectional
    Type: Transit, Node ID: 10.100.100.4
      Metric: 0, Bidirectional
  Aging timer 00:34:46
  Installed 00:25:10 ago, expires in 00:34:47, sent 00:25:08 ago
  Last changed 00:40:53 ago, Change count: 1

Try out and re-configure OSPF features

Let's make vMX1 Designated Router by increasing the ospf router priority to 129 and check the Network LSAs again. Now we should see 3 x Type-2LSAs from vMX1 and 1 x Type-2 LSAs from vMX3 and 2 x Type-2 LSAs from vMX4.  

jcluser@vMX1# delete protocols ospf area 0.0.0.0 interface ge-0/0/0.0 interface-type p2p

jcluser@vMX2# delete protocols ospf area 0.0.0.0 interface ge-0/0/0.0 interface-type p2p 

jcluser@vMX1# set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 priority 129
jcluser@vMX1# set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 priority 129
jcluser@vMX1# set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 priority 129
jcluser@vMX1> show ospf neighbor detail 
Address          Interface              State           ID               Pri  Dead
10.100.12.2      ge-0/0/0.0             Full            10.100.100.2     128    34
  Area 0.0.0.0, opt 0x52, DR 10.100.12.1, BDR 10.100.12.2
  Up 00:00:51, adjacent 00:00:51
10.100.14.2      ge-0/0/1.0             Full            10.100.100.4     128    34
  Area 0.0.0.0, opt 0x52, DR 10.100.14.1, BDR 10.100.14.2
  Up 00:00:51, adjacent 00:00:51
10.100.13.2      ge-0/0/2.0             Full            10.100.100.3     128    33
  Area 0.0.0.0, opt 0x52, DR 10.100.13.1, BDR 10.100.13.2

You can see above that vMX1 is the DR for all three links (shown as DR 10.100.12.1, DR 10.100.14.1 & DR 10.100.13.1)

jcluser@vMX1> show ospf database network 

    OSPF database, Area 0.0.0.0
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Network *10.100.12.1      10.100.100.1     0x80000001   127  0x22 0xea57  32
Network *10.100.13.1      10.100.100.1     0x80000002   126  0x22 0xeb53  32
Network *10.100.14.1      10.100.100.1     0x80000001   127  0x22 0xf04d  32
Network  10.100.23.2      10.100.100.3     0x80000001   496  0x22 0x6fc2  32
Network  10.100.24.2      10.100.100.4     0x80000001   510  0x22 0x68c6  32
Network  10.100.34.2      10.100.100.4     0x80000001   501  0x22 0x81c   32

Let's change the OSPF Network type to P2P on all the interfaces. Now each link is treated as a point-to-point link so, there are no DRs or BDRs elected. So there shouldn't be any Type-2 LSAs.

jcluser@vMX1# load set terminal 
[Type ^D at a new line to end input]
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 interface-type p2p
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 interface-type p2p
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 interface-type p2p
load complete

jcluser@vMX2# load set terminal 
[Type ^D at a new line to end input]
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 interface-type p2p
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 interface-type p2p
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 interface-type p2p
load complete

jcluser@vMX3# load set terminal 
[Type ^D at a new line to end input]
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 interface-type p2p
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 interface-type p2p
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 interface-type p2p
load complete

jcluser@vMX4# load set terminal 
[Type ^D at a new line to end input]
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 interface-type p2p
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 interface-type p2p
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 interface-type p2p
load complete

As you can see below, now the interface type is showing as P2P.

jcluser@vMX1> show ospf interface ge-0/0/0.0 extensive 
Interface           State   Area            DR ID           BDR ID          Nbrs
ge-0/0/0.0          PtToPt  0.0.0.0         0.0.0.0         0.0.0.0            1
  Type: P2P, Address: 10.100.12.1, Mask: 255.255.255.0, MTU: 1500, Cost: 1
  Adj count: 1
  Hello: 10, Dead: 40, ReXmit: 5, Not Stub
  Auth type: None
  Protection type: None
  Topology default (ID 0) -> Cost: 1

As I mentioned earlier, now we only have 4 x Type-1 LSAs. There are no Type-2 LSAs.

jcluser@vMX1> show ospf database summary 
Area 0.0.0.0:
   4 Router LSAs
Externals:
Interface ge-0/0/0.0:
Area 0.0.0.0:
Interface ge-0/0/1.0:
Area 0.0.0.0:
Interface ge-0/0/2.0:
Area 0.0.0.0:
Interface lo0.0:
Area 0.0.0.0:

Configuring OSPF Authentication

Simple authentication

Easy to configure / weak security. The password transmitted between the neighbours are not encrypted. Let's configure plain-text password authentication between vMX1 and vMX2.

jcluser@vMX1# set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 authentication simple-password junos123 

[edit]
jcluser@vMX1# commit 
commit complete

jcluser@vMX2# set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 authentication simple-password junos123 

[edit]
jcluser@vMX2# commit 
commit complete

As you can see below that the Auth type is set to Password

jcluser@vMX1> show ospf interface ge-0/0/0.0 extensive 
Interface           State   Area            DR ID           BDR ID          Nbrs
ge-0/0/0.0          PtToPt  0.0.0.0         0.0.0.0         0.0.0.0            1
  Type: P2P, Address: 10.100.12.1, Mask: 255.255.255.0, MTU: 1500, Cost: 1
  Adj count: 1
  Hello: 10, Dead: 40, ReXmit: 5, Not Stub
  Auth type: Password
  Protection type: None
  Topology default (ID 0) -> Cost: 1

MD5 Authentication

An encoded MD5 checksum is transmitted between the neighbours which improves security compared to the previous method. Let's configure MD5 authentication between vMX3 and vMX4.

jcluser@vMX3# set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 authentication md5 1 key juniper

jcluser@vMX4# set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 authentication md5 1 key juniper

As you can see below that the Auth type is set to MD5 (Please ignore the time)

jcluser@vMX3> show ospf interface ge-0/0/0.0 extensive 
Interface           State   Area            DR ID           BDR ID          Nbrs
ge-0/0/0.0          PtToPt  0.0.0.0         0.0.0.0         0.0.0.0            1
  Type: P2P, Address: 10.100.34.1, Mask: 255.255.255.0, MTU: 1500, Cost: 1
  Adj count: 1
  Hello: 10, Dead: 40, ReXmit: 5, Not Stub
  Auth type: MD5, Active key ID: 1, Start time: 1970 Jan  1 00:00:00 UTC
  Protection type: None
  Topology default (ID 0) -> Cost: 1

OSPF Routes

Cost/Metric

All OSPF interfaces have a cost, which is a routing metric that is used in the link-state calculation. Routes with lower total path metrics/cost are preferred to those with higher path metrics. In this example, we explore how to control the cost of OSPF network.

jcluser@vMX1> show route protocol ospf   

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

10.100.23.0/24     *[OSPF/10] 00:03:11, metric 2
                       to 10.100.12.2 via ge-0/0/0.0
                    >  to 10.100.13.2 via ge-0/0/2.0
10.100.24.0/24     *[OSPF/10] 00:03:11, metric 2
                    >  to 10.100.12.2 via ge-0/0/0.0
                       to 10.100.14.2 via ge-0/0/1.0
10.100.34.0/24     *[OSPF/10] 00:03:16, metric 2
                       to 10.100.14.2 via ge-0/0/1.0
                    >  to 10.100.13.2 via ge-0/0/2.0
10.100.100.2/32    *[OSPF/10] 00:03:11, metric 1
                    >  to 10.100.12.2 via ge-0/0/0.0
10.100.100.3/32    *[OSPF/10] 00:03:16, metric 1
                    >  to 10.100.13.2 via ge-0/0/2.0
10.100.100.4/32    *[OSPF/10] 00:03:26, metric 1
                    >  to 10.100.14.2 via ge-0/0/1.0
224.0.0.5/32       *[OSPF/10] 00:04:17, metric 1
                       MultiRecv

inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

Looking at the above output it seems that there are two equal paths to reach 10.100.23.0/24 network. Junos picks one of them as a best path via ge-0/0/2 (with the > symbol) What if we want to send traffic via ge-0/0/0 instead. Well, we can achieve this by increasing the cost/metric on the link towards vMX3.

jcluser@vMX1# set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 metric 3 

jcluser@vMX1> show ospf interface ge-0/0/2.0 extensive    
Interface           State   Area            DR ID           BDR ID          Nbrs
ge-0/0/2.0          BDR     0.0.0.0         10.100.100.3    10.100.100.1       1
  Type: LAN, Address: 10.100.13.1, Mask: 255.255.255.0, MTU: 1500, Cost: 3
  DR addr: 10.100.13.2, BDR addr: 10.100.13.1, Priority: 128
  Adj count: 1
  Hello: 10, Dead: 40, ReXmit: 5, Not Stub
  Auth type: None
  Protection type: None
  Topology default (ID 0) -> Cost: 3

Let's check the route table again

jcluser@vMX1# run show route protocol ospf                                     

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

10.100.13.0/24      [OSPF/10] 00:00:04, metric 3
                    >  to 10.100.12.2 via ge-0/0/0.0
                       to 10.100.14.2 via ge-0/0/1.0
10.100.23.0/24     *[OSPF/10] 00:00:04, metric 2
                    >  to 10.100.12.2 via ge-0/0/0.0
10.100.24.0/24     *[OSPF/10] 00:13:57, metric 2
                    >  to 10.100.12.2 via ge-0/0/0.0
                       to 10.100.14.2 via ge-0/0/1.0
10.100.34.0/24     *[OSPF/10] 00:00:04, metric 2
                    >  to 10.100.14.2 via ge-0/0/1.0
10.100.100.2/32    *[OSPF/10] 00:13:57, metric 1
                    >  to 10.100.12.2 via ge-0/0/0.0
10.100.100.3/32    *[OSPF/10] 00:00:04, metric 2
                       to 10.100.12.2 via ge-0/0/0.0
                    >  to 10.100.14.2 via ge-0/0/1.0
10.100.100.4/32    *[OSPF/10] 00:14:12, metric 1
                    >  to 10.100.14.2 via ge-0/0/1.0
224.0.0.5/32       *[OSPF/10] 00:15:03, metric 1
                       MultiRecv

inet6.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)

As we expected, the traffic is now going via ge-0/0/0.

Cost metric for a Loopback interface is 0 by default and 1 to any link faster than 100 Mbps

Reference

Introduction to OSPF - TechLibrary - Juniper Networks
OSPF Overview, OSPF Packets Overview, Understanding OSPF External Metrics, Supported OSPF and OSPFv3 Standards

Thanks for reading

As always, your feedback and comments are more than welcome

Written by
Suresh Vina
Tech enthusiast sharing Networking, Cloud & Automation insights. Join me in a welcoming space to learn & grow with simplicity and practicality.
Comments
More from Packetswitch
Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to Packetswitch.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.