Hands-On Lab: Configuring an OSPF NSSA Area

This hands-on lab configures Area 1 as an NSSA, redistributing a local external route directly from within that area and verifying it propagates as a Type 7 LSA before being translated to Type 5 at the ABR, while inter-area routes from elsewhere remain blocked exactly as in a standard stub area.

OSPF NSSA ConfigurationType 7 to Type 5 TranslationASBR Within a Stub-Like Area

~4 دقیقه مطالعه · آخرین به‌روزرسانی ۱ مهر ۱۴۰۵

Lab Objective

Configure Area 1 as an NSSA, redistribute a static route directly on the router within that area (making it an ASBR), verify the resulting Type 7 LSA stays confined within the NSSA, and confirm the ABR translates it to Type 5 before advertising it into the backbone.

Lab Purpose

The previous lab demonstrated that a standard stub area cannot contain an ASBR at all. This lab demonstrates NSSA solving exactly that limitation, allowing R1 itself to redistribute a local route while Area 1 still enjoys the reduced routing table benefits of a stub-like area.

Lab Topology

R1 (Area 1, leaf, will become an ASBR)
  ---- R2 (ABR) ---- R3 (Area 0, backbone)

R1 has a locally significant network to
redistribute: 198.51.100.0/24 (simulating
a local internet connection or other
external route source)

Task 1: Configure Area 1 as an NSSA

Configure area 1 as an NSSA on both R1 and R2, replacing any previous stub configuration.

Task 2: Redistribute a Local Route on R1

Configure a static route to a dummy network on R1, then redistribute it into OSPF, making R1 an ASBR.

Task 3: Verify the Route Appears as a Type 7 LSA Within Area 1

Check R1's or R2's OSPF database for the NSSA-external LSA type.

Task 4: Verify R3 Receives the Route as a Translated Type 5 LSA

Confirm R3, in the backbone area, sees this same route but as a standard external Type 5 LSA.

Task 5: Verify Inter-Area Routes Are Still Blocked

Confirm the earlier external route redistributed at R3 (from the previous lab) still does not reach R1, since NSSA still blocks externally-originated Type 5 LSAs from entering the area.

Solution and Verification

R1(config)# router ospf 1
R1(config-router)# no area 1 stub
R1(config-router)# area 1 nssa

R2(config)# router ospf 1
R2(config-router)# no area 1 stub no-summary
R2(config-router)# area 1 nssa

R1(config)# ip route 198.51.100.0 255.255.255.0 null0
R1(config)# router ospf 1
R1(config-router)# redistribute static subnets

-- R1 is now an ASBR, something that was
-- explicitly forbidden under plain stub or
-- totally stubby configuration in the
-- previous lab

R2# show ip ospf database nssa-external

            Type-7 AS External Link States (Area 1)

Link ID         ADV Router      Age   Seq#       Checksum
198.51.100.0    1.1.1.1         12    0x80000001 0x00a1c1
-- Confirms the route was carried as Type 7
-- within Area 1, exactly as discussed
-- earlier in this series regarding NSSA

R3# show ip ospf database external

            Type-5 AS External Link States

Link ID         ADV Router      Age   Seq#       Checksum
198.51.100.0    2.2.2.2         10    0x80000001 0x00b2d2
-- Notice the Advertising Router changed
-- from R1's ID (1.1.1.1) to R2's ID
-- (2.2.2.2) -- R2, the ABR, performed the
-- Type 7 to Type 5 translation itself,
-- becoming the advertising source for
-- this route from the backbone's perspective

R3# show ip route ospf | include 198.51.100.0

O E2  198.51.100.0/24 [110/20] via 10.2.2.1
-- R3 sees this as a normal external route,
-- unaware it originated within an NSSA

R1# show ip route ospf | include 203.0.113.0

-- (no output -- still blocked, exactly as
--  in the plain stub area from the previous
--  lab, since NSSA does not permit externally
--  originated Type 5 LSAs from elsewhere in
--  the domain to enter the area, even though
--  it permits locally-originated ones)

Key Takeaway

NSSA's behavior is asymmetric by design: it permits a route originating from an ASBR inside the NSSA itself to leave the area (via Type 7 to Type 5 translation at the ABR), while still blocking Type 5 LSAs originating anywhere else in the OSPF domain from entering — this is precisely the combination that makes NSSA the correct choice over a plain stub area whenever a leaf area needs local internet breakout or other local redistribution.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

ادامه

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

ادامه

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

ادامه

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

ادامه

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

ادامه

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

ادامه