OSPFv2/OSPFv3
OSPFv2 (Open Shortest Path First v2) is defined in
RFC 2328.
OSPFv3 is defined in
RFC 5340.
OSPFv2 as PE/CE protocol is defined in
RFC 4577.
OSPF is protocol 89.
Sends updates to multicast 224.0.0.5 (all OSPF routers) and 224.0.0.6 (all DR routers)
Adjacencies
Adjacency can be formed between different networks if "ip unnumbered" is used on both sides.
If multiple "
network" commands are used, the most specific wins.
The following must match for adjacency to be successful:
- area
- hello/dead timers
- mtu
- network type
- stub
- authentication
DR election per network type
- DR/BDR
- broadcast (default on ethernet, multicast hellos)
- non-broadcast (default on frame-relay, unicast hellos)
- no DR/BDR
- point-to-point (default on serial/pos, multicast hellos)
- point-to-multipoint (multicast hellos)
- point-to-multipoint non-broadcast (unicast hellos)
Use the "
neighbor" command to send unicast hellos.
You can use the commands "
ip ospf hello-interval" and "
ip ospf dead-interval" in order to tune the convergence time. Fast hellos (1 sec) are also possible using the "
minimal" keyword.
By default the loopback interface is advertised as a /32 (stub). Use network-type point-to-point under the loopback interface to advertise it with the original subnet mask.
Path Selection
- "bandwidth" under the interface (not applicable to IOS-XR)
- "ip ospf cost" under the interface
- "auto-cost reference-bandwidth" under the ospf process
- "neighbor x.x.x.x cost" under the ospf process
OSPF Route Preference
O - OSPF (intra-area)
IA - OSPF inter area
E1 - OSPF external type 1
E2 - OSPF external type 2
N1 - OSPF NSSA external type 1
N2 - OSPF NSSA external type 2
Distance and metric are evaluated as a second step, between routes of same type.
LSAs
LSA types carried in IPv6 Stub areas:
- Router-LSAs
- Network-LSAs
- Inter-Area-Prefix-LSAs
- Link-LSAs
- Intra-Area-Prefix-LSAs
LSA types carried in IPv6 NSSA areas:
- Router-LSAs
- Network-LSAs
- Inter-Area-Prefix-LSAs
- Link-LSAs
- Intra-Area-Prefix-LSAs
- NSSA-LSAs
LSA types carried in IPv4 Stub areas:
- Router-LSAs
- Network-LSAs
- Summary-LSAs
LSA types carried in IPv4 NSSA areas:
- Router-LSAs
- Network-LSAs
- Summary-LSAs
- NSSA-LSAs
NSSA
The NSSA ASBR redistributes routes into OSPF and originates the Type-7 LSAs.
Type-7 LSAs are only flooded within the originating NSSA area.
Type-7 LSAs have a propagate (P) bit that, when set, tells an NSSA ABR to translate a Type-7 LSA into a Type-5 LSA.
The NSSA ABR translates Type-7 LSAs
into Type-5 LSAs and floods them into area 0.
If there are multiple NSSA ABRs, the router with the highest Router ID is elected as
the translator.
The NSSA ASBR and the NSSA ABR can be the same router.
Preference between two Type-7 LSAs is determined by the following tie breaker rules:
-
An LSA with the P-bit set is preferred over one with the P-bit clear
- If the P-bit settings are the same, the LSA with the higher router ID is preferred
Links
LSDB optimization
You can decrease the LSA DB size by doing one or more of the following:
- configure interfaces as unnumbered
- remove network LSAs (caused by DRs) by using point-to-point as network type on interfaces
- remove transit prefixes by activating prefix-suppression
Prefixes that will be removed by prefix-suppression can be found under "Link connected to: a Stub Network" in Router LSAs (loopbacks, secondary IPs and
passive interfaces are excluded).
LSA flood-reduction
OSPF requires every LSA to be refreshed by default every 1800 seconds
(30 mins) or else the LSA will expire when it reaches 3600 seconds (1
hour).
When flood-reduction is enabled on a router (towards a neighbor), then this router will flood
its self-originated LSAs with the DoNotAge (DNA) bit set, so they do not have to be
re-flooded every 30 mins.
Of course any change in the contents of the LSA will cause the new LSA to be re-flooded (again with the DoNotAge bit set).
IOS
interface X
ip ospf flood-reduction
ipv6 ospf flood-reduction
IOS-XR
router ospf X
flood-reduction enable
area 0
flood-reduction enable
interface X
flood-reduction enable
In
IOS-XR, flood-reduction can be configured under the ospf process, under a specific area and under a specific interface.
Prefer to enable it on stable topologies.
The demand-circuit offers the same functionality plus the suppression of periodic hello packets.
Links
Route Filtering
- distribute-list
- in: filter the routes from entering the RIB
- out: filter the redistributed routes (E1/E2) entering OSPF on an ASBR
- stub area
- stub (filter LSA-5)
- totally stub (filter LSA-3/4/5)
- nssa (filter LSA-5, allow LSA-7)
- totally nssa (filter LSA-3/4/5, allow LSA-7)
- LSA-3 prefix filter
- "area x filter-list prefix x"
LSA Searching
Depending on what type of LSAs you're searching for, you can use the following commands to do so:
IOS
sh ip ospf database router | i Link State ID
Link State ID: x.x.x.x
sh ip ospf database network | i Link State ID
Link State ID: x.x.x.x (address of Designated Router)
sh ip ospf database summary | i Link State ID
Link State ID: x.x.x.x (Summary Network Number)
sh ip ospf database asbr-summary | i Link State ID
Link State ID: x.x.x.x (AS Boundary Router address)
sh ip ospf database external | i Link State ID
Link State ID: x.x.x.x (External Network Number)
IOS-XR
sh ospf database router | i Link State ID
Link State ID: x.x.x.x
sh ospf database network | i Link State ID
Link State ID: x.x.x.x (address of Designated Router)
sh ospf database summary | i Link State ID
Link State ID: x.x.x.x (Summary Network Number)
sh ospf database asbr-summary | i Link State ID
Link State ID: x.x.x.x (AS Boundary Router address)
sh ospf database external | i Link State ID
Link State ID: x.x.x.x (External Network Number)
Searching for IPv6 is a little bit different, because the IPv6 prefix information is stored in another attribute.
Summarization
- Type-3 summary
- at ABR
- area x range 10.10.10.0 255.255.255.0 (IOS)
- area 1 range 10.10.10.0/24 (IOS-XR)
- Type-5 summary
- at ASBR
- summary-address 20.20.20.0 255.255.255.0 (IOS)
- summary-prefix 20.20.20.0/24 (IOS-XR)
Both types of summarization can also accept "
not-advertise" as parameter.
Sub-routes must pre-exist in order for the summaries to be advertised.
OSPFv3
Multicast addresses have become
FF02::x from 224.0.0.x (where x=5 for all OSPF routers, or x=6 for all DR routers).
If there is no IPv4 address assigned to any interface, then you must manually configure an IPv4-formatted router-id under the OSPFv3 process.
OSPFv3 runs per-link instead of per-subnet.
You cannot automatically detect OSPFv3 neighbors when using NBMA
interfaces. You must manually configure your router to detect neighbors
when using an NBMA interface.
All manually configured neighbors in OSPFv3 must be identified by their link-local IPv6 address.
On
all OSPFv3 interfaces except virtual links, OSPFv3 packets are sent
using the interface's associated link-local unicast address as the
source address.
On virtual links, a global scope IPv6 address must be used as the source address for OSPFv3 packets.
Router-LSAs (Type-1) and Network-LSAs (Type-2) no longer contain network addresses, but simply express topology information.
Link-LSAs (Type-8) include the prefixes which are configured on links and
are flooded only on local-link scope.
Link-local addresses appear only
in Link-LSAs.
For Stub areas, the Inter-area Prefix LSA can only be a default route.
For NSSA areas, the AS-External LSA can also be a default route.
IOS
ipv6 router ospf 1
router-id 2.2.0.2
!
interface Ethernet1/0
ipv6 ospf 1 area 0
IOS-XR
router ospfv3 1
router-id 2.2.0.8
address-family ipv6 unicast
area 0
interface Loopback0
passive
!
interface GigabitEthernet0/2/1/1
A use for running multiple OSPFv3 instances is to have a single link belong to two or more OSPFv3 areas.
Also on a LAN you can have multiple adjacencies between different routers, each one on a separate OSPFv3 process/instance.
OSPFv2 Authentication
- Null (Type 0) - default
- Plain-text (Type 1)
- MD5 (Type 2)
In IOS, you can configure the authentication type under the ospf process or under the interface.
IOS
router ospf 1
area 0 authentication
!
interface X
ip ospf authentication
ip ospf authentication-key xxx
IOS
router ospf 1
area 0 authentication message-digest
!
interface X
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 xxx
In
IOS-XR, you can configure the authentication type/key under the ospf process, under the area or under the interface.
IOS-XR
router ospf 1
authentication-key xxx
authentication
area 0
authentication-key xxx
authentication
interface X
authentication-key xxx
authentication
IOS-XR
router ospf 1
authentication message-digest
message-digest-key 1 md5 xxx
area 0
authentication message-digest
message-digest-key 2 md5 xxx
interface X authentication message-digest
message-digest-key 3 md5 xxx
You can always use various combination of enabling authentication for a specific area (under the ospf process) or for a specific adjacency (under the interface).
More specific configurations override the less specific ones.
OSPFv3 Authentication
You can configure an authentication (AH) or encryption (ESP) policy, either on an interface or for an OSPFv3 area/process.
IPSec AH
IPSec ESP
- Encryption
- 3DES
- AES (128,192,256 bits)
- DES
- NULL
- Authentication
To use the IPsec AH (for authentication), you must use commands with the
"authentication" keyword.
To use the IPsec ESP (for authentication & confidentiality), you must use commands with the
"encryption" keyword.
ESP may use encryption and authentication or only authentication (when encryption=null), but is not recommended.
IOS
ipv6 router ospf 1
area 0 authentication ipsec spi 256 md5 yyy
area 0 encryption ipsec spi 256 esp 3des md5 yyy
!
interface X
ipv6 ospf authentication ipsec spi 256 md5 zzz
ipv6 ospf encryption ipsec spi 256 esp 3des
md5 zzz
IOS > 12.3(4)T is required for OSPFv3 IPsec authentication.
IOS-XR
router ospfv3 1
authentication ipsec spi 256 md5 password xxx
encryption ipsec spi 256 esp 3des password xxx
!
area 0
authentication ipsec spi 256 md5 password yyy
encryption ipsec spi 256 esp 3des password yyy
!
interface GigabitEthernet0/2/1/1.78
authentication ipsec spi 256 md5 password zzz
encryption ipsec spi 256 esp 3des password zzz
More specific configurations override the less specific ones.
Links
Options Bits
Hello/DBD/LSA Options Bits
- V6 bit: It should be set, unless the router will not participate in IPv6 topology calculation and IPv6 transit routing. If this bit is clear, the router/link should be excluded from any IPv6 routing calculations.
- R bit: It should be set, unless the router will not participate in any transit routing. It allows the router to participate in the unicast topology, but does not allow transit traffic.
- E bit: It should be set if the interface attaches to a regular area (i.e., not a stub or NSSA area).
-
N bit: It should be set if the interface attaches to an NSSA area.
-
DC bit: This bit describes the router's handling of demand circuits. It should be set in Hellos/DBDs if the router wishes to suppress the sending of future Hellos over the interface. It should be set in LSAs, if the router can correctly process
the DoNotAge bit when it appears in the LS age field of LSAs.
IPv6 Prefix Options Bits
- NU bit: The "No Unicast" capability bit. If set, the prefix should be excluded from IPv6 unicast calculations. If not set, it should be included.
-
LA bit: The "Local Address" capability bit. If set, the prefix is actually an IPv6 interface address of the Advertising Router.
-
P bit: The "Propagate" bit. Set on NSSA area prefixes that should be readvertised by the translating NSSA area border.
-
DN bit: The "Down" bit. This bit controls an inter-area-prefix-LSAs or AS-external-LSAs re-advertisement in a VPN environment. It is used for loop prevention in PE=>CE=>PE advertisements and should not be checked in CE multi-vrf (vrf-lite) scenarios.
Special multi-hop adjacencies
- virtual-link
- connects two areas 0 or extends area 0 across a transit area
- uses a transit area in order to connect areas 0 or extend area 0
- used in normal environments with multiple areas 0 or area 0 extension
- configured betweens two ABRs under the OSPF process
- sham-link
- connects two areas X (including 0)
- uses the MPLS core in order to connect the areas
- used in MPLS VPN environments with backdoor links
- configured betweens two PEs/ABRs under the OSPF vrf process
Virtual-Link
All areas in an OSPF autonomous system must be connected to area 0. When this is not possible in terms of direct connectivity, then
a virtual-link can be used in order to connect the non-backbone areas to area 0, as long as there is a common area between them.
- connect two areas 0
- R1 <=(area 0)=> R2 <=(area 1)=> R3 <=(area 0)=> R4
- a virtual link can be configured between ABRs R2,R3 that connect to area 0 from different sides and have a common area between them
- extend area 0
- R1 <=(area 0)=> R2 <=(area 1)=>R3 <=(area 2)=> R4
- a virtual link can be configured between ABRs R2,R3 that connect to a common area, with only one ABR directly connected to area 0.
- area 0 is extended to R3, in order to serve area 2
If a common area does not exist between the ABRs, then an additional area can be created to become the transit area.
The transit area through which the virtual link is configured, must have full routing information, so it cannot be any type of stub area. If this is the case, a GRE tunnel can be used to connect the two areas 0.
For virtual-links in OSPFv3 you have to use the remote neighbor's router-id (IPv4 format).
ABR #1
IOS
router ospf 1
area 1 virtual-link 2.2.2.2
IOS-XR
router ospf 1
area 1
virtual-link 2.2.2.2
ABR #2
IOS
router ospf 1
area 1 virtual-link 3.3.3.3
IOS-XR
router ospf 1
area 1
virtual-link 3.3.3.3
Sham-Link
To make a route through an MPLS backbone appear to be an intra-area route,
it is necessary to make it appear as if there is
an intra-area link
connecting the two PE routers. A sham link can be thought of as a indirect relation between two VRFs. If two
VRFs are to be connected by a sham link,
each VRF must be associated
with a "Sham Link Endpoint Address", a 32-bit IPv4 address that is
treated as an address of the PE router containing that VRF.
The Sham
Link Endpoint Address is an address in the VPN's address space, not the
SP's address space. It must not be advertised inside customer's OSPF, because when there is no BGP VPNv4 route to the Sham Link Endpoint Address, that address must become unreachable, so that the sham link comes down.
The sham link is an unnumbered point-to-point intra-area link and is advertised as a
type 1 LSA.
Sham links are treated as OSPF Demand Circuits. This means that LSAs
will be flooded over them, but periodic refresh traffic will be avoided. Normal flooding is done over the backdoor link, but if that fails, flooding will occur over the sham-link (because LSA synchronization between sites must continue).
Configuration Steps
- Create a /32 loopback that belongs to the relevant VRF on both PEs
- Advertise the above /32 into BGP VPNv4 on both PEs
- Don't advertise the above /32 into the OSPF vrf process on both PEs
- Create a sham-link between the above /32 of the PEs under the OSPF vrf process
PE1
IOS
interface Loopback1
vrf forwarding VPN
ip address 1.1.1.1 255.255.255.255
!
router ospf 100 vrf VPN
area 0 sham-link 1.1.1.1 2.2.2.2
IOS-XR
interface Loopback1
vrf VPN
ipv4 address 1.1.1.1/32
!
router ospf 100
vrf VPN
area 0
sham-link 1.1.1.1 2.2.2.2
PE2
IOS
interface Loopback1
vrf forwarding VPN
ip address 2.2.2.2 255.255.255.255
!
router ospf 100 vrf VPN
area 0 sham-link 2.2.2.2 2.1.1.1
IOS-XR
interface Loopback1
vrf VPN
ipv4 address 2.2.2.2/32
!
router ospf 100
vrf VPN
area 0
sham-link 2.2.2.2 1.1.1.1
Verification
IOS
R1#sh ip ospf sham-links
Sham Link OSPF_SL0 to address 2.2.2.2 is up
Area 0 source address 1.1.1.1
Run as demand circuit
DoNotAge LSA allowed. Cost of using 1 State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40,
Hello due in 00:00:04
Adjacency State FULL (Hello suppressed)
Index 2/2, retransmission queue length 0, number of retransmission 0
First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0)
Last retransmission scan length is 0, maximum is 0
Last retransmission scan time is 0 msec, maximum is 0 msec
R1#sh ip ospf interface | b _SL
OSPF_SL0 is up, line protocol is up
Internet Address 0.0.0.0/0, Area 0
Process ID 100, Router ID 10.10.10.1, Network Type SHAM_LINK, Cost: 1
Topology-MTID Cost Disabled Shutdown Topology Name
0 1 no no Base
Configured as demand circuit.
Run as demand circuit.
DoNotAge LSA allowed.
Transmit Delay is 1 sec, State POINT_TO_POINT
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:06
Supports Link-local Signaling (LLS)
Cisco NSF helper support enabled
IETF NSF helper support enabled
Index 2/2, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 1
Last flood scan time is 0 msec, maximum is 4 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 10.10.10.2 (Hello suppressed)
Suppress hello for 1 neighbor(s)
R1#sh ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
...
10.10.10.2 0 FULL/ - - 2.2.2.2 OSPF_SL0
...
R1#sh ip ospf neighbor detail | b 2.2.2.2
Neighbor 10.10.10.2, interface address 2.2.2.2
In the area 0 via interface OSPF_SL0
Neighbor priority is 0, State is FULL, 6 state changes
DR is 0.0.0.0 BDR is 0.0.0.0
Options is 0x32 in Hello (E-bit, L-bit, DC-bit)
Options is 0x72 in DBD (E-bit, L-bit, DC-bit, O-bit)
LLS Options is 0x1 (LR)
Neighbor is up for 00:12:16
Index 2/2, retransmission queue length 0, number of retransmission 0
First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0)
Last retransmission scan length is 0, maximum is 0
Last retransmission scan time is 0 msec, maximum is 0 msec
IOS-XR
GSR#sh ospf vrf VPN sham-links
Sham Links for OSPF 2, VRF VPN
Sham Link OSPF_SL0 to address 2.2.2.2 is up
Area 0, source address 1.1.1.1
IfIndex = 2
Run as demand circuit
DoNotAge LSA allowed., Cost of using 1
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
Hello due in 00:00:08
Adjacency State FULL (Hello suppressed)
Number of DBD retrans during last exchange 0
Index 2/2, retransmission queue length 0, number of retransmission 0
First 0(0)/0(0) Next 0(0)/0(0)
Last retransmission scan length is 0, maximum is 0
Last retransmission scan time is 0 msec, maximum is 0 msec
Both sham-links and virtual-links can have most of their "interface" attributes (hellos, cost, authentication, etc.) configured (IOS-XR gives more options).
The OSPF Sham Link endpoint address must not be used as the endpoint address of an OSPF Virtual Link.
OSPF Multi-Area
Applicable to OSPFv2 and OSPFv3.
It allows
a link to be
configured in more than one area, so that the
link could be considered as an intra-area link in all those areas and
get preference over inter-area links.
It exists as a logical construct over an existing primary interface for
OSPF; however, the neighbor state on the primary interface is
independent of the multi-area interface.
Only point-to-point adjacencies are supported.
IOS
interface Ethernet 0/0
ip ospf 1 area 0
ip ospf multi-area 1
IOS-XR
router ospf 1
area 0
interface GigabitEthernet0/2/1/2
area 1
multi-area-interface GigabitEthernet0/2/1/2
area 2
multi-area-interface GigabitEthernet0/2/1/2
The multi-area interface inherits the interface characteristics from its
primary interface, but some interface characteristics can be configured
under the multi-area interface configuration.
It also inherits the BFD characteristics
from its primary interface.
OSPF Multiple-instance
Both IOS and IOS-XR allows you to run multiple OSPFv3 instances. Peer routers need to use the same instance-id for ospfv3 communication to happen.
Also, OSPFv3 can support multiple address-families using a different instance per address-family.
Unlike OSPFv3 where the Instance ID can be used for multiple purposes,
such as putting the same interface in multiple areas, the OSPFv2
Instance ID is reserved for identifying protocol instances.
Although
the relevant RFC defines the mechanism to differentiate packets for
different instances sent and received on the same interface, Cisco's
current IOS implementation allows you to have multiple OSPFv2 processes
(not instances) using only different interfaces. Some of these processes can
be VRF ones.
Links
