Differences in OSPFv3 from OSPFv2

Most of the algorithms have been preserved from OSPFv2, however, some changes were needed either to support larger address space or due to changes in protocol semantics between IPv4 and IPv6.

Following are the differences between OSPFv3 and OSPFv2-

1. Protocol processing per-link, not per-subnet:

IPv6 uses the term "link" instead of "subnet" or "network" to define a medium used to communicate between nodes at the link layer. Multiple IP subnets can be assigned to a single link, and two nodes can communicate with each other even if they do not share a common IP subnet.

This change affects Hello packets and Network LSAs processing.

2. Removal of addressing semantics:

• IPv6 addresses are not present in OSPF packets, except in Link-State Update (LSU) packets.
• Router and Network LSAs do not contain network addresses, but only contains topology information.
• OSPF Router ID, Area ID and Link-State IDs remain at 32-bits size- they cannot be assigned IPv6 addresses.
• Neighboring routers are identified by Router IDs only.

3. Addition of Flooding scope:

There are three seperate scopes for flooding LSAs-
    
    Link-local scope- LSA is flooded only on local link and no further. New Link-LSA uses link-local scope.

    Area scope- LSA is flooded in a single OSPF area. Router-LSAs, Network-LSA, Inter-area Prefix-LSAs, Inter-area Router-LSAs and Intra-area Prefix-LSAs use Area scope.

    AS scope- LSA is flooded throughout the routing domain. AS-external LSAs use AS scope.

4. Explicit support for multiple instances per link:

Providers may run different OSPF domains and would like to keep it seperate even though if they have one or more links in common, can use multiple instances on the same link.

If someone wants a single link in more than one area can use multiple instances on the same link.

Multiple instances on the single link can be achieved using "Instance ID" contained in the OSPF packet header.

5. Use of Link-local addresses:

OSPFv3 requires that every interface has a link-local address from the range FE80/10. A router uses the link-local address as next-hop during packet forwarding for the neighbors attached to its links.

On virtual-links, global or site-local addresses are used for packet forwarding.

Link-local addresses are only sent in Link-LSAs, and not allowed in any other OSPF LSAs.

6. Authentication changes:

In OSPFv3, Authentication for OSPF has been removed. OSPFv3 relies on IPv6 Authentication Header (AH) and Encapsulating Security Payload (ESP) to ensure integrity and authentication/confidentiality of routing exchanges.

Accidental data corruption is handled by checksum.

7. Packet Format changes:

• Version number is now 3.
• No Authentication fields.
• Options field Hello and DBD packets is now 24-bits long
• Two option bits, "R" bit and "v6" bit, are added to Options field for processing Router-LSAs during SPF calculation.
• "Instance ID" is included in Hello packet

8. LSA Format changes:

• Options field is removed from LSA header, increased to 24-bit and moved to Router-LSAs, Network-LSAs, Inter-area Router-LSAs (Type-4 LSA in OSPFv2) and Link-LSAs.
• LSA Type field is expanded to 16 bits with upper 3 bits encoding flooding and handling of unknown LSA Types.
• Addresses in LSAs are now expressed as [prefix, prefix-length]. The default route is expressed as a prefix with length 0.
• Router and Network LSAs have no address information.
• Router LSAs are concatenated before SPF is run.
• New Link-LSA is introduced. They have link-local flooding scope. They have 3 purposes- a) they provide router's link-local address to all neighbors attached to that link b) inform other routers on the link of IPv6 prefixes to associate with the link c) they allow the router to assert a collection of Option bits to associate with the Network LSAs that will be originated for the link
• Type-3 summary LSA is now Inter-area Prefix-LSA and Type-4 summary LSA is now Inter-area Router-LSA.
• New Intra-area Prefix-LSA is introduced. It carries all IPv6 prefix information that in IPv4 is carried in Router and Network LSAs.

9. Handling Unknown LSA Types:

Unknown LSA Types are either treated as having link-local flooding scope, or stored and flooded as if they were understood.

10. Stub Area support:

Stub area support has been retained in OSPFv3. Only Router-LSAs, Network-LSAs, Inter-area Prefix-LSAs, Intra-area Prefix-LSAs and Link-LSAs are allowed in a Stub area.

Unknown LSAs are labelled as "Store and Flood LSAs" as if type understood under following conditions-

a) the LSA has area or link-local flooding scope
b) the LSA has U-bit set to 0.

11. Identifying neighbors by Router ID:

Neighboring routers on a given link are always identified by a Router ID. This behaviour is valid for neighbors on point-to-point, virtual-links, broadcast, NBMA and point-to-multipoint links.

Router ID 0.0.0.0 is reserved.

Further reading:

1. RFC 2740: OSPF for IPv6 http://www.faqs.org/ftp/rfc/pdf/rfc2740.txt.pdf

Migration from EIGRP to OSPF

This example points out the steps required to be carried out for migrating from EIGRP routing protocol to OSPF routing protocol.

Sample EIGRP network:





All routers are configured for EIGRP with the similar configuration given below:
EIGRP Configuration

router eigrp 1
network 0.0.0.0
no auto-summary
passive-interface fastethernet 0/1 ! Clients connected to this interface
!

OSPF deployment:


Now, through proper planning, the flat EIGRP network is converted to multi-area OSPF network as below-

Here, OSPF is enabled on a per-interface basis. Also, the administrative-distance of OSPF is made higher   to 200 or above. The reason being the administrative-distance of EIGRP internal routes is 90, but the AD of EIGRP external routes is 170.

The following is the sample configuration on router R4-

OSPF configuration on R4

Since the AD of OSPF is changed to high values, at this stage, OSPF will not replace EIGRP. However, OSPF speakers will start to form neighbor relationships.


The following outputs are taken from router R4 which shows the neighbors it has formed relationship with. Also, notice that there are no OSPF routes in the routing table.

Once EIGRP configuration is removed from all routers, OSPF routes are installed in the routing table with high AD.

The complete migration is seamless and no outage is noticed by the clients. http://www.nil.com/ipcorner/ChangingRoutingProtocol/

OSPF over Frame-Relay: Non-Broadcast

When OSPF is run on a network, two important events occur before routing information is exchanged.


OSPF neighbors are discovered using multicast Hello packets.

For a multi-access network (like Ethernet and Frame-relay), a DR (Designated Router) and a BDR (Backup Designated Router) are elected. All routers on that segment form adjacency with the DR and BDR only.

Hello packets are multicast to 224.0.0.5 address. In order for the Hello packets to reach remote routers, the underlying Layer 2 technology must allow broadcast/multicast packets to be forwarded. Frame-relay, inherently, does not forward broadcast or multicast packets to be sent. Hence, in NBMA network topology, the neighbors are not discovered automatically. Neighbors must be configured manually. OSPF elects DR and BDR for every multi-access network. In a frame-relay hub-and-spoke environment, ideally, the Hub router must be made the DR.

The below network is a simple hub-and-spoke topology. Each Spoke router has a single DLCI towards the Hub router. The Hub has multiple DLCIs towards Spoke routers.

Frame-Relay Configuration


The frame-relay configuration on the Hub and Spoke routers is as below.

Hub FR Configuration


interface serial 0/0
encapsulation frame-relay
ip address 10.1.1.1 255.255.255.0
frame-relay interface-dlci 102
frame-relay interface-dlci 103
!

Spoke1 FR Configuration

interface serial 0/0
encapsulation frame-relay
ip address 10.1.1.2 255.255.255.0
frame-relay interface-dlci 201
!

Spoke2 FR Configuration

interface serial 0/0
encapsulation frame-relay
ip address 10.1.1.3 255.255.255.0
frame-relay interface-dlci 301
!
This provides reachability from Hub to Spoke routers but not between Spoke routers.

OSPF NSSA

RFC3101 describes an OSPF area called not-so-stubby area (NSSA). The motivation behind NSSA is to allow OSPF Stub areas to carry External routes (routes learned using other routing protocols like RIP, EIGRP, BGP, etc). Stub areas are defined as areas that are not capable of importing routes external to OSPF.

N-bit

RFC 3101 defines a new bit N in the Options field and a new Type 7 LSA to support NSSA. Together, the N-bit (NSSA supported bit) and E-bit (External Routing Capability of the area) reflect an interface's external LSA flooding capability. When the peers exchange Hello messages, they check for the N-bit (should be set to 1) and E-bit (should be set to 0), along with Area ID. A mismatch in the Options field could result in failed adjacency.


Type 7 LSA

External routes are imported into OSPF NSSA as Type 7 LSAs by NSSA ASBR. The NSSA ASBR redistributes routes from different routing protocol(s) into OSPF, and vice versa. This router sets the E-bit in Router LSA flag. The ASBR originates a separate Type 7 LSA for each external route.


Type 7 LSAs are only flooded within the originating NSSA. The NSSA ABR (the routers connecting NSSA to backbone area 0) translates Type 7 LSA into Type 5 LSA, and flooded into the OSPF topology.

In Cisco IOS, by default, the NSSA ASBR always set the N/P-bit (Propagate) in the Options field of Type 7 LSA. The P-bit is not set only when the NSSA ASBR and NSSA ABR are the same router for the area. The P-bit tells the NSSA ABR to translate a Type 7 LSA to Type 5 LSA. These translated Type 5 LSAs copy the Forwarding Address (FA) from Type 7 LSA.

The following packet capture shows a Type 7 LSA

Type 7 Translator Election

If multiple NSSA ABR routers are present, it is recommended that not all ABRs perform Type 7-to-5 translation to avoid routing loops. RFC 3101 defines a configurable parameter NSSATranslatorRole which specifies whether a router will perform Type 7-to-5 translation or not. Cisco IOS does not support this parameter yet. Cisco IOS uses Router ID to elect the Type 7-to-5 translator.


If there exists multiple NSSA ABRs capable of performing Type 7-to-5 translation, the router advertising with higher Router ID is elected as the translator. The NSSA ABR that is no longer required to perform translation, flushes its Type 5 LSAs.

Sample Scenario

OSPF router-LSA

A router originates a router-LSA for each area that it belongs to. Such an LSA describes the collected states of the router's links to the area. The LSA is flooded throughout the particular area and no further.




The router-LSA describes the router's working connections (i.e. interfaces or links) to the area. Each Link Type is according to the kind of attached network. Each link is also labeled with its Link ID. This Link ID gives a name to the entity that is on the other end of the link.


Link Type        Description                         Link ID
1                   Point-to-point link                Neighbor Router ID
2                   Link to transit network         Interface address of DR
3                   Link to Stub network           IP network number
4                   Virtual Link                         Neighbor Router ID

The Link Data field is specified for each link. This field gives 32-bits of extra information for the link. For links to transit network, numbered point-to-point links and virtual link, this field specifies the IP interface address of the associated router interface (this is needed for routing table calculation). For links to stub network, this field specifies the stub network's IP address mask. For unnumbered point-to-point links, the link data field should be set to the unnumbered interface's MIB-II ifIndex value.



1) A router with only one Loopback interface enabled for OSPF- The router generates router-LSA with a Type-3 link (stub network).



interface loopback 0

ip address 1.1.1.1 255.255.255.255

ip ospf 100 area 0

!



Router#show ip ospf database router self-originate



OSPF Router with ID (1.1.1.1) (Process ID 100)



Router Link States (Area 0)



LS age: 15

Options: (No TOS-capability, DC)

LS Type: Router Links

Link State ID: 1.1.1.1

Advertising Router: 1.1.1.1

LS Seq Number: 80000001

Checksum: 0xD055

Length: 36

Number of Links: 1



Link connected to: a Stub Network

(Link ID) Network/subnet number: 1.1.1.1

(Link Data) Network Mask: 255.255.255.255

Number of TOS metrics: 0

TOS 0 Metrics: 1



2) Two routers connected via point-to-point serial link- The routers generate a router-LSA with two links for each point-to-point interface. The router link (Type-1 or point-to-point link) describing the connection to the OSPF neighbor (Link ID as Neighboring Router ID) and Type-3 link (stub network) describing the subnet of the point-to-point interface (Link ID as the network/subnet number).



R2#show ip ospf database router self-originate



OSPF Router with ID (172.16.1.2) (Process ID 100)



Router Link States (Area 0)



LS age: 482

Options: (No TOS-capability, DC)

LS Type: Router Links

Link State ID: 172.16.1.2

Advertising Router: 172.16.1.2

LS Seq Number: 80000005

Checksum: 0x445E

Length: 48

Number of Links: 2



Link connected to: another Router (point-to-point)

(Link ID) Neighboring Router ID: 1.1.1.1

(Link Data) Router Interface address: 172.16.1.2

Number of TOS metrics: 0

TOS 0 Metrics: 64



Link connected to: a Stub Network

(Link ID) Network/subnet number: 172.16.1.0

(Link Data) Network Mask: 255.255.255.252

Number of TOS metrics: 0

TOS 0 Metrics: 64



3) Two routers connected via an Ethernet network- When the adjacency is NOT formed between the two routers, a single Type-3 link is added to the router-LSA with Link ID set to the network number of the attached network and Link Data set to attached network's mask.



R1#show ip ospf database router self-originate



OSPF Router with ID (1.1.1.1) (Process ID 100)



Router Link States (Area 0)



LS age: 63

Options: (No TOS-capability, DC)

LS Type: Router Links

Link State ID: 1.1.1.1

Advertising Router: 1.1.1.1

LS Seq Number: 80000003

Checksum: 0x5AA6

Length: 48

Number of Links: 2



Link connected to: a Stub Network

(Link ID) Network/subnet number: 10.1.1.0

(Link Data) Network Mask: 255.255.255.252

Number of TOS metrics: 0

TOS 0 Metrics: 10



In broadcast network type, a DR must be elected. The router is fully adjacent to the DR, or the router itself is a DR and is fully adjacent to atleast one another router, a single Type-2 link (link to transit network) is added to the router-LSA with Link ID set to IP interface address of the attached network's DR and Link Data set to router's own IP interface address.



R1#show ip ospf database router self-originate



OSPF Router with ID (1.1.1.1) (Process ID 100)



Router Link States (Area 0)



LS age: 4

Options: (No TOS-capability, DC)

LS Type: Router Links

Link State ID: 1.1.1.1

Advertising Router: 1.1.1.1

LS Seq Number: 80000004

Checksum: 0x1DD1

Length: 48

Number of Links: 2



Link connected to: a Transit Network

(Link ID) Designated Router address: 10.1.1.2

(Link Data) Router Interface address: 10.1.1.1

Number of TOS metrics: 0

TOS 0 Metrics: 10





4) Virtual-link to the ABR- The router originates two router-LSAs- one for each area 1 & 2. The virtual links, the description is added to the router-LSA only when the virtual neighbor is fully adjacent. In this case, the Link ID is set to the Router ID of the virtual neighbor and Link Data is set to interface IP address associated to the virtual-link.



Consider the following-

R1 router- R2 router- R3 router-

interface loopback 0 interface loopback 0 interface loopback 0

ip address 1.1.1.1 255.255.255.255 ip address 2.2.2.2 255.255.255.255 ip address 3.3.3.3 255.255.255.255

! ! !

interface fastethernet 0/0 interface fastethernet 0/0 interface fastethernet 0/0

ip address 10.1.1.1 255.255.255.252 ip address 10.1.1.2 255.255.255.252 ip address 10.2.2.2 255.255.255.252

! ! !

interface fastethernet 0/1 interface fastethernet 0/1 interface fastethernet 0/1

ip address 10.3.3.1 255.255.255.252 ip address 10.2.2.1 255.255.255.252 ip address 10.4.4.1 255.255.255.252

! ! !

router ospf 100 router ospf 100 router ospf 100

network 10.1.1.0 0.0.0.3 area 1 network 10.1.1.0 0.0.0.3 area 1 network 10.2.2.0 0.0.0.3 area 1

network 10.3.3.0 0.0.0.3 area 0 network 10.2.2.0 0.0.0.3 area 1 network 10.4.4.0 0.0.0.3 area 2

area 1 virtual-link 3.3.3.3 ! area 1 virtual-link 1.1.1.1

! !



R1#show ip ospf database router self-originate



OSPF Router with ID (1.1.1.1) (Process ID 100)



Router Link States (Area 0)



LS age: 948

Options: (No TOS-capability, DC)

LS Type: Router Links

Link State ID: 1.1.1.1

Advertising Router: 1.1.1.1

LS Seq Number: 80000002

Checksum: 0xAF24

Length: 48

Area Border Router

Number of Links: 2



Link connected to: a Stub Network

(Link ID) Network/subnet number: 10.3.3.0

(Link Data) Network Mask: 255.255.255.252

Number of TOS metrics: 0

TOS 0 Metrics: 10



Link connected to: a Virtual Link

(Link ID) Neighboring Router ID: 3.3.3.3

(Link Data) Router Interface address: 10.1.1.1

Number of TOS metrics: 0

TOS 0 Metrics: 20







Router Link States (Area 1)



LS age: 952

Options: (No TOS-capability, DC)

LS Type: Router Links

Link State ID: 1.1.1.1

Advertising Router: 1.1.1.1

LS Seq Number: 8000000D

Checksum: 0x3ABB

Length: 36

Area Border Router

Virtual Link Endpoint

Number of Links: 1



Link connected to: a Transit Network

(Link ID) Designated Router address: 10.1.1.2

(Link Data) Router Interface address: 10.1.1.1

Number of TOS metrics: 0

TOS 0 Metrics: 10



5) Two router connected by a point-to-multipoint network- The router generates one router-LSA which contains a) a Type-1 point-to-point link with Link ID set to the Router ID of the fully-adjacent neighboring router and Link Data set to the IP address of this router b) a Type-3 Stub network with Link ID set to the router's own interface IP address and Link Data set to 0xffffffff (indicating a host route).



Consider the following-



HUB router- Spoke router-



interface serial 0/0 interface serial 0/0

no ip address ip address 10.1.1.2 255.255.255.0

encapsulation frame-relay encapsulation frame-relay

! frame-relay interface-dlci 202

interface serial 0/0.100 multipoint ip ospf network point-to-multipoint

ip address 10.1.1.1 255.255.255.0 ip ospf priority 0

frame-relay interface-dlci 101 ip ospf 1 area 0

frame-relay interface-dlci 102 !

ip ospf 1 area 0

ip ospf network point-to-multipoint

ip ospf priority 100

!



HUB#show ip ospf database router self-originate



OSPF Router with ID (10.1.1.1) (Process ID 1)



Router Link States (Area 0)



LS age: 145

Options: (No TOS-capability, DC)

LS Type: Router Links

Link State ID: 10.1.1.1

Advertising Router: 10.1.1.1

LS Seq Number: 80000002

Checksum: 0xA8F8

Length: 48

Number of Links: 2



Link connected to: another Router (point-to-point)

(Link ID) Neighboring Router ID: 10.1.1.2

(Link Data) Router Interface address: 10.1.1.1

Number of TOS metrics: 0

TOS 0 Metrics: 64



Link connected to: a Stub Network

(Link ID) Network/subnet number: 10.1.1.1

(Link Data) Network Mask: 255.255.255.255

Number of TOS metrics: 0

TOS 0 Metrics: 0





Further Reading:



RFC 2328: OSPF Version 2 http://www.faqs.org/ftp/rfc/pdf/rfc2328.txt.pdf

OSPF Packet Types

All OSPF packets share a common OSPF Header of 24-bytes. This header allows the receiving router to validate and process the packets. The format of common OSPF header is-

Version- 2 (1-byte)

Type- It specifies the type of OSPF packet. There are 5 different types of OSPF packets. (1-byte)



1- Hello packet


2- Database Descriptor packet


3- Link State Request packet


4- Link State Update packet


5- Link State Acknowledgment packet






Packet Length- Total length of the OSPF packet (2-bytes)

Router ID- The Router ID of the advertising router

Area ID- 32-bit Area ID assigned to the interface sending the OSPF packet (4-bytes)

Checksum- Standard IP Checksum of OSPF packet excluding Authentication field (2-bytes)

AuType- Authentication Type (2-bytes)



0- No Password

1- Plain-text password

2- MD5 authentication



Authentication- Authentication data to verify the packet's integrity (8-bytes)





1. Hello Packet:



Hello packets are OSPF packet Type 1. These packets are multicast periodically to 224.0.0.5 multicast address on all interfaces (unicast on virtual-links) enabling dynamic discovery of neighbors and maintain neighbor relationships. On broadcast and NBMA networks, Hello packets are used to elect DR and BDR.

Network Mask- Subnet mask of the advertising OSPF interface. For unnumbered point-to-point interfaces and virtual-links, it is set to 0.0.0.0 (4-bytes)


HelloInterval- Interval at which Hello packets are advertised. By default, 10 seconds for point-to-point link and 30 seconds for NBMA/Broadcast links (2-bytes)

Options- The local router advertises its capabilities in this field. (1-byte)

Rtr Pri- The Priority of the local router. It is used for DR/BDR election. If set to 0, the router is ineligible for the election. (1-byte)

RouterDeadInterval- The Dead Interval as requested by the advertising router. By default, 40 seconds for point-to-point link and 120 seconds for NBMA/Broadcast links (4-bytes)

Designated Router- The IP address of the current DR. Set to 0.0.0.0 if no DR is elected yet. (4-bytes)

Backup Designated Router- The IP address of the current BDR. Set to 0.0.0.0 if no BDR is elected yet. (4-bytes)

Neighbor- The Router IDs of all OSPF routers from whom a valid Hello packet have been seen on the network.



The following is a sample packet capture of an OSPF Hello packet.

The fields Area ID, HelloInterval, RouterDeadInterval and Authentication information (AuType & Authentication) should match on neighbors to form adjacency. For example, when the Hello interval is changed on a router, the receiving router does not accept the Hello packet due to mismatch of Hello timer. The following message is displayed.
Hello parameters mismatch


R1 router:



interface Serial 1/0

ip address 10.1.1.2 255.255.255.0

ip ospf 1 area 0

ip ospf hello-interval 5

!



R0 router:



interface Serial 1/0

ip address 10.1.1.1 255.255.255.0

ip ospf 1 area 0

!



R0# debug ip ospf hello

00:18:02.491: OSPF: Rcv hello from 10.1.1.2 area 0 from Serial1/0 10.1.1.2

00:18:02.491: OSPF: Mismatched hello parameters from 10.1.1.2

00:18:02.491: OSPF: Dead R 20 C 40, Hello R 5 C 10

2. Database Descriptor packet:

For link-state routing protocol, it is required that the link-state databases for all routers remain synchronized. Th synchronization starts as soon as the adjacency is formed between neighbors. OSPF uses Database Descriptor (DBD) packets for this purpose.




The DBD packets are OSPF packet Type 2. The OSPF router summarizes the local database and the DBD packets carry a set of LSAs belonging to the database. When a neighbor sees an LSA that is more recent than its own database copy, it requests this newer LSA from the neighbor.

Interface MTU- Contains the MTU value of the outgoing interface. For virtual-links, this field is set to 0x0000. (2-bytes)


Options- Same as Options field in a Hello packet (1-byte)

I- Initial Bit. Indicates this is the first in the series of DBD packets (1-bit)

M- More bit. Indicates whether the DBD packet is the last in the series of packets. Last packet has a value of 0, while all previous packets have a value of 1. (1-bit)

MS- Master/ Slave bit. Master=1, Slave=0 (1-bit)

DD Sequence Number- Used to sequence the collection of DBD packets. The initial value should be unique. The sequence number then increments by 1 until the complete database description has been sent.(4-bytes)

LSA Header- This field contains the LSA headers describing the local router's database. (variable length)





During the DBD packet exchange, a Master/ Slave relationship is established between the neighbors. The router with the highest Router ID becomes the Master and initiates DBD packet exchange. The Interface MTU should match on neighbors otherwise FULL adjacency is not reached.





Interface MTU Mismatch

19:24:22.879: OSPF: Rcv DBD from 10.1.1.2 on Serial1/0 seq 0xA9A opt 0x52 flag 0x7 len 32 mtu 1400 state EXCHANGE

19:24:22.883: OSPF: Nbr 10.1.1.2 has smaller interface MTU



19:26:01.591: %OSPF-5-ADJCHG: Process 1, Nbr 10.1.1.2 on Serial1/0 from EXCHANGE to DOWN, Neighbor Down: Too many retransmissions

19:27:01.591: %OSPF-5-ADJCHG: Process 1, Nbr 10.1.1.2 on Serial1/0 from DOWN to DOWN, Neighbor Down: Ignore timer expired





The following packet capture shows a sample OSPF database. The DBD packets contain LSA header which contain the summary of this database i.e the Type of LSA, Link State ID, Advertising router, etc. The neighbors then request further information about these LSAs using Link State Request packets.





OSPF Database

R1# show ip ospf database



OSPF Router with ID (10.1.1.2) (Process ID 1)



Router Link States (Area 0)



Link ID ADV Router Age Seq# Checksum Link count

10.1.1.1 10.1.1.1 1706 0x8000002E 0x00C174 2

10.1.1.2 10.1.1.2 755 0x80000036 0x0031E5 3

3. Link State Request packet:
The Link State Request (LSR) packet is an OSPF packet Type 3. After DBD packets exchange process, the router may find it does not have an up-to-date database. The LSR packet is used to request pieces of neighbor database that is more up-to-date.

LS Type- Type of LSA requested (4-bytes)


Link State ID- Depends upon the type of LSA (4-bytes)

Advertising Router- Router ID of the requesting router (4-bytes)

The following packet capture shows the LSR sent for Router-LSA (Type-1) to an OSPF neighbor after DBD packet exchange process is over.

4. Link State Update packet:

Link State Update (LSU) packets are OSPF packet Type 4. These packets implement the flooding of LSAs. Each LSA contains routing, metric and topology information to describe a portion of OSPF network. The local router advertises LSA within an LSU packet to its neighboring routers. In addition, the local router advertises the LSU packet with information in response to an LSR packet.

# LSAs- Number of LSAs within an LSU packet (4-bytes)


LSAs- The complete LSA is encoded within this field. The LSU may contain single or multiple LSAs.



The following output shows what the router responds to LSR.

Router LSA advertised in response to an LSR


R1# show ip ospf database router 10.1.1.2 adv-router 10.1.1.2



OSPF Router with ID (10.1.1.2) (Process ID 1)



Router Link States (Area 0)



LS age: 748

Options: (No TOS-capability, DC)

LS Type: Router Links

Link State ID: 10.1.1.2

Advertising Router: 10.1.1.2

LS Seq Number: 80000036

Checksum: 0x31E5

Length: 60

Number of Links: 3



Link connected to: a Stub Network

(Link ID) Network/subnet number: 1.1.1.1

(Link Data) Network Mask: 255.255.255.255

Number of TOS metrics: 0

TOS 0 Metrics: 1



Link connected to: another Router (point-to-point)

(Link ID) Neighboring Router ID: 10.1.1.1

(Link Data) Router Interface address: 10.1.1.2

Number of TOS metrics: 0

TOS 0 Metrics: 64



Link connected to: a Stub Network

(Link ID) Network/subnet number: 10.1.1.0

(Link Data) Network Mask: 255.255.255.0

Number of TOS metrics: 0

5. Link State Acknowledgment packet:
Link State Acknowledgment (LSAck) packets are OSPF packet Type 5. OSPF requires acknowledgment for the receipt of each LSA. Multiple LSAs can be acknowledged in a single LSAck packet.

Loopback interfaces in OSPF

OSPF treats Loopback interfaces as STUB NETWORKS and advertise them as HOST ROUTES (with mask /32) regardless of their configured/native mask. According to RFC 2328, Host routes are considered to be subnets whose mask is "all ones (0xffffffff)". In this state, the router's interface is looped back to the network in hardware or software. In this state, the interface is unavailable for regular data traffic. However, it is still available for testing like ICMP pings and BERT. For this reason, IP packets may still be addressed to an interface in Loopback state. Such interfaces are advertised in router-LSA as single host routes, whose destination IP address is the interface address.

A router with one loopback interface generates a router-LSA with Type-1 link (stub network).

Consider the following-

R1 router-

interface Loopback 0
ip address 1.1.1.1 255.0.0.0
ip ospf 100 area 0
!

Router R2's routing table shows that the Loopback 0 is advertised with /32 mask.

R2#show ip route ospf
1.0.0.0/32is subnetted, 1 subnets
O 1.1.1.1 [110/2] via 10.1.12.1, 00:00:13, FastEthernet0/0

R1#show ip ospf interface Loopback 0
Loopback0 is up, line protocol is up
Internet Address 1.1.1.1/8, Area 0
Process ID 100, Router ID 1.1.1.1, Network Type LOOPBACK, Cost: 1
Loopback interface is treated as a stub Host

To change this default behaviour, Cisco IOS lets it change to POINT-TO-POINT network type only. After the change, R2 will see the Loopback address with /8.

R1 router-

interface Loopback 0
ip address 1.1.1.1 255.0.0.0
ip ospf 100 area 0
ip ospf network-type point-to-point
!

Router R2's routing table shows that the Loopback 0 is advertised with /8 mask.

R2#show ip route ospf
O 1.0.0.0/8 [110/2] via 10.1.12.1, 00:02:08, FastEthernet0/0

R1#show ip ospf interface Loopback0
Loopback0 is up, line protocol is up
Internet Address 1.1.1.1/8, Area 0
Process ID 100, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost: 1
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
.....

Other options are a) to summarize at the ABR level and b) redistribute the connected interfaces with subnet keyword