Sooner or later in your networking career, you will need Route redistribution. In fact, this configuration allows you to deal with many situations. More than that, route redistribution may be your only option in some cases. We could talk a lot about redistribution – in fact it is one of the core topics of both CCNP and CCIE. However, this article gives all you need to start working with redistribution effectively.

Route Redistribution can be complex, and to face this topic you should have a clear understanding of routing. If you are not sure, no worries – you can check out our in-depth guide to networking.

Introducing Route Redistribution

What is Route Redistribution?

In a textbook, you would find that route redistribution is the implementation that bridges two different routing domains. This definition is accurate, yet we can expand it to make it clear.

Route Redistribution is the implementation that bridges two different routing domains.

To put it simple, a routing domain is a group of routers (and devices in general) where you run the same routing protocol. For example, a set of routers where you deploy OSPF is a routing domain. In some cases, you might have multiple routing domains in your network. When this happens, and you want these domains to communicate, you need route redistribution.

With route redistribution, routers from one routing domain knows routes from the other domain.

When do you need Route Redistribution?

As we said in the last paragraph, you need route redistribution when two routing domains must talk with each other. Fair enough, but when do you need multiple routing domains?

Generally speaking, a network having multiple routing domains is not a good network. Best practices tells us to select a routing protocol, and stick with it. However, this is not always possible. In fact, there are some circumstances where you end up with multiple routing protocols.

• Integrating a company during a merger
• Migrating from an old protocol to a new protocol
• Connecting to a provider’s network imposing a protocol different from yours

As you can see, the first two are temporary. Eventually, the integration will finish, and so the migration between protocols. As soon as they finish, you will have a single domain and remove redistribution. The latter point is different, because it is permanent. Nonetheless, integrating with an ISP is probably the easier of the three.

On an MPLS network, for example, a provider will generally impose BGP to exchange the private routes among your sites. These are not Internet routes, just the IP plan of your remote sites. This means that they are not hundreds of thousands, like Internet routes, and thus an IGP protocol can handle them as well. As soon as the routes enter a site, you want to propagate them with a faster protocol than BGP. This is when redistribution may take place.

The Dangers behind Route Redistribution

At this point you might think how beautiful redistribution is. And it is, if you do it correctly. If you don’t, your network will simply blow up, potentially harming the business. This is because a misconfigured route redistribution setup can create routing loops.

Having routing loops in your network is something you don’t want to deal with, trust me on this. If you are lucky, loops happens only for a few networks. When this happens, the loop isolates these networks and they simply cannot communicate. It starts to get scary if there are many networks in the loops. You might lose the management of devices, and be unable to fix the configuration remotely.

In this article we will see how to do route redistribution in the right way, avoiding any loop.

Planning Route Redistribution

..with a lab!

Why simply show you how to do route redistribution when we can do this together? Use the image below to download the GNS3 topology that we will use in the demonstration. This way you can check the configuration on your own and do some experiments.

The download includes the initial configuration files as well, so that you can re-create the topology with real routers or with different GNS3 images. In case you don’t know about GNS3, we have a crash course about it.

The Topology

Even with just four routers we can start playing with route redistribution.

Imagine we are merging two companies: the one on the left uses OSPF, and the one on the right uses EIGRP. Since the company on the left purchased the one on the right, it will be the one in control. As you can see in the drawing, we have some small /30 transit networks between routers. Then, each router hosts four subnets that we are emulating with Loopback interfaces.

The basic OSPF and EIGRP configuration are already in place, but we need to configure redistribution. In fact, the only routes we are propagating are the transit network. At the moment, R2 does not know anything about EIGRP. On the other side, R4 does not know anything about the OSPF domain. Furthermore, Loopback addresses are just local. Each router knows only its own loopback networks, and not the ones of the other routers. Not even for the routers in the same routing domain.

Our Target

Before stating what we want to achieve, we need to define the ownership of edge routers. Both R1 and R3 are in both routing domains, so who they belong to? For our lab, they belong to the OSPF company. In real-world, they belong to the company that owns them. So, we can assume that OSPF company purchased R1, R2 and R3, while EIGRP company has only R4.

We want that all OSPF routers see all networks from the EIGRP domain. This must work even if one of the two edge routers (R1 and R3) fails. Furthermore, we want to achieve the best path possible when reaching the EIGRP company. We expect that the bottom part of the network (e.g. 10.80.0.6) goes through R3, and the upper part (e.g. 10.80.0.1) goes through R1. This must be true for traffic going the other way around as well.

We also want that traffic enters the EIGRP domain only if strictly necessary. In other words, R3 should send packets on the OSPF network if it wants to talk to R1. The only exception is for the addresses that relates to the EIGRP topology (10.211.12.129 and 10.211.12.133), that can flow on the EIGRP network.

And, of course, we don’t want any loop!

The “redistribute” command

Redistribution can be as simple as using a single command. Of course, just doing that will end up in a huge loops most of the times. You give the redistribute command inside a routing protocol configuration, and it works something like that:

redistribute 

Options involve using route maps to prevent loops and other advanced stuffs. The other protocol is the protocol from which we will import routes.

The command tells the routing protocol under which it is being configured to propagate routes coming from the other protocol.

Here we have an example.

router ospf 1
 redistribute eigrp 65535

This tells OSPF instance #1 to take the routes inside the EIGRP 65535 instance and redistribute them to its neighbors, in OSPF. Of course, the router must run both OSPF 1 and EIGRP 65545 for this command to do something.

The major cause of a loop

If you want to do your best to avoid loops, make redistribution on a single router. However, this means no redundancy, so it might be not a feasible option in all circumstances.

If you have more than one redistribution point (in this lab we have two), you may end up with loops. They happen because one protocol takes the routes from the other, and gives them to its neighbors. These routes reach the other redistribution point, which injects them back in the original protocol, with a different metric. Some routers may see the same route coming from two different protocols (or path in general), and create the loop.

Without some loop prevention mechanisms, we cannot create a reliable route redistribution setup.

Route Redistribution with Route Maps

The idea behind route maps

If you look at the OSPF or EIGRP configuration, you will see loopback interfaces are not part of it. In fact, the only networks we added are the transit links connecting routers. This is a best practice, you should enable the routing protocols only on networks where the router actually forms adjacencies. The following configuration snippet is from R1.

router ospf 1
 router-id 1.1.1.1
 log-adjacency-changes
 passive-interface default
 no passive-interface FastEthernet0/0
 network 10.80.0.0 0.0.0.3 area 0

Probably, the fastest way to propagate the loopback addresses is by adding them with a network command. This approach may work right now, but it is harder to maintain and troubleshoot. Instead, we are going to redistribute connected networks, implementing route filtering with route maps.

Each route map tells the routing protocol which routes it is allowed to import from the other.

Route Filtering components

Creating a route filter involves three key steps.

1. Create an ACL that defines all the major networks that we want to allow.
   Alternatively, we can create a prefix list. It is similar to an ACL, because it defines a set of addresses. However, it also defines the minimum and maximum prefix length we want to allow. For example, the ACL may say we want to redistribute all 10.0.0.0/8 and its sub networks. With a prefix list, we can say that we only want to redistribute the 10.0.0.0/8 networks bigger than a /25.
2. Associate the prefix list or ACL to a route map
3. Apply the route map to the redistribution

For smaller deployments, you might want to apply the ACL. In a deployment that may scale, you should opt for the prefix list. When using the ACL, all subnets that match that ACL will be included, regardless of their prefix length. This includes smaller subnets as well. Because of that, we recommend using prefix lists in all cases.

Creating Prefix Lists

Each OSPF router will have its own route filtering configuration. Since we will apply the route filter configuration as incoming, it will affect all routes coming into OSPF from other sources. Thus, on the edge routers (R1 and R3), our rule must include also the EIGRP addresses, not only the Loopback addresses.

So, our configuration on R2 will be simple.

ip prefix-list LO-NET seq 5 permit 10.2.0.0/22 ge 24

Of course, LO-NET is the name of the prefix list. Instead, seq indicates the position of each rule inside the list, like an ACL. This is optional, the system will add it for you if you don’t. Then, we have the major network, like 10.1.0.0/22. After that, we can use one or two keywords.

• ge stands for Great or Equal, and it states “from this network, the prefix must be at most this big”
• le stands for Less or Equal, and it states “from this network, the prefix must be at least this large”

In the this statement, we tell to take all /24 or bigger (/23 and /22 in this case) networks from the 10.1.0.0/22 subnet. When it comes to integrating EIGRP, we will use both ge and le. This to tell the router to take only /30 subnets from the 10.211.12.128/29 subnet.

Instead, this is what we need on R1.

ip prefix-list LO-NET seq 5 permit 10.1.0.0/22 ge 24

R3 configuration is almost identical.

ip prefix-list LO-NET seq 5 permit 10.3.0.0/22 ge 24

Inserting the prefix list in a route map

The prefix list identifies the routes. The route map tells the router what to do in case we have a match. However, in this case we don’t want to do anything special for these routes, we just want to redistribute them. However, route maps can modify the routes, set tags, change metrics and more. But that’s for another time… here are the commands to create the map.

route-map REDISTRIBUTE-CONNECTED permit 10
 match ip address prefix-list LO-NET

The first statement creates a route map named REDISTRIBUTE-CONNECTED, and defines that it has a permit statement at sequence 10. That statement (the second line), tells the router to match based on the prefix list LO-NET. Since this is a permit statement, this will allow the routes to join the route redistribution.

We can apply these two commands as is to all three routers.

Enabling Route Redistribution

We can enable the redistribution for the loopback interfaces, that are connected. When doing so, we can use our route map to protect the router. In OSPF, you need to add the subnets keyword to the redistribute command, otherwise it will only search for classful networks. This is not necessary in other protocols, like EIGRP.

router ospf 1
 redistribute connected route-map REDISTRIBUTE-CONNECTED subnets

The command is very simple. It tells the router to redistribute the connected routes, only if the REDISTRIBUTE-CONNECTED route map allows it.

Go the extra mile!

Now you know how to redistribute with a filter. R4 is not redistributing its connected networks, so try to implement this is on your own. It is almost identical to R2, but it is using EIGRP.

One important thing: when redistributing routes in EIGRP, it is better to specify the metric. However, this is not mandatory in case of connected routes.

Route Tagging makes good loop prevention

Redistribution with route tagging

Route tagging is just what the name says: adds a tag to routes. We use this to mark routes coming from another protocol. Then, when these routes reach another edge routes, it will find the tag and won’t allow their redistribution into their original protocol.

This simile mechanism is effective to prevent loops when you have multiple redistribution points.

For this setup to work, we need two route maps. One will tell EIGRP to import all routes that weren’t already coming from the EIGRP domain, and tag them as “OSPF routes”. The other route map, instead, will do the same for OSPF. It will tell OSPF to import all rotues that weren’t already coming from the OSPF domain, and tag them as “EIGRP routes”.

Implementing Route Tagging

Both R1 and R3 do the same thing, symmetrically. Thus, we can use the following commands on both of them, without any modification. First, we need to create a pair of route maps.

route-map REDISTRIBUTE-OSPF deny 10
 match tag 65535
route-map REDISTRIBUTE-OSPF permit 20
 set tag 1
route-map REDISTRIBUTE-EIGRP deny 10
 match tag 1
route-map REDISTRIBUTE-EIGRP permit 20
 set tag 65535

The route map REDISTRIBUTE-OSPF is the one EIGRP will use when importing OSPF routes. This checks if the routes being imported have a tag of 65535. If that’s the case, do not import them (this is a deny statement). If we have no match here, because the tag is not 65535, we will surely match the next role. In fact, no match statement inside a route map means “match everything”. This rule will import the routes and set them a tag of 1.

The other route map is REDISTRIBUTE-EIGRP, the one OSPF will use when importing EIGRP routes. It works exactly like the other route map, but with the tags inverted. It will prevent any route tagged with 1 from being imported, and import any other route by tagging it 65535.

Now, we can apply the route maps and we are done!

router eigrp 65535
 redistribute ospf 1 metric 1000 1 255 1 1500 route-map REDISTRIBUTE-OSPF
router ospf 1
 redistribute eigrp 65535 subnets route-map REDISTRIBUTE-EIGRP

Note that, when redistributing OSPF into EIGRP, we specified the metric values. This is compulsory, otherwise EIGRP won’t know how to deal with the imported routes.

Wrapping it up

Congratulations! At this point, you should have a clear picture of what redistribution is and what harm can do to a network. In this article, we covered some basic techniques to implement redistribution safely. If you have a clear understanding of these topics, you will stand out among other network engineers.

What do you think about redistribution? What do you find more challenging? Let me know your thoughts and questions in the comment!

The post Route Redistribution tutorial with Cisco devices appeared first on ICTShore.com.