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
On Tue, 28 Mar 2006 06:46:13 +0530 "Glen Kent" <glen.kent@gmail.com> wrote:
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. -- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear"
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.
On Tue, 28 Mar 2006 16:37:48 -0500 Joe Maimon <jmaimon@ttec.com> wrote:
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.
Did it happen to be RIPv1 ? Only RIPv2 supports route tags. -- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear"
On Wed, 29 Mar 2006 06:33:08 -0500 Joe Maimon <jmaimon@ttec.com> wrote:
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.
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. -- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear"
participants (3)
-
Glen Kent
-
Joe Maimon
-
Mark Smith