Linux, FreeBSD, Juniper, Cisco / Network security articles and troubleshooting guides

Understanding the OSPF External NSSA LSA Metric Type 1 with JunOS examples

This week, an interesting deployment was presented by a colleague where one SRX device was deployed as a central device (enterprise HUB / customer edge) with a link towards managed MPLS service in OSPF area 0 and two ipsec tunnels in OSPF area 1(NSSA). One IPSEC tunnel (st0.0) flowing through the internet and the other (st0.1) through the provider MPLS service as in the above diagram. This is typical deployment of site-to-site connectivity that Enterprises implement via internet secure tunnels and an MPLS services offering redundancy and control over traffic paths.

The IPSEC tunnel flowing thorugh the MPLS network has tunnel endpoints the loopbacks of both devices, thus a static route towards the loopback is required in both PE devices.

Another characteristic of this design is that the loopbacks, which are endpoints of the st0.1 tunnel, are not in the OSPF domain. More on the reason why, later on.

The spoke device (vSRX2) is also an ASBR importing routes for the 8/8 space into the OSPF domain as NSSA External routes metric type 1. I will list here configuration and relevant output from both vSRX devices as well as my questions and answers.

Following is a diagram showing the network topology:

Initial HUB and Spoke vSRX configuration

HUB vSRX


Spoke vSRX:

Question: Why doesn’t the HUB vSRX install st0.0 and st0.1 interfaces endpoint as next hop ?

As seen on the output, vSRX1 prefers the 8/8 prefix via st0.0 tunnel (built over the internet):


To answer this question, we look at the NSSA Type 7 LSA:

By quickly looking at the LSA output and the diagram, we see that vSRX2 (spoke) injects the 8/8 prefix into OSPF as a metric type 1 NSSA External route and sets the forwarding address to it’s local st0.0 IP address.

Based on this, vSRX2 - the HUB - calculates for this prefix a metric of 2 as the sum of the redistribution metric (1) and the forwarding metric (metric to the forwarding address 172.16.0.2 - 1):

NSSA path cost calculation is described in RFC3101, Section2 https://tools.ietf.org/html/rfc3101#section-2.5:

vSRX1 calculates this in the following manner:
- Redistributed metric of the 8.0.0.0 NSSA LSA - 1
- Metric to the forwarding address 172.16.0.2 from it’s own type 1 - Router LSA - 1 - this being the metric of it’s own st0.0 link in OSPF.

What happens if vSRX1 disables st0.0 ipsec tunnel and vSRX2 increases it’s st0.0 metric to 20 ?

(This is a special case because usually a link fault detection protocol like BFD/LACP/DPD/VPN Monitoring would trigger a tunnel down on both ends that would cause vSRX to change the forwarding address, but this is a special case)
On vSRX2


On vSRX1


In this case, 172.16.0.0 ID will disappear from vSRX1 own Type 1 LSA:

So vSRX1 will “hear” about 172.16.0.0/24 subnet via vSRX2’s Router LSA:

Let’s examine vSRX’2 router LSA:


Based on RFC calculation forumula, in this case, vSRX1 will calculate 8/8 prefix cost as following:
- metric of redistribution: 1
- metric of the forwarding address (forwarding metric) 172.16.0.2 which is calculated as following:
- metric of 172.16.0.0 Link ID in vSRX2 Router LSA (vSRX1 doesn’t have this ID as it disabled st0.0) being 20
- metric of 172.16.1.0 Link ID in vSRX1 Router LSA being 1
Result: 22.

Question: What happens if both nodes add the loopbacks to OSPF domain ?

Without proper configuration update on the provider edge devices (PE2 and PE3), adding the loopbacks in OSPF domain on vSRX1 and vSRX2 will introduce a loop between vSRX1 and PE3 because both PE devices have a static routes for each vSRX loopback IPs and also each vSRX has a static route to each other vSRX into the PE device, so when vSRX1 redistributes vSRX2’s loopback IP in OSPF, st0.1 tunnel will expire, then re-establish and again expire. Also packets for vSRX2’s loopback will loop between these two.

Let’s test:


And adding the loopback in OSPF on vSRX2:

And the result on vSRX1



So how can this be fixed ? Two ways I can think of right now. First is moving st0.1 tunnel binding to physical interfaces ge-0/0/3.23 and ge-0/0/3.22 on the two vSRX removing the need for the static routes towards the loopbacks. But I will not chase this method here.

The second one is a nifty junos workaround, to use a secondary loopback IP on vSRX2 and add that one into OSPF domain.

And the result in the NSSA Type-7 LSA:


This allows us to keep the vSRX2 loopback IP (st0.1 ipsec tunnel endpoint) out of the OSPF domain, but endangers traffic flow as static routes are still in place. It also ensures a balanced forwarding address in NSSA LSA which allows easier metric manipulation of external prefixes only through local ospf interfaces’ metrics.

Question: What happens if we go to the default configuration and re-number tunnel interface names

On the default configuration, Junos will use it’s lowest index interface IP address as forwarding address in NSSA LSAs - st0.0. This is the case when non-zero forwarding address needs to be set in NSSA LSAs. Recursively, this is the case when Type-7 LSAs have the P-bit set, flagging it to the NSSA ABR for translation into a Type-5 LSA. Check RFC 1587 NSSA option for NSSA options: https://tools.ietf.org/html/rfc1587. RFC 3101 describes, but not enforces, Forwarding Address of Type-7 LSAs:


Juniper has it’s own interpretation of this RFC section:
- From my testing I can see that, if no IP interface is set into OSPF, this is the case when st0.0 are un-numbered and loopback is left out, Junos (vSRX2) will forcefully advertise it’s loopback into it’s Router LSA in the NSSA.
- When st0.0 and st0.1 are numbered interfaces and loopback is left out, forwarding address of Type-7 LSAs injected by vSRX2 will be IP of st0.0 (lowest index).
- When st0.0 is renamed to st0.2, forwarding address of Type-7 LSA will be IP of st0.1 (lowest index).
- When loopback is added to OSPF on vSRX2, it it’s primary IP address or “interface <IP ADDRESS>” will be set as Type-7 LSA’s forwarding address.


Coments and criticism will be greately appreciated.