I came across an interesting question in the Cisco Learning Network forums a couple of weeks ago about OSPFv3 virtual-link behavior. The problem was this:

No loopback interfaces on any of the routers are advertized into the OSPFv3 processes. But, a route to R2 and R3′s loopback addresses appeared in the routing tables of all of the routers.

This behavior was not seen in an OSPFv2 (IPv4) lab. I had the OP run some commands and send me the config. I was completely stumped. Nothing obvious popped into my mind, so I decided to lab it up as the OP’s frustration had become mine too.

The Topology

Each of the four routers has a loopback address:

R1: FEC0:1::1/128

R2: FEC0:2::2/128

R3: FEC0:3::3/128

R4: FEC0:4::4/128

Here’s the configuration on R2:

interface Loopback0
no ip address
ipv6 address FEC0:2::2/128
!
interface FastEthernet1/0
no ip address
duplex auto
speed auto
ipv6 address autoconfig
ipv6 ospf 1 area 0
!
interface FastEthernet1/1
no ip address
duplex auto
speed auto
ipv6 address autoconfig
ipv6 ospf 1 area 11
!
ipv6 router ospf 1
router-id 2.2.2.2
log-adjacency-changes
area 11 virtual-link 3.3.3.3
!

And the show ipv6 protocols output:

R2#sh ipv6 proto
IPv6 Routing Protocol is “connected”
IPv6 Routing Protocol is “static”
IPv6 Routing Protocol is “ospf 1″
Interfaces (Area 0):
OSPFv3_VL0
FastEthernet1/0
Interfaces (Area 11):
FastEthernet1/1
Redistribution:
None
R2#

You’ll have to trust me – the configuration is the same on R3, the loopback isn’t advertised, and the Ethernet interfaces are set to autoconfig then advertized into OSPFv3. In trouble-shooting, I removed the virtual link to see if the routes disappeared.

R2(config)#ipv6 router ospf 1
R2(config-rtr)#no area 11 virtual-link 3.3.3.3
R2(config-rtr)#
*Jul 15 14:16:18.631: %OSPFv3-5-ADJCHG: Process 1, Nbr 3.3.3.3 on OSPFv3_VL0 from FULL to DOWN, Neighbor Down: Interface down or detached
R2(config-rtr)#

Then I looked at the v6 routing table on R1:

R1#sh ipv6 route
<–unimportant output omitted –>
L FE80::/10 [0/0]
via ::, Null0
LC FEC0:1::1/128 [0/0]
via ::, Loopback0
OI FEC0:3::3/128 [110/2]
via FE80::C801:BFF:FE7C:1C, FastEthernet1/0
L FF00::/8 [0/0]
via ::, Null0
R1#

R2′s loopback was no longer there, but R3′s was. Hmmm, I checked R3′s configuration and made sure it wasn’t advertizing its loopback. It wasn’t, so I removed the virtual-link config from R3, and then the loopback dropped off R1 and R4:

R1#sh ipv6 route
<–unimportant output omitted –>
L FE80::/10 [0/0]
via ::, Null0
LC FEC0:1::1/128 [0/0]
via ::, Loopback0
L FF00::/8 [0/0]
via ::, Null0

R4#sh ipv6 route
<–unimportant output omitted –>
L FE80::/10 [0/0]
via ::, Null0
LC FEC0:4::4/128 [0/0]
via ::, Loopback1
L FF00::/8 [0/0]
via ::, Null0

The Answer Is In The RFC

Okay, so why on earth is the virtual-link causing the loopbacks to be advertized?! It was driving me nuts, so I tried trawling through search results looking for an answer. I found nothing that jumped out at me. I *had* to know why this was happening, and I knew the obvious answer was right in front of me. Yes, it was time to read the riveting OSPFv3 RFC 2740.

Sure enough, the RFC yielded the answer:

Neighbor IP address
Except on virtual links, the neighbor’s IP address will be an IPv6
link-local address.

IP interface address
For IPv6, the IPv6 address appearing in the source of OSPF packets
sent out the interface is almost always a link-local address. The
one exception is for virtual links, which must use one of the
router’s own site-local or global IPv6 addresses as IP interface
address.

Aha! Suddenly, it all made sense. The Ethernet interfaces connecting the routers are all set to autoconfig, so OSPFv3 used the only non link-local address it could find, which happened to be the loopback address on each of the routers. Because OSPFv3 uses the loopbacks to communicate with the neighbors, it also advertises a route to it.

R2#sh ipv6 ospf neighbor 3.3.3.3
Neighbor 3.3.3.3
In the area 0 via interface OSPFv3_VL1
Neighbor: interface-id 12, IPv6 address FEC0:3::3
Neighbor priority is 1, State is FULL, 6 state changes
Options is 0x65963A85
Neighbor is up for 00:00:40
Index 1/2/3, retransmission queue length 0, number of retransmission 0
First 0×0(0)/0×0(0)/0×0(0) Next 0×0(0)/0×0(0)/0×0(0)
Last retransmission scan length is 0, maximum is 0
Last retransmission scan time is 0 msec, maximum is 0 msec