IPv6 Intro: Routing with OSPFv3 for IPv6

Continuing on with our last lab, let's remove the RIPng config, and set up OSPFv3, instead. Here's the network diagram again, just so you don't have to jump back to the RIPng lab again:



Just like configuring RIPng, we will start by enabling IPv6 OSPF in the interface configurations. Once again, only R1 is shown, but the other routers are configured in exactly the same way:
R1(config)#int fa0/0
R1(config-if)#ipv6 ospf 42 area 0.0.0.0
R1(config-if)#int s0/0
R1(config-if)#ipv6 ospf 42 area 0.0.0.1
R1(config-if)#exit
R1(config)#do sho ipv6 route
IPv6 Routing Table - 8 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
       O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
LC  2001:C0:FFEE::1/128 [0/0]
     via ::, Loopback0
C   2001:C0:FFEE::1:0/125 [0/0]
     via ::, FastEthernet0/0
L   2001:C0:FFEE::1:1/128 [0/0]
     via ::, FastEthernet0/0
C   2001:C0:FFEE::1111:0/126 [0/0]
     via ::, Serial0/0
L   2001:C0:FFEE::1111:1/128 [0/0]
     via ::, Serial0/0
OI  2001:C0:FFEE::2222:0/126 [110/65]
     via FE80::CA03:3CFF:FEAE:0, FastEthernet0/0
L   FE80::/10 [0/0]
     via ::, Null0
L   FF00::/8 [0/0]
     via ::, Null0
R1(config)#

If this looks very familiar from the RIPng lab, it should. Any guesses on how to configure redistribution of connected networks?
R1(config)#ipv6 router ospf 42
R1(config-rtr)#router-id 10.254.254.1
R1(config-rtr)#redist conn
R1(config-rtr)#exit
R1(config)#

At this point, you might be scratching your head, wondering WHY I used an IPv4 address for the router ID. Actually...I didn't. The RFC for OSPF specifies that the router ID is a 32-bit, unique (at least within the AS) identifier. Since IPv4 addresses are ALSO 32-bit, unique identifiers, convention (and, unless a different router ID is specified in the config, Cisco's default behaviour) has set the loopback interface's IPv4 address as the router ID. I also chose to set an IPv4 address on the loopback interface, and I used it as the router ID in this lab. However, technically the OSPFv3 router ID is any random 32-bit number (see the footnote at the end of this lab for more).

After setting up redistribution, the routing table on R1 looks a little more populated:
R1(config)#do sho ipv6 route
IPv6 Routing Table - 12 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
       O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
LC  2001:C0:FFEE::1/128 [0/0]
     via ::, Loopback0
OE2  2001:C0:FFEE::2/128 [110/20]
     via FE80::CA03:3CFF:FEAE:0, FastEthernet0/0
OE2  2001:C0:FFEE::3/128 [110/20]
     via FE80::CA04:3CFF:FEAE:0, FastEthernet0/0
OE2  2001:C0:FFEE::4/128 [110/20]
     via FE80::CA00:3CFF:FEAE:0, Serial0/0
OE2  2001:C0:FFEE::5/128 [110/20]
     via FE80::CA03:3CFF:FEAE:0, FastEthernet0/0
C   2001:C0:FFEE::1:0/125 [0/0]
     via ::, FastEthernet0/0
L   2001:C0:FFEE::1:1/128 [0/0]
     via ::, FastEthernet0/0
C   2001:C0:FFEE::1111:0/126 [0/0]
     via ::, Serial0/0
L   2001:C0:FFEE::1111:1/128 [0/0]
     via ::, Serial0/0
OI  2001:C0:FFEE::2222:0/126 [110/65]
     via FE80::CA03:3CFF:FEAE:0, FastEthernet0/0
L   FE80::/10 [0/0]
     via ::, Null0
L   FF00::/8 [0/0]
     via ::, Null0
R1(config)#

There you go: we have a basic OSPFv3 (IPv6) configuration, sharing routes between each of the five routers in our network. We even set up three separate areas: the backbone, consisting of R1, R2 and R3; Area 1, consisting of R1 and R4; and Area 2, consisting of R2 and R5.

Footnote:
At this point, you may be wondering -- well, I am, anyway -- what OSPFv3 uses for a router ID if there are no IPv4 interfaces in use on the router, and there is no router ID specified in the OSPFv3 config. Let's find out, shall we?
R1(config)#int lo0
R1(config-if)#no ip addr
R1(config-if)#shut
R1(config-if)#no shut
R1(config-if)#no ipv6 router ospf 42
R1(config)#int fa0/0
R1(config-if)#ipv6 ospf 42 area 0.0.0.0
R1(config-if)#int s0/0
R1(config-if)#ipv6 ospf 42 area 0.0.0.1
R1(config-if)#exit
R1(config-if)#ipv6 router ospf 42
R1(config-rtr)# redistribute connected
R1(config-rtr)#exit
R1(config)#exit
R1#
00:36:49: %OSPFv3-4-NORTRID: OSPFv3 process 42 could not pick a router-id,
please configure manually
R1#sho ipv6 ospf neigh
%OSPFv3: Router process 42 is not running, please configure a router-id
R1#

Well, that's interesting! What happens if you don't have an IPv4 address on the loopback interface, but you have an IPv4 address on another interface?
R1(config-if)#int vlan 10
R1(config-if)#ip addr 10.254.254.1 255.255.255.252
R1(config-if)#no shut
R1(config-if)#no ipv6 router ospf 42
R1(config)#ipv6 router ospf 42
R1(config-rtr)#redist conn
R1(config-rtr)#exit
R1(config)#int fa0/0
R1(config-if)#ipv6 ospf 42 area 0.0.0.0
R1(config-if)#int s0/0
R1(config-if)#ipv6 ospf 42 area 0.0.0.1
R1(config-if)#exit
R1(config)#exit
R1#sho ipv6 ospf 42 neigh

Neighbor ID    Pri  State      Dead Time  Interface ID  Interface
10.254.254.2     1  FULL/BDR   00:00:39   4             FastEthernet0/0
10.254.254.3     1  FULL/DR    00:00:36   4             FastEthernet0/0
10.254.254.4     1  FULL/  -   00:00:38   5             Serial0/0
R1#

There you have it. If there is an IPv4 address configured anywhere on the router, OSPFv3 will use it for the router ID. If not, then you MUST configure a router ID in the OSPFv3 configuration.

IPv6 Intro: Routing with RIP for IPv6 (RIPng)

In our last lab, we set up a small network with IPv6 and static routes. Let's up the ante a little bit this time, and set up slightly larger network using IPv6 and RIPng.

True Confession: I wanted to start with EIGRP for IPv6, but it isn't supported on either of the routers I have available in GNS3, grrr... However, RIPng is, so we'll go with RIPng for now. I now return you to your regularly scheduled blog post...

Here's the network I am using for this lab:


We start by enabling unicast routing on the routers, and assigning the IPv6 addresses to all of the interfaces (R1 shown, others similar):
R1(config)#ipv6 unicast-routing
R1(config)#int lo0
R1(config-if)#ip addr 10.254.254.1 255.255.255.255
R1(config-if)#ipv6 enable
R1(config-if)#ipv6 address 2001:00C0:FFEE:0000:0000:0000:0000:1/128
R1(config-if)#no shut
R1(config-if)#int fa0/0
R1(config-if)#ipv6 enable
R1(config-if)#ipv6 address 2001:00C0:FFEE:0000:0000:0000:0001:0001/125
R1(config-if)#no shut
R1(config-if)#int s/0/0
R1(config-if)#ipv6 enable
R1(config-if)#ipv6 address 2001:00C0:FFEE:0000:0000:0000:1111:0001/126
R1(config-if)#no shut

Once you have assigned IPv6 addresses to the respective interfaces on all of the routers, you should be able to ping across each subnet, but (for example) R5 shouldn't be able to ping R4:
R5(config)#do ping 2001:C0:FFEE::2222:1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:C0:FFEE::2222:1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/9/16 ms
R5(config)#do ping 2001:C0:FFEE::1111:2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:C0:FFEE::1111:2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R5(config)#

This is not at all unexpected. In IPv4, you wouldn't be able to ping from R5 to R4 either, unless you had static routes in place or a routing protocol to create the routes between routers that are not directly connected. Let's turn up RIPng on all five routers to share routes across this network (again, R1 shown, but the other routers are similar):
R1(config)#int fa0/0
R1(config-if)#ipv6 rip 10 enable
R1(config-if)#int s0/0
R1(config-if)#ipv6 rip 10 enable
R1(config-if)#exit

That's it! No "network" statements -- just edit the interface configuration to tell the router to start the RIPng process on that interface, and the router will begin sending advertisements for connected networks through that interface. Let's look at the routing table on R1:
R1(config)#do sho ipv6 route
IPv6 Routing Table - 8 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
       O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
LC  2001:C0:FFEE::1/128 [0/0]
     via ::, Loopback0
C   2001:C0:FFEE::1:0/125 [0/0]
     via ::, FastEthernet0/0
L   2001:C0:FFEE::1:1/128 [0/0]
     via ::, FastEthernet0/0
C   2001:C0:FFEE::1111:0/126 [0/0]
     via ::, Serial0/0
L   2001:C0:FFEE::1111:1/128 [0/0]
     via ::, Serial0/0
R   2001:C0:FFEE::2222:0/126 [120/2]
     via FE80::CA01:33FF:FE30:0, FastEthernet0/0
L   FE80::/10 [0/0]
     via ::, Null0
L   FF00::/8 [0/0]
     via ::, Null0
R1(config)#

Hmmm...notice that the loopback interfaces for R2 through R5 aren't showing up? Let's edit R1 and R2 to see if enabling RIPng on the loopback interfaces resolves that problem:
R1(config)#int lo0
R1(config-if)#ipv6 rip 10 enable
R1(config-if)#exit
...
R2(config)#int lo0
R2(config-if)#ipv6 rip 10 enable
R2(config-if)#exit

Does R1 see the loopback address on R2 now?
R1(config)#do sho ipv6 route | inc 2001:C0:FFEE::2/128
R 2001:C0:FFEE::2/128 [120/2]
R1(config)#

Yep, that works...but is there a better way to enable RIPng on an interface that isn't actually connected to another host? Let's try something on R3:
R3(config)#ipv6 router rip 10
R3(config-rtr)#redist connected

Does R1 see R3's loopback now?
R1(config)#do sho ipv6 route | inc 2001:C0:FFEE::3/128
R 2001:C0:FFEE::3/128 [120/2]
R1(config)#

Success! On the downside, it's a little hokey that you enable RIPng on the interface, but have to enable redistribution of connected routes in a global configuration, but I suppose that's better than having to enable redistribution on each interface <shrug>

One other thing to look at: let's look at one other thing in the routing table on R1:
R1(config)#do sho ipv6 route
IPv6 Routing Table - 8 entries
<...snip...>
L   FF00::/8 [0/0]
     via ::, Null0
R1(config)#

Once again, there is an odd-looking IPv6 address showing up in the routing table. Let's check our interfaces for anything similar:
R1(config)#do sho ipv6 int brie | inc FF00
R1(config)#

No...nothing there. What gives?

As it turns out, FF02::9 is a multicast address reserved by IANA for RIPng route updates, as defined in RFC 2080. And with that interesting (?) little tidbit of information, we will wrap up this lab on IPv6 routing with RIPng. Next time, we'll dive into OSPFv3.

Cisco Routing Oddities -- Interaction Between EIGRP, Distribute-List, and Static Routes

I ran into something at work today that I didn't quite understand, and which I finally had to mock up in GNS-3 to figure out. While trying to track down a routing problem, I found a distribute-list statement on an EIGRP configuration that referenced an access list which denied anything from 10.0.0.0/8. That's not terribly unusual, except that it looked like there were still a lot of 10-dot subnets being propagated by EIGRP on this router. Digging into the configuration a bit more, I saw that there was a "redistribute static" command inside the EIGRP configuration, and I found several static routes to 10-dot subnets. To understand the interaction between EIGRP, static routes, and the "distribute-list" statement, I created the following, simple network in GNS-3:



In this network, R1, R3, R4 and R5 will all use EIGRP to share routes with each other. R2 will have a default route pointing to R1, and R1 will have a single static route to R2's loopback address:
R1(config)#ip route 10.254.254.0 255.255.255.0 10.0.0.2
R1(config)#router eigrp 10
R1(config-router)#redistribute static metric 1000000 1 255 1 1500

After turning up EIGRP, R1 shared all of its known routes with R3, R4 and R5, exactly as you would expect:
R2#ping 100.64.254.1
Sending 5, 100-byte ICMP Echos to 100.64.254.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/8 ms
R2#

-----------------------------------------------------------------------

R3#ping 10.0.0.2
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/17/44 ms
R3#

-----------------------------------------------------------------------

R4#ping 10.0.0.2
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/29/72 ms
R4#

-----------------------------------------------------------------------

R5#ping 10.0.0.2
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/27/44 ms
R5#

Then, I added the following configuration statements to R1:
R1(config)#ip access-list standard FILTER-NULL-ROUTES
R1(config-std-nacl)#deny 10.0.0.0
R1(config-std-nacl)#permit any
R1(config-std-nacl)#!
R1(config-std-nacl)#router eigrp 10
R1(config-router)#distribute-list FILTER-NULL-ROUTES out
R1(config-router)#!

Running the exact same ping tests...:
R2#ping 100.64.254.1
Sending 5, 100-byte ICMP Echos to 100.64.254.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/12/40 ms
R2#

-----------------------------------------------------------------------

R3#ping 10.0.0.2
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R3#

-----------------------------------------------------------------------

R4#ping 10.0.0.2
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R4#

-----------------------------------------------------------------------

R5#ping 10.0.0.2
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R5#

This is to be expected -- 10.0.0.0/30 is a control to verify that the distribute-list is working as expected (that is, that it is filtering 10.0.0.0/8 from the EIGRP updates). Let's see if the distribute-list overrides the static route, or if the static route overrides the distribute-list:
R3#ping 10.254.254.9
Sending 5, 100-byte ICMP Echos to 10.254.254.9, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/23/40 ms
R3#

-----------------------------------------------------------------------

R4#ping 10.254.254.9
Sending 5, 100-byte ICMP Echos to 10.254.254.9, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/35/72 ms
R4#

-----------------------------------------------------------------------

R5#ping 10.254.254.9
Sending 5, 100-byte ICMP Echos to 10.254.254.9, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/28/48 ms
R5#

Notice how we can still reach 10.254.254.9, even though we can no longer reach 10.0.0.2? The distribute-list is filtering 10.0.0.0/8 addresses from the EIGRP routing updates sent by R1. However, we have explicitly stated that we want static routes to be redistributed by EIGRP, and we have a static route for 10.254.254.0/24 via 10.0.0.2. Consequently, R1 is still advertising a route for 10.254.254.9, despite the distribute-list filter. This explains how my router at work was still sharing 10-dot routes with other routers in its EIGRP area, even though there was a distribute-list statement filtering 10-dot subnets.

IPv6 Intro: Global Unicast Address, Link-Local Addresses, and a Brief Intro to Static Routing

In the last lab, we configured a link between R1 and R2, using the IP addresses "2001:co:ffee::4:1" and "2001:co:ffee::4:2," respectively.  Let's try something:
R1#sho ipv6 interface brief
FastEthernet0/0            [up/up]
    FE80::CE00:6BFF:FE8E:0
    2001:C0:FFEE::4:1
Loopback0                  [up/up]
    unassigned
R1#

Well, that's odd! I don't know about you, but I only recall configuring a single IPv6 address on Fa0/0 on R1, but the "sho ipv6 interface brief" command is displaying two addresses.

Actually, it's not odd at all. When you enable IPv6 on an interface, it automatically configures a special class of IPv6 addresses on the interface. Notice how the extra address begins with "FE80?" An IPv6 address that begins with FE80 is a "link-local" address, and they are automatically configured on every interface using IPv6. The IPv6 address that we manually added to the routers is called a "global unicast" address. At this point, you are probably wondering why we bothered to assign an IPv6 address to the interface if the router would automatically assign one, too. There's a hint buried within the names of these address types: "Link-local" and "global-unicast." "Link-local" addresses are locally scoped (where "locally" means local to that one interface), whereas "global-unicast" addresses are, well, globally-scoped. Try to ping the link-local address on R1 from R2:
R2#ping ipv6 fe80:0:0:0:ce00:6bff:fe8e:0
Output Interface: FastEthernet0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80::CE00:6BFF:FE8E:0, timeout is 2 seconds:
Packet sent with a source address of FE80::CE01:6BFF:FE8E:0
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/16/36 ms
R2#

Interesting...notice how the router prompted you to specify an output interface? Since link-local addresses are locally-scoped to one specific interface, you have to specify which interface the ping command should use to reach the destination address. Just for giggles, let's add a new interface, Fa1/0, to R2, and connect a third router to that interface:



We'll add the new IPv6 addresses on both R2 and R3 as we've done in the past, and we'll add a static route so that R3 knows how to reach the 2001:co:ffee::4:0/126 network:
R3(config)#ipv6 route 2001:00c0:ffee:0:0:0:4:0/126 2015:0:0:0:0:0:0:1
R3(config)#exit
R3#ping ipv6 2001:00c0:ffee:0:0:0:4:2

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

Good! Let's add a static route for the link-local address on R2, Fa0/0:
R3(config)#ipv6 route fe80:0000:0000:0000:ce01:6bff:fe8e:0/126 2015:0:0:0:0:0:0:1
% Invalid prefix
R3(config)#

"Locally-scoped" means you can't route these addresses. The only place they are valid is on the interface directly connected to the destination address. Therefore, you can't create a static route for a link-local address. Let's try one more thing, just for the fun of it:



We'll configure the subnet 2001::0/125 on each of these interfaces:
R1(config-if)#int fa0/0
R1(config-if)#ipv6 addr 2001:0:0:0:0:0:0:1/125
R1(config-if)#no shut

R2(config-if)#int fa0/0
R2(config-if)#ipv6 addr 2001:0:0:0:0:0:0:2/125
R2(config-if)#no shut

R3(config-if)#int fa0/0
R3(config-if)#ipv6 addr 2001:0:0:0:0:0:0:3/125
R3(config-if)#no shut

Now, let's make sure each router can ping the other two routers:
R1#ping ipv6 2001:0:0:0:0:0:0: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 = 4/12/36 ms
R1#ping ipv6 2001:0:0:0:0:0:0:3

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

(I've omitted the output from R2 and R3 for the sake of brevity, but I did test them)

What about the link-local interfaces? Can we ping them? Let's find out:
R1#sho ipv6 int brie
FastEthernet0/0            [up/up]
    FE80::CE00:6BFF:FE8E:0
    2001::1
<...snip...>
R2#sho ipv6 int brie
FastEthernet0/0            [up/up]
    FE80::CE01:6BFF:FE8E:0
    2001::2
<...snip...>
R3#sho ipv6 int brie
FastEthernet0/0            [up/up]
    FE80::CE03:6BFF:FE8E:0
    2001::3
<...snip...>

Now that we have the link-local addresses on each router, we'll try the ping test:
R1#ping ipv6 FE80::CE01:6BFF:FE8E:0
Output Interface: FastEthernet0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80::CE01:6BFF:FE8E:0, timeout is 2 seconds:
Packet sent with a source address of FE80::CE00:6BFF:FE8E:0
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/22/40 ms
R1#ping ipv6 FE80::CE03:6BFF:FE8E:0
Output Interface: FastEthernet0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80::CE03:6BFF:FE8E:0, timeout is 2 seconds:
Packet sent with a source address of FE80::CE00:6BFF:FE8E:0
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/12/36 ms
R1#
<...snip...>

R2#ping ipv6 FE80::CE00:6BFF:FE8E:0
Output Interface: FastEthernet0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80::CE00:6BFF:FE8E:0, timeout is 2 seconds:
Packet sent with a source address of FE80::CE01:6BFF:FE8E:0
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/8 ms
R2#ping ipv6 FE80::CE03:6BFF:FE8E:0
Output Interface: FastEthernet0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80::CE03:6BFF:FE8E:0, timeout is 2 seconds:
Packet sent with a source address of FE80::CE01:6BFF:FE8E:0
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/10/20 ms
R2#
<...snip...>

R3#ping ipv6 FE80::CE00:6BFF:FE8E:0
Output Interface: FastEthernet0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80::CE00:6BFF:FE8E:0, timeout is 2 seconds:
Packet sent with a source address of FE80::CE03:6BFF:FE8E:0
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/14/40 ms
R3#ping ipv6 FE80::CE01:6BFF:FE8E:0
Output Interface: FastEthernet0/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80::CE01:6BFF:FE8E:0, timeout is 2 seconds:
Packet sent with a source address of FE80::CE03:6BFF:FE8E:0
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/15/36 ms
R3#
<...snip...>


As you can see, the link-local interface is not limited to point-to-point networks; it will also work on multipoint networks.

One other interesting point to raise about IPv6 addresses: there is no broadcast address, as there is in IPv4. Instead, IPv6 uses multicast to replicate the functionality of IPv4 broadcast addresses. In additon to global unicast, link-local and multicast addresses, IPv6 also supports a few other special classes of addresses, but we will save them for another day. With what we have covered in this lab and the previous lab, we now have enough grounding to start playing with routing...but I'll save that for the next lab.

IPv6 Intro: Address Format and Subnetting

A couple of years ago, I created a lab, Advanced Cisco Routing: Implementing OSPF in IPv6. I probably got the cart before the horse when I created that lab, since that was the only in this blog (so far) where we even discussed IPv6. Ideally, I should have given an intro to IPv6 addressing and networking before creating a lab where we implemented a routing protocol in IPv6. Today, I'd like to fix that problem. Let's start with a basic introduction to IPv6, from the beginning.

I won't spend a lot of time discussing the need for IPv6. If you are reading this blog, you are already well aware that we network types are quickly running out of free IPv4 addresses, and that in an increasingly connected world, we need to implement a new Layer-3 protocol in order to connect all of our devices to the public Internet. Good enough? ;) Good. Let's proceed with a description of IPv6.

Basic Format of an IPv6 Address:
In IPv4, a valid IP address is a 32-bit number, broken down into four groups of 8-bit numbers -- that is, four groups of digits, each of which can be in the range 0-255. For example, 10.254.254.1 is a valid IP address, as is 172.16.0.4 and 192.168.131.75. Technically, any grouping of octets from 0.0.0.0 to 255.255.255.255 would be valid for IP addressing. However, in practice, parts of the address space have been reserved for special purposes, and therefore, 224.0.0.0 through 255.255.255.255 are not usable for addressing hosts.

Because one of the primary drivers for IPv6 is a lack of IPv4 address space, an IPv6 address is rather more complex. Where IPv4 addresses are 32 bits in length, an IPv6 address is 128 bits in length. Where IPv4 addresses are typically written in decimal notation, IPv6 addresses are written in hexidecimal. Additionally, where an IPv4 address is divided into four groups of 8 bits, separated by a period ("."), IPv6 addresses are subdivided into eight groups of 16-bits each, separated by a colon (":"). For example:
2001:4840:af21:0000:0000:2112:2358:0042
fe80:0000:0000:0000:baca:8ffe:fe42:f138

Because hexidecimal numbers contain alphabetic characters between "A" and "F," you will often see IPv6 addresses with...ummm...clever (?)...words enmbedded in the addresses:
2016:00c0:ffee:4a11:0000:0000:0000:0001
2001:dead:beef:cafe:0000:0000:0000:0128

...which helps with memorizing frequently used addresses. Even better, if an address contains a long sequence of zeroes, you can abbreviate the IPv6 address by replacing the sequence with two colons (":"):
2016:00c0:ffee:4a11::0001

Actually, even that can be shortened, because it isn't necessary to include all of the leading zeroes in each 16-bit string, like so:
2016:c0:ffee:4a11::1

Note: This only applies to LEADING zeroes, however, because trailing zeroes are placeholders, and therefore are required! Consequently, you cannot shorten "2016:c0:ffee:4a11::1" any further, as the zero in "2016" and "c0" must be present. One other catch: you can only truncate sequences of zeroes ONCE in an IPv6 address. For example, if you had the complete IPv6 address, "2001:0000:0042:0000:0000:0000:0000:af41," you would have to choose which sequence of zeroes to truncate. These would be acceptable:
2001::42:0000:0000:0000:0000:af41
2001:0000:42::af41

...but this would not:
2001::42::af41

That is because with either of the first two examples, you can still determine where within the 128 bits of address the "42" lies, but "2001::42::af41" could be any of the following addresses:
2001:0000:0042:0000:0000:0000:0000:af41
2001:0000:0000:0042:0000:0000:0000:af41
2001:0000:0000:0000:0042:0000:0000:af41
2001:0000:0000:0000:0000:0042:0000:af41

Note: Wait a minute! When you abbreviated the full IPv6 address as "2001:0000:42::af41,", you dropped the two leading zeroes ahead of the "42" in "0042," even though you replaced all of the zeroes after "42!"

Yes, but since you can only drop the leading zeroes in a 16-bit segment (i.e., "0042" can be abbreviated as "42," but "4200" cannot), we still know exactly where it belongs in the full, expanded IPv6 address.

Subnetting:
Just as in IPv4, IPv6 addresses can be subnetted. Just as 10.254.254.1/32 is a host address in IPv4, 2001::192:168:1:1/128 is a host address in IPv6. You can subdivide networks in IPv6 to optimize the number of networks and hosts in exactly the same way that you would in IPv4. However, it is important to remember that IPv6 uses hexadecimal numbers, so if you decide to "encapsulate" a common IPv4 address in IPv6 as I did above, don't make the mistake of assuming that, for example, 2001::192:168:1:9/126 and 2001::192.168.1.10/126 are contiguous host addresses within the same subnet. They aren't, as I discovered in a lab recently ;) Between ":9" and ":10" in an IPv6 address, you will find ":a" through ":f" -- which spans two /126 subnets, with ":10" being the network address (as opposed to a host address) for yet another subnet!

Putting it into practice!
Let's create a lab in GNS3 (or actual hardware, if you'd prefer) where we start connecting devices with IPv6. We'll start with a very simple network consisting of two routers. For this first lab, all we'll do is enable IPv6 on the routers, apply an IPv6 address to the connected interfaces, and make sure we can ping across the connection:



Now, we'll turn up the IPv6 addresses on these two routers:
R1(config)#ipv6 unicast-routing
R1(config)#int fa0/0
R1(config-if)#ipv6 enable
R1(config-if)#ipv6 address 2001:00c0:ffee:0000:0000:0000:0004:0001/126
R1(config-if)#no shut
R1(config-if)#exit
R1(config#exit

...and on R2:
R2(config)#ipv6 unicast-routing
R2(config)#int fa0/0
R2(config-if)#ipv6 enable
R2(config-if)#ipv6 address 2001:00c0:ffee:0000:0000:0000:0004:0002/126
R2(config-if)#no shut
R2(config-if)#exit
R2(config#exit

Can we ping?
R1#ping ipv6 2001:00c0:ffee:0000:0000:0000:0004:0002

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

How about from R2?
R2#ping ipv6 2001:00c0:ffee:0000:0000:0000:0004:0001

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

Perfect! We have met the objectives of this lab, so we'll call it a day.

IPv6 Intro: Address Format and Subnetting

A couple of years ago, I created a lab, Advanced Cisco Routing: Implementing OSPF in IPv6. I probably got the cart before the horse when I created that lab, since that was the only in this blog (so far) where we even discussed IPv6. Ideally, I should have given an intro to IPv6 addressing and networking before creating a lab where we implemented a routing protocol in IPv6. Today, I'd like to fix that problem. Let's start with a basic introduction to IPv6, from the beginning.

I won't spend a lot of time discussing the need for IPv6. If you are reading this blog, you are already well aware that we network types are quickly running out of free IPv4 addresses, and that in an increasingly connected world, we need to implement a new Layer-3 protocol in order to connect all of our devices to the public Internet. Good enough? ;) Good. Let's proceed with a description of IPv6.

Basic Format of an IPv6 Address:
In IPv4, a valid IP address is a 32-bit number, broken down into four groups of 8-bit numbers -- that is, four groups of digits, each of which can be in the range 0-255. For example, 10.254.254.1 is a valid IP address, as is 172.16.0.4 and 192.168.131.75. Technically, any grouping of octets from 0.0.0.0 to 255.255.255.255 would be valid for IP addressing. However, in practice, parts of the address space have been reserved for special purposes, and therefore, 224.0.0.0 through 255.255.255.255 are not usable for addressing hosts.

Because one of the primary drivers for IPv6 is a lack of IPv4 address space, an IPv6 address is rather more complex. Where IPv4 addresses are 32 bits in length, an IPv6 address is 128 bits in length. Where IPv4 addresses are typically written in decimal notation, IPv6 addresses are written in hexidecimal. Additionally, where an IPv4 address is divided into four groups of 8 bits, separated by a period ("."), IPv6 addresses are subdivided into eight groups of 16-bits each, separated by a colon (":"). For example:
2001:4840:af21:0000:0000:2112:2358:0042
fe80:0000:0000:0000:baca:8ffe:fe42:f138

Because hexidecimal numbers contain alphabetic characters between "A" and "F," you will often see IPv6 addresses with...ummm...clever (?)...words enmbedded in the addresses:
2016:00c0:ffee:4a11:0000:0000:0000:0001
2001:dead:beef:cafe:0000:0000:0000:0128

...which helps with memorizing frequently used addresses. Even better, if an address contains a long sequence of zeroes, you can abbreviate the IPv6 address by replacing the sequence with two colons (":"):
2016:00c0:ffee:4a11::0001

Actually, even that can be shortened, because it isn't necessary to include all of the leading zeroes in each 16-bit string, like so:
2016:c0:ffee:4a11::1

Note: This only applies to LEADING zeroes, however, because trailing zeroes are placeholders, and therefore are required! Consequently, you cannot shorten "2016:c0:ffee:4a11::1" any further, as the zero in "2016" and "c0" must be present. One other catch: you can only truncate sequences of zeroes ONCE in an IPv6 address. For example, if you had the complete IPv6 address, "2001:0000:0042:0000:0000:0000:0000:af41," you would have to choose which sequence of zeroes to truncate. These would be acceptable:
2001::42:0000:0000:0000:0000:af41
2001:0000:42::af41

...but this would not:
2001::42::af41

That is because with either of the first two examples, you can still determine where within the 128 bits of address the "42" lies, but "2001::42::af41" could be any of the following addresses:
2001:0000:0042:0000:0000:0000:0000:af41
2001:0000:0000:0042:0000:0000:0000:af41
2001:0000:0000:0000:0042:0000:0000:af41
2001:0000:0000:0000:0000:0042:0000:af41

Note: Wait a minute! When you abbreviated the full IPv6 address as "2001:0000:42::af41,", you dropped the two leading zeroes ahead of the "42" in "0042," even though you replaced all of the zeroes after "42!"

Yes, but since you can only drop the leading zeroes in a 16-bit segment (i.e., "0042" can be abbreviated as "42," but "4200" cannot), we still know exactly where it belongs in the full, expanded IPv6 address.
Subnetting:
Just as in IPv4, IPv6 addresses can be subnetted. Just as 10.254.254.1/32 is a host address in IPv4, 2001::192:168:1:1/128 is a host address in IPv6. You can subdivide networks in IPv6 to optimize the number of networks and hosts in exactly the same way that you would in IPv4. However, it is important to remember that IPv6 uses hexadecimal numbers, so if you decide to "encapsulate" a common IPv4 address in IPv6 as I did above, don't make the mistake of assuming that, for example, 2001::192:168:1:9/126 and 2001::192.168.1.10/126 are contiguous host addresses within the same subnet. They aren't, as I discovered in a lab recently ;) Between "::9" and "::10" in an IPv6 address, you will find "::a" through "::f" -- which spans two /126 subnets, with "::10" being the network address for a third!

Putting it into practice!
Let's create a lab in GNS3 (or actual hardware, if you'd prefer) where we start connecting devices with IPv6. We'll start with a very simple network consisting of two routers. For this first lab, all we'll do is enable IPv6 on the routers, apply an IPv6 address to the connected interfaces, and make sure we can ping across the connection:



Now, we'll turn up the IPv6 addresses on these two routers:
R1(config)#ipv6 unicast-routing
R1(config)#int fa0/0
R1(config-if)#ipv6 enable
R1(config-if)#ipv6 address 2001:00c0:ffee:0000:0000:0000:0004:0001/126
R1(config-if)#no shut
R1(config-if)#exit
R1(config#exit

...and on R2:
R2(config)#ipv6 unicast-routing
R2(config)#int fa0/0
R2(config-if)#ipv6 enable
R2(config-if)#ipv6 address 2001:00c0:ffee:0000:0000:0000:0004:0002/126
R2(config-if)#no shut
R2(config-if)#exit
R2(config#exit
>
Can we ping?
R1#ping ipv6 2001:00c0:ffee:0000:0000:0000:0004:0002

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

How about from R2?
R2#ping ipv6 2001:00c0:ffee:0000:0000:0000:0004:0001

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

Perfect! We have met the objectives of this lab, so we'll call it a day.

Cisco Advanced Routing Lab: Redistribution, Default Routes, and Virtual Tunnels

Today, I felt like challenging myself a little bit, so I created a large, somewhat complex network in GNS3 to try putting several concepts together into one, cohesive network. As usual, we'll start with the network diagram:



R1, R2, R3 and R4 are the network core. These routers all live in Area 0 (in the center of the diagram). R1 also participates in Area 1 and shares routes via BGP with R5. R5 participates in an entirely separate OSPF domain with R6 (my idea was that R5 and R6 would be "Internet" hosts for this lab). Just like R1, R2 also participates in Area 1, providing a redundant link to this area. R3 participates in OSPF area 3 and is one of the endpoints for the virtual tunnel to Area 4. R4 also belongs to Area 2. R7, 8 and 9 are pretty straightforward, existing only in Area 1. Likewise, R10 and R11 only live in Area 2; there's nothing complex about their configurations, either. R12, however, is the boundary between Area 2 and the RIP network including R13. R14 and R15 are routers belonging to Area 3, but R16 is a little more tricky. R16 participates in both Area 3 and Area 4.

However, OSPF requires ALL OSPF areas connect to the backbone (area 0) by at least one router. If you notice, there is no direct link between Area 4 and Area 0 in this network diagram, so in order to have Area 4 share routes with the rest of the network, you need to create a "virtual link" between R16 and R3. If ever you find yourself with an OSPF area that doesn't connect to the backbone, it might be worth rethinking your network design so that all of your areas do connect to Area 0. Speaking in broad generalities, there's usually something flawed with your design if you can't connect various OSPF areas directly to the backbone, but if for some reason you can't, it's pretty easy to connect R16 and R3 via a virtual tunnel. First, on R3:
R3(config)#router ospf 42
R3(config-router)#area 0.0.0.3 virtual-link 10.254.254.16


...and on R16:
R16(config)#router ospf 42
R16(config-router)#area 0.0.0.3 virtual-link 10.254.254.3


That's it! There are several options -- such as the various timers -- that you can adjust to account for various network performance issues across the virtual tunnel, but that's essentially all there is to creating the tunnel. Inside the OSPF config on each tunnel endpoint, you list the area ID of the OSPF area that the tunnel will be transiting, and you give the IP address of the other router's OSPF router-ID. In this network, I am using 10.254.254.<router number> for the loopback0 IP address, so R3 is 10.254.254.3 and R16 is 10.254.254.16.

The next "interesting" feature of this lab is the redistribution between OSPF Area 2 and the RIP network on R12. On R13, I created several 172.16.x.y networks on loopback interfaces...:
R13#sho ip int brie
Interface         IP-Address    OK? Method Status...
FastEthernet0/0   unassigned    YES unset  admin...
FastEthernet1/0   10.128.12.2   YES manual up ...
FastEthernet2/0   unassigned    YES unset  admin...
FastEthernet3/0   unassigned    YES unset  admin...
Loopback0         10.254.254.13 YES manual up...
Loopback1         172.16.1.1    YES manual up...
Loopback2         172.16.2.1    YES manual up...
Loopback3         172.17.1.1    YES manual up...
Loopback4         172.17.3.1    YES manual up...

RIPv1 is classful, while we are using classless routing, so the first thing to do is make sure that we are using RIPv2 on both R12 and R13:
R12(config)#router rip
R12(config-router)#version 2

Next, on R12, I want to tell RIP to redistribute OSPF routes, but to add a metric that is sufficiently large that R12 and R13 will prefer local routes to routes that have been imported from OSPF:
R12(config-router)#redistribute ospf 42 metric 3

Since RIP, being a distance-vector protocol, uses hop count as a metric (with a maximum of 15 hops), we start routes imported from OSPF with a hop count of 3 (the "42" is the OSPF process ID I used in the lab -- "router ospf 42"). Now, we'll do the same thing with OSPF:
R12(config-router)#router ospf 42
R12(config-router)#redistribute rip metric 50000 subnets

Again, we are setting the OSPF metric for routes important from RIP to an arbitrarily large value, so that OSPF will prefer local routes to imported routes; the exact value may require some tweaking on your network. I am also using the "subnets" option to tell OSPF to import just the specific subnets that RIP is advertising. Otherwise, any subnets from Class A IP space will be imported as /8 networks; any subnets from Class B IP space will be imported as /16 subnets; and any subnets from Class C IP space will be imported as /24 subnets (in other words, the two 172.16.x.y/24 subnets on R13 would be imported as a single 172.16.0.0/16, the two 172.16.x.y/24 subnets would be imported as a single 172.17.0.0/16, and the 10.254.254.13/32 subnet would be imported as 10.0.0.0/8 -- not at all what we wanted!).

On R1, we are advertising all of the subnets hosted in all of the OSPF areas as well as the RIP network to R5 via BGP:
router bgp 2358
no synchronization
bgp router-id 100.64.0.2
bgp log-neighbor-changes
network 10.0.0.4 mask 255.255.255.252
network 10.0.0.8 mask 255.255.255.252
network 10.0.1.4 mask 255.255.255.252
... network 172.16.0.0
network 172.17.0.0
network 192.168.9.0
neighbor 100.64.0.1 remote-as 2112
no auto-summary
!
It would also be possible to simply import OSPF into BGP, rather than list all of the subnets individually. However, this raises an interesting point: how do you import the routes that R5 is sharing via BGP into the network? The whole point of BGP is to share extremely large routing tables between routers. You don't want to import the entire Internet's routing tables into OSPF, so what is the best way to share external routes with the other routers in your internal network?

In this case, I used a simple, one-line statement to have the other routers send traffic destined for external networks to R1:
R1(config)#router ospf 42
R1(config-router)#default-information originate always
Since R5 is sharing its routes with R1, R1 knows how to reach the external subnets. By adding the "default-information originate" command to R1's OSPF config, it is essentially telling the other routers within the network that is the default gateway -- that traffic destined for unknown networks should be sent to it. R5 has the exact same statement in its OSPF config, so that R6 can reach the networks R5 has received via BGP.