In the NMC Sample lab, R1 is an IPv6 border router between OSPF and BGP. It has a loopback interface on R1-Lo100, FEC0::1111:1/125, which is part of the BGP domain by virtue of:

address-family ipv6
neighbor FE80::3333:3333 activate
neighbor FE80::3333:3333 route-map NH-out out
network FEC0::1111:0/125


R1 forms its peer relationship with R3 as it should, and picks up prefixes from there, which it redistributes into OSPF:

R1#show run | sec ipv6 router ospf
ipv6 router ospf 1
router-id 172.16.10.1
log-adjacency-changes
area 13 virtual-link 172.16.130.1
redistribute bgp 100 metric 20 include-connected


But what about that include-connected? Shouldn’t that get our FEC0::1111:0/125 route into OSPF? Apparently not. I found it necessary to do a redistribute connected as well.

R1#show run | sec ipv6 router ospf
ipv6 router ospf 1
router-id 172.16.10.1
log-adjacency-changes
area 13 virtual-link 172.16.130.1
redistribute connected
redistribute bgp 100 metric 20 include-connected

Conclusion? When redistributing IPv6 BGP into OSPF, the include-connected keyword does not seem to work.

I had an issue going the other way too: OSPF–>BGP. It seems it is not enough just to redistribute:

address-family ipv6
neighbor FE80::3333:3333 activate
neighbor FE80::3333:3333 route-map NH-out out
network FEC0::1111:0/125
redistribute ospf 1 include-connected
no synchronization
exit-address-family


You need to specify what to redistribute:

address-family ipv6
neighbor FE80::3333:3333 activate
neighbor FE80::3333:3333 route-map NH-out out
network FEC0::1111:0/125
redistribute ospf 1 match internal external 1 external 2 include-connected
no synchronization
exit-address-family


I want to look these behaviors up in the Command Reference, but for some reason I cannot find the IPv6 Command Reference documents on the Cisco web site.  I can find the Configuration Guide OK, but not the Command References.  I wrote to their HelpLine about it.

Since we had a couple of holidays this week (week 18), and having given up on lab 18, I thought I would have a go at the sample lab.  Being a showpiece, I thought it might be interesting and representative.

• S7.7 – BGP auto-summary
   
• S.8 – In IPv6, redistribute ospf 1 include-connected does not redistribute the externals by default.  You have to do redistribute ospf 1 match internal external 1 external 2 include-connected.
   
• S.8 – Learned the proper syntax for ipv6 BGP validation commands (instead of guessing) 
  • show bgp ipv6 unicast
  • show bgp ipv6 unicast summary
  • show bgp ipv6 unicast neighbor
     
• S.8 – IPv6 – Redistributing BGP <–> OSPF

Following NMC Lab16, I reloaded my stack, only to find R1 is in a reload loop.  This isn’t the first time it has happened, and it was R1 last time as well.  I wonder if I have a hardware problem, or whether it is an IOS bug.  Last time I managed to fix it by loading without the NVRAM, just like a password recovery, then loading the config once the router was running.  This time, the technique didn’t work; as soon as I pasted in the old config, it would crash again.

So instead, I loaded up the router without the NVRAM config, then added the config section by section.  I narrowed down the crash to a distribute-list in my IPv6 RIP process.  The distribute list was called “default-only”, and I think it didn’t like that for some reason.  It referred to a prefix list that has only the default route in it. Anyway, I shouldn’t have needed it, because the SHOWiT solution is much more elegant: ipv6 rip RIP default-information only.

As someone recently commented, it’s just as well they use that special bug-free version of IOS for the CCIE exam labs!

Busy busy busy, so I only have time for a few notes which I hope I shall expand later.  Just to punish myself for my mistakes …

• 14.4.1 : RIP : I read too much into the requirements.  I read 14.4.1 as meaning that I should set up neighbor relations R2<–>R6<–>R4, but not R2<–>R4.  Then I wondered why there was nothing in the requirements about the route from R2 to 172.16.104.1 and from R4 to 172.16.102.1.  (Of course, the answer would have been no ip split-horizon on R6-F0/0.)  But it seems I “spotted an issue” that wasn’t there in the first place! 
• 14.8.1 : Security : I’m just going to have to sit down and read the Command Reference for all those itty-bitty security commands.  Boring or what!
• 14.9 : IPv6 : Don’t mess about thinking “can I get away without specifying link-local addresses”.  In a frame-relay configuration, they are absolutely essential so that you can set frame-maps to them.  Do them as a matter of course.  Oh, and the pseudo-broadcast should only go to the link-local at the other end of the DLCI, not to any of the others.  I wasted an hour on the IPv6 section that should have taken me half that time.
• 14.10.2 : Layer-3 access list on Catalyst layer-2 port.  This can be done; I know because I do it all the time on my 4500 switches at work.  What I am a bit puzzled at here is that the access-lists don’t seem to be counting packets.  My first attempt didn’t include return traffic for telnet, so I know the access-list is working.  So why doesn’t it count packets?
• 14.11.2 : NAT : ip nat source list 11 pool IG overload will not do instead of ip nat inside source list 11 pool IG overload. I’m not sure what it does without the “inside” keyword, but it does accept the command, and it doesn’t do the job I wanted it to.  Careful!

This is a gotcha that almost anyone who has ever configured IPv6 has tripped over.  One thing it is easy to forget in the heat of the moment is that an interface can have as many IPv6 addresses as you want.

If you are used to configuring IPv4, you are probably used to changing the IP address of an interface and having it do exactly that.  So:

R7#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R7(config)#int Lo7
R7(config-if)#ip address 192.168.7.1 255.255.255.0
R7(config-if)#exit
R7(config)#exit
R7#
*Mar  1 00:02:27.467: %SYS-5-CONFIG_I: Configured from console by console
R7#
R7#show run int Lo7
Building configuration... Current configuration : 65 bytes
!
interface Loopback7
 ip address 192.168.7.1 255.255.255.0
end

Oops, I meant 192.168.17.1:

R7#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R7(config)#int Lo7
R7(config-if)#ip address 192.168.17.1 255.255.255.0
R7(config-if)#exit
R7(config)#exit
R7#
*Mar  1 00:04:13.351: %SYS-5-CONFIG_I: Configured from console by console
R7#show run int Lo7
Building configuration... Current configuration : 66 bytes
!
interface Loopback7
 ip address 192.168.17.1 255.255.255.0
end

That’s better.  Now let’s try the same thing in IPv6:

R7#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R7(config)#int Lo7
R7(config-if)#ipv6 address fec0::7:1/124
R7(config-if)#^Z
R7#
*Mar  1 00:06:49.107: %SYS-5-CONFIG_I: Configured from console by console
R7#show run int Lo7
Building configuration... Current configuration : 94 bytes
!
interface Loopback7
 ip address 192.168.17.1 255.255.255.0
 ipv6 address FEC0::7:1/124
end

Oops, I actually meant FEC7::7:1/124.  FEC0::7:1/124 should have been somewhere else in the topology. Let’s change it:

R7#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R7(config)#int Lo7
R7(config-if)#ipv6 address fec7::7:1/124
R7(config-if)#^Z
R7#
*Mar  1 00:08:29.679: %SYS-5-CONFIG_I: Configured from console by console
R7#

OK, that’s changed it, hasn’t it?  Let’s check:

R7#show run int Lo7
Building configuration... Current configuration : 122 bytes
!
interface Loopback7
 ip address 192.168.17.1 255.255.255.0
 ipv6 address FEC0::7:1/124
 ipv6 address FEC7::7:1/124
end

You see how it hasn’t changed the IPv6 address?  It has just added an extra one.  A real “gotcha”.

I just learned that you can peer IPv6 BGP across link-local addresses, even on a tunnel interface.  This came as a surprise to me.  I had always peered across site local addresses and I had assumed that you could not peer across link-local addresses because they are not unique.

(OTOH, I should not have been surprised.  After all, IPv6 OSPF can form adjacencies across link-local addresses, so why not BGP).

So, if you are going to peer to, say, fe80::5, how does the router know which interface to connect through?  Wel, in the example in this lab, we specify the update source too, so I am guessing that it uses that to determine which interface to connect through.

This has some strange implications.  Suppose you have two link-neighbors, but they both have the address fe80::2.  You can only peer with one of them.  For the other one, you would have to use a unique address.

Futhermore,  if your neighbor is a link-local address, then the update source must be mandatory.

The wierd and wonderful world of IP6!