Ospf | Darren's Blog

Demystifying the IS-IS database

I’ve gone over the OSPFv2 and OSPFv3 databases in depth before. Now is the time for IS-IS. As always, I’ll start from a basic two router set up and add devices to the topology.

Basic LSPs

In OSPF we use the term LSA, Link-State Advertisement. In IS-IS we use the term LSP – Link-State PDUs. Further expanded into Link-State Protocol Data Units. Not to be confused with Label Switched Paths.

This is the topology we’ll start with:

Like OSPF, IS-IS will treat ethernet links as broadcast by default. In OSPF a DR and BDR will be elected. In IS-IS a single DIS (Designated Intermediate System) is elected with no backup DIS. This DIS election is also pre-emtptive, unlike OSPF. The DIS will originate an LSP representing the DIS. This means I should have three LSPs in the database currently:

RP/0/0/CPU0:XR1#show isis database
Tue Aug 12 17:34:21.594 UTC

IS-IS 1 (Level-2) Link State Database
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime  ATT/P/OL
XR1.00-00           * 0x00000003   0x8577        736             0/0/0
XR1.01-00             0x00000002   0x1fba        931             0/0/0
XR2.00-00             0x00000005   0x856b        806             0/0/0

 Total Level-2 LSP count: 3     Local Level-2 LSP count: 1

XR2 has a single LSP with XR1 has two. The XR1.01 LSP is the DIS LSP. Dig deeper into the LSPs to see their current content:

RP/0/0/CPU0:XR1#show isis database XR1.00-00 detail
Tue Wed 12 17:38:23.307 UTC

IS-IS 1 (Level-2) Link State Database
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime  ATT/P/OL
XR1.00-00           * 0x00000003   0x8577        494             0/0/0
  Area Address: 49.0001
  NLPID:        0xcc
  Hostname:     XR1
  IP Address:   1.1.1.1
  Metric: 10         IS XR1.01
  Metric: 10         IP 1.1.1.1/32
  Metric: 10         IP 10.0.12.0/24

XR1 has originated an LSP stating what area it’s in and hostname. Notice the NLPID value. This means Network Layer Protocol IDentifier. The value of 0xcc translates to IPv4. Further down the LSP contains the IS of XR1 itself, plus two IP ranges. All these with metrics to those IS and IPs. I’ll get onto the ATT/P/OL bits later so ignore those for now.

It’s important to note that an LSP is made up of several TLVs. On the wire multiple TLVs can be grouped together in a single frame. If large enough, IS-IS will fragment these frames.

As XR1 is the DIS, there is a separate DIS LSP, let’s take a look at that:

RP/0/0/CPU0:XR1#show isis database XR1.01-00 detail
Tue Aug 12 17:43:00.448 UTC

IS-IS 1 (Level-2) Link State Database
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime  ATT/P/OL
XR1.01-00             0x00000003   0x1dbb        1161            0/0/0
  Metric: 0          IS XR1.00
  Metric: 0          IS XR2.00

The DIS LSP advertises all the IS’ that are on the segment in which the DIS sits.

If I change the segment to point-to-point, this removes the need of a DIS and as such there will be no DIS LSP.

router isis 1
!
 interface GigabitEthernet0/0/0/1
  point-to-point

RP/0/0/CPU0:XR1#show isis database
Tue Aug 12 18:46:50.566 UTC

IS-IS 1 (Level-2) Link State Database
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime  ATT/P/OL
XR1.00-00           * 0x0000000b   0x7480        674             0/0/0
XR2.00-00             0x0000000d   0x5297        543             0/0/0

 Total Level-2 LSP count: 2     Local Level-2 LSP count: 1

Externals

I’m going to add another loopback interface on XR1 and redistribute that loopback into IS-IS. This will make the route external

interface Loopback100
 ipv4 address 100.100.100.100 255.255.255.255
!
prefix-set LOOPBACK100
  100.100.100.100/32
end-set
!
route-policy RP-100
  if destination in LOOPBACK100 then
    done
  else
    drop
  endif
end-policy
!
router isis 1
 address-family ipv4 unicast
  redistribute connected level-2 route-policy RP-100

As I mentioned above, IS-IS has separate TLVs that make up the LSP. Therefore there is still only a single LSP from XR1:

RP/0/0/CPU0:XR2#sh isis database
Tue Aug 12 19:03:31.569 UTC

IS-IS 1 (Level-2) Link State Database
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime  ATT/P/OL
XR1.00-00             0x0000000d   0x6be5        1043            0/0/0
XR2.00-00           * 0x00000010   0x9c8f        1094            0/0/0

 Total Level-2 LSP count: 2     Local Level-2 LSP count: 1

The external route can be seen in the detailed output under that LSP:

RP/0/0/CPU0:XR2#sh isis database XR1.00-00 detail
Tue Aug 12 19:03:58.637 UTC

IS-IS 1 (Level-2) Link State Database
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime  ATT/P/OL
XR1.00-00             0x0000000d   0x6be5        1016            0/0/0
  Area Address: 49.0001
  NLPID:        0xcc
  Hostname:     XR1
  IP Address:   1.1.1.1
  Metric: 10         IS XR2.00
  Metric: 10         IP 1.1.1.1/32
  Metric: 10         IP 10.0.12.0/24
  Metric: 0          IP-External 100.100.100.100/32

Inter-Area

XR3 has now been added to the topology. I’ve had to move XR2 into the same area as XR3 otherwise they will not be able to form a L1 adjacency:

the R2-R3 link has not been changed to point-to-point, and as such I would expect to see three LSPs in XR3s database:

RP/0/0/CPU0:XR3#show isis database
Tue Aug 12 09:44:40.660 UTC

IS-IS 1 (Level-1) Link State Database
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime  ATT/P/OL
XR2.00-00             0x00000008   0xd230        1107            1/0/0
XR3.00-00           * 0x00000008   0xf1be        1105            0/0/0
XR3.07-00             0x00000003   0xfcd3        1105            0/0/0

 Total Level-1 LSP count: 3     Local Level-1 LSP count: 1

If you look at XR2’s L1 LSP in detail you now see the ATT bit set. Also note it’s advertising only it’s directly connected interfaces:

RP/0/0/CPU0:XR3#show isis database XR2.00-00 detail
Tue Aug 12 19:45:51.025 UTC

IS-IS 1 (Level-1) Link State Database
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime  ATT/P/OL
XR2.00-00             0x00000008   0xd230        1037            1/0/0
  Area Address: 49.0023
  NLPID:        0xcc
  Hostname:     XR2
  IP Address:   2.2.2.2
  Metric: 10         IS XR3.07
  Metric: 10         IP 2.2.2.2/32
  Metric: 10         IP 10.0.12.0/24
  Metric: 10         IP 10.0.23.0/24

XR2 has set the ATT bit which is the attached bit. An L1/L2 router will set this bit in the LSP inside the L1 area it’s connected to. This is to inform the L1 routers that it is attached to the L2 domain. No actual default route is advertised, but L1 routers can create their own defaults pointing towards the attached routers:

RP/0/0/CPU0:XR3#sh ip route 0.0.0.0
Tue Aug 12 19:47:07.839 UTC

Routing entry for 0.0.0.0/0
  Known via "isis 1", distance 115, metric 10, candidate default path, type level-1
  Installed Aug 12 19:43:09.476 for 00:03:58
  Routing Descriptor Blocks
    10.0.23.2, from 2.2.2.2, via GigabitEthernet0/0/0/0.23
      Route metric is 10
  No advertising protos.

Notice from XR1’s persepctive, that any routes coming from an L1 area is simple flooded from the L1/L2 router as normal routes:

RP/0/0/CPU0:XR1#show isis database XR2.00-00 detail
Tue Aug 12 19:50:08.676 UTC

IS-IS 1 (Level-2) Link State Database
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime  ATT/P/OL
XR2.00-00             0x0000001b   0x5b3d        778             0/0/0
  Area Address: 49.0023
  NLPID:        0xcc
  Hostname:     XR2
  IP Address:   2.2.2.2
  Metric: 10         IS XR1.00
  Metric: 10         IP 2.2.2.2/32
  Metric: 20         IP 3.3.3.3/32
  Metric: 10         IP 10.0.12.0/24
  Metric: 10         IP 10.0.23.0/24
  Metric: 10         IP 200.200.200.200/32

IS-IS gives you the ability to leak L2 prefixes into the L1 domain. This is handy when you have two L1/L2 border routers and want to engineer destiations to go on particular paths. From XR2 I’ll leak XR1’s loopback into the L1 domain. The database now shows:

RP/0/0/CPU0:XR3#show isis database XR2.00-00 detail
Tue Aug 12 21:53:13.981 UTC

IS-IS 1 (Level-1) Link State Database
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime  ATT/P/OL
XR2.00-00             0x0000002f   0x4e13        1193            1/0/0
  Area Address: 49.0023
  NLPID:        0xcc
  Hostname:     XR2
  IP Address:   2.2.2.2
  Router Cap:   2.2.2.2, D:0, S:0
  Metric: 10         IS XR3.07
  Metric: 20         IP-Interarea 1.1.1.1/32
  Metric: 10         IP 2.2.2.2/32
  Metric: 10         IP 10.0.23.0/24

1.1.1.1/32 shows up in LSP as an IP-Interarea route. Again a TLV is used for this.

IPv6

When running both IPv4 and IPv6 at the same time, IS-IS can be run in single-topology or multi-topolgy mode. In single topology, all your IS-IS links need to have both v4 and v6 addresses as the SPF tree is run indenpently of prefix information. If the SPF tree is calculated to use a link without a v6 address, IPv6 traffic will be blackholed over that link.

For now I’ve added an IPv6 loopback and interface address. I’ve got IS-IS running in multi topology mode. I should still only see two LSPs from XR1’s perspective:

RP/0/0/CPU0:XR1#show isis database
Tue Aug 12 23:47:02.152 UTC

IS-IS 1 (Level-2) Link State Database
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime  ATT/P/OL
XR1.00-00           * 0x0000001e   0x9683        1115            0/0/0
XR2.00-00             0x0000002b   0x62fa        1117            0/0/0

 Total Level-2 LSP count: 2     Local Level-2 LSP count: 1

IPv6 information is carried inside another TLV. Note also that there is a new NLPID value of 0x8e in the LSP. As you would guess this value represents IPv6:

RP/0/0/CPU0:XR1#show isis database detail XR2.00-00
Tue Aug 12 23:47:50.899 UTC

IS-IS 1 (Level-2) Link State Database
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime  ATT/P/OL
XR2.00-00             0x0000002b   0x62fa        1068            0/0/0
  Area Address: 49.0023
  NLPID:        0xcc
  NLPID:        0x8e
  MT:           Standard (IPv4 Unicast)
  MT:           IPv6 Unicast                                     0/0/0
  Hostname:     XR2
  IP Address:   2.2.2.2
  IPv6 Address: 2001:db8:2:2::2
  Metric: 10         IS XR1.00
  Metric: 10         IP 2.2.2.2/32
  Metric: 20         IP 3.3.3.3/32
  Metric: 10         IP 10.0.12.0/24
  Metric: 10         IP 10.0.23.0/24
  Metric: 10         IP 200.200.200.200/32
  Metric: 10         MT (IPv6 Unicast) IS-Extended XR1.00
  Metric: 10         MT (IPv6 Unicast) IPv6 2001:db8:2:2::2/128
  Metric: 10         MT (IPv6 Unicast) IPv6 2001:db8:12::/64

When running multi-topology mode, you’ll see MT: plus the address families configured for multi-topology. If I change this to single topology:

RP/0/0/CPU0:XR1#show isis database XR2.00-00 detail
Tue Aug 12 23:11:20.989 UTC

IS-IS 1 (Level-2) Link State Database
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime  ATT/P/OL
XR2.00-00             0x00000023   0xd22a        1196            0/0/0
  Area Address: 49.0023
  NLPID:        0xcc
  NLPID:        0x8e
  Hostname:     XR2
  IP Address:   2.2.2.2
  IPv6 Address: 2001:db8:2:2::2
  Metric: 10         IS XR1.00
  Metric: 10         IP 2.2.2.2/32
  Metric: 10         IP 10.0.12.0/24
  Metric: 10         IP 10.0.23.0/24
  Metric: 10         IP 200.200.200.200/32
  Metric: 10         IPv6 2001:db8:2:2::2/128
  Metric: 10         IPv6 2001:db8:12::/64

MT no longer shows up, and all TLVs are added as-is to the LSP.

Traffic Engineering

To enable TE, wide-metrics need to be enabled. Up until this point I’ve been using narrow metrics. Once enabled You can see the TE information in the LSP by doing a verbose output:

RP/0/0/CPU0:XR1#show isis database verbose XR2.00-00
Tue Aug 12 23:42:09.932 UTC

IS-IS 1 (Level-2) Link State Database
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime  ATT/P/OL
XR2.00-00             0x00000026   0x2dd8        910             0/0/0
  Area Address: 49.0023
  NLPID:        0xcc
  NLPID:        0x8e
  Hostname:     XR2
  IP Address:   2.2.2.2
  IPv6 Address: 2001:db8:2:2::2
  Router ID:    2.2.2.2
  Metric: 10         IS-Extended XR1.00
    Affinity: 0x00000000
    Interface IP Address: 10.0.12.2
    Neighbor IP Address: 10.0.12.1
    Physical BW: 1000000 kbits/sec
    Reservable Global pool BW: 0 kbits/sec
    Global Pool BW Unreserved:
      [0]: 0        kbits/sec          [1]: 0        kbits/sec
      [2]: 0        kbits/sec          [3]: 0        kbits/sec
      [4]: 0        kbits/sec          [5]: 0        kbits/sec
      [6]: 0        kbits/sec          [7]: 0        kbits/sec
    Admin. Weight: 167772160
    Ext Admin Group: Length: 32
      0x00000000   0x00000000
      0x00000000   0x00000000
      0x00000000   0x00000000
      0x00000000   0x00000000
  Metric: 10         IP-Extended 2.2.2.2/32
  Metric: 10         IP-Extended 10.0.12.0/24
  Metric: 10         IP-Extended 10.0.23.0/24
  Metric: 10         IP-Extended 200.200.200.200/32
  Metric: 10         IPv6 2001:db8:2:2::2/128
  Metric: 10         IPv6 2001:db8:12::/64

Notice there there is no new NLPID value for TE. TE extensions are enabled under address-family ipv4 and hence it uses the 0xcc id. If/when RSVP-TE can use IPv6 natively, I could expect to see only the IPv6 ID.

Overload

IS-IS has the ability to set the overload bit in an LSP. This could be originated by the router itself if it was overwhelmed, but it can also be hard set when doing planned works for example. If the overload bit is set, other routers will route around the router.

router isis 1
 set-overload-bit

Note that OL bit set in the LSP:

RP/0/0/CPU0:XR1#show isis database
Tue Aug 12 23:32:58.107 UTC

IS-IS 1 (Level-2) Link State Database
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime  ATT/P/OL
XR1.00-00           * 0x0000001f   0x9484        947             0/0/0
XR2.00-00             0x0000002e   0x97a4        1151            0/0/1

 Total Level-2 LSP count: 2     Local Level-2 LSP count: 1

I no longer have access to R3 now as R2 is the only router connecting these two devices:

RP/0/0/CPU0:XR1#ping 3.3.3.3
Tue Aug 12 23:08:44.083 UTC
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
UUUUU
Success rate is 0 percent (0/5)

I am still able to ping XR2 itself though:

RP/0/0/CPU0:XR1#ping 2.2.2.2
Tue Aug 12 23:09:32.870 UTC
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms

We’ve now seen the purpose of both the ATT and OL bits, so what is the P bit for? that bit is for the Partition Repair Bit which no vendor has implemented. i.e. it should always show 0.

Segment Routing

IS-IS is easily extended using new TLVs. If I enable segment routing under my IS-IS process, I see it added as a new TLV in the LSP:

RP/0/0/CPU0:XR1#show isis database verbose XR2.00-00
Tue Aug 12 23:50:35.855 UTC

IS-IS 1 (Level-2) Link State Database
LSPID                 LSP Seq Num  LSP Checksum  LSP Holdtime  ATT/P/OL
XR2.00-00             0x00000036   0x252b        954             0/0/0
  Area Address: 49.0023
  NLPID:        0xcc
  NLPID:        0x8e
  MT:           Standard (IPv4 Unicast)
  MT:           IPv6 Unicast                                     0/0/0
  Hostname:     XR2
  IP Address:   2.2.2.2
  IPv6 Address: 2001:db8:2:2::2
  Router Cap:   2.2.2.2, D:0, S:0
    Segment Routing: I:1 V:0, SRGB Base: 900000 Range: 65535
  Metric: 10         IS XR1.00
  Metric: 10         IP 2.2.2.2/32
  Metric: 20         IP 3.3.3.3/32
  Metric: 10         IP 10.0.12.0/24
  Metric: 10         IP 10.0.23.0/24
  Metric: 10         IP 200.200.200.200/32
  Metric: 10         MT (IPv6 Unicast) IS-Extended XR1.00
  Metric: 10         MT (IPv6 Unicast) IPv6 2001:db8:2:2::2/128
  Metric: 10         MT (IPv6 Unicast) IPv6 2001:db8:12::/64

OSPF Enhancements in recent IOS versions

OSPFv3 Authentication Trailer

In 2011 I wrote an article showing that in order to provide authenticated OSPFv3 neighbour sessions, you needed the security license on IOS.

Manav Bhatia commented on that post stating they were working on an IETF standard to fix this. That draft became RFC6506 and then RFC7166

Cisco has added support for RFC7166 as of IOS 15.4(2)T and IOS-XE 3.11S

Configuration is very quick and easy. Note that OSPFv3 authentication headers do not support md5 according to the RFC. If you configure your key chain with md5, it will not work.

R1#sh run int gi0/0.12
Building configuration...

Current configuration : 125 bytes
!
interface GigabitEthernet0/0.12
 encapsulation dot1Q 12
 ipv6 address 2001:DB8:12:0:10:1:2:1/64
 ospfv3 1 ipv6 area 0
end

Standard interface config. I’ll now configure the key chain and authenticate ensure all area 0 adjacencies:

R1#sh run | sec key chain
key chain AUTH
 key 1
  key-string RFC
  cryptographic-algorithm hmac-sha-512

R1#sh run | sec router ospfv3
router ospfv3 1
 router-id 1.1.1.1
 !
 address-family ipv6 unicast
  authentication mode strict
  area 0 authentication key-chain AUTH
 exit-address-family

Verify:

R1#show ospfv3 interface
GigabitEthernet0/0.12 is up, line protocol is up
  Link Local Address FE80::A8AA:11FF:FE11:1111, Interface ID 15
  Area 0, Process ID 1, Instance ID 0, Router ID 1.1.1.1
  Network Type BROADCAST, Cost: 1
  Cryptographic authentication enabled with strict key lifetime
    Sending SA: Key 1, Algorithm HMAC-SHA-512 - key chain AUTH
  Transmit Delay is 1 sec, State BDR, Priority 1
  Designated Router (ID) 2.2.2.2, local address FE80::A8AA:22FF:FE22:2222
  Backup Designated router (ID) 1.1.1.1, local address FE80::A8AA:11FF:FE11:1111
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    Hello due in 00:00:06
  Graceful restart helper support enabled
  Index 1/1/1, flood queue length 0
  Next 0x0(0)/0x0(0)/0x0(0)
  Last flood scan length is 2, maximum is 2
  Last flood scan time is 0 msec, maximum is 0 msec
  Neighbor Count is 1, Adjacent neighbor count is 1
    Adjacent with neighbor 2.2.2.2  (Designated Router)
  Suppress hello for 0 neighbor(s)


R1#show ospfv3 neighbor

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

Neighbor ID     Pri   State           Dead Time   Interface ID    Interface
2.2.2.2           1   FULL/DR         00:00:33    15              GigabitEthernet0/0.12

Oddly, IOS-XR 5.2.0 still does not support this RFC. Only the previous IPSec authentication:

RP/0/0/CPU0:XR6(config-ospfv3-ar)#authentication ?
  disable  Do not authenticate OSPFv3 packets
  ipsec    Use IPSec AH authentication

OSPFv2 Multiarea Adjacency

In 2012 I wrote another post explaining the problem of suboptimal routing in OSPFv2. RFC5185 was created to allow a single interface to be in multiple areas. At the time of writing that original post, this feature was only in Junos and IOS-XE. This has now been added to IOS 15.4(1)T I recommend you read the above post first to understand the issue.

I’ll use a similar topology to that original post. I’ve substituted R5 and R6 with IOS-XR boxes:

XR5 goes over the primary link, but XR6 goes over the backup:

RP/0/0/CPU0:XR5#traceroute 4.4.4.4
Thu Aug  7 21:39:21.188 UTC

Type escape sequence to abort.
Tracing the route to 4.4.4.4

 1  10.0.15.1 9 msec  0 msec  0 msec
 2  10.0.14.4 0 msec  *  0 msec


RP/0/0/CPU0:XR6#traceroute 4.4.4.4
Thu Aug  7 21:39:31.999 UTC

Type escape sequence to abort.
Tracing the route to 4.4.4.4

 1  10.0.26.2 0 msec  0 msec  0 msec
 2  10.0.24.4 0 msec  *  0 msec

Configuration is pretty simple. Add the original area plus the second area to the interface needed:

interface GigabitEthernet0/0.13
 encapsulation dot1Q 13
 ip address 10.0.13.1 255.255.255.0
 ip ospf multi-area 4
 ip ospf 1 area 0

To verify:

R1#show ip ospf 1 multi-area
OSPF_MA0 is down, line protocol is down
  Primary Interface GigabitEthernet0/0.13, Area 4
  Interface ID 17
  MTU is 1500 bytes
  Interface DOWN as link is not P2P

An interesting caveat, the interface needs to be in point-to-point mode for this to work:

R1(config)#int gi0/0.13
R1(config-subif)#ip ospf net point-to-point

Once I’ve made the above changes on R1, R2, and R3:

R1#show ip ospf 1 multi-area
OSPF_MA0 is up, line protocol is up
  Primary Interface GigabitEthernet0/0.13, Area 4
  Interface ID 17
  MTU is 1500 bytes
  Neighbor Count is 1

A traceroute from XR6 should now follow the path over the primary link:

RP/0/0/CPU0:XR6#traceroute 4.4.4.4
Thu Aug 7 21:55:58.302 UTC

Type escape sequence to abort.
Tracing the route to 4.4.4.4

 1  10.0.26.2 0 msec  0 msec  0 msec
 2  10.0.23.3 0 msec  0 msec  0 msec
 3  10.0.13.1 0 msec  0 msec  0 msec
 4  10.0.14.4 0 msec  *  0 msec

OSPF Multi-Area Adjacency is one of those things that can fix some odd corner case topologies. I would not recommend it. The issue is that now R3 has a full area 4 and area 0 database. It’s also messy. Rather redesign your network!

IOS-XR has had this feature since v3.4.1 – A quick config on XR6:

RP/0/0/CPU0:XR6#sh run router ospf
Thu Aug 7 22:05:25.833 UTC
router ospf 1
 area 0
  interface GigabitEthernet0/0/0/0.26
   network point-to-point
  !
 !
 area 10
  multi-area-interface GigabitEthernet0/0/0/0.26
  !
 !
!

To verify on XR you need to look at the last few lines on a show ospf interface:

RP/0/0/CPU0:XR6#show ospf interface gi0/0/0/0.26
Thu Aug 7 22:05:53.841 UTC

GigabitEthernet0/0/0/0.26 is up, line protocol is up
  Internet Address 10.0.26.6/24, Area 0
  Process ID 1, Router ID 10.0.26.6, Network Type POINT_TO_POINT, Cost: 1
  Transmit Delay is 1 sec, State POINT_TO_POINT, MTU 1500, MaxPktSz 1500
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    Hello due in 00:00:07:158
  Index 1/1, flood queue length 0
  Next 0(0)/0(0)
  Last flood scan length is 1, maximum is 1
  Last flood scan time is 0 msec, maximum is 0 msec
  LS Ack List: current length 0, high water mark 16
  Neighbor Count is 1, Adjacent neighbor count is 1
    Adjacent with neighbor 2.2.2.2
  Suppress hello for 0 neighbor(s)
  Multi-area interface Count is 1
    Multi-Area interface exist in area 10 Neighbor Count is 1

OSPFv3 Multiarea Adjacency

IOS 15.4(2)T and IOS-XE 3.11S now has support for multi-area adjacency for OSPFv3.

The config is identical to OSPFv2 so I’m not going to go over it here.

That’s a wrap for today.

Demystifying the OSPFv3 database – Part 4

OSPFv3 has been extended so that IPv4 can now be routed using it. If running both IPv6 and IPV4 over OSPFv3, they are run as separate processes completely. If we go back to the topology we started with:

R1 and R2 have IPv6 OSPFv3 set to point-to-point. If I enable IPv4 OSPFv3, there is an entirely separate adjacency process. I won’t set the IPv4 to point-to-point to ensure the difference is seen:

interface FastEthernet0/0
 ip address 10.1.2.1 255.255.255.0
 ipv6 address 2001:DB8:12:0:10:1:2:1/64
 ospfv3 1 ipv4 area 0
 ospfv3 1 ipv6 area 0
 ospfv3 1 ipv6 network point-to-point

There will be two separate adjacencies set up:

R1#show ospfv3 neighbor

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

Neighbor ID     Pri   State           Dead Time   Interface ID    Interface
2.2.2.2           1   FULL/DR         00:00:34    2               FastEthernet0/0

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

Neighbor ID     Pri   State           Dead Time   Interface ID    Interface
2.2.2.2           0   FULL/  -        00:00:38    2               FastEthernet0/0

Checking the detail the same link-local addresses are used. This is an important fact as if you wanted to run OSPFv3 in a pure IPv4 environment, you would still need IPV6 link-local addresses on each link:

R1#show ospfv3 neighbor detail

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

 Neighbor 2.2.2.2, interface address 10.1.2.2
    In the area 0 via interface FastEthernet0/0
    Neighbor: interface-id 2, link-local address FE80::C802:30FF:FEB0:8
    Neighbor priority is 1, State is FULL, 6 state changes
    DR is 2.2.2.2 BDR is 1.1.1.1
    Options is 0x000112 in Hello (E-Bit, R-bit, AF-Bit)
    Options is 0x000112 in DBD (E-Bit, R-bit, AF-Bit)
    Dead timer due in 00:00:33
    Neighbor is up for 00:04:17
    Index 1/1/1, retransmission queue length 0, number of retransmission 1
    First 0x0(0)/0x0(0)/0x0(0) Next 0x0(0)/0x0(0)/0x0(0)
    Last retransmission scan length is 1, maximum is 1
    Last retransmission scan time is 0 msec, maximum is 0 msec

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

 Neighbor 2.2.2.2
    In the area 0 via interface FastEthernet0/0
    Neighbor: interface-id 2, link-local address FE80::C802:30FF:FEB0: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:37
    Neighbor is up for 00:07:12
    Index 1/1/1, retransmission queue length 0, number of retransmission 4
    First 0x0(0)/0x0(0)/0x0(0) Next 0x0(0)/0x0(0)/0x0(0)
    Last retransmission scan length is 1, maximum is 2
    Last retransmission scan time is 0 msec, maximum is 0 msec

Two hello processes:

R2#debug ospfv3 hello
OSPFv3 hello events debugging is on for process 1, IPv4, Default vrf
OSPFv3 hello events debugging is on for process 1, IPv6, Default vrf
R2#
*Aug  1 11:09:04.835: OSPFv3-1-IPv4 HELLO Fa0/0: Send hello to FF02::5 area 0 from FE80::C802:30FF:FEB0:8 interface ID 2
*Aug  1 11:09:05.611: OSPFv3-1-IPv6 HELLO Fa0/0: Rcv hello from 1.1.1.1 area 0 from FE80::C801:30FF:FEB0:8 interface ID 2
R2#
*Aug  1 11:09:09.123: OSPFv3-1-IPv6 HELLO Fa0/0: Send hello to FF02::5 area 0 from FE80::C802:30FF:FEB0:8 interface ID 2
R2#
*Aug  1 11:09:11.483: OSPFv3-1-IPv4 HELLO Fa0/0: Rcv hello from 1.1.1.1 area 0 from FE80::C801:30FF:FEB0:8 interface ID 2

The OSPFv3 database will have separate IPv4 and IPv6 databases. They do not share any of the LSAs, including Type1 and Type2s. All of the other LSAs are the same as their IPv6 counterparts in that the actual IP prefixes are carried in separate LSAs:

R2#show ospfv3 database prefix self-originate

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

		Intra Area Prefix Link States (Area 0)

  Routing Bit Set on this LSA
  LS age: 49
  LS Type: Intra-Area-Prefix-LSA
  Link State ID: 0
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000001
  Checksum: 0xE4EB
  Length: 40
  Referenced LSA Type: 2001
  Referenced Link State ID: 0
  Referenced Advertising Router: 2.2.2.2
  Number of Prefixes: 1
  Prefix Address: 2.2.2.2
  Prefix Length: 32, Options: LA, Metric: 0

  Routing Bit Set on this LSA
  LS age: 974
  LS Type: Intra-Area-Prefix-LSA
  Link State ID: 2048
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000001
  Checksum: 0x6664
  Length: 40
  Referenced LSA Type: 2002
  Referenced Link State ID: 2
  Referenced Advertising Router: 2.2.2.2
  Number of Prefixes: 1
  Prefix Address: 10.1.2.0
  Prefix Length: 24, Options: None, Metric: 0

Here R2 is originating two Intra-Area LSAs for v4. The second is type 2002 which means that LSA is originated as the DR of that segment.

RFC 5329 has been created in order to carry TE extensions on OSPFv3, however I do not currently see support for it. I’ll have to leave those new LSAs to another day.

Conclusion

OSPFv3 is much more than just OSPF for IPv6. There are a number of enhancements that should make the IGP much more stable and efficient in larger topologies. The biggest change is the removal of IP prefix information from the Type1 LSA. A quick table look at OSPFv2 and OSPFv3 LSAs covered:

OSPF LSA Types
LSA	OSPFv2	OSPFv3
1	Router	Router
2	Network	Network
3	Summary	Inter-Area Prefix
4	ASBR-Summary	Inter-Area Router
5	External	External
7	NSSA-External	NSSA-Enteral
8	-	Link
9	-	Intra-Area Prefix

OSPFv3 is also a new protocol so there is not going to be 100% feature parity with OSPFv2 right now. I certainly would not rip out OSPFv2 and replace it with OSPFv3 anytime soon. The lack of workable TE makes it unusable as an IPv4 IGP for ISPs.

Type1 and Type2 are the big difference. In OSPFv3 they contain link-state only. Type3s and 4s are nearly identical, the only change is their name. Type5s and Type7s have the same bahaviour and even names. Type8s are the new link-local LSA unique to OSPFv3. Finally the Type9 carries the prefix information that was previously carried in the Type1 and Type2 LSAs.

Master these differences and you’re well on your way to understand this new database.

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

Demystifying the OSPFv3 database – Part 3

Previous posts in this series has been limited to a single area. Let’s now start adding new areas and see what LSAs are produced. I’m going to add R6 to area 6 as follows:

Area 1 is a standard area. R6 is originating it’s loopback into OSPFv3. R1 is a regular ABR. In OSPFv2 I would expect R1 to originate Type3 LSAs for all the Type1 and Type2 LSAs in area 0. In OSPFv3 this is similar behaviour. The Type3 LSA is now labelled as the ‘Inter Area Prefix Link States’

R6#show ospfv3 database | begin Inter
		Inter Area Prefix Link States (Area 1)

ADV Router       Age         Seq#        Prefix
 1.1.1.1         783         0x80000001  2001:DB8::1:1:1:1/128
 1.1.1.1         783         0x80000001  2001:DB8:12::/64
 1.1.1.1         783         0x80000001  2001:DB8::2:2:2:2/128
 1.1.1.1         783         0x80000001  2001:DB8::3:3:3:3/128
 1.1.1.1         783         0x80000001  2001:DB8::7:7:7:7/128
 1.1.1.1         783         0x80000001  2001:DB8:13::/64

Note that there is a separate Type3 for each and every prefix. This is similar the Type3 in OSPFv2. If I add another loopback to R7, I would expect R7 to originate a new single Type9 in area 0 listing all it’s connected prefixes. I would also then expect R1 to originate an extra Type3 for that prefix in addition to the existing Type3s:

R7(config)#int lo0
R7(config-if)#ipv6 address 2001:db8::77:77:77:77/128

R1#show ospfv3 database prefix adv-router 7.7.7.7

          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: 56
  LS Type: Intra-Area-Prefix-LSA
  Link State ID: 0
  Advertising Router: 7.7.7.7
  LS Seq Number: 80000002
  Checksum: 0xDB08
  Length: 72
  Referenced LSA Type: 2001
  Referenced Link State ID: 0
  Referenced Advertising Router: 7.7.7.7
  Number of Prefixes: 2
  Prefix Address: 2001:DB8::7:7:7:7
  Prefix Length: 128, Options: LA, Metric: 0
  Prefix Address: 2001:DB8::77:77:77:77
  Prefix Length: 128, Options: LA, Metric: 0

R6#show ospfv3 database | begin Inter
		Inter Area Prefix Link States (Area 1)

ADV Router       Age         Seq#        Prefix
 1.1.1.1         1464        0x80000001  2001:DB8::1:1:1:1/128
 1.1.1.1         1464        0x80000001  2001:DB8:12::/64
 1.1.1.1         1464        0x80000001  2001:DB8::2:2:2:2/128
 1.1.1.1         1464        0x80000001  2001:DB8::3:3:3:3/128
 1.1.1.1         1464        0x80000001  2001:DB8:13::/64
 1.1.1.1         82          0x80000001  2001:DB8::7:7:7:7/128
 1.1.1.1         82          0x80000001  2001:DB8::77:77:77:77/128

R1 being the ABR is also originating Type3’s into area 0:

R2#show ospfv3 database inter-area prefix

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

		Inter Area Prefix Link States (Area 0)

  Routing Bit Set on this LSA
  LS age: 560
  LS Type: Inter Area Prefix Links
  Link State ID: 0
  Advertising Router: 1.1.1.1
  LS Seq Number: 80000001
  Checksum: 0x6F46
  Length: 36
  Metric: 64
  Prefix Address: 2001:DB8:16::
  Prefix Length: 64, Options: None

  Routing Bit Set on this LSA
  LS age: 560
  LS Type: Inter Area Prefix Links
  Link State ID: 1
  Advertising Router: 1.1.1.1
  LS Seq Number: 80000001
  Checksum: 0xFF6A
  Length: 44
  Metric: 64
  Prefix Address: 2001:DB8::6:6:6:6
  Prefix Length: 128, Options: None

Area 1 will now be converted to a total stub.

R6(config)#router ospfv3 1
R6(config-router)#add ipv6 un
R6(config-router-af)#area 1 stub

R1(config)#router ospfv3 1
R1(config-router)#add ipv6 un
R1(config-router-af)#area 1 stub no-summary

R6 still has the area 1 Type1, Type8, and Type9s. There is now only a single Type3 advertising a default route:

R6#show ospfv3 database inter-area prefix

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

		Inter Area Prefix Link States (Area 1)

  Routing Bit Set on this LSA
  LS age: 243
  LS Type: Inter Area Prefix Links
  Link State ID: 7
  Advertising Router: 1.1.1.1
  LS Seq Number: 80000001
  Checksum: 0x49E9
  Length: 28
  Metric: 1
  Prefix Address: ::
  Prefix Length: 0, Options: None

This will create a standard inter-area route:

R6#sh ipv6 route ::/0
Routing entry for ::/0
  Known via "ospf 1", distance 110, metric 65, type inter area
  Route count is 1/1, share count 0
  Routing paths:
    FE80::C801:7BFF:FE9E:8, Serial1/0
      Last updated 00:05:54 ago

I’ll now originate an external LSA on R2:

R2(config)#router ospfv3 1
R2(config-router)#address-family ipv6 unicast
R2(config-router-af)#default-information originate always

This action will cause R2 to originate a Type5 LSA. This is pretty much identical to an OSPFv2 Type5:

R7#show ospfv3 database external

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

		Type-5 AS External Link States

  Routing Bit Set on this LSA
  LS age: 221
  LS Type: AS External Link
  Link State ID: 0
  Advertising Router: 2.2.2.2
  LS Seq Number: 80000001
  Checksum: 0x9871
  Length: 32
  Prefix Address: ::
  Prefix Length: 0, Options: None
  Metric Type: 2 (Larger than any link state path)
  Metric: 1
  External Route Tag: 1

I’m going to change area 1 back to a regular area. As there is an external LSA on area 0, that LSA should be flooded into area 1. Routers in area 1 also need to know how to get to the ASBR, R2 in this case. In OSPFv2 the ABR originated a Type4 LSA, the ASBR-Summary LSA. In OSPFv3 it’s also a Type4, but it’s now called the Inter-Area Router LSA. With this Type4 and Type5, R6 is able to work out a path for the external route:

R6#show ospfv3 database inter-area router

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

		Inter Area Router Link States (Area 1)

  Routing Bit Set on this LSA
  LS age: 150
  Options: (V6-Bit, E-Bit, R-bit, DC-Bit)
  LS Type: Inter Area Router Links
  Link State ID: 33686018
  Advertising Router: 1.1.1.1
  LS Seq Number: 80000001
  Checksum: 0xC829
  Length: 32
  Metric: 1
  Destination Router ID: 2.2.2.2

I’m now going to convert area 1 to an NSSA and originate an external route via R6:

R1(config)#router ospfv3 1
R1(config-router)#add ipv6 un
R1(config-router-af)#area 1 nssa no-sum

R6(config)#int lo1
R6(config-if)#ipv6 add 2001:db8::66:66:66:66/128

R6(config-if)#route-map LOOPBACK1
R6(config-route-map)#match interface lo1

R6(config-route-map)#router ospfv3 1
R6(config-router)#add ipv6 un
R6(config-router-af)#area 1 nssa
R6(config-router-af)#redistribute connected route-map LOOPBACK1

R1 should see this as a Type7 NSSA external. OSPFv2 and OSPFv3 are the same in this regard:

R1#sh ospfv3 database nssa-external

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

		Type-7 AS External Link States (Area 1)

  Routing Bit Set on this LSA
  LS age: 60
  LS Type: AS External Link
  Link State ID: 1
  Advertising Router: 6.6.6.6
  LS Seq Number: 80000001
  Checksum: 0x8857
  Length: 60
  Prefix Address: 2001:DB8::66:66:66:66
  Prefix Length: 128, Options: P
  Metric Type: 2 (Larger than any link state path)
  Metric: 20
  Forward Address: 2001:DB8::6:6:6:6

R1 being the ABR into area 0 should convert that Type7 into a Type5:

R1#show ospfv3 database external adv-router 1.1.1.1

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

		Type-5 AS External Link States

  LS age: 172
  LS Type: AS External Link
  Link State ID: 0
  Advertising Router: 1.1.1.1
  LS Seq Number: 80000001
  Checksum: 0x23BB
  Length: 60
  Prefix Address: 2001:DB8::66:66:66:66
  Prefix Length: 128, Options: None
  Metric Type: 2 (Larger than any link state path)
  Metric: 20
  Forward Address: 2001:DB8::6:6:6:6

As R1 is originating this LSA, routers in area 0 don’t need the Type4 for information on how to get to the ASBR R6.

In part 4 I’ll go over various other parts of OSPFv3, including using IPv4.

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

Demystifying the OSPFv3 database – Part 2

In yesterday’s post I forgot to mention a very interesting behaviour of the way router’s originate Type9 LSAs over a broadcast segment. Let’s remind ourselves of the topology we were up to:

I’ve reset this topology and currently R3 is the DR. Let’s first check the non-broadcast link between R1 and R2. Each router oritiginates a Type9 with all their OSPFv3 enabled prefixes. This includes the link between them:

R2#show ospfv3 database prefix self-originate

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

		Intra Area Prefix Link States (Area 0)

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

Here R2 has two prefixes in the LSA. R1 is also originating 2001:DB8:12::/64 in it’s LSA. When connected to a broadcast segment, routers do NOT advertise the connected prefixes address. Take a look at R7’s Type9:

R7#show ospfv3 database prefix self-originate

          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: 6
  LS Type: Intra-Area-Prefix-LSA
  Link State ID: 0
  Advertising Router: 7.7.7.7
  LS Seq Number: 80000003
  Checksum: 0x2E11
  Length: 52
  Referenced LSA Type: 2001
  Referenced Link State ID: 0
  Referenced Advertising Router: 7.7.7.7
  Number of Prefixes: 1
  Prefix Address: 2001:DB8::7:7:7:7
  Prefix Length: 128, Options: LA, Metric: 0

R7 is not showing it’s connected to the 2001:db8:13::/64 subnet.

Responsibility for advertising that Type9 lies with the DR. The interesting part is that the DR actually originates two separate Type9s:

R3#show ospfv3 database prefix self-originate

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

		Intra Area Prefix Link States (Area 0)

  Routing Bit Set on this LSA
  LS age: 876
  LS Type: Intra-Area-Prefix-LSA
  Link State ID: 0
  Advertising Router: 3.3.3.3
  LS Seq Number: 80000004
  Checksum: 0xE984
  Length: 52
  Referenced LSA Type: 2001
  Referenced Link State ID: 0
  Referenced Advertising Router: 3.3.3.3
  Number of Prefixes: 1
  Prefix Address: 2001:DB8::3:3:3:3
  Prefix Length: 128, Options: LA, Metric: 0

  Routing Bit Set on this LSA
  LS age: 1150
  LS Type: Intra-Area-Prefix-LSA
  Link State ID: 2048
  Advertising Router: 3.3.3.3
  LS Seq Number: 80000001
  Checksum: 0x1297
  Length: 44
  Referenced LSA Type: 2002
  Referenced Link State ID: 2
  Referenced Advertising Router: 3.3.3.3
  Number of Prefixes: 1
  Prefix Address: 2001:DB8:13::
  Prefix Length: 64, Options: None, Metric: 0

There is an important detail to note. The Type9 originated for the segment has a reference LSA Type value of 2002 while a regular Type9 has a value of 2001. The 2002 value tells you that the LSA was originated by the DR for the segment.

Ultimately this means that a DR will originate two separate LSAs for each broadcast segment. The second LSA being the link state Type2:

R3#show ospfv3 database network self-originate

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

		Net Link States (Area 0)

  LS age: 1524
  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

In part 3 I’ll be going over inter-area LSAs

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