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
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
Thanks for reading
As always, your feedback and comments are more than welcome