This post is the fourth in a series of posts on route redistribution. If you haven't yet read the first three, here are the links:

• Route Redistribution - Part 1
• Route Redistribution - Part 2
• Route Redistribution - Part 3

Up until now in this series, we’ve seen the need for route redistribution, looked at a basic configuration, saw how we could filter specific routes from being redistributed, and learned how to prevent a routing loop by tagging redistributed routes. In this final route redistribution post, we want to check out route redistribution with IPv6, and how that configuration varies a bit from what we’ve done previously with IPv4 networks.

Consideration #1 - The Redistribution of Connected Networks

First, consider a router running a routing protocol; let’s say it’s OSPF in this instance. Also, let’s say that router has several interfaces that are participating in the OSPF routing protocol. On that same router, imagine we’re running another routing protocol (let’s say it’s EIGRP), and we’re doing mutual route redistribution.

Here’s what might be surprising. If we’re doing route redistribution on that router, the IPv4 networks associated with that router’s interfaces participating in OSPF will be redistributed, into EIGRP in our example. However, that’s not the behavior we witness with IPv6 networks. Specifically, with IPv6 networks, we have to give an extra parameter to our route redistribution configuration explicitly stating we want to redistribute connected networks. Otherwise, those IPv6 routes associated with directly connected interfaces are not redistributed.

The logic behind that behavior stems from the understanding that in order to redistribute a route, that route has to appear in a router’s IP routing table. Of course, when we look at a router’s IP routing table and see directly connected networks, those networks show up as connected networks, rather than networks that have been learned by a specific routing protocol.

While route redistribution for IPv4 understands that the network is directly connected, but is participating in a routing process and will therefore be redistributed, route redistribution for IPv6 makes no such assumption. Specifically, if we’re redistributing IPv6 networks from one routing protocol into another, those networks need to show up in a router’s IPv6 routing table along with the indication they were learned via the routing protocol being redistributed. Of course, we can add an extra parameter to our redistribute command to cause those directly connected IPv6 networks (participating in the redistributed protocol) to also be redistributed. This post will show that configuration a bit later.

Consideration #2 - Redistributing into OSPF

In a previous post, we discussed a potential issue you might encounter when redistributing into OSPF (depending on your Cisco IOS version). The issue was related to subnets. Specifically, by default in older versions of Cisco IOS, OSPF only redistributes classful networks into OSPF, unless we add the subnets parameter to the redistribute command. The addition of that parameter allowed the redistribution of networks into OSPF even if they didn’t have a classful mask. Please keep in mind though that recent versions of Cisco IOS automatically add the subnets parameter without requiring you to manually enter it.

However, there is no subnets parameter with IPv6 route redistribution. The reason is, IPv6 has no concept of subnets.

IPv6 Route Redistribution Example

To demonstrate IPv6 route redistribution, consider the following topology:

The OSPFv3 and EIGRP for IPv6 routing protocols for IPv6 have already been configured on all of the routers. Now, let’s go to router R2 and configure mutual route redistribution between these two autonomous systems. We'll begin by confirming that by checking out router R2’s IPv6 routing table.

The above output shows we’ve learned two IPv6 networks via OSPF, two IPv6 networks via EIGRP, and R2 is directly connected to two IPv6 networks. Next, let’s configure mutual route redistribution between OSPFv3 and EIGRP for IPv6.

Notice the mutual route redistribution configuration used for IPv6 routes is nearly identical to our previous configuration for redistributing IPv4 routes. However, the include-connected option was specified for both redistribute commands. This allowed router R2 to redistribute the 2003::/64 network (directly connected to router R2’s Gig 0/1 interface and participating in OSPF) into EIGRP. It also allowed router R2 to redistribute the 2004::/64 network (directly connected to router R2’s Gig 0/2 interface and participating in EIGRP) into OSPF.

To confirm our configuration was successful, let’s visit both routers R1 and R3, confirming they each know how to reach all six IPv6 networks in our topology.

The above output confirms that routers R1 and R3 each know about their three directly connected routes and three routes redistributed into their routing process. So, the great news is, there’s not much new to learn when it comes to redistributing IPv6 routes as compared to redistributing IPv4 routes. I hope you’ve enjoyed this 4-part series of blog posts on route redistribution.

Kevin Wallace, CCIEx2 (R/S and Collaboration) #7945