nanog at fa1c52f96c54f7450e1ffb215f29991e.nosense.org
Tue Mar 28 20:19:22 UTC 2006
On Tue, 28 Mar 2006 06:46:13 +0530
"Glen Kent" <glen.kent at gmail.com> wrote:
> 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.
"Sheep are slow and tasty, and therefore must remain constantly
- Bruce Schneier, "Beyond Fear"
More information about the NANOG