Link state routing and OSPF · routing tables ©Rui Valadas, version 3.0, 20/10/2017 15 R1#sh ipv6 route IPv6 Routing Table - 7 entries Codes: C - Connected, L - Local, S - Static,

Link state routing and OSPF

Rui Valadas

Principles and technologies

• Many networking protocols are complex and have many details• You need to survive and be successful…

• It is essential for a networking engineer to separate what is fundamental from what it is not, the principles from the technological details, …

©Rui Valadas, version 3.0, 20/10/2017 2

Link state routing

• Each router builds and maintains a Link State Database (LSDB), containing the routing information…

• Topological information: what are the routers, the links between routers, and the costs assigned to links (i.e. what is the network map)?

• Addressing information: what are the addresses (IPv4 or IPv6) assigned to routers and links?

• Link information: what are the addresses required to transport packets in the link towards the next-hop router?


topological information

addressing information

link information

LSDB structure

Link state routing

• The LSDB is built in a distributed way: each router disseminates to all others its local view of the network

• What are the router’s neighbors?

• What is state and cost of the links with the router’s neighbors?

• What are the prefixes (PIv4 or IPv6) assigned to the router and to its links?

• What are the link addresses required to reach the router (at each link)?

• It is based on the LSDB that each router builds its forwarding table, e.g. using Dijkstra’s algorithm


Link state routing

• Three main aspects:

• How is the routing information represented at the LSDB?

• What are the mechanisms used to keep the LSDB updated and synchronized (i.e. consistent) at all nodes?

• How does the network representation and synchronization mechanisms scale to large networks? – not covered in this course


Link state routing

• Synchronization mechanisms• Hello protocol - detects the active neighbors of a router

• Reliable flooding procedure - disseminates the routing information originated by one router to all other routers

• Initial LSDB synchronization process - allows a fast update of the LSDB when a router joins the network


Hello protocol

reliable flooding

initial LSDB sync

LSDB synchronization mechanisms

Link state routing

• LSR technologies:• OSPF, IS-IS, NLSP, …

• LSR technologies addressed in this course:• OSPFv2 (IPv4) and OSPFv3 (IPv6)

• Main differences and similarities between OSPFv2 and OSPFv3• OSPFv2 mixes topological and addressing information

• In OSPFv2, link information is not explicitly included in the LSDB

• The synchronization mechanisms are the same in both technologies


The structure of an OSPF network


R4 R5

R2 (ABR) R3 (ABR)

R1

R6 (ABR)

R7

Area 1

Area 0

Area 2

R8 (ASBR)

R9 (ABR)

R10

Area 3

• An OSPF can be structured in multiple areas, organized hierarchically

in two-levels – Hierarchical OSPF

• In this course we only address single-area OSPF

Case study – OSPFv2


Case study – OSPFv2 configuration


R1(config)#int s0/0

R1(config-if)#ip address 222.222.10.1 255.255.255.0

R1(config-if)#encapsulation ppp

R1(config-if)#no shutdown

R3(config)#router ospf 1

R3(config-router)#router-id 3.3.3.3

R3(config-router)#network 222.222.20.0 0.0.0.255 area 0

R3(config-router)#network 222.222.30.0 0.0.0.255 area 0

Configuration of serial interface of R1

Configuration of OSPF at R3

First install slot NM-4T

Case study – IPv4 routing tables


O 222.222.50.0/24 [110/30] via 222.222.20.3, 00:00:31, FastEthernet0/0

C 222.222.20.0/24 is directly connected, FastEthernet0/0

C 222.222.10.0/24 is directly connected, Serial0/0






[110/74] via 222.222.20.1, 00:07:38, FastEthernet0/0




Forwarding table of R1

Forwarding table of R3

Default interface costs: Fast Ethernet = 10

Serial = 64

R1#show ip route

Case study – Changing interface costs

©Rui Valadas, version 3.0, 20/10/2017 12Forwarding table of R3, after changing cost of f0/1-R3 to 15

Default interface costs: Fast Ethernet = 10

Serial = 64














Forwarding table of R3, before changing cost of f0/1-R3

R3(config)#int f0/1

R3(config-if)#ip ospf cost 15

Case study – OSPFv3


Case study - OSPFv3 configuration


R2(config)#ipv6 unicast-routing

R2(config)#ipv6 router ospf 1

R2(config-rtr)#router-id 2.2.2.2

R2(config-rtr)#exit

R2(config)#int f0/0

R2(config-if)#ipv6 enable

R2(config-if)#ipv6 add 2001:db8:faca:1::2/64

R2(config-if)#ipv6 ospf 1 area 0

R2(config-if)#no shut

R2(config-if)#exit

R2(config)#int f0/1

R2(config-if)#ipv6 enable

R2(config-if)#ipv6 add 2001:db8:beca:1::2/64

R2(config-if)#ipv6 ospf 1 area 0

R2(config-if)#no shut

PC1(config)#int f0/0

PC1(config-if)#ipv6 address autoconfig

PC1(config-if)#no shut

PC1(config-if)#end

PC1#ping 2001:db8:beca:1:c009:1fff:fe68:0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 2001:DB8:BECA:1:C009:1FFF:FE68:0, timeout

is 2 seconds:

!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 28/48/84 ms

Ping from PC1 to PC2

Configuration of PC1 and R2

Case study: IPv6 routing tables


R1#sh ipv6 route

IPv6 Routing Table - 7 entries

Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP

U - Per-user Static route

I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary

O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2

ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2

O 2001:DB8:BECA:1::/64 [110/20]

via FE80::C006:1FFF:FE68:0, FastEthernet0/1

C 2001:DB8:CAFE:1::/64 [0/0]

via ::, FastEthernet0/0

L 2001:DB8:CAFE:1::1/128 [0/0]


C 2001:DB8:FACA:1::/64 [0/0]


L 2001:DB8:FACA:1::1/128 [0/0]


L FE80::/10 [0/0]

via ::, Null0

L FF00::/8 [0/0]

via ::, Null0

R2#sh ipv6 route

IPv6 Routing Table - 7 entries

Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP

U - Per-user Static route

I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary

O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2

ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2

C 2001:DB8:BECA:1::/64 [0/0]


L 2001:DB8:BECA:1::2/128 [0/0]


O 2001:DB8:CAFE:1::/64 [110/20]

via FE80::C004:5FF:FE2C:1, FastEthernet0/0

C 2001:DB8:FACA:1::/64 [0/0]


L 2001:DB8:FACA:1::2/128 [0/0]


L FE80::/10 [0/0]

via ::, Null0

L FF00::/8 [0/0]

via ::, Null0

Building the network map

• Which types of topological elements are considered in the network representation?

• Routers, point-to-point links, and shared links

• How are the topological elements identified?• Using identifiers for routers and links from different address spaces (to

start with)

• How is the network topology described (i.e. the connection between topological elements) described?

• Link State Advertisements (LSAs)




The real network… … and its graph representation

(this is what routers need to have!)

r1 r2

r3 r4

lp1

ls1 ls2

lp2

ls310

5

40 10

30

20

5

5

25

50

15

E1 link

PDA

Server

IP Router

Ethernet

switch

Ethernet

hub

PC

Portable

10

5

40 10

30 20

5

5

25

50

15



Two types of shared links: transit and stub

r1 r2

r3 r4

lp1

ls1 ls2

lp2

ls310

5

40 10

30

20

5

5

25

50

15Transit shared link

Stub shared link



Each router contributes with

its local view of the network,

which it disseminates to all

others using a flooding

mechanism

r1

lp1: 40

ls1: 5

ls2: 50

5

40

lp1

ls1 ls2

50

r1

What r1 knows...

r210

3020

lp1

ls2lp2

r2

lp1: 10

ls2: 30

lp2: 20

What r2 knows...

15r3

25

ls2ls1

r3

ls1: 25

ls2: 15

What r3 knows…

Link State Advertisement

(LSA)

What routers need to have…

r1 r2

r3 r4

lp1

ls1 ls2

lp2

ls310

5

40 10

30

20

5

5

25

50

15

What r4 knows…

r4

10

5

5

ls2lp2

ls3

r4

ls2: 5

lp2: 5

ls3: 10

Building the network map (step-by-step)


LSDB of r3, when alone in the world

r3

ls1 ls2

25 15

r3

ls1: 25

ls2: 15



LSDB of r3, after receiving LSA from r2

r2

lp1: 10

lp2: 20

ls2: 30

r2

r3

lp1

ls2

lp2

10

30

20

25 15

ls1

r3

ls1: 25

ls2: 15



LSDB of r3, after receiving LSAs from r2 and r4

r4

lp2: 5

ls2: 5

ls3: 10

r2

r3 r4

lp1

ls1 ls2

lp2

ls310

10

30

20

5

5

25 15

r2

lp1: 10

lp2: 20

ls2: 30

r3

ls1: 25

ls2: 15



LSDB of r3, after receiving LSAs from r2, r4, and r1. Done!

r1

lp1: 40

ls1: 5

ls2: 50

r1 r2

r3 r4

lp1

ls1 ls2

lp2

ls310

5

40 10

30

20

5

5

25

50

15

r4

lp2: 5

ls2: 5

ls3: 10

r2

lp1: 10

lp2: 20

ls2: 30

r3

ls1: 25

ls2: 15

Hello protocol

• Nodes and links may fail – a mechanism is needed to detect if links are operational

• Hello protocol: identify active neighbors on a link and detect possible failures on nodes or links

• Each node maintains an updated list with the identifiers of the routers currently active on the link

• Operation:• Each router sends an Hello message periodically, listing all its active

neighbors; every HelloInterval in OSPF (default = 10 seconds)

• When a router ceases to receive Hello from a neighbor after a period of time (RouterDeadInterval in OSPF, default = 40 seconds) it deletes that neighbor from the list of active routers


Hello protocol


r1 r2

r3

r1

r2

r3

r1

r2

r3

r1

r2

r3

List of Active Routers(on link)

HELLO

Routers send Hello messages periodically

(every 10 seconds) and maintain List of

Active Routers (on each Link)

Hello protocol


r1 r2

r3

r1

r2

r3

r1

r2

r3


HELLO

Routers r2 fails and ceases sending

Hello messages

Hello protocol


r1 r2

r3

r1

r3

r1

r3


HELLO

After a while (40 seconds), r1 and r3

detect the failure, and remove r2 from

List of Active Routers

Hello protocol

• In broadcast subnets Hello packets are sent to the multicast address AllSPFRouters (224.0.0.5 in IPv4 and ff02::5 in IPv6)


OSPF packet header

Network Mask

HelloInterval Options Router Priority

RouterDeadInterval

Designated Router

Backup Designated Router

Neighbor

8 16 24 320

Case study – OSPFv2 Hello protocol


Hello packets sent on

222.222.30.0/24

Case study – OSPFv2 Hello protocol


Hello packet sent by R4

Case study: OSPFv3 Hello protocol


Flooding

• How can messages be disseminated to all routers?

• Uncontrolled flooding rules:• Routers retransmit message on all interfaces except the one where the

message was received

• Message is delivered to all destinations… but the flooding of messages never stops

• Unless network is a tree


Flooding


1 2

3 4

1 2

3 4

1 2

3 4

1 2

3 4

From node 3 to all others: uncontrolled flooding

RULE: receive on one interface,

retransmit on all others

Flooding


Controlled flooding, broadcast of first message.

Link 4→2 much slower than others

1 2

3 4

1 2

3 4

ID=3,SN=1

ID=3,SN=1

1 2

3 4

ID=3,SN=1

ID=3,SN=1

ID=3,SN=1

1 2

3 4

ID=3,SN=1 ID=3,SN=1

ID=3,SN=1

(a) (b)

(c) (d)

ID=3,SN=1 ID=3,SN=1

ID=3,SN=1 ID=3,SN=1

Flooding

©Rui Valadas, version 3.0, 20/10/2017 35Controlled flooding, broadcast of second message

Link 4→2 much slower than others

1 2

3 4

1 2

3 4

ID=3,SN=1

ID=3,SN=1

1 2

3 4

ID=3,SN=1

1 2

3 4

ID=3,SN=2

ID=3,SN=2

ID=3,SN=2

ID=3,SN=1

ID=3,SN=2

ID=3,SN=1

ID=3,SN=2

ID=3,SN=1

ID=3,SN=2

ID=3,SN=1

ID=3,SN=2

ID=3,SN=1

ID=3,SN=2

(a) (b)

(c) (d)

ID=3,SN=1ID=3,SN=1 ID=3,SN=1

ID=3,SN=1ID=3,SN=1 ID=3,SN=1

ID=3,SN=1 ID=3,SN=1

ID=3,SN=2 ID=3,SN=2

ID=3,SN=2ID=3,SN=2

Flooding

• Controlled flooding rules:• Origin routers assign each message to be broadcasted (i) an identifier (ID)

of the router and (ii) a number that is unique for every new message sent, called sequence number (SN).

• When a message is received at a router, the router verifies if the received pair (ID,SN) is already stored in memory. If yes, the message is discarded; if not the pair is stored, and the message is flooded to the neighboring routers (except the one that sent the message).

• The flooding of messages stops at some point. Great!

• OSPF uses controlled flooding, enhanced with a reliabilityprocedure; SN is called LS Sequence Number; only highest SN needs to be stored


Configuration of router and link identifiers

• Router and link identifiers are configured at routers (links are not layer-3 active equipment)

• Router identifiers must be explicitly configured at routers - static identifiers

• Link identifiers can be based on the identifiers of routers attached to the link, which become known through the Hello protocol –dynamic identifiers

• To avoid ambiguity, links must be flagged as point-to-point or shared


r1 r2

p|1

p|2


• A point-to-point link is dynamically identified through the identifier of the router on the other side of the link

• Parallel links require a local tag to be uniquely identified (e.g. the interface number)


r1 r2

i1

i5

i3

i7

p|1|7

p|2|5

p|1|3

p|2|1

neighbor

identifier interface

identifierlink

type


• A shared link is dynamically identified through the identifier of a router selected among the routers attached to the link –Designated Router (DR)


r2

r3 r4

r1

Designated Router (DR)

transit shared link s|2


• No election needed for stub shared links, only for transit shared links

• Since a router can be the DR at more than one link, local tag (e.g. interface number) is needed to uniquely identify link


r5s|5|1

s|5|2

s|5|3

i1

i3

i2

DR

identifierDR interface

identifier

DR link

type

Reaction to network changes

• Types of network changes• Changes in interface costs

• Additions of routers and links

• Removals of routers and links (e.g. failures)

• Network map must be updated as soon as possible when network changes


Reaction to router failures


Network map before failure

r1

r2

r3

r4

r5

lp2: 10

r1

ls1: 50

r3

ls1: 15

r5

ls1: 30

r2

lp1: 10

lp2: 5

lp3: 25

r4

ls1: 5lp1: 40 lp3: 15

15

r2

r3 r4

40 10

30

5

50

r1

r5

15

25

10

5

DRls1=s|2

lp1

lp2

lp3

r1

ls2: 50

r3

ls2: 15

r5

ls1: 30

r2

lp1: 10

lp2: 5

lp3: 25

r4

ls2: 5 lp3: 15



r1

r2

r3

r4

r5

Failure of DR – DR becomes isolated in the network map; Ok!Could not be deleted

because r2 failed

15

r2

r3 r4

40 10

30

5

50

r1

r5

15

25

10

5

old DRls1=s|2

lp1

lp2

lp3

ls2=s|3

new DR

ls1: 30

lp2: 5lp1: 40

r1

ls1: 50

r3

ls1: 15

r2

lp3: 25

r4

ls1: 5

lp3: 15

r5

lp2: 10



Failure of non-DR – r1 remains reachable

in the network map; wrong!

r1

r2

r3

r4

r5

Could not be deleted

because r1 failed

15

r2

r3 r4

40 10

30

5

50

r1

r5

15

25

10

5

DRls1=s|2

lp1

lp2

lp3


• To cope with router failures two types of LSAs are needed to describe the network map

• Router-LSAs – describe routers and their attached links; originated by described router

• Network-LSAs – describe transit shared links and their attached routers; originated by DR of described link


r1 r2

r3 r4

ls1 ls2

ls310

5

40 10

30

20

5

5

25

50

15

lp1

lp2

ls3: 10

ls2: 50

r1

lp1: 40

ls1: 5

r2

lp1: 10

lp2: 20

Router-LSAs

r3

ls1: 25

r4

lp2: 5

ls2: 5ls2: 15

ls2: 30

r1

ls2

r2

r3

Network-LSAs

ls1

r1

r3

r4



Failure of non-DR – r1 is isolated in the network map; Ok!

r1

r2

r3

r4

r5

Before failure

After failure

15

r2

r3 r4

40 10

30

5

50

r1

r5

15

25

10

5

DRls1=s|2

lp1

lp2

lp3

r4lp3: 15

lp1: 40

ls1: 30r1

ls1: 50

r2

lp1: 10

lp2: 5

r3

ls1: 15

lp3: 25

r4

ls1: 5

r5

lp2: 10

r1

ls1

r2

r3

Router-LSAs Network-LSAs

lp3: 15

lp1: 40

ls1: 30r1

ls1: 50

r2

lp2: 5

r3

ls1: 15

lp3: 25

r4

ls1: 5

r5

lp2: 10

r2

ls1

r3

r4

Router-LSAs Network-LSAs

Separation of topological and addressing information

• Should router and link identifiers be IP addresses?

• Good reasons for separation• Identifiers of routers and links need only be unique inside routing domain;

(public) routable prefixes must identify unambiguously all Internet hosts

• Routable prefixes may change more frequently than the network topology

• OSPFv3 does it! OSPFv2 doesn’t do it!

• Intra-Area-Prefix-LSA (IAP-LSA) – OSPFv3• Describes address prefix assigned to some network element (router, point-

to-point link, or shared link)

• Must have pointer to network element

• Simplification: stub shared links can be removed from the network map, if a cost field is added to IAP-LSAs




Router Own router Router ID

Point-to-point link Each link end router Link ID

Transit shared link Link DR Link ID

Stub shared link Link end router Router ID

Addresses assigned to...IAP-LSA

originator(s)Pointer to

topological element

• What router originates an IAP-LSA?

• How an IAP-LSA points to the topological element (router or link) to which

the prefix was assigned?



r1

ls2

r2

r3

Network-LSAs

ls1

r1

r3

r4

• Stub shared links not described by topological LSAs (Router-LSAs and Network-LSAs)

• Address prefixes described by Inter-Area-Prefix-LSAs (IAP-LSAs) pointing to topological

element (router or link) using topological identifier

• Prefixes assigned to point-to-point links advertised by both link end routers

r1 r2

r3 r4

ls1

10

5

40 10

30

20

5

5

25

50

15

lp1 ap2

lp2

ls2 ap1

ls3 ap3r3 ap4

ls2: 50

r1

lp1: 40

ls1: 5

r2

lp1: 10

lp2: 20

Router-LSAs

r3

ls1: 25

r4

lp2: 5

ls2: 5ls2: 15

ls2: 30

ap1

ls2: 0

ap2

lp1: 10

Inter-Area-Prefix-LSAs

ap2

lp1: 40

ap3

r4: 10

ap4

r3: 0

Stub shared link

no longer here

useless cost

information

Link information

• Before forwarding packet, router needs to find link-layer address required to transport packet at the link, from itself to the next-hop router (if the next-hop is a router)

• Link address – address that can be resolvable into a layer-2 address, at which the next-hop can be reached within the link (e.g. link-local address of IPv6)

• Link-LSA – OSPFv3• Includes advertised link address, RID of advertising router and link ID

• OSPFv2 has no specific LSA for this type of information


LSDB with topological, addressing and link information


la8

r1, ls1

Link-LSAs

(link ls1)

la2

r3, ls1

la1

r2, ls2

Link-LSAs

(link ls2)

la2

r3, ls2

la3

r4, ls2

la6

r1, ls2

This is the LSDB of router r3. Other routers

have different sets of Link-LSAs.

r1 r2

r3 r4

10

5

40 10

30 20

5525

50

15

la2

la2

la8

la3

la1la6

ls1

lp1 ap2

lp2

ls2 ap1

ls3 ap3

la1

la1 la2

la2

r3 ap4

r1

ls2

r2

r3

Network-LSAs

ls1

r1

r3

r4

ls2: 50

r1

lp1: 40

ls1: 5

r2

lp1: 10

lp2: 20

Router-LSAs

r3

ls1: 25

r4

lp2: 5

ls2: 5ls2: 15

ls2: 30

ap1

ls2: 0

ap2

lp1: 10

Inter-Area-Prefix-LSAs

ap2

lp1: 40

ap3

r4: 10

ap4

r3: 0

OSPF LSDB

• Contains the LSAs that describe the topological, addressing, and link information

• Different in OSPFv2 and OSPFv3

• Several LSA types:• Router-LSAs and Network-LSAs describe the topological information

(network map) in IPv6 and both the topological and addressing information in IPv4

• Intra-Area-Prefix-LSAs describe the addressing information internal to the domain (OSPFv3 only)

• Link-LSAs describe the link information (OSPFv3 only)

• … and a few more

• All LSAs have a common header


222.222.20.0/24

R1 R2

222.222.30.0/24

R3 R4

10 10

10 10

20

10

1020

20

i1i2

i1 i2 i1 i2

i1

i2i3

222.222.10.0/24

222.222.40.0/24

222.222.50.0/24

i3 30222.222.20.3

222.222.20.1

222.222.30.3

222.222.30.2

222.222.30.4

222.222.10.1 222.222.10.2

222.222.40.2

222.222.40.4

RID = 1.1.1.1 RID = 2.2.2.2

RID = 3.3.3.3 RID = 4.4.4.4

Designated Router of

222.222.20.0/24


222.222.30.0/24

OSPFv2 Link State Database


1.1.1.1

2.2.2.2, 222.222.10.1, c=10

222.222.20.1, 222.222.20.1, c=10

2.2.2.2

1.1.1.1, 222.222.10.2, c=20

222.222.30.3, 222.222.30.2, c=20

4.4.4.4, 222.222.40.2, c=10

3.3.3.3

222.222.20.1, 222.222.20.3, c=10

222.222.30.3, 222.222.30.3, c=10

4.4.4.4

2.2.2.2, 222.222.40.4, c=10

222.222.30.3, 222.222.30.4, c=20

222.222.50.0/24, c=30

222.222.20.1/24

1.1.1.1

3.3.3.3

222.222.30.3/24

2.2.2.2

3.3.3.3

4.4.4.4

Router-LSAs(describes one router and its outgoing links)

Network-LSAs(describes one transit broadcast

subnet and its attached routers)

Broadcast subnets identified by

IP address of DR

Routers identified by RID

Interfaces to stub subnets identified by subnet address

Interfaces to p2p subnets identified by RID of

neighbor and IP add of interface

Interfaces to transit subnets identified by IP

add of DR and IP add of interface

Advertising Routers


sn1

R1 R2

sn2

R3 R4

10 10

10 10

20

10

1020

20

i1i2

i1 i2 i1 i2

i1

i2i3

The LSDB is the same in all routers, but

each LSA has a responsible: the Advertising

Router

Only the AR can create, update, delete, and

flood its LSAs

DRDR

Router-LSA of R1

Adv Router = R1

Router-LSA of R2

Adv Router = R2

Router-LSA of R3

Adv Router = R3

Router-LSA of R4

Adv Router = R4

Network-LSA of sn1

Adv Router = R1

Network-LSA of sn2

Adv Router = R2

Link State DataBase

Designated and Backup Designated Routers

• Every broadcast subnet has a Designated Router (DR) and Backup Designated Router (BDR)

• DR plays special role in flooding process and identifies subnet in the LSDB

• BDR replaces the DR in case of failure


R2R1

multiple access link

R3 R4

Designated Router


OSPF link types

• More than just point-to-point and shared links

• 5 link types• Point-to-point

• Broadcast (the same as broadcast transit shared links)

• Point-to-multipoint

• Non-Broadcast Multi-Access (NBMA)

• Virtual

• Point-to-point and broadcast are the most important


How are routers and links identified?

• Routers• RID (Router ID), uses IPv4 address (32 bits) in both OSPFv2 and OSPFv3

• Point-to-point links• OSPFv2 – RID of neighbor concatenated with IPv4 address of interface

attaching the link

• OSPFv3 – RID of neighbor concatenated with interface ID of interface attaching the link

• Shared links• OSPFv2 – IPv4 address of DR interface attaching the link

• OSPFv3 – RID of DR concatenated with interface ID of DR interface attaching the link


How are routers and links identified?


R1

RID=3.3.3.3

IP address = 8.8.3.1 (OSPFv2)

Interface ID = 7 (OSPFv3)

IP address = 8.8.5.9 (OSPFv2)

Interface ID = 3 (OSPFv3)

Shared link identified by:

- 8.8.5.9 (OSPFv2)

- 3.3.3.3||3 (OSPFv3)

Shared link identified by:

- 8.8.3.1 (OSPFv2)

- 3.3.3.3||7 (OSPFv3)

Shared link identifiers in OSPFv2 and OSPFv3

LSA header format

• Advertising Router• RID of router responsible for creating, updating, deleting and flooding the

LSA

• LS Type• Type of LSA: 1 for Router-LSA, 2 for Network-LSA, 3 for Summary-LSA, …

• LS ID• Distinguishes among LSAs of the same type originated by the same router

• Interpretation depends on LS Type

• LSAs are uniquely identified by 3-tuple (Advertising Router, LS Type, and LS ID), called the LSA Identifier


LS Age Options

LS ID

Advertising Router

LS Sequence Number

LS Type

LS Checksum Length

0 8 16 24 32

LSA header format

• LS Sequence Number• Distinguishes among different LSA instances

• Starts at 0x80000001 and stops at 0x7FFFFFFF (uses 32-bit signed integer, MSB=1 means negative number; MSB=0 means positive)

• LS Identifier and LS Sequence Number are used to control the flooding process

• LS Age• Number of seconds since LSA instance was created

• LSA instances have a lifetime, called MaxAge (1 hour)

• Advertising Router floods a new LSA instance (LS Sequence Number incremented by one and LS Age = 0) every LSRefreshTime (30 minutes)


LS Age Options

LS ID

Advertising Router

LS Sequence Number

LS Type

LS Checksum Length

0 8 16 24 32

Router-LSAs and Network-LSAs


LS Age

Options

Link State ID

Advertising Router

LS Sequence Number

LS Type

LS Checksum

Length

2

1

1

4

4

4

2

2

LSA header (OSPFv2)

Number of Links

Link ID

Link Data

Type

# TOS

Metric

0 0 0 0 V B E 0 1

2

4

4

1

2

2

Router-LSA (OSPFv2)

Network Mask

Attached Router

4

4

Network-LSA (OSPFv2)

Type

Interface ID

Neighbor Interface ID

Neighbor Router ID

Metric

LS Age

Link State ID

Advertising Router

LS Sequence Number

LS Type

LS Checksum

Length

2

2

4

4

4

2

2

Flags 1

2

4

4

4 Attached Router 4

LSA header (OSPFv3) Router-LSA (OSPFv3) Network-LSA (OSPFv3)

Options 3

1

Options 3

Router-LSAs

• Describes a router and its outgoing interfaces

• Main fields of the interface descriptor• OSPFv2 – Type, Link ID, Link Data, Metric

• OSPFv3 – Type, Interface ID, Neighbor Interface ID, Neighbor Router ID, Metric

• 4 types of interface descriptors• Type 1 – Point-to-point link

• Type 2 – Link to transit network (called transit shared links in OSPFv3)

• Type 3 – Link to stub network (not present in OSPFv3)

• Type 4 – Virtual link

• More than one descriptor may be needed to completely characterize an interface


Router-LSAs

• Interface to point-to-point link (OSPFv2)• Type 1: Link ID = neighbor RID, Link Data =

interface IPv4 address, Metric = interface cost

• Type 3: Link ID = subnet IPv4 address, Link Data = subnet mask, Metric = interface cost

• Interface to point-to-point link (OSPFv3)• Type 1: Interface ID = local interface identifier,

Neighbor Interface ID = neighbor’s interface identifier, Neighbor Router ID = RID of neighbor, Metric = interface cost

• No type 3 descriptor since addressing information is separated from topological information


Number of Links

Link ID

Link Data

Type

# TOS

Metric

0 0 0 0 V B E 0 1

2

4

4

1

2

2

Router-LSA (OSPFv2)

Type

Interface ID


Neighbor Router ID

Metric

Flags 1

2

4

4

4

Router-LSA (OSPFv3)

Options 3

1

Repeated information,

too complex

Router-LSAs

• Interface to transit shared link (OSPFv2)• Type 2: Link ID = IPv4 address of DR interface

attached to link, Link Data = interface IPv4 address, Metric = interface cost

• Interface to transit shared link (OSPFv3)• Type 2: Interface ID = local interface identifier,

Neighbor Interface ID = DR’s interface identifier, Neighbor Router ID = RID of DR, Metric = interface cost


Number of Links

Link ID

Link Data

Type

# TOS

Metric

0 0 0 0 V B E 0 1

2

4

4

1

2

2

Router-LSA (OSPFv2)

Type

Interface ID


Neighbor Router ID

Metric

Flags 1

2

4

4

4

Router-LSA (OSPFv3)

Options 3

1

Router-LSAs

• Interface to stub shared link (OSPFv2)• No topological representation

• Type 3: Link ID = subnet IPv4 address, Link Data = subnet mask, Metric = interface cost

• No such interface in OSPFv3 – stub shared links are not represented topologically, and addressing information is separated from topological information


Number of Links

Link ID

Link Data

Type

# TOS

Metric

0 0 0 0 V B E 0 1

2

4

4

1

2

2

Router-LSA (OSPFv2)

Type

Interface ID


Neighbor Router ID

Metric

Flags 1

2

4

4

4

Router-LSA (OSPFv3)

Options 3

1

Router-LSAs

• IPv4 address assigned to router (OSPFv2)• Type 3: Link ID = IPv4 address, Link Data = all

ones subnet mask, Metric = 0

• No such interface in OSPFv3 – addressing information is separated from topological information


Number of Links

Link ID

Link Data

Type

# TOS

Metric

0 0 0 0 V B E 0 1

2

4

4

1

2

2

Router-LSA (OSPFv2)

Type

Interface ID


Neighbor Router ID

Metric

Flags 1

2

4

4

4

Router-LSA (OSPFv3)

Options 3

1

Network-LSAs

• Describes broadcast shared links and attached routers

• Attached router (OSPFv2 and OSPFv3) = RID of router attached to link

• Network mask in OSPFv2 completes the addressing information of type 2 interface descriptors


Network Mask

Attached Router

4

4


Attached Router 4


Options 3

Case study – Analyzing the OSPFv2 LSDB


Link State ID ADV Router Age Seq#

1.1.1.1 1.1.1.1 75 0x80000003

2.2.2.2 2.2.2.2 73 0x80000003

3.3.3.3 3.3.3.3 71 0x80000004

4.4.4.4 4.4.4.4 74 0x80000003

Link State ID ADV Router Age Seq#

222.222.20.3 3.3.3.3 76 0x80000001

222.222.30.4 4.4.4.4 74 0x80000001

Router Link States (Area 0)

Net Link States (Area 0)

R1#show ip ospf database

LS age: 1008

Options: (No TOS-capability, DC)

LS Type: Router Links

Link State ID: 4.4.4.4

Advertising Router: 4.4.4.4

LS Seq Number: 80000003

Checksum: 0xA91E

Length: 72

Number of Links: 4

Link connected to: a Stub Network

(Link ID) Network/subnet number: 222.222.50.0

(Link Data) Network Mask: 255.255.255.0

Number of TOS metrics: 0

TOS 0 Metrics: 10

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

(Link ID) Neighboring Router ID: 2.2.2.2

(Link Data) Router Interface address: 222.222.40.4


TOS 0 Metrics: 64

Link connected to: a Stub Network

(Link ID) Network/subnet number: 222.222.40.0

(Link Data) Network Mask: 255.255.255.0


TOS 0 Metrics: 64

Link connected to: a Transit Network

(Link ID) Designated Router address: 222.222.30.4

(Link Data) Router Interface address: 222.222.30.4


TOS 0 Metrics: 10

Case study –Analyzing the LSDB


Router-LSA of R4 (4.4.4.4)

R1#show ip ospf database router 4.4.4.4

How subnets assigned to

p2p links are advertised

Subnet mask for this

subnet is in Network-LSA

Routing Bit Set on this LSA

LS age: 221


LS Type: Network Links

Link State ID: 222.222.20.3 (address of Designated Router)



Checksum: 0x1D2B

Length: 32

Network Mask: /24

Attached Router: 3.3.3.3



LS age: 268



Link State ID: 222.222.30.4 (address of Designated Router)



Checksum: 0xA977

Length: 36

Network Mask: /24




Case study –Analyzing the LSDB


Network-LSAs

R1#show ip ospf database network

Inter-Area-Prefix-LSA (OSPFv3 only)


LS Age

Link State ID

Advertising Router

LS Sequence Number

LS Type

LS Checksum

Length

2

2

4

4

4

2

2

LSA header

Number of Prefixes 2

Intra-Area-Prefix-LSA

Referenced LS Type 2

Referenced Link State ID 4

Referenced Advertising Router 4

Prefix Length 1

Prefix Options 1

Metric 2

Address Prefix v

Inter-Area-Prefix-LSA (OSPFv3 only)


Referenced

LS Type = 0x2001

Referenced

Link State ID

Referenced

Advertising Router

Link State ID

Advertising Router

......

Intra-Area-Prefix-LSA Router-LSA

Referenced

LS Type = 0x2002

Referenced

Link State ID

Referenced

Advertising Router

Link State ID

Advertising Router

......

Intra-Area-Prefix-LSA Network-LSA

LS Type = 2

LS Type = 1

How does IAP-LSAs refer to Router-LSAs and Network-LSAs?

Link-LSA (OSPFv3 only)


LS Age

Link State ID

Advertising Router

LS Sequence Number

LS Type

LS Checksum

Length

2

2

4

4

4

2

2

LSA header

Router Priority 1

Options 3

Link-Local Interface Address 16

Number of Prefixes 4

Prefix Length 1

Prefix Options 1

Address Prefix v

Link-LSA

In OSPFv2, link addresses are provided through

Router-LSAs (Link Data field)

Case study: OSPFv3 LSDB


R2#show ipv6 ospf database

OSPFv3 Router with ID (2.2.2.2) (Process ID 1)


ADV Router Age Seq# Fragment ID Link count Bits

1.1.1.1 944 0x80000006 0 1 None

2.2.2.2 823 0x80000005 0 1 None


ADV Router Age Seq# Link ID Rtr count

1.1.1.1 944 0x80000002 5 2

Link (Type-8) Link States (Area 0)

ADV Router Age Seq# Link ID Interface

2.2.2.2 823 0x80000002 5 Fa0/1

1.1.1.1 944 0x80000002 5 Fa0/0

2.2.2.2 823 0x80000002 4 Fa0/0

Intra Area Prefix Link States (Area 0)

ADV Router Age Seq# Link ID Ref-lstype Ref-LSID

1.1.1.1 944 0x80000004 0 0x2001 0

1.1.1.1 946 0x80000002 5120 0x2002 5

2.2.2.2 825 0x80000002 0 0x2001 0



R2#show ipv6 ospf database router



LS age: 728

Options: (V6-Bit E-Bit R-bit DC-Bit)


Link State ID: 0



Checksum: 0x4A93

Length: 40

Number of Links: 1


Link Metric: 10

Local Interface ID: 5

Neighbor (DR) Interface ID: 5

Neighbor (DR) Router ID: 1.1.1.1

LS age: 621



Link State ID: 0



Checksum: 0x20BB

Length: 40

Number of Links: 1


Link Metric: 10

Local Interface ID: 4

Neighbor (DR) Interface ID: 5

Neighbor (DR) Router ID: 1.1.1.1

• Stub networks not listed here

• On transit networks, Neighbor Interface ID and

Neighbor Router ID are those of the DR



R2#show ipv6 ospf database network



LS age: 2017



Link State ID: 5 (Interface ID of Designated Router)



Checksum: 0x25CD

Length: 32





R2#show ipv6 ospf database prefix


Intra Area Prefix Link States (Area 0)


LS age: 109

LS Type: Intra-Area-Prefix-LSA

Link State ID: 0



Checksum: 0x45B9

Length: 44

Referenced LSA Type: 2001

Referenced Link State ID: 0

Referenced Advertising Router: 1.1.1.1

Number of Prefixes: 1

Prefix Address: 2001:DB8:CAFE:1::

Prefix Length: 64, Options: None, Metric: 10


LS age: 109


Link State ID: 5120



Checksum: 0x5F95

Length: 44





Prefix Address: 2001:DB8:FACA:1::



LS age: 4


Link State ID: 0



Checksum: 0x63D5

Length: 44





Prefix Address: 2001:DB8:BECA:1::


refers to router-LSA

refers to network-LSA

refers to router-LSA

• All 3 prefixes listed here



R2#show ipv6 ospf database link


Link (Type-8) Link States (Area 0)

LS age: 390


LS Type: Link-LSA (Interface: FastEthernet0/1)

Link State ID: 5 (Interface ID)



Checksum: 0xFE7B

Length: 56

Router Priority: 1

Link Local Address: FE80::C006:1FFF:FE68:1


Prefix Address: 2001:DB8:BECA:1::

Prefix Length: 64, Options: None

LS age: 496






Checksum: 0xC8D1

Length: 56

Router Priority: 1

Link Local Address: FE80::C004:5FF:FE2C:1




LS age: 392






Checksum: 0x2F11

Length: 56

Router Priority: 1

Link Local Address: FE80::C006:1FFF:FE68:0




• Link-local addresses, in particular, those required

to communicate with R1

From the LSDB to the forwarding table


Calculation of shortest path from a node to an address

prefix (ap):

1st step: Build graph from network map (from Router-LSAs and

Network-LSAs) - e.g. with all network elements (routers and links)

as nodes of the graph

2nd step: Determine shortest paths from source node of graph

(which represents the source router) to all other nodes, using

Dijkstra’s algorithm

3rd step: Associate prefixes with nodes of graph to determine the

shortest path towards each prefix; determine link addresses (if

needed)



40 0 100

0

15

0

n45

n1 n5 n2

n7 n8 n6

n3 n4

20

3050

5

0

0

25

0

0

0

0

5

n1 r1n2 r2n3 r3n4 r4

n5 lp1n6 lp2

n7 ls1n8 ls2

Routers Point-to-point links

Shared linksBuild graph of network topology, from Router-

LSAs and Network-LSAs, and run Dijkstra’s

algorithm to determine shortest paths

r1 r2

r3 r4

10

5

40 10

30 20

5525

50

15

la2

la2

la8

la3

la1la6

ls1

lp1 ap2

lp2

ls2 ap1

ls3 ap3

la1

la1 la2

la2

r3 ap4

i3

i1i2

i1

i2i3i1

i2

i3

i1i2



Associate nodes with prefixes, from IAP-

LSAs (OSPFv3) or from Router-LSAs and

Network-LSAs (OSPFv2)

r1 r2

r3 r4

10

5

40 10

30 20

5525

50

15

la2

la2

la8

la3

la1la6

ls1

lp1 ap2

lp2

ls2 ap1

ls3 ap3

la1

la1 la2

la2

r3 ap4

i3

i1i2

i1

i2i3i1

i2

i3

i1i2

ap1 n8 ap2 n5 ap3 n4, cost 10 ap4 n3

Prefixes

40 0 100

0

15

0

n45

n1 n5 n2

n7 n8 n6

n3 n4

20

3050

5

0

0

25

0

0

0

0

5

ap4

ap1

ap2

ap3

cost:10



Build forwarding table for relevant prefixes. Next-hop addresses

are obtained from Link-LSAs (OSPFv3) or Router-LSAs (OSPFv2).

dest

ap1

ap2

nh

dc

cost

-

Router r3

int

i1

ap3 la3 25i1

la1 25i1

ap4 --local

dest

ap1

ap2

nh

dc

dc

cost

-

-

Router r1

int

i2

i3

ap3 la2 30i1

ap4 5i1la2

dest

ap1

ap2

nh

dc

la2

cost

-

15

Router r4

int

i2

i1

ap3 dc -i3

la1 15i2

ap4 5i2la2

dest

ap1

ap2

nh

dc

dc

cost

-

-

Router r2

int

i2

i1

ap3 la1 30i3

ap4 15i1la1

r1 r2

r3 r4

10

5

40 10

30 20

5525

50

15

la2

la2

la8

la3

la1la6

ls1

lp1 ap2

lp2

ls2 ap1

ls3 ap3

la1

la1 la2

la2

r3 ap4

i3

i1i2

i1

i2i3i1

i2

i3

i1i2

Management of LSAs

• Every LSA has an Advertising Router• The single responsible for creating, updating, deleting and flooding it

• Every LSA instance has an age (LS Age) and a lifetime• Lifetime is 1 hour• LSA is deleted from the LSDB if its LS Age reaches the lifetime

• Every LSA instance has a sequence number• Starts at 0x80000001 and stops at 0x7FFFFFFF (uses 32-bit signed integer, MSB=1

means negative number; MSB=0 means positive)

• A new LSA instance is created and flooded every 30 minutes or when the Advertising Router senses a change in its link states• A new LSA instance has LS Age = 0 and the LS Sequence Number incremented

by one

• The Advertising Router can delete one of its LSAs using the premature aging mechanism• Broadcast the LSA instance with an LS age = 3600 seconds


Creating LSAs and LSA instances

• Each LSA has a responsible: the Advertising Router (AR)

• The AR creates the LSA first, and then creates new LSA instances (LS Sequence Number incremented by one and LS Age = 0) to update the LSA


Router-LSA

Advertising Router = R1

LS SN = 0x80000001

LS Age = 0

Router-LSA


LS SN = 0x80000002

LS Age = 0

Router-LSA


LS SN = 0x80000003

LS Age = 0

New LSA created New LSA instance New LSA instance

OSPF packets


Interface MTU

DD Sequence Number

LSA Headers

M

SMI00000Options

8 16 24 320

OSPF packet header

OSPF packet header

Network Mask


RouterDeadInterval

Designated Router


Neighbor

8 16 24 320

Version # Type

Router ID

Area ID

Packet length

Checksum AuType

Authentication

Authentication

8 16 24 320

8 16 24 320

OSPF packet header

LS Type

LS ID

Advertising Router

LSA headers

8 16 24 320

OSPF packet header

# LSAs

LSA headers

8 16 24 320

OSPF packet header

HelloDatabase Description

LS Request

LS Update

LS Acknowledgement

OSPF Packet Header

OSPF packets are encapsulated directly over IP (protocol number = 89)

OSPFv2 multicasts

• OSPF uses two multicast addresses: AllSPFRouters (224.0.0.5) and AllDRouters (224.0.0.6).

• OSPF IP multicast packets are destined for the subnet of the originating router only. Thus, they are sent with TTL=1.

• On Ethernet networks IP multicast addresses map to Ethernet multicast addresses in this way:• the first 24 bits of the Ethernet multicast address (from bit 48 to bit 25)

are 0×01005e;

• bit 24 is 0;

• bit 23 to bit 1 are the last 23 bits of the IP multicast address.

• For example, IP packets addressed to 222.0.0.5 will be encapsulated in Ethernet packets addressed to 0×01005e000005.


OSPF flooding

• The process used for distribution of the LSAs over the whole OSPF network

• Flooding is controlled by the LSA identifier and LSA freshness triplets• LSA identifier = (Advertising Router, LS Type, LS ID)

• LSA freshness = (LS Sequence Number, LS Age, LS Checksum)

• If an LSA arrives at router and is a new LSA or a fresher instance of an already existing LSA it is installed at the LSDB and transmitted on all interfaces except the receiving one; otherwise it is not transmitted

• A new LSA instance replaces and older one at the LSDB, since it contains fresher information


OSPF flooding

• LSAs are flooded encapsulated in LS Update packets

• Reliable flooding: each router is required to acknowledge the reception of an LSA to the neighbor that sent it, using a LS Acknowledgement packet


OSPF flooding – reliable flooding


1 2

3 4

20

1020 525 30

15

40

ID=2,SN=1

ID=2,SN=1

1 2

3 4

20

1020 525 30

15

40

ID=2,SN=1

ID=2,SN=1ID=2,SN=1

1 2

3 4

20

1020 525 30

15

40

ID=2,SN=1

ID=2,SN=1ID=2,SN=1

1 2

3 4

20

1020 525 30

15

40

ID=2,SN=1

ID=2,SN=1ID=2,SN=1

ACK

ACKACK

ACK

ACK

ACK

ACK

OSPF flooding - in broadcast subnets

• In broadcast subnets, flooding is via the DR

• DR and BDR transmit on AllSPFRouters (224.0.0.5) address; all other routers transmit on AllDRouters (224.0.0.6) address

• In principle, an LSA broadcasted on a subnet must be acknowledged by all other routers… but there are several special cases




DR BDR

Update

DR BDR

UpdateallDRouters(224.0.0.6)

Router (not DR nor BDR) receives Update

packet to be flooded on broadcast subnet

Sends to DR and BDR using multicast address

allDRouters (224.0.0.6)



DR BDR DR BDRUpdateallSPFRouters(224.0.0.5)

ACKallDRouters(224.0.0.6)

ACKallSPFRouters(224.0.0.5)

DR sends to all routers using multicast address

allSPFRouters (224.0.0.5)

Each router sends ACK packet to the DR

(except the initial router)



DR BDR

Ack

AllRouters

2Ack

AllDesignated

2

Ack

AllDesignated

Update

AllRouters

1

2

Update

DR BDRUpdate

Update

AllRouters

1Ack

AllDesignated

2

Ack

AllDesignated

Ack

AllRouters

2

2

Case study – Analyzing the flooding procedure


EXPERIMENT: Change cost of s0/0-R2 to 100.

Observe LS Update and LS Acknowledge

packets exchanged at 222.222.30.0/34. DR is

R2 and BDR is R4.

Both DR and BDR multicast same LSA. R3 acknowledges to AllDRouters

multicast address (224.0.0.6); DR and BDR use AllSPFRouters multicast

address (224.0.0.5)

IMPORTANT: the routing tables will not change, but the network graph

must be updated

Case study – Analyzing the flooding procedure


LS Update packet sent by R2

How to delete an LSA? - Premature aging

• Process used by Advertising Routers to delete their LSAs from the LSDB

• Just flood the LSA to be deleted with LS Age = 3600 seconds

• OSPF rules say that, for the same SN, an instance with LS Age = 3600 is fresher than an instance with lower age


1 2

3 4

20

1020 525 30

15

40

ID=2,SN=5

ID=2,SN=5

ID=2,SN=5

Age=3600 s

1 2

3 4

20

1020 525 30

15

40

ID=2,SN=5

ID=2,SN=5ID=2,SN=5

ID=2,SN=5

ID=2,SN=5

ID=2,SN=5

Age=3600 s

1 2

3 4

20

1020

525 30

15

40

ID=2,SN=5

Age=3600 s

ID=2,SN=5

Age=3600 s

ID=2,SN=5

How to delete an LSA? - Premature aging


LS Update clearing network-LSA of 222.222.20.0/24

Election of the DR and BDR

• Main principle: once a router is elected as DR or BDR no one can takeover its role (unless there is a failure)

• Procedure:• The first router to be switched on becomes the DR, and the second one

the BDR

• If the DR fails, the BDR becomes the new DR

• The new BDR is the one with higher priority (a configurable parameter called Router Priority); in case of a tie, the router with higher RID is elected

• The election is performed via Hello packets


OSPF packet header

Network Mask


RouterDeadInterval

Designated Router


Neighbor

8 16 24 320

Case study – Changing the DR and BDR


Assuming R4 is DR and R3 is BDR, how to make R2 the DR

and R4 the BDR?

1. Deactivate f0/0 of R4 → R3 becomes DR and R2 BDR2. Deactivate f0/1 of R3 → R2 becomes DR3. Activate f0/0 of R4 → R4 becomes BDR4. Activate f0/1 of R3

Use show ip ospf interface f0/0 at R2 to check who the DR and BDR are

Case study – Changing the DR and BDR


Before any change

After f0/0 of R4 deactivatedAfter f0/1 of R3 deactivated

Case study – Changing the DR and the BDR


First Hello sent by R4 when its f0/0 activated

again

After f0/0 of R4 activated

After f0/1 of R3 activated

Initial synchronization of the LSDB

• Problem: when a router is switched on how does it get to know the network topology?

• Recall that updates are not sent frequently, as in RIP; they are only sent by a router when it perceives a change in a link with a neighbor or every 30 minutes

• Solution: when a router is switched on it tries to get the LSAs from its neighbors, as soon as possible




Router (r1 in this case) synchronizes with every neighbor that has a point-to-point link and the DR and BDR in a broadcast subnet

r1 r3

r4 r6

LSDB

r2LSDB

LSDB

DR

r5

BDR


• First exchange summary information, only after request complete information if needed

• OSPF uses Database Description messages to get the LSA headers

• When it verifies that the LSA body is also needed, the router asks it using a Link State Request message, and the requested LSA is sent using a Link State Update message


n1 n2

Hello protocol

Database description

Exchange of Database Description packets

• Neighbors establish Master/Slave relationship and use a stop-and-wait protocol

• The Master is the neighbor with higher RID• The Master/Slave bit (MS-bit)

indicates who the Master is

• Protocol• Either neighbor can send the

first DD packet; it will have the Init bit (I-bit) set to 1

• DD request-response exchanges are initiated by the Master; Slave answers using the Sequence Number received from the Master (DD Sequence Number -ddSN)

• Only the Master can retransmit packets; timeout period is RxmtInterval (RFC suggests 5 seconds on a LAN)

• Neighbors signal each other that they have nothing else to send using the More bit (M-bit); only the Master can end a DD exchange (when its M-bit is zero, and the one of the Slave is also 0)


Interface MTU

DD Sequence Number

LSA Headers

M

SMI00000Options

8 16 24 320

OSPF packet header

Initial synchronization of the LSBD - example


222.222.20.0/24

R1 R2

222.222.30.0/24

R3 R4

10 10

10

20

10

1020

20

i1i2

i1 i1 i2

i1

i2i3

222.222.10.0/24

222.222.40.0/24

222.222.50.0/24

i3 30222.222.20.3

222.222.20.1222.222.30.2

222.222.30.4

222.222.10.1 222.222.10.2

222.222.40.2

222.222.40.4

RID = 1.1.1.1 RID = 2.2.2.2

RID = 3.3.3.3 RID = 4.4.4.4


222.222.20.0/24


222.222.30.0/24

R3 is not directly connected with 222.222.30.0/24

Switch off R3, wait until R1 updates its LSAs, switch on R3 again

Initial synchronization of the LSDB - example


R1 R3222.222.20.3222.222.20.1

RID = 1.1.1.1 RID = 3.3.3.3

Hello

Hello

DB Description, ddSN = 634, I=1,M=1,MS=1



Header of Router-LSA, 1.1.1.1, 0x80000005




Header of Network-LSA, 222.222.30.0/24, 0x80000001




Initial synchronization of the LSDB -example




LS Request, directed to R1





Header of Network-LSA, 222.222.30.0/24, 0x80000001

LS Update, directed to R3

Complete Router-LSA, 1.1.1.1, 0x80000005




Complete Network-LSA, 222.222.30.0/24, 0x80000001

LS Update, flooded


R1 R3222.222.20.3222.222.20.1

RID = 1.1.1.1 RID = 3.3.3.3

Case study – Initial synchronization of the LSDB


EXPERIMENT:

1. Switch off R3

2. Switch on R3 again

R3 synchronizes with R1 and with the

DR and BDR of 222.222.30.0/24

Too many things happening at the same

time!



EXPERIMENT:

R3 is only connected to R1;

Initially, R1 is the DR at

222.222.20.0/24

1. Switch-off R3

2. Wait for a while until R1

updates its LSAs

3. Switch-on R3 again

NOTE: the old router-LSA of R3 is still in

the LSDB when R3 is switched on



Initial Hello sent by R3DR=0.0.0.0, BDR=0.0.0.0

Initial DD pkt sent R3I=1,M=1,MS=1, SN=8966

Initial DD pkt sent R1I=1,M=1,MS=1, SN=634

I=0,M=0,MS=0, SN=8967

R1 declares being DRDR=222.222.20.1, BDR=0.0.0.0

I=0,M=0,MS=0, SN=8968

R3 initiates end of DD exchange,

I=0,M=0,MS=1, SN=8968

R3 sends header of its router-LSA with SN = 0x80000001, I=0,M=1,MS=1, SN=8967

R1 assumes being slaveI=0,M=1,MS=0, SN=8966

Sends all its 5 LSA headers



R3 requests the 5 LSAsR1 delivers the 5 LSAs

Router-LSA of R3 has SN = 0x80000004

Flooding of new network-LSA of 222.222.20.0/24; it is no longer stubR3 floods router-LSA with SN =

0x80000005; replaces old one

Flooding of new router-LSA of R1222.222.20.0/24 is no longer stub



DB Description sent by R1

DB Description sent by R3



LS Update with requested LSAs

LS Request



EXPERIMENT:

Same as initial experiment

but OSPF process is cleared

at R3 (instead of the router

being switched off)

OSPF has some time to think!

R3#clear ip ospf process

Eliminates router-LSA of R3

Eliminates network-LSA of 222.222.20.0/24;R3 was the DR



LS Update clearing network-LSA of

222.222.20.0/24

LS Update clearing the router-LSA of R3

Summary of the essential OSPF structures and mechanisms

• Many networking protocols are complex and have many details• You need to survive and be successful…

• It is essential for a networking engineer to separate what is fundamental from what it is not, the principles from the technological details, …


Summary of the essential OSPF structures and mechanisms

• Hello protocol• Each router gets to know its local portion of the network topology by

sending Hello packets to its neighbors.

• Flooding process• Each router disseminates to all other routers its local routing information

using a reliable flooding process.

• The Link State Database (LSDB)• The LSDB is structured in several parts called LSAs; each LSA describes a

portion of the local routing information (topological, addressing and link information) and has a responsible router, the only one that can create it, update it or delete it.

• Initial Database Synchronization process• A new router joining the network builds its LSDB by retrieving a copy of it

from its neighbors


Bibliography

• John Moy, “OSPF Anatomy of an Internet Routing Protocol”, Addison Wesley, 1998

• John Moy, “OSPF Version 2”, RFC 2328, April 1998

• Silvia Hagen, “IPv6 Essentials”, 2nd edition, 2006, O‘Reilly


Documents

Link state routing and OSPF · routing tables ©Rui Valadas, version 3.0, 20/10/2017 15 R1#sh ipv6 route IPv6 Routing Table - 7 entries Codes: C - Connected, L - Local, S - Static,