Re: Routing Loop Prevention Methods

From: Aidan Marks (amarks@cisco.com)
Date: Thu Dec 26 2002 - 17:45:59 GMT-3


There are many different approaches to multiple redistribution points, some
include:

- distribute lists
- tags
- adjusting distances

The particular problem to resolve is ensuring you prefer routing protocol
A's subnets via that protocol and preferably those routes via protocol B as
an alternative backup path on each mutual redistribution point. Routing
loops occur when the RT on each both point to each other for a particular
route. This usually occurs as a result of learning a route via a routing
protocol that has a lower AD than the originating protocol.

Distrbute Lists - RIP<-->OSPF with 2 mutual redistribution points - R1, R2.

You can use distribute lists to stop RIP route feedback via OSPF. That is,
R1 and R2 will learn RIP routes via OSPF and prefer the OSPF route because
of the lower AD. So define all your RIP routes and filter them on OSPF
inbound. Downside is there is no backup path, i.e. if R1's interface to
the RIP domain goes down, it will not be able to take the alternative path
via OSPF/R2.

Tags - EIGRP<-->OSPF with 2 mutual redistribution points - R1, R2.

Tags can be used to avoid routing loops - discussed here -

http://www.cisco.com/en/US/customer/tech/tk648/tk365/technologies_tech_note09186a008009487e.shtml#probs

Downside is that it does not work for RIPv1 or IGRP. Advantages are that
you can do not have to define any ACLs and additions to any networks will
be automatically handled.

Adjusting Distances - ISIS<-->OSPF with 2 mutual redistribution points -
R1, R2.

This is a fairly universal method. To avoid a routing loop, you have to
ensure that when ISIS routes are learned via OSPF, that they are not
preferred over the original ISIS route on R1 and R2. By default, it will
be, AD 110 < 115. Set your default distance in OSPF to a high value, say
140 - "distance 140". Define your OSPF routes in an ACL and set their
distance using the "distance 110 0.0.0.0 255.255.255.255 <acl>"
command. Now you will have your OSPF routes being preferred via OSPF and
ISIS as a secondary path and your ISIS routes preferred via ISIS and a
backup path of OSPF (nice). So rule of thumb is to define on the protocol
that has the lower AD (OSPF in this case) a higher default AD (than the
other routing protocol) and lower the AD for recognised OSPF routes. You
do _not_ need to do the same for ISIS (define an ACL and modify distances)
as R1 or R2 will never prefer the ISIS path for an OSPF route unless there
is failure.

I prefer this method. I have only touched on this topic and there are many
ways to address this as I am sure others will suggest.

You can write all the routes down manually and/or perhaps check this via
show ip route ospf to verify what subnets are in the domain (or if you
want, show ip ospf database). Don't forget if you do this any routes
originating from that box won't show up in the show ip route ospf command
for example, say a loopback on that box, so perhaps check your list by
doing that command on both mutual redistribution points. I suggest you do
this at the time you come to do the mutual redistribution, as you may not
have a full understanding of what your routing domains look like and you
can sanity check with show commands. I would further suggest that you get
each routing domain up and running in complete isolation before attempting
any mutual redistribution. While doing it all at once and preparing lists
beforehand may save you a small amount of time, you expose yourself to
error in the process and back tracking on an area that requires you to be
very careful will cost you dearly.

Regards/Aidan

At 01:07 AM 27/12/2002, Jay Greenberg wrote:

>Does anyone have a solid method for preventing routing loops via
>redistribution? I have considered writing down all the subnets that
>belong to each routing domain and creating a prefix list at the
>beginning of the lab, and applying it to all redistribution commands.
>
>If this method works, how can one clearly define the subnets that are
>allowed to be redistributed into another protocol? I'm worried that
>when lab day comes, it will be such a nightmare of redistribution that I
>will not be able to mentally comprehend what I want / don't want to
>inject.
>.
.



This archive was generated by hypermail 2.1.4 : Fri Jan 17 2003 - 17:21:53 GMT-3