Mutual Redistribution

Mailman List Mirror (Read Only)
1

Hi,

There is a provider who is running ISIS in its core and they are using
RIP for the management interface. Is it valid to redistribute all the
ISIS routes into RIP and all the RIP routes into ISIS?

Cant this create a loop or something?

Thanks,
Kent

2

Hi,

There is a provider who is running ISIS in its core and they are using
RIP for the management interface. Is it valid to redistribute all the
ISIS routes into RIP and all the RIP routes into ISIS?

Depends on what they are trying to achieve, as well as their routing
protocol topology. Mutual redistribution may not be necessary if in one
of the routing protocol clouds they have a default route pointing
towards the other e.g. for a a hub and spoke topology (IS-IS hub, RIP
spokes), a default in the RIP cloud pointing towards the IS-IS hub, and
then redistributing the RIP learned routes into IS-IS would achieve the
same as what mutual redistribution is being used for.

Cant this create a loop or something?

You've just got to make sure that routes don't get redistributed back to
where they came from e.g. an IS-IS route into RIP, then from RIP back
into IS-IS, then IS-IS into RIP etc. On face value you'd think that
increasing metrics would prevent this routing information loop, except
during redistribution the metric can loose its ability to properly
measure the path length, in part due to some protocols not having very
large metric capacity (RIP probably being the only one). One better
solution is to take advantage of route tags or labels. When a route is
redistributed you tag it, and then when mutual redistribution occurs in
the other direction, you exclude routes that have that tag. You'd need
to do this in both redistribution directions, with different tags to
prevent loops in either direction. This method doesn't rely on the
behaviour of always increase metrics, so it would be more robust.

HTH,
Mark.

3

Mark Smith wrote:

One better
solution is to take advantage of route tags or labels. When a route is
redistributed you tag it, and then when mutual redistribution occurs in
the other direction, you exclude routes that have that tag. You'd need
to do this in both redistribution directions, with different tags to
prevent loops in either direction. This method doesn't rely on the
behaviour of always increase metrics, so it would be more robust.

HTH,
Mark.

I dont believe popular vendors implementations of rip propogate tags.

At least the last time I tried loop prevention with that, it didnt work.

4

Did it happen to be RIPv1 ? Only RIPv2 supports route tags.

5

Mark Smith wrote:

On Tue, 28 Mar 2006 16:37:48 -0500

Did it happen to be RIPv1 ? Only RIPv2 supports route tags.

Of course it was rip2

Rip1 is dead. Anyone using it should be shot.

6

I don't know. If it solves the problem well enough, and you don't have
any better alternatives, I think using it would be fine.