Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

TechLibrary
Navigation

Example: Configuring OSPFv3 Not-So-Stubby Areas

Understanding OSPFv3 Not-So-Stubby Areas

Like an OSPF stub area, an OSPFv3 stub area has no external routes, so you cannot redistribute routes from another protocol into a stub area. Not-so-stubby-areas (NSSAs) allow external routes to be flooded within the area. Routers in an NSSA do not receive external link-state advertisements (LSAs) from area border routers (ABRs), but are allowed to send external routing information for redistribution. They use type 7 LSAs to tell the ABRs about these external routes, which the ABR then translates to type 5 external LSAs and floods as normal to the rest of the OSPF network.

Example: Configuring OSPFv3 Not-So-Stubby Areas

This example shows how to configure an OSPFv3 not-so-stubby area (NSSA) to control the advertisement of external routes into the area.

Requirements

No special configuration beyond device initialization is required before configuring this example.

Overview

In this example, Device 7 redistributes static Customer 1 routes into OSPFv3. Device 7 is in area 9, which is configured as an NSSA. Device 3 is the ABR attached to the NSSA. An NSSA is a type of stub area that can import autonomous system external routes and send them to other areas, but still cannot receive AS-external routes from other areas. Because area 9 is defined as an NSSA, Device 7 uses type 7 LSAs to tell the ABR (Device 3) about these external routes. Device 3 then translates the type 7 routes to type 5 external LSAs and floods them as normal to the rest of the OSPF network.

In area 3, Device 5 redistributes static Customer 2 routes into OSPFv3. These routes are learned on Device 3, but not on Device 7 or 10. Device 3 injects a default static route into area 9 so that Device 7 and 10 can still reach the Customer 2 routes.

You configure each routing device in area 9 (area ID 0.0.0.9) with the following setting:

  • nssa—Specifies an OSPFv3 NSSA. You must include the nssa statement on all routing devices in area 9.

You also configure the ABR in area 9 with the following additional settings:

  • no-summaries—Prevents the ABR from advertising summary routes into the NSSA. If configured in combination with the default-metric statement, the NSSA only allows routes internal to the area and advertises the default route into the area. External routes and destinations to other areas are no longer summarized or allowed into the NSSA. Only the ABR requires this additional configuration because it is the only routing device within the NSSA that creates Type 3 summary LSAs used to receive and send traffic from outside the area.
  • default-lsa—Configures the ABR to generate a default route into the NSSA. In this example, you configure the following:
    • default-metric—Specifies that the ABR generate a default route with a specified metric into the NSSA. This default route enables packet forwarding from the NSSA to external destinations. You configure this option only on the ABR. The ABR does not automatically generate a default route when attached to an NSSA. You must explicitly configure this option for the ABR to generate a default route.
    • metric-type—(Optional) Specifies the external metric type for the default LSA, which can be either Type 1 or Type 2. When OSPFv3 exports route information from external ASs, it includes a cost, or external metric, in the route. The difference between the two metrics is how OSPFv3 calculates the cost of the route. Type 1 external metrics are equivalent to the link-state metric, where the cost is equal to the sum of the internal costs plus the external cost. Type 2 external metrics use only the external cost assigned by the AS boundary router. By default, OSPFv3 uses the Type 2 external metric.
    • type-7—(Optional) Floods Type 7 default LSAs into the NSSA if the no-summaries statement is configured. By default, when the no-summaries statement is configured, a Type 3 LSA is injected into NSSAs for Junos OS release 5.0 and later. To support backward compatibility with earlier Junos OS releases, include the type-7 statement.

Figure 1: OSPFv3 Network Topology with an NSSA

OSPFv3 Network Topology with an NSSA

CLI Quick Configuration shows the configuration for all of the devices in Figure 1. The section Step-by-Step Procedure describes the steps on Device 3, Device 7, and Device 9.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Device 1

set interfaces fe-1/2/0 unit 0 family inet6 address 9009:1::1/64set interfaces fe-1/2/1 unit 0 family inet6 address 9009:3::1/64set interfaces lo0 unit 0 family inet address 1.1.1.1/32set protocols ospf3 area 0.0.0.0 interface fe-1/2/0.0set protocols ospf3 area 0.0.0.0 interface fe-1/2/0.5set protocols ospf3 area 0.0.0.0 interface fe-1/2/1.0set protocols ospf3 area 0.0.0.0 interface lo0.0 passive

Device 3

set interfaces fe-1/2/0 unit 0 family inet6 address 9009:3::2/64set interfaces fe-1/2/1 unit 0 family inet6 address 9009:5::1/64set interfaces lo0 unit 0 family inet address 3.3.3.3/32set protocols ospf3 area 0.0.0.0 interface fe-1/2/0.0set protocols ospf3 area 0.0.0.0 interface lo0.0 passiveset protocols ospf3 area 0.0.0.9 nssa default-lsa default-metric 10set protocols ospf3 area 0.0.0.9 nssa default-lsa metric-type 1set protocols ospf3 area 0.0.0.9 nssa default-lsa type-7set protocols ospf3 area 0.0.0.9 nssa no-summariesset protocols ospf3 area 0.0.0.9 interface fe-1/2/1.0

Device 4

set interfaces fe-1/2/0 unit 0 family inet6 address 9009:1::2/64set interfaces fe-1/2/1 unit 0 family inet6 address 9009:6::1/64set interfaces lo0 unit 0 family inet address 4.4.4.4/32set protocols ospf3 area 0.0.0.0 interface fe-1/2/0.0set protocols ospf3 area 0.0.0.0 interface lo0.0 passiveset protocols ospf3 area 0.0.0.3 interface fe-1/2/1.0

Device 5

set interfaces fe-1/2/0 unit 0 family inet6 address 9009:6::2/64set interfaces fe-1/2/1 unit 0 family inet6 address 9009:7::1/64set interfaces lo0 unit 0 family inet address 5.5.5.5/32set protocols ospf3 export static-to-ospfset protocols ospf3 area 0.0.0.3 interface fe-1/2/0.0set protocols ospf3 area 0.0.0.3 interface lo0.0 passiveset policy-options policy-statement static-to-ospf term 1 from protocol staticset policy-options policy-statement static-to-ospf term 1 then acceptset routing-options rib inet6.0 static route 1010::1/128 next-hop 9009:7::2set routing-options rib inet6.0 static route 2020::1/128 next-hop 9009:7::2

Device 7

set interfaces fe-1/2/0 unit 0 family inet6 address 9009:8::1/64set interfaces fe-1/2/1 unit 0 family inet6 address 9009:9::1/64set interfaces lo0 unit 0 family inet address 7.7.7.7/32set protocols ospf3 export static2-to-ospfset protocols ospf3 area 0.0.0.9 nssaset protocols ospf3 area 0.0.0.9 interface fe-1/2/1.0set protocols ospf3 area 0.0.0.9 interface lo0.0 passiveset policy-options policy-statement static2-to-ospf term 1 from protocol staticset policy-options policy-statement static2-to-ospf term 1 then acceptset routing-options rib inet6.0 static route 3030::1/128 next-hop 9009:8::2set routing-options rib inet6.0 static route 4040::1/128 next-hop 9009:8::2

Device 8

set interfaces fe-1/2/0 unit 0 family inet6 address 9009:7::2/64set interfaces lo0 unit 0 family inet address 8.8.8.8/32set interfaces lo0 unit 0 family inet6 address 1010::1/128set interfaces lo0 unit 0 family inet6 address 2020::1/128

Device 9

set interfaces fe-1/2/0 unit 0 family inet6 address 9009:8::2/64set interfaces lo0 unit 0 family inet address 9.9.9.9/32set interfaces lo0 unit 0 family inet6 address 3030::1/128set interfaces lo0 unit 0 family inet6 address 4040::1/128

Device 10

set interfaces fe-1/2/0 unit 0 family inet6 address 9009:5::2/64set interfaces fe-1/2/1 unit 0 family inet6 address 9009:9::2/64set interfaces lo0 unit 0 family inet address 10.10.10.10/32set protocols ospf3 area 0.0.0.9 nssaset protocols ospf3 area 0.0.0.9 interface fe-1/2/0.0set protocols ospf3 area 0.0.0.9 interface fe-1/2/1.0set protocols ospf3 area 0.0.0.9 interface lo0.0 passive

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Device 3:

  1. Configure the interfaces.
    [edit interfaces]user@3# set fe-1/2/0 unit 0 family inet6 address 9009:3::2/64user@3# set fe-1/2/1 unit 0 family inet6 address 9009:5::1/64user@3# set lo0 unit 0 family inet address 3.3.3.3/32
  2. Enable OSPFv3 on the interfaces that are in area 0.
    [edit protocols ospf3 area 0.0.0.0]user@3# set interface fe-1/2/0.0user@3# set interface lo0.0 passive
  3. Enable OSPFv3 on the interface that is in area 9.
    [edit protocols ospf3 area 0.0.0.9]user@3# set interface fe-1/2/1.0
  4. Configure an OSPFv3 NSSA.

    The nssa statement is required on all routing devices in the area.

    [edit protocols ospf3 area 0.0.0.9]user@3# set nssa
  5. On the ABR, inject a default route into the area.
    [edit protocols ospf3 area 0.0.0.9]user@3# set default-lsa default-metric 10
  6. (Optional) On the ABR, specify the external metric type for the default route.
    [edit protocols ospf3 area 0.0.0.9]user@3# set nssa default-lsa metric-type 1
  7. (Optional) On the ABR, specify the flooding of Type 7 LSAs.
    [edit protocols ospf3 area 0.0.0.9]user@3# set nssa default-lsa type-7
  8. On the ABR, restrict summary LSAs from entering the area.
    [edit protocols ospf3 area 0.0.0.9]user@3# set nssa no-summaries

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Device 5:

  1. Configure the interfaces.
    [edit interfaces]user@5# set fe-1/2/0 unit 0 family inet6 address 9009:6::2/64user@5# set fe-1/2/1 unit 0 family inet6 address 9009:7::1/64user@5# set lo0 unit 0 family inet address 5.5.5.5/32
  2. Enable OSPFv3 on the interface that is in area 3.
    [edit protocols ospf3 area 0.0.0.3]user@5# set interface fe-1/2/0.0user@5# set interface lo0.0 passive
  3. Configure static routes that enable connectivity to the customer routes.
    [edit routing-options rib inet6.0 static]user@5# set route 1010::1/128 next-hop 9009:7::2user@5# set route 2020::1/128 next-hop 9009:7::2
  4. Configure a routing policy to redistribute the static routes.
    [edit policy-options policy-statement static-to-ospf term 1]user@5# set from protocol staticuser@5# set then accept
  5. Apply the routing policy to the OSPFv3 instance.
    [edit protocols ospf3]user@5# set export static-to-ospf

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Device 7:

  1. Configure the interfaces.
    [edit interfaces]user@7# set fe-1/2/0 unit 0 family inet6 address 9009:5::2/64user@7# set fe-1/2/1 unit 0 family inet6 address 9009:7::1/64user@7# set lo0 unit 0 family inet address 7.7.7.7/32
  2. Enable OSPFv3 on the interface that is in area 9.
    [edit protocols ospf3 area 0.0.0.9]user@7# set interface fe-1/2/0.0user@7# set interface lo0.0 passive
  3. Configure an OSPFv3 NSSA.

    The nssa statement is required on all routing devices in the area.

    [edit protocols ospf3 area 0.0.0.9]user@7# set nssa

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

To configure Device 8:

  1. Configure the interfaces.
    [edit interfaces]user@8# set fe-1/2/0 unit 0 family inet6 address 9009:7::2/64user@8# set lo0 unit 0 family inet address 8.8.8.8/32
  2. Configure two loopback interface addresses to simulate customer routes.
    [edit interfaces lo0 unit 0 family inet6]user@8# set address 1010::1/128user@8# set address 2020::1/128

Results

From configuration mode, confirm your configuration by entering the show interfaces, show protocols, show policy-options, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Device 3

user@3# show interfaces
fe-1/2/0 {unit 0 {family inet6 {address 9009:3::2/64;}}}
fe-1/2/1 {unit 0 {family inet6 {address 9009:5::1/64;}}}
lo0 {unit 0 {family inet {address 3.3.3.3/32;}}}
}
user@3# show protocols
ospf3 {area 0.0.0.0 {interface fe-1/2/0.0;interface lo0.0 {passive;}}area 0.0.0.9 {nssa {default-lsa {default-metric 10;metric-type 1;type-7;}no-summaries;}interface fe-1/2/1.0;}}

Device 5

user@5# show interfaces
fe-1/2/0 {unit 0 {family inet6 {address 9009:6::2/64;}}}
fe-1/2/1 {unit 0 {family inet6 {address 9009:7::1/64;}}}
lo0 {unit 0 {family inet {address 5.5.5.5/32;}}}
user@5# show protocols
ospf3 {export static-to-ospf;area 0.0.0.3 {interface fe-1/2/0.0;interface lo0.0 {passive;}}}
user@5# show policy-options
policy-statement static-to-ospf {term 1 {from protocol static;then accept;}}
user@5# show routing-options
rib inet6.0 {static {route 1010::1/128 next-hop 9009:7::2;route 2020::1/128 next-hop 9009:7::2;}}

Device 7

user@7# show interfaces
fe-1/2/0 {unit 0{family inet6 {address 9009:5::2/64;}}}
lo0 {unit 0 {family inet {address 7.7.7.7/32;}}}
user@7# show protocols
ospf3 {area 0.0.0.9 {nssa;interface fe-1/2/0.0;interface lo0.0 {passive;}}}

Device 8

user@8# show interfaces
fe-1/2/0 {unit 0 {family inet6 {address 9009:7::2/64;}}}
lo0 {unit 0 {family inet {address 8.8.8.8/32;}family inet6 {address 1010::1/128;address 2020::1/128;}}}

If you are done configuring the device, enter commit from configuration mode.

Verification

Confirm that the configuration is working properly.

Verifying the Type of OSPFv3 Area

Purpose

Verify that the OSPFv3 area is an NSSA area. Confirm that the output displays Stub NSSA as the Stub type.

Action

From operational mode on Device 3, Device 7, and Device 10 enter the show ospf3 overview command.

user@3> show ospf3 overview
Instance: master
  Router ID: 3.3.3.3
  Route table index: 36
  Area border router, AS boundary router, NSSA router
  LSA refresh time: 50 minutes
  Area: 0.0.0.0
    Stub type: Not Stub
    Area border routers: 2, AS boundary routers: 0
    Neighbors
      Up (in full state): 1
  Area: 0.0.0.9
    Stub type: Stub NSSA, Stub cost: 10
    Area border routers: 0, AS boundary routers: 1
    Neighbors
      Up (in full state): 1
  Topology: default (ID 0)
    Prefix export count: 0
    Full SPF runs: 22
    SPF delay: 0.200000 sec, SPF holddown: 5 sec, SPF rapid runs: 3
    Backup SPF: Not Needed
user@7> show ospf3 overview
Instance: master
  Router ID: 7.7.7.7
  Route table index: 44
  AS boundary router, NSSA router
  LSA refresh time: 50 minutes
  Area: 0.0.0.9
    Stub type: Stub NSSA
    Area border routers: 1, AS boundary routers: 1
    Neighbors
      Up (in full state): 1
  Topology: default (ID 0)
    Prefix export count: 2
    Full SPF runs: 11
    SPF delay: 0.200000 sec, SPF holddown: 5 sec, SPF rapid runs: 3
    Backup SPF: Not Needed
user@10> show ospf3 overview
Instance: master
  Router ID: 10.10.10.10
  Route table index: 55
  NSSA router
  LSA refresh time: 50 minutes
  Area: 0.0.0.9
    Stub type: Stub NSSA
    Area border routers: 1, AS boundary routers: 2
    Neighbors
      Up (in full state): 2
  Topology: default (ID 0)
    Prefix export count: 0
    Full SPF runs: 6
    SPF delay: 0.200000 sec, SPF holddown: 5 sec, SPF rapid runs: 3
    Backup SPF: Not Needed

Meaning

On Device 3, the stub type of area 0 is Not Stub. The stub type of area 9 is Stub NSSA. The stub default metric is 10.

On Device 7 and Device 10, the stub type of area 9 is Stub NSSA.

Verifying the Routes in the OSPFv3 Stub Area

Purpose

Make sure that the expected routes are present in the routing tables.

Action

From operational mode on Device 7 and Device 3, enter the show route command.

user@7> show route
inet.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

7.7.7.7/32         *[Direct/0] 3d 03:00:23
                    > via lo0.0

inet6.0: 12 destinations, 14 routes (12 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

::/0               *[OSPF3/150] 01:01:31, metric 12, tag 0
                    > via fe-1/2/1.0
3030::1/128        *[Static/5] 01:01:43
                    > to 9009:8::2 via fe-1/2/0.0
4040::1/128        *[Static/5] 01:01:43
                    > to 9009:8::2 via fe-1/2/0.0
9009:5::/64        *[OSPF3/10] 01:01:33, metric 2
                    > via fe-1/2/1.0
9009:8::/64        *[Direct/0] 01:01:43
                    > via fe-1/2/0.0
9009:8::1/128      *[Local/0] 01:02:01
                      Local via fe-1/2/0.0
9009:9::/64        *[Direct/0] 01:01:45
                    > via fe-1/2/1.0
                    [OSPF3/10] 01:01:44, metric 1
                    > via fe-1/2/1.0
9009:9::1/128      *[Local/0] 01:02:01
                      Local via fe-1/2/1.0
fe80::/64          *[Direct/0] 01:01:45
                    > via fe-1/2/1.0
                    [Direct/0] 01:01:43
                    > via fe-1/2/0.0
fe80::2a0:a514:0:f4c/128
                   *[Local/0] 01:02:01
                      Local via fe-1/2/0.0
fe80::2a0:a514:0:114c/128
                   *[Local/0] 01:02:01
                      Local via fe-1/2/1.0
ff02::5/128        *[OSPF3/10] 3d 03:01:25, metric 1
                      MultiRecv
user@10> show route
inet.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.10.10.10/32     *[Direct/0] 01:01:59
                    > via lo0.0

inet6.0: 11 destinations, 14 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

::/0               *[OSPF3/150] 01:01:35, metric 11, tag 0
                    > via fe-1/2/0.0
3030::1/128        *[OSPF3/150] 01:01:35, metric 0, tag 0
                    > via fe-1/2/1.0
4040::1/128        *[OSPF3/150] 01:01:35, metric 0, tag 0
                    > via fe-1/2/1.0
9009:5::/64        *[Direct/0] 01:01:50
                    > via fe-1/2/0.0
                    [OSPF3/10] 01:01:50, metric 1
                    > via fe-1/2/0.0
9009:5::2/128      *[Local/0] 01:01:50
                      Local via fe-1/2/0.0
9009:9::/64        *[Direct/0] 01:01:50
                    > via fe-1/2/1.0
                    [OSPF3/10] 01:01:40, metric 1
                    > via fe-1/2/1.0
9009:9::2/128      *[Local/0] 01:01:50
                      Local via fe-1/2/1.0
fe80::/64          *[Direct/0] 01:01:50
                    > via fe-1/2/0.0
                    [Direct/0] 01:01:50
                    > via fe-1/2/1.0
fe80::2a0:a514:0:c4c/128
                   *[Local/0] 01:01:50
                      Local via fe-1/2/0.0
fe80::2a0:a514:0:124c/128
                   *[Local/0] 01:01:50
                      Local via fe-1/2/1.0
ff02::5/128        *[OSPF3/10] 01:02:16, metric 1
                      MultiRecv
user@3> show route
inet.0: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

3.3.3.3/32         *[Direct/0] 3d 03:03:10
                    > via lo0.0

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

1010::1/128        *[OSPF3/150] 01:04:21, metric 0, tag 0
                    > via fe-1/2/0.0
2020::1/128        *[OSPF3/150] 01:04:21, metric 0, tag 0
                    > via fe-1/2/0.0
3030::1/128        *[OSPF3/150] 01:03:57, metric 0, tag 0
                    > via fe-1/2/1.0
4040::1/128        *[OSPF3/150] 01:03:57, metric 0, tag 0
                    > via fe-1/2/1.0
9009:1::/64        *[OSPF3/10] 3d 03:02:06, metric 2
                    > via fe-1/2/0.0
9009:3::/64        *[Direct/0] 3d 03:02:55
                    > via fe-1/2/0.0
                    [OSPF3/10] 3d 03:02:54, metric 1
                    > via fe-1/2/0.0
9009:3::2/128      *[Local/0] 3d 03:02:55
                      Local via fe-1/2/0.0
9009:5::/64        *[Direct/0] 01:04:09
                    > via fe-1/2/1.0
                    [OSPF3/10] 01:04:09, metric 1
                    > via fe-1/2/1.0
9009:5::1/128      *[Local/0] 3d 03:02:54
                      Local via fe-1/2/1.0
9009:6::/64        *[OSPF3/10] 3d 02:19:14, metric 3
                    > via fe-1/2/0.0
9009:9::/64        *[OSPF3/10] 01:04:02, metric 2
                    > via fe-1/2/1.0
fe80::/64          *[Direct/0] 3d 03:02:55
                    > via fe-1/2/0.0
                    [Direct/0] 01:04:09
                    > via fe-1/2/1.0
fe80::2a0:a514:0:84c/128
                   *[Local/0] 3d 03:02:55
                      Local via fe-1/2/0.0
fe80::2a0:a514:0:b4c/128
                   *[Local/0] 3d 03:02:54
                      Local via fe-1/2/1.0
ff02::5/128        *[OSPF3/10] 3d 03:03:50, metric 1
                      MultiRecv

Meaning

On Device 7, the default route has been learned because of the default-metric statement on the ABR, Device 3. Otherwise, the only OSPFv3 routes in Device 7’s routing table are those local to area 9 and the OSPFv3 multicast address ff02::5/128 for all SPF link-state routers, also known as AllSPFRouters.

Device 10 has the default route injected by Device 3 and also the OSPF external routes injected by Device 7.

Neither Device 7 nor Device 10 has the external customer routes that were injected into OSPFv3 by Device 5.

On Device 3, all of the OSPFv3 routes have been learned, including the external customer routes, 1010::1/128 and 2020::1/128.

Verifying the Type of LSAs

Purpose

Verify the type of LSAs that are in the area.

Action

From operational mode on Device 7, enter the show ospf3 database nssa detail command.

user@7> show ospf3 database nssa detail
Area 0.0.0.9
 Type       ID               Adv Rtr           Seq         Age  Cksum  Len 
NSSA        0.0.0.1          3.3.3.3          0x8000002a  1462  0xf406  28
  Prefix ::/0
  Prefix-options 0x0, Metric 10, Type 1,
NSSA       *0.0.0.1          7.7.7.7          0x80000003  1625  0x88df  60
  Prefix 3030::1/128
  Prefix-options 0x8, Metric 0, Type 2,
   Fwd addr 9009:9::1,
NSSA       *0.0.0.2          7.7.7.7          0x80000003  1025  0xef57  60
  Prefix 4040::1/128
  Prefix-options 0x8, Metric 0, Type 2,
   Fwd addr 9009:9::1,

Meaning

On Device 7, the NSSA LSAs are the type 1 external default route, learned from Device 3, and the type 2 external static routes to the Customer 1 network.

 

Related Documentation

 

Published: 2013-02-01

Previous Page Next Page