Network types, area types

1.4.b Network types

General information about “OSPF network types”

Used to set the optimal operational characteristics of OSPF on a particular interface

Network type	DR/BDR election	Unicast/Multicast	Hello/Dead timers	Neighbor discovery
Point-to-Point	No	Multicast	10/40	Dynamic
Point-to-Multipoint	No	Multicast	30/120	Dynamic
Point-to-Multipoint Non-Broadcast	No	Unicast	30/120	Static
Broadcast	Yes	Multicast	10/40	Dynamic
Non-Broadcast	Yes	Unicast	30/120	Static
Loopback	N/A	N/A	N/A	N/A

How to remember:

Point-to-x networks: No DR/BDR
Non-Broadcast networks: Static Neighbor (unicast)
Point-to-Point/Broadcast networks: Fast 10/40 (hello/dead) timers

“OSPF network types” CLI configuration commands:

## ======
## OSPFv2
## ======

## Configuring the OSPFv2 network type per interface
Router(config)# interface <if>
Router(config-if)# ip ospf network [broadcast | non-broadcast | point-to-multipoint | point-to-multipoint non-broadcast | point-to-point]


## ======
## OSPFv3
## ======

## Configuring the OSPFv3 network type per interface for a specific address families
Router(config)# interface <if>
Router(config-if)# ospfv3 <pid> [ipv4 | ipv6] network [broadcast | manet | non-broadcast | point-to-multipoint | point-to-multipoint non-broadcast | point-to-point]

## Configuring the OSPFv3 network type per interface for all address families
Router(config)# interface <if>
Router(config-if)# ospfv3 network [broadcast | manet | non-broadcast | point-to-multipoint | point-to-multipoint non-broadcast | point-to-point]

1.4.b LSA types (not on blueprint)

LSA types:

Type 1: Router LSA
- Generated by every router within an area
- Flooded only within an area
- Describes its directly connected links (costs, neighbors)
- Host routes are advertised as stub networks (/32)
Type 2: Network LSA
- Generated by the DR on multi-access networks
- Flooded only within an area
- Describes who’s adjacent with the DR
- DRs let the network look like a star-topology
- Without DRs a full-mesh network would be needed
Type 3: Network Summary LSA (OSPFv3: Inter-Area Prefix LSA)
- Generated by ABRs to advertise inter-area routes
- Flooded into adjacent areas
- Consists of each subnet and cost to reach it
- Summarizes information from Type 1 and Type 2 LSAs
- Nonbackbone-to-Backbone area: Only intra-area routes can be propagated (loop-prevention mechanism)
- ABRs only accept Type 3 LSAs from the backbone area for SPF computation and will never accept Type 3 LSAs originated by other ABRs within the same nonbackbone area (prevents ABRs from using other nonbackbone areas to reach an inter-area network)
- In other words: Traffic from nonbackbone to nonbackbone areas must always pass the backbone area (area 0)
- Important: Network Summary LSA != Route Summarization
Type 4: ASBR Summary LSA (OSPFv3: Inter-Area Router LSA)
- Generated by ABRs when they receive Type 1 LSAs with E-Bit set from ASBRs
- Flooded into adjacent areas
- Used to advertise the route pointing to an ASBR
- Tells an area which ABR to use to reach a specific ASBR
- ABRs generate one for each area they are connected to
Type 5: AS External LSA
- Generated by ASBRs to advertise external routes
- Flooded to all non-stub areas
- Type 4 provides reachability for the Type 5 routes
Type 7: NSSA External LSA (OSPFv3 NSSA LSA)
- Created by ASBRs inside an NSSA
- Flooded only within the NSSA
- Used instead of Type 5
- Used to inject/redistribute external routes into NSSA
- On reaching an ABR it will be converted into Type 5 (in case of multiple ABRs this is done on the one with the highest RID)
Type 8: Link Local LSA (OSPFv3 only)
- Generated by every router which is on the same link
- Flooded only on the link
- Used to advertise the link-local address of each router on the same link
- Inform other routers on the same link which IPv6 addresses they should associate with the link
Type 9: Intra-Area Prefix LSA (OSPFv3 only)
- Generated by every router within an area
- Flooded only within an area
- Describes the directly connected links (costs, neighbors)

Important information on “LSA Type 8 and 9”:

In OSPFv3, LSA Type 1 and Type 2 no longer carry addressing information
They only carry a description of topology adjacencies using RIDs as an address-independent way of referring to a neighboring object (comparable to TLOCs in SD-WAN)
This results in a significant improvement: Changing the link addresses between two routers no longer triggers an SPF run!

“OSPF LSA types” CLI show commands:

## ======
## OSPFv2
## ======

## Showing the different OSPFv2 databases
Router# show ip ospf database router <lsa-type> <rid>


## ======
## OSPFv3
## ======

## Showing the different OSPFv3 databases
Router# show ospfv3 [ipv4 | ipv6] database <lsa-type> <rid>

1.4.b Area types

Area types:

Backbone:
- Area 0
- All areas must be connected to it
- Only needed if there is more than one area
Normal:
- Non-backbone area
- LSDB contains internal and external routes
Transit:
- Used to connect the backbone area to another area
- Used for virtual-links
- Can’t be a stub area
Stub:
- ABRs will filter Type 4 and 5 LSAs
- This means they don’t accept routes belonging to external AS
- LSDB contains internal routes (intra-area), summary routes (inter-area) and a default route
- Default route (0.0.0.0/0) is automatically generated
Totally Stub:
- Similar to a stub area and additionally…
- ABRs will filter Type 3 LSAs as well
- This means they don’t accept summary (inter-area) routes
- Technically allows one Type 3 LSA for the default route
- LSDB contains internal (intra-area) and a default route
- Default route (0.0.0.0/0) is automatically generated
NSSA:
- Stands for “not-so-stubby-area”
- Allows redistribution of routes from external AS via an ASBR into the area
- Redistributed routes will use Type 7 LSAs within area
- LSDB contains internal (intra-area), summary (inter-area), Type 7 (external) and a default route
- Default route is not automatically generated
Totally NSSA:
- Similar to NSSA but also filters Type 3 LSA routes
- Does not filter the default route
- LSDB contains internal (intra-area), Type 7 (external) and default routes
- Default route (0.0.0.0/0) is automatically generated

Important: All routers within an area must be the same type of stub (if configured)!

Area type	Allowed LSAs	Fildered LSAs	Allowed Routes	Blocked Routes
Stub	Type 1, 2, 3	Type 4, 5	Intra-Area, Summary (Inter-Area), Default	External
Totally Stub	Type 1, 2	Type 3, 4, 5	Intra-Area, Default	External, Inter-Area
NSSA	Type 1, 2, 3, 7	Type 4, 5	Intra-Area, Summary (Inter-Area), Default, Type 7	External
Totally NSSA	Type 1, 2, 7	Type 3, 4, 5	Intra-Area, Default, Type 7	External, Inter-Area

“OSPF Area types” CLI configuration commands:

## ======
## OSPFv2
## ======

## Configuring the area type in OSPFv2
Router(config)# router ospf <pid>
Router(config-router)# area <id> [stub | stub no-summary | nssa | nssa default-information-originate | nssa no-summary | default-cost <value>]


## ======
## OSPFv3
## ======

## Configuring the area type in OSPFv3
Router(config)# router ospfv3 <pid>
Router(config-router)# address-family [ipv4 | ipv6]
Router(config-router-af)# area <id> [stub | stub no-summary | nssa | nssa default-information-originate | nssa no-summary | default-cost <value>]

1.4.b Route types (not on blueprint)

OSPF route types:

O: Intra-Area
- Route within an area
O*IA: Inter-Area
- Router between two areas
O*N1: NSSA Type 1
- External route with increasing metric inside an NSSA
- Will be converted to E1 type route when passing through an ABR
O*E1: External Type 1
- External route with increasing metric when it traverses the network
O*N2: NSSA Type 2
- External route with “hardcoded” (not changing) metric inside an NSSA
- Will be converted to E2 type route when passing through an ABR
- Although the metric is hardcoded, the metric to the ASBR (forward metric) is still relevant within the OSPF domain if there are multiple paths/ASBRs for a given external route
O*E2: External Type 2
- External route with “hardcoded” (not changing) metric (default metric = 20)
- Although the metric is hardcoded, the metric to the ASBR (forward metric) is still relevant within the OSPF domain if there are multiple paths/ASBRs for a given external route

1.4.b Router types (not on blueprint)

OSPF router types:

Internal Router:
- Router within an area
Backbone Router:
- Router within the backbone area
ABR:
- Stands for Area Border Router
- Router connecting an area to the backbone area
ASBR:
- Stands for Autonomous System Border Router
- Router redistributing routes from other protocols into an area

1.4.b Virtual link (not on blueprint)

General information on “OSPF Virtual Link”:

Normally all areas have to be connected to the backbone area (area 0)
In some OSPF designs this isn’t possible and therefor virtual links are needed
Sometimes there are also discontiguous (partitioned) (backbone) areas which need to be connected
So called transit areas have to be used for this to work
A transit area can’t be a stub area
The configuration is done on the ABR in area 0 as well as the ABR in the not directly connected area
ABRs connected over virtual links send all OSPF messages as unicast
They also mark the Do Not Age (DNA) bit in LSAs
Virtual links are on-demand circuits
Important: Prefix-Suppression must be disabled on the to-be-used transit-link for virtual-links to work. This is because although the RID is the target of a virtual-link, the transit-link addresses are used to connect them.
Important: Within OSPFv3, virtual-links can only be configured within IPv6 AFs but they transport IPv4 information as well!

Important: The area ID in the CLI command is the area ID of the transit area (not the not directly connected area)!

“OSPF Virtual link” CLI configuration commands:

## ======
## OSPFv2
## ======

## Configuring a virtual-link in OSPFv2
Router(config)# router ospf <pid>
Router(config-router)# area <id> virtual-link <remote-rid>


## ======
## OSPFv3
## ======

## Configuring a virtual-link in OSPFv3
Router(config)# router ospfv3 <pid>
Router(config-router)# address-family ipv6
Router(config-router-af)# area <id> virtual-link <remote-rid>

“OSPF Virtual link” CLI show commands:

## ======
## OSPFv2
## ======

## Showing configured OSPFv2 virtual-links
Router# show ip ospf virtual-links


## ======
## OSPFv3
## ======

## Showing configured OSPFv3 virtual-links
Router# show ospfv3 virtual-links

1.4.b Capability Transit (not on blueprint)

General information on “Capability Transit”:

Enabled by default
Can’t be disabled in OSPFv3
Used to allow traffic to take a shorter path (if available) and not forcing it over the virtual-link
Affects only traffic destined for areas which are not directly connected to the backbone area (= areas behind a non-backbone area connected via a virtual link)
If disabled, all traffic is forced to use the virtual link regardless of the available paths
If enabled, virtual link is only used if no better paths are available through the transit area
Disabling the transit capability can introduce routing loops in certain situations:
- Leaving the capability transit enabled would allow traffic to flow directly from R3-R2-R4-R5.
- Disabling the capability transit on R2 forces the traffic from R3 to explicitly use the virtual-link which would result in R3-R2-R1-R2-R4-R5. This introduces a routing loop. R2 says in order to reach R3/R5 you need to go to R1. R1 says in order to reach R3/R5 you need to go to R2. The traffic will ping-pong/loop until TTL reached 0.

// Graphic missing - Coming soon //

“OSPF Capability Transit” CLI configuration commands:

## Configuring the Transit capability for OSPFv2
Router(config)# router ospf <pid>
Router(config-router)# [no] capability transit

1.4.b Capability VRF-Lite (not on blueprint)

General information on “Capability VRF-Lite”:

MP-BGP/MPLS related feature
Disabled by default
When VRF-aware OSPF is configured, the router behaves like a MPLS PE router
This means that all incoming LSAs which have the DN/DOWN-Bit and/or Domain-Tag set will be rejected
The DN-/DOWN-bit is set by the last-hop PE when redistributing from MP-BGP to OSPF for Type 3/5 LSAs
If the DN-/DOWN-bit is set it means that the route was already redistributed by the PE and isn’t any longer eligible for redistribution (comparable to the UP-/DOWN-bit in IS-IS)
The Domain-Tag was used in the past for marking Type 5 LSAs, although all newer IOS versions use the DN-bit on Type 5 LSAs as well
The Domain-Tag still remains as to preserve backwards compatibility
Capability VRF-Lite enabled: the DN-Bit/Domain-Tag checks are disabled
Capability VRF-Lite disabled: the DN-Bit/Domain-Tag checks are enabled (default setting)
Important: When a CE router uses OSPF as CE-PE protocol with VRF-Lite, then the capability vrf-lite needs to be enabled. When an OSPF sham-link is configured in the MPLS superbackbone, the capability does NOT need to be enabled!

“OSPF Capability VRF-Lite” CLI configuration commands:

## ======
## OSPFv2
## ======

## Configuring the VRF-Lite capability for OSPFv2
Router(config)# router ospf <pid>
Router(config-router)# capability vrf-lite


## ======
## OSPFv3
## ======

## Configuring the VRF-Hite capability for OSPFv3
Router(config)# router ospfv3 <pid>
Router(config-router)# address-family [ipv4 | ipv6] vrf [VRF-NAME]
Router(config-router-af)# capability vrf-lite