v6l3 rethoughts...

just as i thought, the tunneling part of this was easy but i managed to make it difficult... also, this topology taught me about me...

i've found over time that ipv6 isn't at all tough; making mistakes with the addressing is easy.... another thing that often gets me is that when you change the ipv6 address on an interface, or more importantly, get rid of the address and add a new one, that interface loses it's ipv6 routing, and must be re-added...

so i began again, as i do...

this time i started with the serial connection between r4 and r3... i double checked the ipv4 addressing, and established that connectivity first... you'll note in the topology that the addressing between r4 and r3 is not correct...

i caught this the first time through... it's painfully obvious that 10.1.1.8/30 cannot possibly end in 1 and 2 on either side... but you were all over that...

R3#sh run int s1/2
Building configuration...

Current configuration : 88 bytes
!
interface Serial1/2
 ip address 10.1.1.9 255.255.255.252

R3#ping 10.1.1.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/18/20 ms

R3#sh run int tun0
Building configuration...

Current configuration : 123 bytes
!
interface Tunnel0
 no ip address
 ipv6 address 2026::34:1/122
 tunnel source 10.1.1.9
 tunnel destination 10.1.1.10

the tunneling will use gre by default... there is  no more config needed... however, for me, as soon as i see v6, i instantly add ipv6 unicast-routing and ipv6 cef as a knee jerk to all the devices... good habit...

R3#sh run int tun0
Building configuration...

Current configuration : 123 bytes
!
interface Tunnel0
 no ip address
 ipv6 address 2026::34:1/122
 tunnel source 10.1.1.9
 tunnel destination 10.1.1.10

R4#sh int tun0
Tunnel0 is up, line protocol is up
  Hardware is Tunnel
  MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation TUNNEL, loopback not set
  Keepalive not set
  Tunnel source 10.1.1.10, destination 10.1.1.9
  Tunnel protocol/transport GRE/IP

R3#sh ipv6 route
IPv6 Routing Table - default - 3 entries

C   2026::34:0/122 [0/0]
     via Tunnel0, directly connected
L   2026::34:1/128 [0/0]
     via Tunnel0, receive
L   FF00::/8 [0/0]
     via Null0, receive

my usual approach to configuration is this:

start by establishing basic connectivity throughout...  which to me means, simple l2 and l3 between directly connected interfaces...

where i deviated here is in avoiding the tunnel until the end...

what this taught me about my methodology?

that that will not change, however in a case like this, basic connectivity also includes the tunnel... duh...

quote of the day, overlay...

from:

VPNs Illustrated: Tunnels, VPNs, and IPsec
 By Jon C. Snader


the next time someone mentions overlay, look at them like they have five heads and say:

The fundamental mechanism that allows us to have secure communications in the Internet is the notion of a tunnel. As we'll see, tunnels are a way of overlaying a logical or virtual network on top of a physical network. Once we have such a tunnel, we can secure it by encrypting and authenticating the network traffic that flows through it, thus recreating the security of private leased lines.