OSPFv3 Neighbors do not need to be on same subnet

Check it out:

R2 F0/0 <-----> F0/0 R3

Here is R2's config:

R2#sho run int f0/0
Building configuration...

Current configuration : 153 bytes
!
interface FastEthernet0/0
 no ip address
 duplex auto
 speed auto
 ipv6 address 2001:2::2/64
 ipv6 address FE80::2 link-local
 ipv6 ospf 1 area 0
end

Here is R3's config:

R3#sho run int f0/0
Building configuration...

Current configuration : 153 bytes
!
interface FastEthernet0/0
 no ip address
 duplex auto
 speed auto
 ipv6 address 2001:3::3/64
 ipv6 address FE80::3 link-local
 ipv6 ospf 1 area 0
end

R2's show commands:

R2#sho ipv6 ospf ne   

Neighbor ID     Pri   State           Dead Time   Interface ID    Interface
3.3.3.3           1   FULL/DR         00:00:35    4               FastEthernet0/0

R2#sho ipv6 route  
IPv6 Routing Table - 5 entries
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
C   2001:2::/64 [0/0]
     via ::, FastEthernet0/0
L   2001:2::2/128 [0/0]
     via ::, FastEthernet0/0
O   2001:3::/64 [110/10]
     via ::, FastEthernet0/0
L   FE80::/10 [0/0]
     via ::, Null0
L   FF00::/8 [0/0]
     via ::, Null0

R2 can now ping 2001:3::3

R2#ping 2001:3::3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:3::3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/20/56 ms
R2#

This is possible because neighbors are known by their router-ids and link-local addresses are used as next hops, not the actual interface addresses.

Renumbering IPv6 with ease via ipv6 general-prefix

This is rather neat IPv6 feature that eases renumbering. We define a general prefix globally and then assign interface addresses based on that interface. Should you change providers or ever have to renumber the network, all you have to do is change the general prefix. Here's how it works:

R5(config)#ipv6 general-prefix TEST 2001:5::/48           
R5(config)#
R5(config)#int s1/0
R5(config-if)#ipv6 address TEST 2001:5::/48 eui-64 

R5#sho ipv6 interface s1/0 | inc :
  IPv6 is enabled, link-local address is FE80::E1B8:5FF:FE4C:9CDD 
  Global unicast address(es):
    2001:5::, subnet is 2001:5::/48 [GEN]
    2001:5::E1B8:5FF:FE4C:9CDD, subnet is 2001:5::/48 [EUI]
  Joined group address(es):
    FF02::1
    FF02::2
    FF02::1:FF00:0
    FF02::1:FF4C:9CDD
  ND DAD is enabled, number of DAD attempts: 1
R5#

We now have an IPv6 address assigned based on the EUI-64 method. The address is 2001:5::E1B8:5FF:FE4C:9CDD. Now suppose we need to change our prefix to 2001:6.

R5(config)#no ipv6 general-prefix TEST 2001:5::/48        
R5(config)#ipv6 general-prefix TEST 2001:6::/48   
R5(config)#
R5(config)#^Z
R5#sho ipv6 interface s1/0 | inc :
  IPv6 is enabled, link-local address is FE80::E1B8:5FF:FE4C:9CDD 
  Global unicast address(es):
    2001:6::, subnet is 2001:6::/48 [GEN]
    2001:6::E1B8:5FF:FE4C:9CDD, subnet is 2001:6::/48 [EUI]
  Joined group address(es):
    FF02::1
    FF02::2
    FF02::1:FF00:0
    FF02::1:FF4C:9CDD
  ND DAD is enabled, number of DAD attempts: 1
R5#

Image if we had more interfaces, this would make things so much easier. Especially considering each interface would have its own subnet. Imagine if we had interfaces on the 2001:5:0:1, 2001:5:0:2 (and so on) networks. We could change all of these to /48 prefix 2001:6:0:x:/64 with a couple commands. When you do change the general prefix, it does not overwrite the already configured one. This way you can have two prefixes during transition and eventually remove the older one as we did above.

IPv6 NAT-PT

This is a very simple IPv6 NAT-PT scenario. Here is the topology and addressing:


R1 is an IPv6 only host and R2 is an IPv4 only host.
R1 should use address 2001:23::2 to reach R2.
R2 should use 192.168.13.1 to reach R1.
R3 will be doing NAT-PT

Assign addresses per the diagram. The rest of the configuration is on R3.

R3(config)#int e0/0
R3(config-if)#ipv6 nat
R3(config-if)#int e0/1
R3(config-if)#ipv6 nat
R3(config)#ipv6 nat v4v6 source 192.168.23.2 2001:23::2
R3(config)#ipv6 nat v6v4 source 2001:13::1 192.168.13.1
R3(config)#ipv6 nat prefix 2001:23::/96

Remember to assing default gateways on R1 and R2:

R1(config)#ipv6 route 0::/0 2001:13::3

R2(config)#ip route 0.0.0.0 0.0.0.0 192.168.23.3

Let's ping from R1 while debugging on R3:

R3#debug ipv6 nat
IPv6 NAT-PT debugging is on

R1#ping 2001:23::2 re 1

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

R3#
*Mar 1 13:51:12.323: IPv6 NAT: icmp src (2001:13::1) -> (192.168.13.1), dst (2001:23::2) -> (192.168.23.2)
*Mar 1 13:51:12.327: IPv6 NAT: src (192.168.23.2) -> (2001:23::2), dst (192.168.13.1) -> (2001:13::1)
R3#

Now let's try the other way:

R2#ping 192.168.13.1 re 1

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

R3#
*Mar 1 13:53:00.991: IPv6 NAT: src (192.168.23.2) -> (2001:23::2), dst(192.168.13.1) -> (2001:13::1)
*Mar 1 13:53:00.995: IPv6 NAT: icmp src (2001:13::1) -> (192.168.13.1), dst (2001:23::2) -> (192.168.23.2)
R3#

You can view the translations on R3:

R3#sho ipv6  nat translations
Prot  IPv4 source              IPv6 source
      IPv4 destination         IPv6 destination
---   ---                      ---
      192.168.23.2             2001:23::2

---   192.168.13.1             2001:13::1
      192.168.23.2             2001:23::2

---   192.168.13.1             2001:13::1
      ---                      ---

That's it!

Making a VLAN IPv6 only

Here is the simple topology for this lab. R1 and R2 are on VLAN 12. VLAN12 needs to be IPv6 only. We test this my assigning IPv4 and IPv6 addresses to both routers and then pinging.

R1---SW1---SW2---R2

R1:

IPv4: 192.168.12.1/24
IPv6: 2001::1/64

R2:

IPv4: 192.168.12.2/24
IPv6: 2001::2/64

Making a vlan IPv6 only requires more configuration than I previously thought. This was my first attempt. On all switches:

mac access-list extended IPv6
permit any any 0x86DD 0x0
vlan access-map IPv6only 10
action forward
match mac address IPv6
vlan filter IPv6only vlan-list 12

So R1 pings R2:

R1#ping 192.168.12.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.12.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R1#ping 192.168.12.2

But wait, let's remove the filter, ping, add the filter back, and ping again.

SW1(config)#no vlan filter IPv6only vlan-list 12

R1#ping 192.168.12.2

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

SW1(config)#vlan filter IPv6only vlan-list 12

R1#ping 192.168.12.2

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

R1 can still ping. What happened? Well the original filter wasn't blocking IP, it was only blocking ARP packets. Remember MAC access-lists do not have an implicit deny for the IP ethertype but they do have an implicit deny for all the other ethertypes. So once we removed the filter and allowed ARP through, R1 was able to ping R2 when the filtered was applied.

To make the vlan IPv6 only I had to specify a drop action in an empty access-map statement:

SW1(config)#vlan access-map IPv6only 20
SW1(config-access-map)# action drop

R1#ping 192.168.12.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.12.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R1#

But wait, let's check out spanning-tree:

SW1#sho spanning-tree vlan 12 | inc root
This bridge is the root
SW2#show spanning-tree vlan 12 | inc root
This bridge is the root

This is bad because both switches forward out all ports when they think they are root. If we had multiple links between these switches, we would have a loop. You may start seeing these messages:

SW2#
01:28:49: %SW_MATM-4-MACFLAP_NOTIF: Host 00b0.6410.3901 in vlan 12 is flapping between port Fa0/13 and port Fa0/14
01:28:49: %SW_MATM-4-MACFLAP_NOTIF: Host 0007.eb14.4f81 in vlan 12 is flapping between port Fa0/13 and port Fa0/14

We need to allow STP bpdu's in our original MAC access-list. Do this now:

SW1(config)#mac access-list extended IPv6
SW1(config-ext-macl)#permit any any lsap 0xAAAA 0x0

Now we see SW2 blocking on the port f0/14 (for VLANs 1 and 12):

SW2#sho span | inc BLK
Fa0/14 Altn BLK 19 128.16 P2p
Fa0/14 Altn BLK 19 128.16 P2p

Verify R1 can ping R2 via IPv6 and not IPv4:

R1#ping 192.168.12.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.12.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R1#ping 2001::2

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

I used 0xAAAA because this what lsap type PVST uses. I don't know where I got this but I think I saw it on GS somehwere. I have also seen 0x4242 used but I think this is for normal STP (802.1d). In any case, only the 0xAAAA worked for me.

IPv6 Tunneling - ISATAP

R2, R5 and R6 connected via an IPv4 frame-relay network.
There is no PVC in use between R5 and R6.
Each device has a loopback 192.168.x.x where x is router number.
The goal here is to allow the remote IPv6 networks to communicate over the IPv4 cloud.


Below are the configs.

Loopback 100 = tunnel endpoint
Loopback 101 = "remote" network

R6:

interface Loopback100
ip address 192.168.6.6 255.255.255.255

interface Loopback101
no ip address
ipv6 address 2001:600::6/64

interface Tunnel1
ipv6 address 2001:200::/64 eui-64
tunnel source Loopback100
tunnel mode ipv6ip isatap

R5:

interface Loopback100
ip address 192.168.5.5 255.255.255.255

interface Loopback101
no ip address
ipv6 address 2001:500::5/64

interface Tunnel1
ipv6 address 2001:200::/64 eui-64
tunnel source Loopback100
tunnel mode ipv6ip isatap

Static routes on R5 and R6:

R5(config)#ipv6 route 2001:600::/64 tunnel 1 fe80::5efe:c0a8:0606

R6(config)#ipv6 route 2001:500::/64 tunnel 1 fe80::5efe:c0a8:0505

Where did I get these next hops? Well when you create an ISATAP tunnel they are created in a modified eui-64 format. Take a look

at R5:

R5#show ipv6 interface brief tun 1
Tunnel1 [up/up]
FE80::5EFE:C0A8:505
2001:200::5EFE:C0A8:505

When the router decides to route a packet out of that tunnel interface, it calculates the Ipv4 next hop address from the last 32 bits of the modified eui-64 address. In this case C0A8:505 converts to 192.168.5.5. R6 sends all packets destined for 2001:500::/64 to 192.168.5.5.

Key things to remember:

-The tunnel source address must be reachable by remote routers
-There is no manually specified tunnel destination
-You must specify the tunnel interface and link layer address in static routes

IPv6 - Stateless autoconfig

Logical Topology:

R6------SW2

R6 is in vlan 6.
SW2 get its address for SVI 6 via stateless autoconfiguration.
R6 will be advertising the prefix for SW2 to use to build it's address.
R6 already has an IPv6 address configured: 2001:cc1e:1:6::6/64

Also, a good command to run here is "debug ipv6 nd".

Rack1R6#debug ipv6 nd
ICMP Neighbor Discovery events debugging is on

Rack1SW2#debug ipv6 nd
ICMP Neighbor Discovery events debugging is on

Before we do anything let's see what debugging gives us on R6:

Rack1R6#
*Mar 1 00:42:14.219: ICMPv6-ND: Sending RA to FF02::1 on Ethernet0/1
*Mar 1 00:42:14.219: ICMPv6-ND: MTU = 1500
*Mar 1 00:42:14.219: ICMPv6-ND: prefix = 2001:CC1E:1:6::/64 onlink autoconfig
*Mar 1 00:42:14.219: ICMPv6-ND: 2592000/604800 (valid/preferred)
Rack1R6#

We can see that R6 is already advertising it's prefix for hosts on this segment to use. Look at the output of the debug. We have

1) All nodes multicast address FF02::1, this is the destination of the RA advertisement
2) MTU of 1500
3) Prefix advertised by R6 2001:CC1E:1:6::/64
4) Valid and Preferred Lifetime 2592000/604800

All we need to do on SW2 is configure the SVI for autoconfiguration:

SW2#conf t
SW2(config)#int vlan 6
SW2(config-if)#ipv6 address ?
WORD General prefix name
X:X:X:X::X IPv6 link-local address
X:X:X:X::X/<0-128> IPv6 prefix
autoconfig Obtain address using autoconfiguration

SW2(config-if)#ipv6 address autoconfig

Notice that SW2 immediately sends an RS message asking for information about this segment:

00:19:39: ICMPv6-ND: Sending RS on Vlan6
00:19:39: ICMPv6-ND: Received RA from FE80::205:32FF:FE22:E442 on Vlan6
00:19:39: ICMPv6-ND: Sending NS for 2001:CC1E:1:6:21D:45FF:FEC0:F443 on Vlan6
00:19:39: ICMPv6-ND: Autoconfiguring 2001:CC1E:1:6:21D:45FF:FEC0:F443 on Vlan6
00:19:40: ICMPv6-ND: DAD: 2001:CC1E:1:6:21D:45FF:FEC0:F443 is unique.
00:19:40: ICMPv6-ND: Sending NA for 2001:CC1E:1:6:21D:45FF:FEC0:F443 on Vlan6
00:19:40: ICMPv6-ND: Address 2001:CC1E:1:6:21D:45FF:FEC0:F443/64 is up on Vlan6

It also receives the prefix, calcualtes its global unicast address and performs DAD. Now let's check the interface on SW2:

SW2#show ipv6 interface
Vlan6 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::21D:45FF:FEC0:F443
Global unicast address(es):
2001:CC1E:1:6:21D:45FF:FEC0:F443, subnet is 2001:CC1E:1:6::/64 [PRE]
valid lifetime 2591864 preferred lifetime 604664
Joined group address(es):
FF02::1
FF02::2
FF02::1:FFC0:F443
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
ND advertised reachable time is 0 milliseconds
ND advertised retransmit interval is 0 milliseconds
ND router advertisements are sent every 200 seconds
ND router advertisements live for 1800 seconds
ND advertised default router preference is Medium
Hosts use stateless autoconfig for addresses.
Rack1SW2#

There are several adjustments we can make on the timers. Let's look at R6:

R6(config-if)#ipv6 nd ?
advertisement-interval Send an advertisement interval option in RA's
dad Duplicate Address Detection
managed-config-flag Hosts should use DHCP for address config
ns-interval Set advertised NS retransmission interval
other-config-flag Hosts should use DHCP for non-address config
prefix Configure IPv6 Routing Prefix Advertisement
ra-interval Set IPv6 Router Advertisement Interval
ra-lifetime Set IPv6 Router Advertisement Lifetime
reachable-time Set advertised reachability time
suppress-ra Suppress IPv6 Router Advertisements

Here we can set various parameters such as the advertisement interval (200 seconds default) and the RA lifetime.

More information on these options can be found in the addressing section non the IPv6 configuration guide on the DocCD:

Implementing IPv6 Addressing and Basic Connectivity

IPv6: RIPng, traffic filters and split horizon

R5, R6 and R7 all sit on the same LAN. R6 is also connected to R9. R5 must see this network between R6 and R9 with a next hop of R7, not R6. How can we do it?

Well first we need to disable split horizon on R7. For IPv6 RIP, this is done under the routing process:

IPeR7(config)#ipv6 router rip RIP6
IPeR7(config-rtr)#no split-horizon

Next we need to filter routing updates from R6. What do these RIPng packets look like? We can see through "debug ipv6 rip."

IPeR5#debug ipv6 rip
RIP Routing Protocol debugging is on
IPeR5#
*Nov 3 00:45:44.453: RIPng: response received from FE80::6 on FastEthernet0/0 for RIP6
*Nov 3 00:45:44.453: src=FE80::6 (FastEthernet0/0)
*Nov 3 00:45:44.453: dst=FF02::9
*Nov 3 00:45:44.453: sport=521, dport=521, length=52
*Nov 3 00:45:44.453: command=2, version=1, mbz=0, #rte=2
*Nov 3 00:45:44.453: tag=0, metric=1, prefix=2001:200::/64
*Nov 3 00:45:44.453: tag=0, metric=1, prefix=2001:96::/64

Now we know the source and destination, we can create our filter:

IPeR5(config)#ipv6 access-list RIP-FILTER
IPeR5(config-ipv6-acl)#deny ipv6 FE80::6/128 FF02::9/128
IPeR5(config-ipv6-acl)#permit ipv6 any any
IPeR5(config-ipv6-acl)#int f0/0
IPeR5(config-if)#ipv6 access-group RIP-FILTER in
^
% Invalid input detected at '^' marker.

Whoa! what gives!? This stupid things doesn't let me apply my ACL.

IPeR5(config-if)#ipv6 acc?
% Unrecognized command

Well that's because traffic filtering in IPv6 uses a whole different syntax:

IPeR5(config-if)#ipv6 traffic-filter RIP-FILTER in
IPeR5(config-if)#

BAM!

Let's clear the route table then check our next hop:

IPeR5#show ipv6 route rip | sec exclude Codes:
IPv6 Routing Table - 7 entries
R 2001:96::/64 [120/3]
via FE80::7, FastEthernet0/0
IPeR5#

IPv6: Summarizing OSPFv3 addresses

This is from IPexpert volume 1 section 22. We have to summarize the following routes:

2020:100:100:2222::/64
2020:100:100:2666::/64

This is how I do it:

1) Identify the hextet ( I don't know if this is a word, I derived it from octet) where we will summarize. This is the 4th hextet. So we know our subnet will be somewhere between /48 and /64.

2) Break it down in binary:

2222 = 0010 0010 0010 0010
2666 = 0010 0110 0110 0110

Converting hex to binary is easy because we just treat each digit in the IPv6 address as a 4 bit binary number by itself. Notice how all the 2's broke down to 0010.

3) Find the common bits. I highlighted them in red below. We have 5 of them. We will use to get our mask.

2222 = 0010 0010 0010 0010
2666 = 0010 0110 0110 0110

4) Set the rest if the bits to 0 and calculate the summary, convert to hex.

summary = 0010 0000 0000 0000 = 2000

5) Calculate subnet mask by adding the common bits to the lower of our subnet range. This means we add 5 to /48 which makes /53.

So our summary address is 2020:100:100:2000::/53

In OSPFv3 we would enter:

R2(config)#ipv6 router ospf 1
R2(config-rtr)#area 1 range 2020:100:100:2000::/53

Check our other routers for the summary:

R4#show ipv6 route | inc 53
OI 2020:100:100:2000::/53 [110/129]

IPexpert Volume 1 Section 21 - IPv6, RIPng

This is not an extremely difficult lab but it did bring up some good troubleshooting. In it we have two RIPng processes running over each other, cisco12 and cisco275 are their names.

Here is the basic topology:

R1----R2====R5----R7

R2 and R5 have two connections, one via frame-relay, and another over an ipv6ip tunnel. RIPng process cisco275 runs from R7 to R5, and R5 to R2 over frame link. RIPng process cisco12 runs over the tunnel and R1 to R2.

After redistributing between the two processes on R5, R7 still cannot ping R1 even though it has a route. Both routes below belong to R1's loopbacks.

R7#show ipv6 route rip

R 2000:1:1:1100::/64 [120/5]
via FE80::21B:D5FF:FE0F:F358, FastEthernet0/0
R 2000:1:1:1111::/64 [120/5]
via FE80::21B:D5FF:FE0F:F358, FastEthernet0/0

When we ping from R7 here is the debug on R1:

R1#debug ipv6 packet
IPv6 unicast packet debugging is on
R1#
*Sep 23 01:22:44.255: IPV6: source 2000:1:1:75::7 (FastEthernet0/0)
*Sep 23 01:22:44.255: dest 2000:1:1:1111::1
*Sep 23 01:22:44.259: traffic class 0, flow 0x0, len 100+14, prot 58, hops 62, forward to ulp
*Sep 23 01:22:44.259: IPV6: source 2000:1:1:1111::1 (local)
*Sep 23 01:22:44.259: dest 2000:1:1:75::7
*Sep 23 01:22:44.259: traffic class 0, flow 0x0, len 100+14, prot 58, hops 64, Route not found

Whats the ulp!? don't know right now...Let's check R2 since it is upstream from R1:

R2#show ipv6 route 2000:1:1:75::

R 2000:1:1:75::/64 [120/2]
via FE80::5, Serial0/1/0.1

R2 is learning the route but why isn't it sending it to R1? If we debug ipv6 rip on R2 we will see why:

*Oct 4 20:18:45.243: RIPng: response received from FE80::9664:1905 on Tunnel0 for cisco12
*Oct 4 20:18:45.243: src=FE80::9664:1905 (Tunnel0)
*Oct 4 20:18:45.243: dst=FF02::9
*Oct 4 20:18:45.243: sport=521, dport=521, length=132
*Oct 4 20:18:45.243: command=2, version=1, mbz=0, #rte=6
*Oct 4 20:18:45.243: tag=0, metric=4, prefix=FEC0:0:0:6419::/64
*Oct 4 20:18:45.243: tag=0, metric=4, prefix=2000:1:1:5500::/64
*Oct 4 20:18:45.243: tag=0, metric=4, prefix=2000:1:1:75::/64
*Oct 4 20:18:45.243: tag=0, metric=1, prefix=2000:1:1:25::/64
*Oct 4 20:18:45.243: tag=0, metric=4, prefix=2002:2:2:2::/64
*Oct 4 20:18:45.243: tag=0, metric=4, prefix=2000:1:1:7700::/64

*Oct 4 20:18:55.915: RIPng: response received from FE80::5 on Serial0/1/0.1 for cisco275
*Oct 4 20:18:55.915: src=FE80::5 (Serial0/1/0.1)
*Oct 4 20:18:55.915: dst=FF02::9
*Oct 4 20:18:55.915: sport=521, dport=521, length=192
*Oct 4 20:18:55.915: command=2, version=1, mbz=0, #rte=9
*Oct 4 20:18:55.915: tag=0, metric=1, prefix=FEC0:0:0:6419::/64
*Oct 4 20:18:55.915: tag=0, metric=1, prefix=2000:1:1:5500::/64
*Oct 4 20:18:55.915: tag=0, metric=1, prefix=2000:1:1:75::/64
*Oct 4 20:18:55.915: tag=0, metric=4, prefix=2000:1:1:25::/64
*Oct 4 20:18:55.919: tag=0, metric=2, prefix=2000:1:1:7700::/64
*Oct 4 20:18:55.919: tag=0, metric=4, prefix=2000:1:1:2222::/64
*Oct 4 20:18:55.919: tag=0, metric=4, prefix=2000:1:1:2200::/64
*Oct 4 20:18:55.919: tag=0, metric=4, prefix=2000:1:1:1100::/64

R2 is hearing two advertisements for 2000:1:1:75::/64, one is coming through the tunnel process cisco12 and the other is coming through the frame-relay cloud process cisco275.

R2 is installing the one from cisco275 because it has a lower metric and thus not advertising it to R1 because that's where process cisco12 is running.

We resolve this by redistributing between cisco12 and cisco275 on R2.

R2(config)#ipv6 router rip cisco12
R2(config-rtr)#redistribute rip cisco275 include-connected metric 3
R2(config-rtr)#ipv6 router rip cisco275
R2(config-rtr)#redistribute rip cisco12 include-connected metric 3

Now we have reachability:

R7#ping 2000:1:1:1111::1

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

IPV6 - OSPFv3, default route, RIPng, redistribution

This is the third of three ipv6 posts today. The others are below. Here we configure OSPFv3 over an nbma cloud, adevrtise a default route, and redistribute with RIPng.

Here is the topology:

|---RIPng---|-------OSPFv3 area 0---------|

[BB2]------[R5]---[FRAME]---[R1]---VLAN1001

Addressing:

R5-BB2 : 2001:192:10:1::/64
R1-R5 : 2001:CC1E:1:1515::/64
VLAN1001: FEC0:CC1E:1:1::/64

BB2 and R5 are doing RIPng (config not shown, it's easy enough!)
R5,R1 are doing OSPFv3, area 0 everywhere else.

Here is how I configured the neighbors over the FR cloud:

R1#show run int s1/0

interface Serial1/0
encapsulation frame-relay
ipv6 address 2001:CC1E:1:1515::1/64
ipv6 ospf neighbor FE80::CE01:9FF:FEE8:0
ipv6 ospf 1 area 0
frame-relay map ipv6 FE80::CE01:9FF:FEE8:0 105 broadcast
frame-relay map ipv6 2001:CC1E:1:1515::5 105 broadcast

R5#show run int s1/0

interface Serial1/0
no ip address
encapsulation frame-relay
ipv6 address 2001:CC1E:1:1515::5/64
ipv6 ospf neighbor FE80::CE00:9FF:FEE8:0
ipv6 ospf 1 area 0
frame-relay map ipv6 2001:CC1E:1:1515::1 501 broadcast
frame-relay map ipv6 FE80::CE00:9FF:FEE8:0 501 broadcast

Notice that I use the link-local address as the neighbor address.

R1#show ipv6 ospf neighbor

Neighbor ID Pri State Dead Time Interface ID Interface
150.1.5.5 1 FULL/DR 00:01:44 5 Serial1/0
R1#

R5 is learning VLAN 1001:

R5#show ipv6 route ospf
O FEC0:CC1E:1:1::/64 [110/65]
via FE80::CE00:9FF:FEE8:0, Serial1/0

R5 is also learning some loopback networks from BB2 via RIP:

R5#show ipv6 route rip

R 2001:205:90:31::/64 [120/2]
via FE80::CE02:9FF:FEE8:0, FastEthernet0/0
R 2001:220:20:3::/64 [120/2]
via FE80::CE02:9FF:FEE8:0, FastEthernet0/0
R 2001:222:22:2::/64 [120/2]
via FE80::CE02:9FF:FEE8:0, FastEthernet0/0

Task is to advertise default route to R1 via OSPFv3 without "default-information originate always" command. R5 should drop traffic unless it has a longer match. Sounds like a summary route, eh?! WRONG! we can't summarize intra-area, but we are allowed on static route...hmmm....We can point it to null and redistribute!

R5(config)#ipv6 route 0::/0 null0
R5(config-rtr)#redistribute static

Let's check R1:

R1#show ipv6 route ospf

R1#

Nothing!...well. The task says not to use the "default-information originate always" command. What if we leave off the always!

R5(config-rtr)#no redistribute static
R5(config-rtr)#default-information originate

R1#show ipv6 route ospf
OE2 ::/0 [110/1], tag 1
via FE80::CE01:9FF:FEE8:0, Serial1/0

There we go and we didn't need to redistribute static either. If you delete that default route to NULL, then the LSA disappears too!

So now R1 has a default route but BB2 still has no route back to VLAN1001. So we can redistribute into RIPng on R5:

R5(config)#ipv6 router rip RIPNG
R5(config-rtr)#redistribute ospf 1 metric 1

Ping from R1:

R1#ping 2001:205:90:31::1 source FEC0:CC1E:1:1::1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:205:90:31::1, timeo
Packet sent with a source address of FEC0:CC1E:1:1::1
!!!!!

IPv6 - Policy-based routing

Same topology as before but without the offset:

Three loopbacks on BB2 advertised through RIPng to R3:

2001:205:90:31::1
2001:220:20:3::1
2001:222:22:2::1

Here is a traceroute from VLAN38:

R3#trace
Protocol [ip]: ipv6
Target IPv6 address: 2001:205:90:31::1
Source address: FEC0:CC1E:1:38::3
Insert source routing header? [no]: no
Numeric display? [no]:
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Priority [0]:
Port Number [33434]:
Type escape sequence to abort.
Tracing the route to 2001:205:90:31::1

1 FEC0:CC1E:1:35::5 28 msec 32 msec 32 msec
2 FEC0:CC1E:1:54::4 12 msec
FEC0:CC1E:1:45::4 60 msec
FEC0:CC1E:1:54::4 28 msec
3 2001:205:90:31::1 52 msec 72 msec 24 msec
R3#

Notice at step 2 of the trace we flip-flop between the two hops from R5. Let's use policy based routing to force traffic from VLAN38 to use the serial link to R4. On R5:

ipv6 access-list PBRv6
permit ipv6 FEC0:CC1E:1:38::/64 2001:205:90:31::/64
permit ipv6 FEC0:CC1E:1:38::/64 2001:220:20:3::/64
permit ipv6 FEC0:CC1E:1:38::/64 2001:222:22:2::/64

route-map PBRv6 permit 10
match ipv6 address PBRv6
set ipv6 default next-hop FEC0:CC1E:1:45::4

int s1/0.35
ipv6 policy route-map PBRv6

Do the trace again:

R3#trace
Protocol [ip]: ipv6
Target IPv6 address: 2001:205:90:31::1
Source address: FEC0:CC1E:1:38::3
Insert source routing header? [no]:
Numeric display? [no]:
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Priority [0]:
Port Number [33434]:
Type escape sequence to abort.
Tracing the route to 2001:205:90:31::1

1 FEC0:CC1E:1:35::5 20 msec 36 msec 24 msec
2 FEC0:CC1E:1:45::4 4 msec 80 msec 24 msec
3 2001:205:90:31::1 16 msec 40 msec 36 msec
R3#

Sweet. What if the link between R4 and R5 fails?

R5(config-subif)#int s1/1
R5(config-if)#shut

Now back to R3:

Protocol [ip]: ipv6
Target IPv6 address: 2001:205:90:31::1
Source address: FEC0:CC1E:1:38::3
Insert source routing header? [no]:
Numeric display? [no]:
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Priority [0]:
Port Number [33434]:
Type escape sequence to abort.
Tracing the route to 2001:205:90:31::1

1 FEC0:CC1E:1:35::5 48 msec 28 msec 44 msec
2 FEC0:CC1E:1:54::4 24 msec 88 msec 20 msec
3 2001:205:90:31::1 8 msec 64 msec 44 msec
R3#

Now we are using the frame relay link.

IPv6 - RIPng metric offset

Here is the topology, use whatever DLCI's and interfaces you want:

R4 is learning these routes from BB2:

R 2001:205:90:31::/64 [120/2]
via FE80::CE03:8FF:FE9C:0, FastEthernet2/0
R 2001:220:20:3::/64 [120/2]
via FE80::CE03:8FF:FE9C:0, FastEthernet2/0
R 2001:222:22:2::/64 [120/2]
via FE80::CE03:8FF:FE9C:0, FastEthernet2/0

The task is to force R5 to use the serial link instead of the frame-relay link to reach these networks. Let's look at R5 right now:

R5#show ipv6 route

R 2001:205:90:31::/64 [120/3]
via FE80::CE01:8FF:FE9C:0, Serial1/1
via FE80::CE01:8FF:FE9C:0, Serial1/0.54
R 2001:220:20:3::/64 [120/3]
via FE80::CE01:8FF:FE9C:0, Serial1/1
via FE80::CE01:8FF:FE9C:0, Serial1/0.54
R 2001:222:22:2::/64 [120/3]
via FE80::CE01:8FF:FE9C:0, Serial1/1
via FE80::CE01:8FF:FE9C:0, Serial1/0.54

As you can see it's currently load sharing between the two 3-hop routes. How can we make the serial link more preferred? We can use an offset. It's not like the offset in rip for ipv4, but it works similar:

R5(config)#int s1/0.54
R5(config-subif)#ipv6 rip RIPNG metric-offset 2

Now let's take a look at our routes:

R5#show ipv6 route

R 2001:205:90:31::/64 [120/3]
via FE80::CE01:8FF:FE9C:0, Serial1/1
R 2001:220:20:3::/64 [120/3]
via FE80::CE01:8FF:FE9C:0, Serial1/1
R 2001:222:22:2::/64 [120/3]
via FE80::CE01:8FF:FE9C:0, Serial1/1

Trace from R3:

R3#trace 2001:205:90:31::1

Type escape sequence to abort.
Tracing the route to 2001:205:90:31::1

1 FEC0:CC1E:1:35::5 24 msec 32 msec 32 msec
2 FEC0:CC1E:1:45::4 8 msec 44 msec 16 msec
3 2001:205:90:31::1 56 msec 16 msec 60 msec
R3#

Easy!

I first started out thinking offset-list but I ran into a couple issues. First you can't make ipv6 standard ACLs, at least I couldn't find a way. Then before attempting to use ipv6 prefix lists I thought I would check out what commands were available under an interface for RIPng:

R5(config-subif)#ipv6 rip RIPNG ?
default-information Configure handling of default route
enable Enable/disable RIP routing
metric-offset Adjust default metric increment
summary-address Configure address summarization

This is where I noticed the metric-offset. In addition there is no offset list under router config mode:

R5(config-subif)#ipv6 router rip RIPNG
R5(config-rtr)#?
default Set a command to its defaults
distance Administrative distance
distribute-list Filter networks in routing updates
exit Exit from IPv6 routing protocol configuration mode
maximum-paths Forward packets over multiple paths
no Negate a command or set its defaults
poison-reverse Poison reverse updates
port Port and multicast address
redistribute Redistribute IPv6 prefixes from another routing protocol
split-horizon Split horizon updates
timers Adjust routing timers

Didn't even need the DocCD!

some IPv6 notes: frame relay, RIPng, default routes

I was doing an IPv6 lab today. Here are some issues I came across:

Issue #1:
Hub and spoke environment, hubs could ping spoke, spokes couldn't ping hub. Turns out I didn't have "ipv6 unicast-routing" on the hub or the other routers.

Issue #2:
IPv6 router wasn't get routes from the backbone. I didn't have IPv6 rip enabled on the loopbacks.

Issue #3:
Spoke wasn't getting routes from other spoke. I needed to turn of split horizon on the hub. This is turned off under the process as follows:

ipv6 router rip RIP6
no split-horizon

Issue #4:
Default route wasn't getting propogated to downstream router. I need to have a metric for this route. Like this:

interface Serial1/0
ipv6 rip RIP6 default-information only metric 2

IPv6 - link local address, MAC to EUI-64 conversion

The fastest way to get a link local address is to configure an interface with the ipv6 enable command. For example:

R1(config)#int f0/0
R1(config-if)#ipv6 enable

What will the link local address be? Before we take a look, let's figure it out ourselves. First do a show interface:

R1#show int f0/0 | in add
Hardware is Gt96k FE, address is c200.0854.0000 (bia c200.0854.0000)
R1#

To convert this MAC address to a link-local using eui-64 format do the following:

1. MAC Address: c200.0854.0000
2. Insert FFFE in the middle: c200:08FF:FE54:0000
3 Flip the U/L bit: 7th bit from the left: c000:08FF:FE54:0000
4. Append the prefix FE80: FE80::c000:08FF:FE54:0000
5. Remove extra 0's: FE80::C000:8FF:FE54:0

Let's take a look:

R1#show ipv6 interface f0/0 | in link
IPv6 is enabled, link-local address is FE80::C000:8FF:FE54:0

IPv6 tunneling - gre ip

This example is going to use the same topology as IPv6 tunneling - IPv6IP. In this mode, the passenger protocol is IPv6, the carrier protocol is GRE and IPv4 is used as the transport.

Here is the network:

[R1]---[R2]---[R3]---[R4]

R1-R2: IPv6 network 2002:1:0:12::/64
R2-R3: IPv4 network 172.12.23.0/24
R3-R4: IPv6 network 2002:1:0:34::/64

Make sure you enable ipv6 unicast routing on R2 and R3:

R2(config)#ipv6 unicast-routing

R3(config)#ipv6 unicast-routing

Configuration is pretty much the same as ipv6ip except the mode is different. In fact, we don't even need to specify a mode as gre ip is the default. I will show it here just for clarity but note that it will probably not show up in the running-config:

R2(config)#int tunnel 1
R2(config-if)#description gre ip tunnel
R2(config-if)#ipv6 address 2002:2:0:23::2/64
R2(config-if)#tunnel source 172.12.23.2
R2(config-if)#tunnel destination 172.12.23.3
R2(config-if)#tunnel mode gre ip

R3(config)#int tunnel 1
R3(config-if)#description gre ip tunnel
R3(config-if)#ipv6 address 2002:2:0:23::3/64
R3(config-if)#tunnel source 172.12.23.3
R3(config-if)#tunnel destination 172.12.23.2
R3(config-if)#tunnel mode gre ip

Let's add the static routes:

R2(config)#ipv6 route 2002:1:0:34::/64 Tunnel1

R3(config)#ipv6 route 2002:1:0:12::/64 Tunnel1

Verify:

R1#ping 2002:1:0:34::4

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

R2#debug tunnel
Tunnel Interface debugging is on
R2#
*Mar 1 01:09:12.999: Tunnel1: GRE/IP encapsulated 172.12.23.2->172.12.23.3 (linktype=79, len=124)
*Mar 1 01:09:13.095: Tunnel1: GRE/IP to classify 172.12.23.3->172.12.23.2 (len=124 type=0x86DD ttl=254 tos=0x0)

Some of the benefits of this mode are that GRE tunnels can carry more than just IPv6. At work, we sometimes use them for multicast and some other non-IP traffic, we even use them to route normal IP packets to default destinations across VPN clouds.

IPv6 tunneling - IPv6IP

This is a pretty simple and straightforward manual method of tunneling IPv6 packets over an IPv4 network. IP protocol type 41 is used to tell the router that the packet inside of the IP packet is and IPv6 packet.

Here is the network:

[R1]---[R2]---[R3]---[R4]

R1-R2: IPv6 network 2002:1:0:12::/64
R2-R3: IPv4 network 172.12.23.0/24
R3-R4: IPv6 network 2002:1:0:34::/64

Make sure you enable ipv6 unicast routing on R2 and R3:

R2(config)#ipv6 unicast-routing

R3(config)#ipv6 unicast-routing

Let's create the tunnels:

R2(config)#int tunnel 0
R2(config-if)#ipv6 address 2002:1:0:23::2/64
R2(config-if)#tunnel source 172.12.23.2
R2(config-if)#tunnel destination 172.12.23.3
R2(config-if)#tunnel mode ipv6ip

R3(config)#int tun 0
R3(config-if)#ipv6 address 2002:1:0:23::3/64
R3(config-if)#tunnel source 172.12.23.3
R3(config-if)#tunnel destination 172.12.23.2
R3(config-if)#tunnel mode ipv6ip

Next we need tell the router when to use the tunnel by making some static routes. The following route tells R2 that whenever a packet comes in destined for the R3-R4 network, encapsulate it in IP and tunnel it to the tunnel destination, R3 in this case. The second route does the opposite on R3.

R2(config)#ipv6 route 2002:1:0:34::/64 tunnel 0

R3(config)#ipv6 route 2002:1:0:12::/64 tunnel 0

Let's verify:

R1#ping 2002:1:0:34::4

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

Debugging IPv6 Neighbor Discovery

R1 and R2 are on the same LAN segment via their f0/0 interfaces.

IPv6 addressing:

R1(config)#interface f0/0
R1(config-if)#ipv6 address 2001::1/64
R1(config-if)#ipv6 address FE80::1 link-local

R2(config)#interface f0/0
R2(config-if)#ipv6 address 2001::2/64
R2(config-if)#ipv6 address FE80::2 link-local

Let's also enable ipv6 icmp debugging since that what ipv6 uses instead of ARP tp discover neighbors:

R1#debug ipv6 icmp
ICMP packet debugging is on

R2#debug ipv6 icmp
ICMP packet debugging is on

Shut both interfaces down and bring them up at the same time. Here is what we see on R1:

R1#
*Mar 1 00:35:28.615: ICMPv6: Received ICMPv6 packet from FE80::2, type 136
*Mar 1 00:35:29.695: ICMPv6: Received ICMPv6 packet from 2001::2, type 136

R1 has received icmp type 136 messages from R2's ipv6 address and ipv6 link-local address. R2 will receive the same messages. However, each router still has not "discovered" the other router (in other words, the ipv6 to layer 2 mac address resolution has not taken place)

R1#show ipv6 neighbors
R1#

Let's ping from R1:

R1#ping ipv6 2001::2 repeat 1

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

on R1:

Jun 11 21:26:11.569: ICMPv6: Sending echo request to 2001::2
Jun 11 21:26:11.749: ICMPv6: Received ICMPv6 packet from 2001::2, type 136
Jun 11 21:26:11.813: ICMPv6: Received echo reply from 2001::2

on R2:

Jun 11 21:26:11.299: ICMPv6: Received ICMPv6 packet from 2001::1, type 135
Jun 11 21:26:11.343: ICMPv6: Received echo request from 2001::1
Jun 11 21:26:11.343: ICMPv6: Sending echo reply to 2001::1

Some of these things seem a bit out of sequence but let's analyze a little further. Specifically let's focus on icmpv6 message types 135 and 136. Looking up these codes at http://www.iana.org/assignments/icmpv6-parameters you will see that these are Neighbor Solicitation and Advertisement messages.

Here's the breakdown:

· When R1 sends a ping to 2001::2 it realizes it doesn't have the MAC address to put in that packet.
· It sends a icmpv6 type 135 message to FF02::1:FF00:2 which is the solicited-node multicast address for 2001::2
· R2 is listening to this address because for every ipv6 unicast address it owns, it listens for the corresponding solicited-node multicast address.

You can verify this as follows, look under the "Joined group address(es)" section to see the multicast addresses that this router is listening for:

R2#show ipv6 int f0/0
FastEthernet0/0 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::2
Global unicast address(es):
2001::2, subnet is 2001::/64
Joined group address(es):
FF02::1
FF02::2
FF02::1:FF00:2
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

· R2 will then see this message and reply because it's address, 2001::2 is in the "target" section of the packet.
· R2 responds with a type 136 neighbor advertisement message and put its MAC address in the portion of the icmpv6 packet designed for this purpose (of course the source of the packet also has the MAC address, but this is not used for resolution).
· Then R1 can send the icmpv6 echo, and R2 will reply (R2 already resolved R1's address via the very first packet it received from R1 which had both the IPv6 and L2 MAC addresses)

Let's check those neighbors now:

R1#show ipv6 neighbors
IPv6 Address Age Link-layer Addr State Interface
2001::2 0 c201.0e8c.0000 REACH Fa0/0
FE80::2 10 c201.0e8c.0000 STALE Fa0/0