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 vSRXCode:
[edit]
admin@hub-vSRX1# show routing-options
static {
route 10.0.22.0/24 next-hop 10.0.23.1;
route 172.16.255.2/32 next-hop 10.0.23.1;
}
[edit]
admin@hub-vSRX1# show security ike
policy ikepol {
mode main;
proposal-set standard;
pre-shared-key ascii-text "$9$Yb4JD.PQ9A0ikA0BIrl24aZikmfT3/C"; ## SECRET-DATA
}
gateway vsrx2-internet {
ike-policy ikepol;
address 10.0.24.2;
local-identity hostname vsrx1-internet;
remote-identity hostname vsrx2-internet;
external-interface ge-0/0/3.24;
}
gateway vsrx2-mpls {
ike-policy ikepol;
address 172.16.255.2;
local-identity hostname vsrx1-mpls;
remote-identity hostname vsrx2-mpls;
external-interface ge-0/0/3.23;
local-address 172.16.255.1;
}
[edit]
admin@hub-vSRX1# show security ipsec
policy ipsecpol {
perfect-forward-secrecy {
keys group2;
}
proposal-set standard;
}
vpn vsrx2-internet {
bind-interface st0.0;
ike {
gateway vsrx2-internet;
ipsec-policy ipsecpol;
}
establish-tunnels immediately;
}
vpn vsrx2-mpls {
bind-interface st0.1;
inactive: vpn-monitor {
source-interface st0.1;
destination-ip 172.16.1.2;
}
ike {
gateway vsrx2-mpls;
ipsec-policy ipsecpol;
}
establish-tunnels immediately;
}
[edit]
admin@hub-vSRX1# show interfaces ge-0/0/3.23
vlan-id 23;
family inet {
address 10.0.23.2/24;
}
[edit]
admin@hub-vSRX1# show interfaces ge-0/0/3.23
vlan-id 23;
family inet {
address 10.0.23.2/24;
}
[edit]
admin@hub-vSRX1# show interfaces lo0
unit 0 {
family inet {
address 172.16.255.1/32;
}
}
[edit]
admin@hub-vSRX1# show interfaces st0
unit 0 {
family inet {
address 172.16.0.1/24;
}
}
unit 1 {
family inet {
address 172.16.1.1/24;
}
}
[edit]
admin@hub-vSRX1# show protocols ospf
area 0.0.0.1 {
nssa {
default-lsa {
default-metric 1;
metric-type 1;
type-7;
}
no-summaries;
}
interface st0.0 {
interface-type p2p;
}
interface st0.1 {
interface-type p2p;
}
}
area 0.0.0.0 {
interface ge-0/0/3.23;
}
[edit]
admin@hub-vSRX1# run show route 8/8 exact
inet.0: 16 destinations, 18 routes (16 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
8.0.0.0/8 *[OSPF/150] 00:02:43, metric 2, tag 0
> via st0.0
Spoke vSRX:
Code:
[edit]
admin@spoke-vSRX2# show routing-options
static {
route 10.0.23.0/24 next-hop 10.0.22.1;
route 172.16.255.1/32 next-hop 10.0.22.1;
route 8.0.0.0/8 next-hop 1.1.1.2;
}
[edit]
admin@spoke-vSRX2# show security ike
policy ikepol {
mode main;
proposal-set standard;
pre-shared-key ascii-text "$9$Yb4JD.PQ9A0ikA0BIrl24aZikmfT3/C"; ## SECRET-DATA
}
gateway vsrx1-internet {
ike-policy ikepol;
address 10.0.24.1;
local-identity hostname vsrx2-internet;
remote-identity hostname vsrx1-internet;
external-interface ge-0/0/3.24;
}
gateway vsrx1-mpls {
ike-policy ikepol;
address 172.16.255.1;
local-identity hostname vsrx2-mpls;
remote-identity hostname vsrx1-mpls;
external-interface ge-0/0/3.22;
local-address 172.16.255.2;
}
[edit]
admin@spoke-vSRX2# show security ipsec
policy ipsecpol {
perfect-forward-secrecy {
keys group2;
}
proposal-set standard;
}
vpn vsrx1-internet {
bind-interface st0.0;
ike {
gateway vsrx1-internet;
ipsec-policy ipsecpol;
}
establish-tunnels immediately;
}
vpn vsrx1-mpls {
bind-interface st0.1;
ike {
gateway vsrx1-mpls;
ipsec-policy ipsecpol;
}
establish-tunnels immediately;
}
admin@spoke-vSRX2# show interfaces lo0
unit 0 {
family inet {
address 172.16.255.2/32;
}
}
[edit]
admin@spoke-vSRX2# show interfaces st0
unit 0 {
family inet {
address 172.16.0.2/24;
}
}
unit 1 {
family inet {
address 172.16.1.2/24;
}
}
[edit]
admin@spoke-vSRX2# show interfaces ge-0/0/3.22
vlan-id 22;
family inet {
address 10.0.22.2/24;
}
[edit]
admin@spoke-vSRX2# show interfaces ge-0/0/3.24
vlan-id 24;
family inet {
address 10.0.24.2/24;
}
[edit]
admin@spoke-vSRX2# show protocols ospf
export into-ospf;
area 0.0.0.1 {
nssa;
interface st0.0 {
interface-type p2p;
}
interface st0.1 {
interface-type p2p;
}
}
[edit]
admin@spoke-vSRX2# show policy-options policy-statement into-ospf
term 1 {
from {
protocol static;
route-filter 8.0.0.0/8 orlonger;
}
then {
metric 1;
external {
type 1;
}
accept;
}
}
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):
Code:
[edit]
admin@hub-vSRX1# run show route 8/8 exact
inet.0: 16 destinations, 18 routes (16 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
8.0.0.0/8 *[OSPF/150] 00:10:57, metric 2, tag 0
> via st0.0
To answer this question, we look at the NSSA Type 7 LSA:
Code:
[edit]
admin@hub-vSRX1# run show ospf database nssa lsa-id 8.0.0.0 extensive
OSPF database, Area 0.0.0.1
Type ID Adv Rtr Seq Age Opt Cksum Len
NSSA 8.0.0.0 172.16.255.2 0x80000029 2946 0x28 0x27a 36
mask 255.0.0.0
Topology default (ID 0)
Type: 1, Metric: 1, Fwd addr: 172.16.0.2, Tag: 0.0.0.0
Aging timer 00:10:53
Installed 00:49:03 ago, expires in 00:10:54, sent 20:49:57 ago
Last changed 20:49:05 ago, Change count: 4
[edit]
admin@hub-vSRX1# run show ospf database router area 1 lsa-id 172.16.255.1 extensive
OSPF database, Area 0.0.0.1
Type ID Adv Rtr Seq Age Opt Cksum Len
Router *172.16.255.1 172.16.255.1 0x80000063 1 0x20 0xe4ca 72
bits 0x3, link count 4
id 172.16.255.2, data 172.16.0.1, Type PointToPoint (1)
Topology count: 0, Default metric: 1
id 172.16.0.0, data 255.255.255.0, Type Stub (3)
Topology count: 0, Default metric: 1
id 172.16.255.2, data 172.16.1.1, Type PointToPoint (1)
Topology count: 0, Default metric: 1
id 172.16.1.0, data 255.255.255.0, Type Stub (3)
Topology count: 0, Default metric: 1
Topology default (ID 0)
Type: PointToPoint, Node ID: 172.16.255.2
Metric: 1, Bidirectional
Gen timer 00:49:59
Aging timer 00:59:59
Installed 00:00:01 ago, expires in 00:59:59, sent 00:00:01 ago
Last changed 00:00:01 ago, Change count: 29, Ours
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):
Code:
NSSA path cost calculation is described in RFC3101, Section2
https://tools.ietf.org/html/rfc3101#section-2.5:
Quote:
…
If the forwarding address is non-zero look up the forwarding
address in the routing table. For a Type-5 LSA the matching
routing table entry must specify an intra-area or inter-area
path through a Type-5 capable area. For a Type-7 LSA the
matching routing table entry must specify an intra-area path
through the LSA's originating NSSA. If no such path exists
…
(4) Let X be the cost specified by the preferred routing table
entry for the ASBR/forwarding address, and Y the cost
specified in the LSA. X is in terms of the link state metric,
and Y is a type 1 or 2 external metric.
[OSPF]
…
If no entry exists for N, install the AS external path to N,
with the next hop equal to the list of next hops to the
ASBR/forwarding address, and advertising router equal to the
ASBR. If the external metric type is 1, then the path-type is
set to Type-1 external and the cost is equal to X + Y. If the
external metric type is 2, the path-type is set to Type-2
external, the link-state component of the route's cost is X,
and the type 2 cost is Y.
[OSPF]
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
Code:
[edit]
admin@spoke-vSRX2# set protocols ospf area 1 interface st0.0 metric 20
[edit]
admin@spoke-vSRX2# commit
commit complete
On vSRX1
Code:
[edit]
admin@hub-vSRX1# run show ospf database nssa lsa-id 8.0.0.0 extensive
OSPF database, Area 0.0.0.1
Type ID Adv Rtr Seq Age Opt Cksum Len
NSSA 8.0.0.0 172.16.255.2 0x8000002e 875 0x28 0xf77f 36
mask 255.0.0.0
Topology default (ID 0)
Type: 1, Metric: 1, Fwd addr: 172.16.0.2, Tag: 0.0.0.0
Aging timer 00:45:24
Installed 00:14:34 ago, expires in 00:45:25, sent 00:25:32 ago
Last changed 00:14:34 ago, Change count: 8
[edit]
admin@hub-vSRX1# set interfaces st0.0 disable
[edit]
admin@hub-vSRX1# commit
commit complete
[edit]
admin@hub-vSRX1# run show route 8/8 exact
inet.0: 16 destinations, 17 routes (16 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
8.0.0.0/8 *[OSPF/150] 00:00:06, metric 22, tag 0
> via st0.1
In this case, 172.16.0.0 ID will disappear from vSRX1 own Type 1 LSA:
Code:
[edit]
admin@hub-vSRX1# run show ospf database router area 1 lsa-id 172.16.255.1 extensive
OSPF database, Area 0.0.0.1
Type ID Adv Rtr Seq Age Opt Cksum Len
Router *172.16.255.1 172.16.255.1 0x80000065 3 0x20 0x5caa 48
bits 0x3, link count 2
id 172.16.255.2, data 172.16.1.1, Type PointToPoint (1)
Topology count: 0, Default metric: 1
id 172.16.1.0, data 255.255.255.0, Type Stub (3)
Topology count: 0, Default metric: 1
Topology default (ID 0)
Type: PointToPoint, Node ID: 172.16.255.2
Metric: 1, Bidirectional
Gen timer 00:49:57
Aging timer 00:59:57
Installed 00:00:03 ago, expires in 00:59:57, sent 00:00:01 ago
Last changed 00:00:03 ago, Change count: 30, Ours
So vSRX1 will “hear” about 172.16.0.0/24 subnet via vSRX2’s Router LSA:
Let’s examine vSRX’2 router LSA:
Code:
[edit]
admin@hub-vSRX1# run show ospf database router area 1 lsa-id 172.16.255.2 extensive
OSPF database, Area 0.0.0.1
Type ID Adv Rtr Seq Age Opt Cksum Len
Router 172.16.255.2 172.16.255.2 0x8000006a 195 0x20 0x40df 60
bits 0x2, link count 3
id 172.16.0.0, data 255.255.255.0, Type Stub (3)
Topology count: 0, Default metric: 20
id 172.16.255.1, data 172.16.1.2, Type PointToPoint (1)
Topology count: 0, Default metric: 1
id 172.16.1.0, data 255.255.255.0, Type Stub (3)
Topology count: 0, Default metric: 1
Topology default (ID 0)
Type: PointToPoint, Node ID: 172.16.255.1
Metric: 1, Bidirectional
Aging timer 00:56:44
Installed 00:03:14 ago, expires in 00:56:45, sent 00:05:09 ago
Last changed 00:03:14 ago, Change count: 28
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:
Code:
[edit]
admin@hub-vSRX1# run show route 172.16.255.2
inet.0: 16 destinations, 17 routes (16 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.255.2/32 *[Static/5] 1d 19:58:21
> to 10.0.23.1 via ge-0/0/3.23
[edit]
admin@hub-vSRX1# run ping 172.16.255.2 source 172.16.255.1
PING 172.16.255.2 (172.16.255.2): 56 data bytes
64 bytes from 172.16.255.2: icmp_seq=0 ttl=61 time=15.019 ms
64 bytes from 172.16.255.2: icmp_seq=1 ttl=61 time=10.069 ms
And adding the loopback in OSPF on vSRX2:
Code:
[edit]
admin@spoke-vSRX2# set protocols ospf area 1 interface lo0.0
[edit]
admin@spoke-vSRX2# commit
commit complete
And the result on vSRX1
Code:
[edit]
admin@hub-vSRX1# run traceroute 172.16.255.2 source 172.16.255.1 ttl 2
traceroute to 172.16.255.2 (172.16.255.2) from 172.16.255.1, 2 hops max, 40 byte packets
1 10.0.23.1 (10.0.23.1) 9.760 ms 9.733 ms 10.115 ms
2 10.0.23.2 (10.0.23.2) 5.118 ms 3.778 ms 9.930 ms
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.
Code:
[edit]
admin@spoke-vSRX2# delete protocols ospf area 1 interface lo0.0
[edit]
admin@spoke-vSRX2# set interfaces lo0.0 family inet address 172.16.255.2/32 primary
[edit]
admin@spoke-vSRX2# set interfaces lo0.0 family inet address 172.16.255.3/32
[edit]
admin@spoke-vSRX2# set protocols ospf area 1 interface 172.16.255.3
[edit]
admin@spoke-vSRX2# commit
commit complete
And the result in the NSSA Type-7 LSA:
Code:
[edit]
admin@hub-vSRX1# run show ospf database nssa lsa-id 8.0.0.0 extensive
OSPF database, Area 0.0.0.1
Type ID Adv Rtr Seq Age Opt Cksum Len
NSSA 8.0.0.0 172.16.255.2 0x80000031 11 0x28 0xff73 36
mask 255.0.0.0
Topology default (ID 0)
Type: 1, Metric: 1, Fwd addr: 172.16.255.3, Tag: 0.0.0.0
Aging timer 00:59:48
Installed 00:00:10 ago, expires in 00:59:49, sent 00:50:30 ago
Last changed 00:00:10 ago, Change count: 11
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:
Quote:
Normally the next hop address of an installed AS external route
learned by an NSSA ASBR from an adjacent AS points at one of the
adjacent AS's gateway routers. If this address belongs to a network
connected to the NSSA ASBR via one of its NSSAs' active interfaces,
then the NSSA ASBR copies this next hop address into the forwarding
address field of the route's Type-7 LSA that is originated into this
NSSA, as is currently done with Type-5 LSAs. (See [OSPF] Section
12.4.4.1.) For an NSSA with no such network the forwarding address
field may only be filled with an address from one of the its active
interfaces or 0.0.0.0. If the P-bit is set, the forwarding address
must be non-zero; otherwise it may be 0.0.0.0. If an NSSA requires
the P-bit be set and a non-zero forwarding address is unavailable,
then the route's Type-7 LSA is not originated into this NSSA.
When a router is forced to pick a forwarding address for a Type-7
LSA, preference should be given first to the router's internal
addresses (provided internal addressing is supported). If internal
addresses are not available, preference should be given to the
router's active OSPF stub network addresses. These choices avoid the
possible extra hop that may happen when a transit network's address
is used. When the interface whose IP address is the LSA's forwarding
address transitions to a Down state (see [OSPF] Section 9.3), the
router must select a new forwarding address for the LSA and then re-
originate it. If one is not available the LSA should be flushed.
The metrics and path types of Type-5 LSAs are directly comparable
with the metrics and path types 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.