Tag Archives: ipv6

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:
OSPFv3 1 Demystifying the OSPFv3 database – Part 4
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:
OSPFv3 4 Demystifying the OSPFv3 database – Part 3
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:
OSPFv3 3 Demystifying the OSPFv3 database – Part 2
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

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 Demystifying the OSPFv3 database   Part 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 21 Demystifying the OSPFv3 database   Part 1

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 Demystifying the OSPFv3 database   Part 1
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

IPv6 over IPv4 MPLS Core Interop – IOS, Junos, Netiron – Part 1 of 2 – 6PE

I wanted to test 6PE and 6VPE interoperability with the three major vendors. As always I’m stuck with IOS only in the Cisco world for now, but what can I do. This test will run over a Junos MPLS core. All my MPLS labs thus far has been using RSVP, so let’s change this to LDP for now just to mix things up a bit.

6PE allows you to run IPv6 transport over a IPv4 MPLS core. MPLS does not have native label support for IPv6 addresses, at least yet. This means if you need to transport IPv6 traffic over your MPLS core, you need to tunnel it over IPv4. 6PE is one of those ways. 6VPE is essentially MPLS layer 3 VPN for IPv6 over an IPv4 as opposed to 6PE which is simple IPv6 over an IPv4 MPLS core.

multi vendor l3vpn IPv6 over IPv4 MPLS Core Interop   IOS, Junos, Netiron   Part 1 of 2   6PE

6PE

There is no need to worry about CPE kit for now. I’ll simply have an IPv6 loopback address on R3, R4, and R8. These PE routers will peer over MP-BGP over the IPv4-only core.

R3 – Junos

interfaces {
    ae1 {
        unit 13 {
            vlan-id 13;
            family inet {
                address 10.0.4.13/30;
            }
            family inet6;
            family mpls;
        }
    lo0 {
        unit 3 {
            family inet {
                address 3.3.3.3/32;
            }
            family inet6 {
                address 2001:db8:3333::3333/128;
            }
        }
    }
}
protocols {

    mpls {
        ipv6-tunneling;
        interface ae1.13;
    }
    bgp {
        group 6PE {
            family inet6 {
                labeled-unicast {
                    explicit-null;
                }
            }
            export LOOPBACK;
            peer-as 100;
            neighbor 4.4.4.4;
            neighbor 8.8.8.8;
        }
    }
    ldp {
        interface ae1.13;
    }
}
policy-options {
    policy-statement LOOPBACK {
        from {
            protocol direct;
            route-filter 2001:db8:3333::3333/128 exact;
        }
        then accept;
    }
}
routing-options {
    autonomous-system 100;
}

Junos requires you to active the family inet6 address family on the core-facing interface, even if no address is applied. LDP is configured. BGP has been configured with family inet6 address family only. You also need to send labelled unicast as well as explicit-null. Junos will not commit if you leave this out.

I’ve then redistributed my IPv6 loopback address into BGP.

R4 – IOS

interface Loopback6
 no ip address
 ipv6 address 2001:DB8:4444::4444/128
!
interface Loopback0
 ip address 4.4.4.4 255.255.255.255
 ip ospf 1 area 0
!
interface FastEthernet1/0.24
 encapsulation dot1Q 24
 ip address 10.0.4.9 255.255.255.252
 ip ospf network point-to-point
 mpls ip
!
router bgp 100
 no bgp default ipv4-unicast
 bgp log-neighbor-changes
 neighbor 3.3.3.3 remote-as 100
 neighbor 3.3.3.3 update-source Loopback0
 neighbor 8.8.8.8 remote-as 100
 neighbor 8.8.8.8 update-source Loopback0
 !
 address-family ipv6
  no synchronization
  network 2001:DB8:4444::4444/128
  neighbor 3.3.3.3 activate
  neighbor 3.3.3.3 send-label
  neighbor 8.8.8.8 activate
  neighbor 8.8.8.8 send-label
 exit-address-family

IOS is a bit easier. Create my loopback, IPv6 unicast BGP sessions with send-label configured, and advertise IPv6 loopback.

R8 – Netiron

interface loopback 1
 ip ospf area 0
 ip address 8.8.8.8/32
 ipv6 address 2001:db8:8888::8888/128
!
router bgp
 local-as 100
 next-hop-mpls
 neighbor 3.3.3.3 remote-as 100
 neighbor 3.3.3.3 update-source 8.8.8.8
 neighbor 4.4.4.4 remote-as 100
 neighbor 4.4.4.4 update-source 8.8.8.8

 address-family ipv6 unicast
 network 2001:db8:8888::8888/128
 neighbor 3.3.3.3 activate
 neighbor 3.3.3.3 send-label
 neighbor 4.4.4.4 activate
 neighbor 4.4.4.4 send-label
 exit-address-family
!
router mpls

 mpls-interface ve2
  ldp-enable

Very similar to IOS here.

Verification

First let’s see if each of our boxes has the IPv6 routes to the others loopbacks:

USER3:R3> show route 2001:db8:4444::4444/128

inet6.0: 9 destinations, 10 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

2001:db8:4444::4444/128
                   *[BGP/170] 00:19:31, MED 0, localpref 100, from 4.4.4.4
                      AS path: I
                    > to 10.0.4.14 via ae1.13, Push 16, Push 300016(top)

USER3:R3> show route 2001:db8:8888::8888/128

inet6.0: 9 destinations, 10 routes (9 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

2001:db8:8888::8888/128
                   *[BGP/170] 21:40:12, MED 0, localpref 100, from 8.8.8.8
                      AS path: I
                    > to 10.0.4.14 via ae1.13, Push 794624, Push 300048(top)
7200_SRD_R4#show ipv6 route 2001:DB8:3333::3333/128
Routing entry for 2001:DB8:3333::3333/128
  Known via "bgp 100", distance 200, metric 0, type internal
  Route count is 1/1, share count 0
  Routing paths:
    3.3.3.3%default indirectly connected
      MPLS Required
      Last updated 00:20:47 ago

7200_SRD_R4#show ipv6 route 2001:DB8:8888::8888/128
Routing entry for 2001:DB8:8888::8888/128
  Known via "bgp 100", distance 200, metric 0, type internal
  Route count is 1/1, share count 0
  Routing paths:
    8.8.8.8%default indirectly connected
      MPLS Required
      Last updated 00:21:00 ago
SSH@XMR_R8#show ipv6 route 2001:db8:3333::3333/128
Type Codes - B:BGP C:Connected I:ISIS L:Local O:OSPF R:RIP S:Static
BGP  Codes - i:iBGP e:eBGP
ISIS Codes - L1:Level-1 L2:Level-2
OSPF Codes - i:Inter Area 1:External Type 1 2:External Type 2
STATIC Codes - d:DHCPv6
Type IPv6 Prefix           Next Hop Router    Interface     Dis/Metric     Uptime src-vrf
Bi   2001:db8:3333::3333/128
                           ::                 LDP (5)       200/0          8m3s   -
label information: 2(OUT)
SSH@XMR_R8#show ipv6 route 2001:db8:4444::4444/128
Type Codes - B:BGP C:Connected I:ISIS L:Local O:OSPF R:RIP S:Static
BGP  Codes - i:iBGP e:eBGP
ISIS Codes - L1:Level-1 L2:Level-2
OSPF Codes - i:Inter Area 1:External Type 1 2:External Type 2
STATIC Codes - d:DHCPv6
Type IPv6 Prefix           Next Hop Router    Interface     Dis/Metric     Uptime src-vrf
Bi   2001:db8:4444::4444/128
                           ::                 LDP (3)       200/0          7m25s  -
label information: 16(OUT)

Control plane looks fine. Routes are installed with next-hops associated with labels. Let’s see if data actually flows:

USER3:R3> ping 2001:db8:4444::4444 source 2001:db8:3333::3333 rapid count 5
PING6(56=40+8+8 bytes) 2001:db8:3333::3333 --> 2001:db8:4444::4444
!!!!!
--- 2001:db8:4444::4444 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 1.262/1.399/1.789/0.196 ms
7200_SRD_R4#ping 2001:DB8:8888::8888 source lo6

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:8888::8888, timeout is 2 seconds:
Packet sent with a source address of 2001:DB8:4444::4444
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/0/0 ms
SSH@XMR_R8#ping ipv6 2001:db8:3333::3333 source 2001:db8:8888::8888 count 5
Sending 5, 16-byte ICMPv6 Echo to 2001:db8:3333::3333
timeout 5000 msec, Hop Limit 64
Type Control-c to abort
Reply from 2001:db8:3333::3333: bytes=16 time=1ms Hop Limit=64
Reply from 2001:db8:3333::3333: bytes=16 time<1ms Hop Limit=64
Reply from 2001:db8:3333::3333: bytes=16 time<1ms Hop Limit=64
Reply from 2001:db8:3333::3333: bytes=16 time<1ms Hop Limit=64
Reply from 2001:db8:3333::3333: bytes=16 time<1ms Hop Limit=64
Success rate is 100 percent (5/5), round-trip min/avg/max=0/0/1 ms.

All looks good to me.

You can find part 2 here: hhttp://mellowd.co.uk/ccie/?p=3546