Setting up OSPFv3 on a broadcast network

Setting up OSPFv3 (IPv6) doesn't require much effort if you already know EIGRPv6, which I covered in my last post.  There are differences, obviously, such as OSPF using an independent process number instead of a network-wide AS number like EIGRP.  As well, OSPF pools updates into a hub type of configuration known as a DR and BDR on broadcast type networks, such as Ethernet, whereas EIGRP requires that all neighbors talk to all other neighbors, thus being a tad more wasteful.  But aside from these major differences, the configurations are similar, also applied on a sub interface level.  We simply tell the IOS which interfaces are to be active in the OSPF conversation and any networks assigned to them end up being exchanged.

We are using a similar setup as with EIGRP, except now there are four routers connected via Metro Ethernet (it looks like a LAN switch to IOS) - Bloor, Booth, Kensington and the new Spadina office.  In the EIGRPv6 tutorial, I configured IPv6 addresses on the WAN side as I'm used to doing that in the IPv4 world, but there is no need for that anymore, since the interfaces use LLA (link-local addresses) for routing protocols on the same data link.  If the WAN interfaces are going to be reachable via IPv6 for other purposes they should obviously have an address other than an LLA, as LLAs are not routable, unlike GUAs (global unicast addresses).

Addressing

We're using the same addressing scheme as for EIGRP, with the addition of the Spadina router.

Engineering (Bloor)
2001:4:4:4::/64
2001:5:5:5::/64
2001:6:6:6::/64
2001:7:7:7::/64
FD00:8:8:8::/64

Sales (Kensington)
2001:1:1:1::/64

Support (Booth)
2001:2:2:2::/64
2001:3:3:3::/64

Datacentre (Spadina)
2001:9:9:9::/64 
 

Config

Before enabling OSPFv3, let's take a look at what an interface on Spadina looks like.

spadina#show ipv6 interface FE0/1
FastEthernet0/1 is up, line protocol is up
  IPv6 is enabled, link-local address is FE80::20C:26FF:FE50:8795
  Global unicast address(es):
  2001:9:9:9::1, subnet is 2001:9:9:9::/64
  Joined group address(es):
    FF02::1
    FF02::2
    FF02::1:FF00:1
    FF02::1:FF50:8795
  MTU is 1500 bytes
  ICMP error messages limited to one every 100 milliseconds
  ICMP redirects are enabled
  ND DAD is enabled, number of DAD attempts: 1
  ND reachable time is 30000 milliseconds
  Hosts use stateless autoconfig for addresses.

Third line is the header "Global unicast address(es:", below which we see that the :9 address is assigned properly.  Below it IOS has automatically joined this interface to several address groups.  Notably FF02:1 for all IPv6 devices, and FF02:2 for all IPv6 routers (as opposed to hosts).

Let's look at a similar config on Bloor, which has many more networks:

bloor#show ipv6 interface FE0/1
FastEthernet0/1 is up, line protocol is up
  IPv6 is enabled, link-local address is FE80::20C:21FF:FE10:5542
  Global unicast address(es):
  2001:4:4:4::1, subnet is 2001:4:4:4::/64
  2001:5:5:5::1, subnet is 2001:5:5:5::/64
  2001:6:6:6::1, subnet is 2001:6:6:6::/64
  2001:7:7:7::1, subnet is 2001:7:7:7::/64
  FD00:8:8:8::1, subnet is FD00:8:8:8::/64
  Joined group address(es):
    FF02::1
    FF02::2
    FF02::1:FF00:1
    FF02::1:FF10:5542
  MTU is 1500 bytes
  ICMP error messages limited to one every 100 milliseconds
  ICMP redirects are enabled
  ND DAD is enabled, number of DAD attempts: 1
  ND reachable time is 30000 milliseconds
  Hosts use stateless autoconfig for addresses.

Very similar output, except there are simply more entries below the third line header.  We see that this router is connected to 4 subnets in 2001 block and one subnet in the unique local FD00 range.  Technically these are called prefixes, but Cisco still retains the term subnet in the IOS.

Now let's configure OSPFv3 on Spadina:

spadina#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
spadina(config)#ipv6 router ospf 137
% IPv6 routing not enabled.

We get an error if we try it out of the blue.  IOS will not let us configure any IPv6 protocols unless IPv6 unicast routing is enabled beforehand.  The IPv6 routing process won't run without the ipv6 unicast-routing global command and without this process none of the routing processes for IPv6 have anything to latch onto.

spadina(config)#ipv6 unicast-routing
spadina(config)#ipv6 router ospf 137
*Oct 22 14:55:07.539: %OSPF-4-NORTRID: OSPF process 137 cannot pick a router-id.
  Please configure manually or bring up an interface with an ip address.

We have successfully enabled IPv6 unicast routing, but failed to start the OSPFv3 process.  The router ID, just like with EIGRP, must be configured manually via the router-id router sub command if no IPv4 interfaces are up/up.  This is because the RID is still a 32-bit value, and cannot arbitrarily pick it's own value, nor is there currently any mechanism for deriving one from the IPv6 128-bit value.  We can easily add a RID after this error message or by entering router ospf 137 first from the configure mode.

spadina(config-rtr)#router-id 1.1.1.1

That wasn't so hard!  Please note that the 137 after ospf is the process ID, and is usually an arbitrary number chosen by you, the network administrator.  It doesn't have to be 137, most people usually settle on 1 with the command router ospf 1.  These numbers also don't have to match from one router to the next, as you'll see in our Bloor config, we use a different number.  It simply identifies the process number within the IOS hierarchy, and has no bearing on routing nor on packet flow.  In EIGRP, the number in the router eigrp 701 was the autonomous system number and it had to match across the whole EIGRP network.  With OSPF, it doesn't have to match.

Next we add our interface to the OSPFv3 process.  OSPF will automatically pick up any configured prefixes (subnets) from the interface config and start sending an LSA (LSU!) to the DRs and BDRs, which are two elected routers.  Let's configure the interface:

spadina#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
spadina(config)#int FE0/1
spadina(config-if)#ipv6 ospf 137 ?
area                    Set the OSPF area ID
spadina(config-if)#ipv6 ospf 137 area 0

That's all it takes to add an interface with all its subnets to OSPF for exchange.  To verify we can use the show ipv6 protocols command:

spadina#show ipv6 protocols
IPv6 Routing Protocol is "connected"
IPv6 Routing Protocol is "static"
IPV6 Routing Protocol is "ospf 137"
  Interfaces (Area 0):
    FastEthernet0/1
  Redistribution:
    None

As you can tell the interface has been added to Area 0.  OSPF is a bit more efficient than EIGRP.  Whereas in EIGRP we had to configure an autonomous system (AS) number for the whole network, with OSPF we configure areas to break up the network into smaller chunks.  Area 0 was configured with the "area 0" keyword.  It is known as the backbone area, and all other areas must be connected to it.  Only a router may connect one area to another.  This means that a router that connects any area to the backbone will have to be a part of both areas, and thus will require two commands for that interface with different area numbers, obviously.  This type of router is called an ABR (area border router).  We will not be configuring any of those, as that's a bit more advanced.  Just remember that in order to speed up routing updates, the routing tables get broken up into areas, that way only routes within each area get updated and nothing from the outside.  Now let's configure Bloor:

bloor(config)#ipv6 unicast-routing
bloor(config)#ipv6 router ospf 37
*Oct 22 15:08:11.518: %OSPF-4-NORTRID: OSPF process 37 cannot pick a router-id.
  Please configure manually or bring up an interface with an ip address.
bloor(config-rtr)#router-id 2.2.2.2
bloor(config-rtr)#exit
bloor(config)#int FE0/1
bloor(config-if)#ipv6 ospf 37 area 0
bloor(config-if)#end
bloor#show ipv6 protocols
IPv6 Routing Protocol is "connected"
IPv6 Routing Protocol is "static"
IPV6 Routing Protocol is "ospf 37"
  Interfaces (Area 0):
    FastEthernet0/1
  Redistribution:
    None

We've done all the same things as on Spadina.  The only difference is that here we've chosen a different process ID, 37.  We're being funny with these numbers just to illustrate they don't need to match, it would have made more sense in a production environment to pick something easier to troubleshoot like 1 obviously.

We've gone ahead and configured the other two routers.  If we look at the output of show ipv6 ospf on the Booth router we get a lot of, mostly, useless statistics:

booth#show ipv6 ospf
 Routing Process "ospf 1" with ID 4.4.4.4
 Supports only single TOS(TOS0) routes
 Supports opaque LSA
 Supports Link-local Signaling (LLS)
 Supports area transit capability
 Initial SPF schedule delay 5000 msecs
 Minimum hold time between two consecutive SPFs 10000 msecs
 Maximum wait time between two consecutive SPFs 10000 msecs
 Incremental-SPF disabled
 Minimum LSA interval 5 secs
 Minimum LSA arrival 1000 msecs
 LSA group pacing timer 240 secs
 Interface flood pacing timer 33 msecs
 Retransmission pacing timer 66 msecs
 Number of external LSA 0. Checksum Sum 0x000000
 Number of opaque AS LSA 0. Checksum Sum 0x000000
 Number of DCbitless external and opaque AS LSA 0
 Number of DoNotAge external and opaque AS LSA 0
 Number of areas in this router is 1. 1 normal 0 stub 0 nssa
 Number of areas transit capable is 0
 External flood list length 0
    Area BACKBONE(0)
       Number of interfaces in this area is 1
       Area has no authentication
       SPF algorithm last executed 00:00:00 ago
       SPF algorithm executed 1 times
       Area ranges are
       Number of LSA 1. Checksum Sum 0x00A797
       Number of opaque link LSA 0. Checksum Sum 0x000000
       Number of DCbitless LSA 0
       Number of indication LSA 0
       Number of DoNotAge LSA 0
       Flood list length 0

The important bit here is the first line which tells us the OSPF process number, in this case 1, and the router ID is 4.4.4.4, though the word "router" is omitted from router ID and it just says ID.  The IOS is funky like that sometimes.  But we still won't have any DRs, BDRs, nor routes being exchanged.  This is because all of these interface configs were done on our LAN interfaces.  We also need to enable OSPF on the WAN interfaces so that the LAN subnets can be exchanged.  This is easily done and is nearly identical.  Here is an example from Spadina:

spadina(config)#int FE0/0
spadina(config-if)#ipv6 ospf 137 area 0
OSPFv3: No IPv6 enabled on this interface.

Uh-Oh!  What does this mean?  I thought interfaces didn't need specific IPv6 addresses assigned to them since ULA (unique local addresses) took care of that on data-links for us.  Why doesn't this interface have an FE80 address already assigned to it?  Clearly without an IPv6 address, we can't enable OSPFv3 on an interface.  That would be like asking for mail to be delivered to a house that hasn't been issued a street number yet.

FE80 addresses (ULAs) are only assigned by IOS when the first ipv6 address command is issued.  Until then, the interface remains unassigned in the IPv6 realm and no routing protocols may be enabled.  So we go ahead and assign an IPv6 address for the magic to begin:

spadina(config-if)#ipv6 address FD00:1:1:1::4/64
spadina(config-if)#ipv6 ospf 137 area 0

The rest of the routers are numbered just like in the EIGRPv6 Triangle tutorial:

Bloor
FD00:1:1:1::1

Kensington
FD00:1:1:1::2

Booth
FD00:1:1:1::3

Spadina
FD00:1:1:1::4

That's all it takes.  After a short delay we get this on our consoles:

*Oct 22 15:47:04.799: %OSPF-5-ADJCHG: Process 137, Nbr 3.3.3.3 on FastEthernet0/0 from LOADING to FULL, Loading Done
*Oct 22 15:47:04.193: %OSPF-5-ADJCHG: Process 137, Nbr 4.4.4.4 on FastEthernet0/0 from LOADING to FULL, Loading Done

These two lines tell us that we have formed an adjacency with two neighbors.  The Nbr part is short for Router-ID, and it tells us that routers 3.3.3.3 and 4.4.4.4 have gone from a LOADING phase, whereby the LSA are being exchanged, to a FULL state, whereby all the LSA are finished transferring.  We can check our OSPFv3 neighbors to be sure:

spadina#show ipv6 ospf neighbo
Neighbor ID     Pri   State           Dead Time   Interface ID    Interface
3.3.3.3           1   FULL/DR         00:00:40    3               FastEthernet0/0
2.2.2.2           1   2WAY/DROTHER    00:00:40    3               FastEthernet0/0
4.4.4.4           1   FULL/BDR        00:00:40    3               FastEthernet0/0

As you can see, we have three neighbors, but we only have full adjacencies with two of them.  The router with RID 2.2.2.2 is not in a FULL state, but in a 2WAY state, which comes before FULL.  This means we are not exchanging LSAs with it.  The router 3.3.3.3 is the DR (as noted after the word FULL), which means it's the designated router.  It's backup is the BDR, which is 4.4.4.4.  In case the DR goes down, the BDR takes over.  No matter how many OSPFv3 routers are on this network, there will ever only be two adjacencies, one with the DR and one with the BDR.  All other routers will be in a 2WAY/DROTHER state if they are fully configured.  They will still have the same routing table, but will have received it from the DR and not from each of the other routers.  Basically the DR (and BDR) act as a kind of a hub in a hub and spoke network.  The routers send their LSAs to the two of them, and they are in turn responsible for updating the rest of the network.  This is counter to the way EIGRP works, where each router forms a neighbor relationship with every other router, which is kinda wasteful.

We can now look at the routing table:

spadina#show ipv6 route
IPv6 Routing Table
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
       D - EIGRP, EX - EIGRP external
C   FD00:1:1:1::/64 [0/0]
     via FastEthernet0/0, directly connected
L   FD00:1:1:1::4/128 [0/0]
     via FastEthernet0/0, receive
C   2001:9:9:9::/64 [0/0]
     via FastEthernet0/1, directly connected
L   2001:9:9:9::1/128 [0/0]
     via FastEthernet0/1, receive
O   2001:1:1:1::/64 [110/2]
     via FE80::20C:39FF:FE62:6232, FastEthernet0/0
O   2001:2:2:2::/64 [110/2]
     via FE80::20C:31FF:FE68:8461, FastEthernet0/0
O   2001:4:4:4::/64 [110/2]
     via FE80::20C:84FF:FE99:1947, FastEthernet0/0
L   FF00::/8 [0/0]
     via Null0, receive

All the routes that start with O on the far left are from the OSPF process.  We see all the routes have made it, despite the various routers having differing process IDs.  However, we see that only the 2001:4:4:4::/64 network has made it from Bloor.  What happened to the rest?  Well kind of like with EIGRP, we did not configure redistribute connected command, which would have inserted all the connected routes into OSPF.  Without this command, IOS only can add an LSA for the first network of an interface.  The rest just get ignored by the OSPF process.

Enjoy!

Setting up an EIGRPv6 triangle

A while back LIST (Latitude Internet Security Team) wanted to test out EIGRPv6 in three of their offices in Toronto.  The WAN product they used was Metro Ethernet whereby all three routers appear like any other Ethernet hosts to each other, and that made matters relatively simple despite the distances involved.  On the provided diagram the offices are labelled according to their physical locations.  Bloor is located near Toronto's Yorkville offices on Bloor street.  Booth is located on Booth Avenue just south of East Chinatown near Queen Street across the lovely Jimmie Simpson park.  And the final part of the triangle is located in an office at the Kensington Market.

Addressing

Since this was an internal test, all neighbor interfaces were configured using ULA (unique local addressing).  GUA (global unicast addressing) could have also been used to make it routable but that wasn't a requirement, and it's a bit safer to use ULA during this type of test anyway.  ULA space is FC00::/7, however RFC 4193 practically limits this range to the FD00::/8 block so all our addresses will start with FD00.  While section 3.2.2 of the RFC directs us on how to choose our ULA prefix through a pseudo-random process, as our test will be run once and there won't be a feasable successor network after it (that's an EIGRP joke!) we will use the simplified prefix of FD00:1:1:1::/64 for all neighbors.  This strategy should not be used in large enterprises as in case of mergers it would yield duplicate addressing problems the kind everyone would sooner avoid.

EIGRPv6 Neighbor addressing is as follows:

Bloor
FD00:1:1:1::1

Kensington
FD00:1:1:1::2

Booth
 FD00:1:1:1::3

These will be the only addresses establishing EIGRPv6 neighbors.  We use IPv6 internally, but for this test we'll be exchanging a mix of GUAs and ULAs.  The addressing is as follows:

Engineering (Bloor)
2001:4:4:4::/64
2001:5:5:5::/64
2001:6:6:6::/64
2001:7:7:7::/64
FD00:8:8:8::/64

Sales (Kensington)
2001:1:1:1::/64


Support (Booth)
2001:2:2:2::/64
2001:3:3:3::/64

As you can tell our Engineering team uses the most network space followed by the Support team.  Once again this addressing scheme isn't to be used in the real world as these addresses could very well be assigned to someone else by IANA, we use it here for this test only.

Config

Before configuring EIGRPv6 we need to establish basic IPv6 connectivity, meaning all three routers need to be placed into the same prefix (subnet), and for that we've chosen FD00:1:1:1::/64.

First we assign an IPv6 address on the Bloor router's FastEthernet0/0:
bloor(config)#int FE 0/0
bloor(config-if)#ipv6 address FD00:1:1:1::1/64

Next we do the same to Booth but we make a mistake the first time by holding down shift a bit too long, a typical error when typing IPv6 addresses quickly.  This error may throw you off because IOS does not put the ^ market at the exact point where the ! is located instead of the 1:
booth(config)#int FE 0/0
booth(config-if)#ipv6 address FD00:1:1:!::3/64
                             ^
% Invalid input detected at '^' marker.

booth(config-if)#ipv6 address FD00:1:1:1::3/64
booth(config-if)#^Z

Lastly we configure Kensington and thus establishing full IPv6 connectivity:
kensington(config)#int FE 0/0
kensington(config-if)#ipv6 address FD00:1:1:1::2/64

It's always good to test connectivity with a simple ping, so we do that from the Booth router as that's where the Support team is located.  First we do an extended ping to show how that it yields the same results as a normal ping:

booth#ping
Protocol [ip]: ipv6
Target IP address: FD00:1:1:1::1
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:

Type escape sequence to abort.
Sending  5,  100-byte ICMP Echos to FD00:1:1:1::1, timeout is  2 seconds:
!!!!!
Success rate is 100 percent ( 5/ 5), round-trip min/avg/max = 1/2/4 ms
booth#
booth#ping FD00:1:1:1::2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FD00:1:1:1::2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

Before configuring EIGRP we must decide on an AS (autonomous system) number for our network.  As it's network wide it must match on all three routers.  We use 701 internally.  The command to configure EIGRP is ipv6 router eigrp 701 in this case, but as you can see something went wrong.

bloor#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
bloor(config)#ipv6 router eigrp ?
<1-65535>               Autonomous system number
bloor(config)#ipv6 router eigrp 701
%IPv6 unicast routing not enabled.

Before any IPv6 routing protocol is enabled, unicast routing must be enabled globally in IOS.  Here is the corrected config that works:

bloor(config)#ipv6 unicast-routing
bloor(config)#ipv6 router eigrp 701
bloor(config-rtr)#no shut

These commands don't produce any errors and so we enter them on all three routers.  The final command, no shut, may seem strange as it's usually associated with interfaces.  Cisco chose to maintain consistency when implementing this method.  The EIGRP process is in a shutdown state when created with the router eigrp command, without this little guy the whole thing wouldn't provide any exchange of routes.  So ensure you remember this bit.

So let's see what interfaces are exchanging EIGRP routes:
booth#show ipv6 eigrp interfaces
IPv6-EIGRP interfaces for process 701
% No router ID for EIGRP 701

Uh-oh!  Here is a key problem.  Although we are using IPv6 with it's 128-bit addressing, the RID (router-ID) that EIGRP (and OSPF) rely on is still a 32-bit value.  A RID is required for neighbors to form, and since the IOS cannot arbitrarily create one from the 128-bit interface addresses, we must provide a value here via the config.  RIDs don't have to be actual IP addresses, so we'll use 1.1.1.1 for Bloor, 2.2.2.2 for Kensington, and 3.3.3.3 for Booth.  These addresses are inline with our IPv6 naming convention, thus making it easier to remember and associate during debugging of issues.  We'll only show the config on Bloor, but the config is identical on the other two devices, with the obvious difference being the number placed into the config.

bloor(config)#ipv6 router eigrp 701
bloor(config-rtr)#router-id ?
a.b.c.d                 EIGRP Router-ID in IP address format
bloor(config-rtr)#router-id 1.1.1.1

We now run our show ipv6 eigrp interfaces command, and still we have nothing showing, but this time we don't get an error.

booth#show ipv6 eigrp interfaces
IPv6-EIGRP interfaces for process 701

                        Xmit Queue   Mean   Pacing Time   Multicast    Pending
Interface        Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
booth#

What gives?  Well, EIGRPv6 is running.  But there are no indications what networks it should exchange and on what interface it should exchange them on.  This is configured using the interface subcommand ipv6 eigrp 701 on all three routers.  Here is an example on Bloor, but we do the same exact command on the other two routers.

bloor(config)#int FE 1/0
bloor(config-if)#ipv6 eigrp ?
<1-65535>               Autonomous system number
bloor(config-if)#ipv6 eigrp 701

That has enabled the EIGRPv6 process on each of the interfaces connected to our "LAN" (aka Metro Ethernet WAN).  But wait!  It still won't work.  How does EIGRP know what networks to advertise?  How does it know on what interfaces to look for neighbors?  We have to tell IOS these things specifically, it's not going to make any assumptions for us.  EIGRPv6 doesn't allow for specific networks to be listed, instead it picks up the prefixes from the interfaces it is enabled on.  The interface subcommand is ipv6 eigrp 701 and here is an example from Bloor.  We use the exact same command on the other two routers:

bloor(config)#int FE0/0
bloor(config-if)#ipv6 eigrp 701
bloor(config-if)#^Z
%SYS-5-CONFIG_I: Configured from console by console

*Oct 20 09:12:46.929: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 701: Neighbor FE80::20C:84FF:FE99:1947 (FastEthernet0/0) is up: new adjacency

What happened there was that a moment after adding this command, as the other router was already configured with the same command, the adjacency came up and we were notified of this fact by IOS on the console.  Now we can look at various EIGRP outputs.  Let's look from the Booth router:

booth#show ipv6 eigrp neighbors
IPv6-EIGRP neighbors for process 701
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
                                            (sec)         (ms)       Cnt Num
0   Link-local address:     Fa0/0             14 00:08:39  936  5616  0  4 
    FE80::20C:39FF:FE62:6232
1   Link-local address:     Fa0/0             14 00:07:04  291  1746  0  4 
    FE80::20C:31FF:FE68:8461

As you can see, Booth has two neighbors.  However EIGRPv6 doesn't use the FD00 addresses we've assigned the interfaces.  Instead it uses a third type of address, called a link-local address (LLA).  This is a self-generated address.  If you look at the very middle it has FF:FE.  This is part of the EUI-64 auto-addressing rule whereby the MAC address is split in half, the FF:FE is inserted in the middle, and the 7th bit from the left is inverted.  This is attached to the FE80:: prefix and thus the LLA is formed.  It is not routable, and only serves for communication on the local network, such as Ethernet in this case.

If we look at the routing table we see our routes as expected:
booth#show ipv6 route
IPv6 Routing Table
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
       D - EIGRP, EX - EIGRP external
C   FD00:1:1:1::/64 [0/0]
     via FastEthernet0/0, directly connected
L   FD00:1:1:1::3/128 [0/0]
     via FastEthernet0/0, receive
C   2001:2:2:2::/64 [0/0]
     via FastEthernet0/1, directly connected
L   2001:2:2:2::1/128 [0/0]
     via FastEthernet0/1, receive
C   2001:3:3:3::/64 [0/0]
     via FastEthernet0/1, directly connected
L   2001:3:3:3::1/128 [0/0]
     via FastEthernet0/1, receive
D   2001:4:4:4::/64 [90/30720]
     via FE80::20C:39FF:FE62:6232, FastEthernet0/0
D   2001:1:1:1::/64 [90/30720]
     via FE80::20C:31FF:FE68:8461, FastEthernet0/0
L   FF00::/8 [0/0]
     via Null0, receive

All our routes are there.  You can see the 2001:4:4:4::/64 being learned, as well as 2001:1:1:1::/64.  These have a D on the left, as per the legend meaning learned via EIGRP.  You might be wondering, if Bloor has more than one network, why did only the 4 network make it into EIGRP?  This is because to have the rest appear in the routing tables we need to use the redistribute connected command which tells the EIGRP process to include all connected routes.  Since this option wasn't enabled, all the routes won't be present.

We can look at some statistics about EIGRP traffic, too:
booth#show ipv6 eigrp traffic
IPv6-EIGRP Traffic Statistics for AS 701
  Hellos sent/received: 110/106
  Updates sent/received: 12/2
  Queries sent/received: 14/10
  Replies sent/received: 5/6
  Acks sent/received: 11/5
  Input queue high water mark 2, 0 drops
  SIA-Queries sent/received: 0/0
  SIA Replies sent/received: 0/0:
  Hello Process ID: 107
  PDM Process ID: 105

The relevant parts are the Hellos and perhaps Updates.  If Hellos are incrementing, everything should be working smoothly.

And so our EIGRP triangle works perfectly.  Aside from a few small glitches as documented above, we ran into zero problems setting this up.  Enjoy your IPv6 journey.