Demystifying the OSPFv3 database – Part 1

Two years ago I published a post demystifying the OSPF database. I thought I’d do the same with OSPFv3 and the LSA types are fundamentally different. OSPFv3 is not simply OSPF for IPV6. OSPFv3 can also be used for IPv4 and has the capability to be extended.

In order to go through the LSA types, I’m going to be building a network as we go along and viewing the database. One thing to note is that since OSPFv3 has been extended on IOS, you can either use ipv6 ospf or simply ospfv3 in your configuration and show commands. I’m going to be using the ospfv3 version.

LSA Types

Let’s start with the following basic topology:
OSPFv3-1

I’ll be running this ethernet link in point-to-point mode. I’ll also have an IPv6 adress on each loopback in OSPFv3.

R2(config)#interface Loopback0
R2(config-if)#ipv6 address 2001:DB8::2:2:2:2/128
R2(config-if)#ipv6 ospf 1 area 0
R2(config-if)#int fa0/0
R2(config-if)#ipv6 address 2001:DB8:12:0:10:1:2:2/64
R2(config-if)#ipv6 ospf 1 area 0
R2(config-if)#ipv6 ospf network point-to-point
*Jul 29 16:04:26.915: %OSPFv3-4-NORTRID: Process OSPFv3-1-IPv6 could not pick a router-id, please configure manually

OSPFv3 still needs a 32bit router-id. Usually IOS will take the highest IPv4 loopback address as the 32bit number. I have no IPv4 configured on this router and hence will need to hard-code this value. Remember this is a 32bit number in dotted decimal format. It is not an IPv4 address in itself.

First, let’s confirm our adjacency is up:

R2#show ospfv3 neighbor

          OSPFv3 1 address-family ipv6 (router-id 2.2.2.2)

Neighbor ID     Pri   State           Dead Time   Interface ID    Interface
1.1.1.1           0   FULL/  -        00:00:39    2               FastEthernet0/0

The neighbour ID is the 32bit router-id on the other side. OSPFv3 uses IPv6 link-local addresses to form the adjacency:

R2#show ospfv3 neighbor detail

          OSPFv3 1 address-family ipv6 (router-id 2.2.2.2)

 Neighbor 1.1.1.1
    In the area 0 via interface FastEthernet0/0
    Neighbor: interface-id 2, link-local address FE80::C800:6FFF:FE16:8
    Neighbor priority is 0, State is FULL, 6 state changes
    Options is 0x000013 in Hello (V6-Bit, E-Bit, R-bit)
    Options is 0x000013 in DBD (V6-Bit, E-Bit, R-bit)
    Dead timer due in 00:00:38
    Neighbor is up for 00:27:24
    Index 1/1/1, retransmission queue length 0, number of retransmission 0
    First 0x0(0)/0x0(0)/0x0(0) Next 0x0(0)/0x0(0)/0x0(0)
    Last retransmission scan length is 0, maximum is 0
    Last retransmission scan time is 0 msec, maximum is 0 msec

Let’s take a quick look at the database. In OSPFv2 I would expect to see 2 Type1 LSAs only. What does OSPFv3 give us?:

R1#show ospfv3 database

          OSPFv3 1 address-family ipv6 (router-id 1.1.1.1)

		Router Link States (Area 0)

ADV Router       Age         Seq#        Fragment ID  Link count  Bits
 1.1.1.1         12          0x80000007  0            1           None
 2.2.2.2         18          0x8000000B  0            1           None

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

ADV Router       Age         Seq#        Link ID    Interface
 1.1.1.1         13          0x80000005  2          Fa0/0
 2.2.2.2         18          0x80000004  2          Fa0/0

		Intra Area Prefix Link States (Area 0)

ADV Router       Age         Seq#        Link ID    Ref-lstype  Ref-LSID
 1.1.1.1         12          0x8000000B  0          0x2001      0
 2.2.2.2         18          0x80000007  0          0x2001      0

A lot more than just two Type1s! There are still Type1 LSAs, but also Type8 and Type9s. In OSPFv2, the Type1 LSA would be originated by each router in the area and would contain it’s router-id, links, and IPs associated with those links. OSPFv3 removes the IP addressing from the Type1 as it’s now there to show the router-id and links it’s connected to:

R1#show ospfv3 database router adv-router 1.1.1.1

          OSPFv3 1 address-family ipv6 (router-id 1.1.1.1)

		Router Link States (Area 0)

  LS age: 87
  Options: (V6-Bit, E-Bit, R-bit, DC-Bit)
  LS Type: Router Links
  Link State ID: 0
  Advertising Router: 1.1.1.1
  LS Seq Number: 80000007
  Checksum: 0xDA0F
  Length: 40
  Number of Links: 1

    Link connected to: another Router (point-to-point)
      Link Metric: 1
      Local Interface ID: 2
      Neighbor Interface ID: 2
      Neighbor Router ID: 2.2.2.2

Remember 2.2.2.2 is simply the neighbours router-id. Note that this LSA does not contain the p2p IPv6 address, nor the loopback address. It’s simply a link topology LSA.
Type8 LSAs have link flooding scope, something you simply do not see in OSPFv2. I’ll get back to this one once we hadd another router into the area as it’ll make more sense then.

The IP addressing information in this topology is contained in the Type9 LSA. The intra-area prefix LSA:

R1#show ospfv3 database prefix adv-router 1.1.1.1

          OSPFv3 1 address-family ipv6 (router-id 1.1.1.1)

		Intra Area Prefix Link States (Area 0)

  Routing Bit Set on this LSA
  LS age: 454
  LS Type: Intra-Area-Prefix-LSA
  Link State ID: 0
  Advertising Router: 1.1.1.1
  LS Seq Number: 80000026
  Checksum: 0x1DFF
  Length: 64
  Referenced LSA Type: 2001
  Referenced Link State ID: 0
  Referenced Advertising Router: 1.1.1.1
  Number of Prefixes: 2
  Prefix Address: 2001:DB8::1:1:1:1
  Prefix Length: 128, Options: LA, Metric: 0
  Prefix Address: 2001:DB8:12::
  Prefix Length: 64, Options: None, Metric: 1

Here we see the two prefixes originated. Also notice the LSA can contain more than one prefix at a time. Much like a Type1 LSA.

I’ll now add a third router to the topology. This will also be in Area 0
OSPFv3-2

Let’s go back to the Type8 LSA we delayed earlier. In OSPFv2 all routers in an area need to have identical databases. In OSPFv3 this is not the case as each router will have different link LSAs. This LSA has link-only flooding scope and so is never flooded past the link in question. If we look at the Type8s from R3’s perspective:

R3#show ospfv3 database link

          OSPFv3 1 address-family ipv6 (router-id 3.3.3.3)

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

  LS age: 847
  Options: (V6-Bit, E-Bit, R-bit, DC-Bit)
  LS Type: Link-LSA (Interface: FastEthernet0/0)
  Link State ID: 3 (Interface ID)
  Advertising Router: 1.1.1.1
  LS Seq Number: 80000002
  Checksum: 0x9063
  Length: 56
  Router Priority: 1
  Link Local Address: FE80::C800:6FFF:FE16:6
  Number of Prefixes: 1
  Prefix Address: 2001:DB8:13::
  Prefix Length: 64, Options: None

  LS age: 772
  Options: (V6-Bit, E-Bit, R-bit, DC-Bit)
  LS Type: Link-LSA (Interface: FastEthernet0/0)
  Link State ID: 2 (Interface ID)
  Advertising Router: 3.3.3.3
  LS Seq Number: 80000001
  Checksum: 0xAC3D
  Length: 56
  Router Priority: 1
  Link Local Address: FE80::C802:6FFF:FE16:8
  Number of Prefixes: 1
  Prefix Address: 2001:DB8:13::
  Prefix Length: 64, Options: None

R3 has two LSAs. One originated by R1 and the other by R3. It contains the link local address of each side plus the prefixes assigned to that interface itself. R1, in the same area, will have a different view as it has neighbours on two different links:

R1#show ospfv3 database | begin Type-8
		Link (Type-8) Link States (Area 0)

ADV Router       Age         Seq#        Link ID    Interface
 1.1.1.1         81          0x80000003  3          Fa0/1
 3.3.3.3         1110        0x80000001  2          Fa0/1
 1.1.1.1         1967        0x80000020  2          Fa0/0
 2.2.2.2         164         0x80000020  2          Fa0/0

I’ll now add a new router in the area, and connect it to the same segment that R1 and R3 is connected to. I’ll change the network type back to broadcast for this link:
OSPFv3-3
On a broadcast link, the DR will originate a Type2 LSA. This is one of the few LSAs that is near identical to it’s OSPFv2 counterpart. This LSA still has area flooding scope and hence R2 will also be able to see it:

R2#show ospfv3 database network

          OSPFv3 1 address-family ipv6 (router-id 2.2.2.2)

		Net Link States (Area 0)

  LS age: 368
  Options: (V6-Bit, E-Bit, R-bit, DC-Bit)
  LS Type: Network Links
  Link State ID: 2 (Interface ID of Designated Router)
  Advertising Router: 3.3.3.3
  LS Seq Number: 80000002
  Checksum: 0xF0D8
  Length: 36
	Attached Router: 3.3.3.3
	Attached Router: 1.1.1.1
	Attached Router: 7.7.7.7

R3 is the DR for the segment, and the LSA contains the router-ids of all three routers connected to that segment. Each of those three routers will still only originate a single Type8 on that link. So I would expect to see three Type8s on that link from R7’s perspective:

R7#show ospfv3 database | begin Type-8
		Link (Type-8) Link States (Area 0)

ADV Router       Age         Seq#        Link ID    Interface
 1.1.1.1         718         0x80000004  3          Fa0/0
 3.3.3.3         1922        0x80000001  2          Fa0/0
 7.7.7.7         505         0x80000001  2          Fa0/0

Recalculation

It’s clear from above that OSPFv3 separates IP address information from the topology LSAs. This is important for a number of reasons. In OSPFv2, if a router originated a new Type1 or Type2 LSA, it would cause all routers in the area to run SPF. If I changed the IP address of any OSPF link, that would cause SPF to run. If I added a secondary address to an OSPF link, SPF would run. In OSPFv3 the adding or changing of addresses does not cause the router to originate a new Type1. This means that addresses being changed will not cause SPF to run.

Take a look at R7’s current excecution count:

R7#show ospfv3 statistic | include algorithm
  Area 0: SPF algorithm executed 2 times

On R1 I’ll add an address to the loopback interface. This would cause SPF to run in OSPFv2:

R1(config)#int lo0
R1(config-if)#ipv6 address 2001:db8::11:11:11:11/128

What does R7 see?

R7#show ospfv3 statistic | include algorithm
  Area 0: SPF algorithm executed 2 times

No increase.

Let’s dig a little deeper in the LSAs to see what’s happened. The Type1 LSA originated by R1:

R7#show ospfv3 database router adv-router 1.1.1.1

          OSPFv3 1 address-family ipv6 (router-id 7.7.7.7)

		Router Link States (Area 0)

  LS age: 1160
  Options: (V6-Bit, E-Bit, R-bit, DC-Bit)
  LS Type: Router Links
  Link State ID: 0
  Advertising Router: 1.1.1.1
  LS Seq Number: 80000028
  Checksum: 0xF6AD
  Length: 56
  Number of Links: 2

    Link connected to: a Transit Network
      Link Metric: 1
      Local Interface ID: 3
      Neighbor (DR) Interface ID: 2
      Neighbor (DR) Router ID: 3.3.3.3

    Link connected to: another Router (point-to-point)
      Link Metric: 1
      Local Interface ID: 2
      Neighbor Interface ID: 2
      Neighbor Router ID: 2.2.2.2

The LSA age is 1160 seconds, even though I just added a new IPv6 address. i.e. no new Type1. If we look at the Type9 LSA from R1:

R7#show ospfv3 database prefix adv-router 1.1.1.1

          OSPFv3 1 address-family ipv6 (router-id 7.7.7.7)

		Intra Area Prefix Link States (Area 0)

  Routing Bit Set on this LSA
  LS age: 146
  LS Type: Intra-Area-Prefix-LSA
  Link State ID: 0
  Advertising Router: 1.1.1.1
  LS Seq Number: 8000002D
  Checksum: 0xADA5
  Length: 84
  Referenced LSA Type: 2001
  Referenced Link State ID: 0
  Referenced Advertising Router: 1.1.1.1
  Number of Prefixes: 3
  Prefix Address: 2001:DB8::1:1:1:1
  Prefix Length: 128, Options: LA, Metric: 0
  Prefix Address: 2001:DB8::11:11:11:11
  Prefix Length: 128, Options: LA, Metric: 0
  Prefix Address: 2001:DB8:12::
  Prefix Length: 64, Options: None, Metric: 1

There’s the new prefix we added. LSA age is lower so this is a new one. R7 already has the existing Type1 LSA so it knows about router-id 1.1.1.1 – It can therefore now work out the route to the new prefix with this Type9 LSA. It does not need to run SPF again as it has already run SPF on that Type1. R7 therefore has an intra-area route to that prefix:

R7#show ipv6 route 2001:db8::11:11:11:11
Routing entry for 2001:DB8::11:11:11:11/128
  Known via "ospf 1", distance 110, metric 1, type intra area
  Route count is 1/1, share count 0
  Routing paths:
    FE80::C800:6FFF:FE16:6, FastEthernet0/0
      Last updated 00:05:52 ago

Read part 1
Read part 2
Read part 3
Read part 4

© 2009-2019 Darren O'Connor All Rights Reserved -- Copyright notice by Blog Copyright