RE: redistribution , then seeing non-stop route add then delete

Brian, Marc, et al,

I had a full lab scenario I was dealing with here....6 routers, few switches
(couple acting as routers couple acting as switches), so really 8 routers
and 2 switches...

EIGRP
RIPv2
OSPF

RIP domain was disjointed but with a tunnel between two of the RIP routers
acting as the tunnel endpoints, and the tunnel via area 0 of ospf
domain...with a requirement to only let rip origins traverse the tunnel

Couple of the 8 routers had direct connects to a couple of the different igp
routing domains but only one router had a direct connect to all 3 igp
domains.

Over the last few days, the way that I was trying to redistribute between
the IGP's seemed to solve some of the reachability the test was asking for,
but not all of the requirements

I read something last night about trying to look at the entire multi-igp
domain hierarchically, if possible, and it may not be possible. Mine didn't
exactly seem like a nicely arranged hierarchy (surprise surprise, must ccie
lab scenarios are a mess). Anyway, I looked at it and thought that since
there was one router with direct links into all 3 igp domains that this
might be a nice place to do all the redistribution mutually between all 3
domains. I did. I saw route flapping over and over again, with some of the
routers giving messages about...

RT: closer admin distance for x.x.x.x, flushing 1 routes

 .....then I thought I wonder if I made the rip process in those rip
speakers AD 109, I did, then did a "cle ip ro *" and it seems to have solved
the requirements for reachability. And no more route flaps. I was excited
so thought I'd share.

Aaron

-----Original Message-----
From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
Brian Dennis
Sent: Wednesday, February 08, 2012 7:43 AM
To: ccielab_at_groupstudy.com
Subject: Re: redistribution , then seeing non-stop route add then delete

You need to start at the source of the route redistribution and in
particular the protocol that has the higher administrative distance.
When you redistribute between two protocols one is going to have a
higher administrative distance than the other. In your case you have
RIP and OSPF. I'm going to assume the default administrative distance
has not been changed. If this is the case you need to ensure that on
ALL routers where the two routing protocol domains meet (routers running
both RIP and OSPF), the routes that originate in RIP are never installed
in the routing table of these routers as OSPF routes.

You need to protect the source of the redistributed routes. That is the
goal you need keep in mind. How you do this is up to you. You could
use a distribute-list inbound in OSPF on the routers that are in both
routing protocol domains (where the protocols meet as I mentioned
earlier), you could change the routes when they are put into OSPF by
summarizing them (the RIP routes would always be more specific), you
could play with the administrative distance on the routers where the two
protocols meet (not the best solution), etc. It's up to you how you
solve it but at the end of the day you are trying to ensure that the
source of the route redistribution always remains in the routing table
of the high administrative distance protocol.

The reason you don't have a problem with OSPF routes going into RIP by
default is that OSPF has a lower administrative distance and the RIP
routes can never overtake the OSPF routes assuming they are the same
route of course (same network and mask). This means you are always
trying to "protect" the high administrative distance protocol's routes.
  Most route redistribution problems come from the fact the higher
administrative protocols routes are "lost" (i.e. removed from the
routing table) once redistributed into a lower administrative distance
protocol and passed to another router.

Example 1:
Router R1, R2 and R3 are running RIP. Route R2 and R3 are also running
OSPF. OSPF and RIP are being mutually redistributed on R2 and R3. Lets
say R1's Loopback is 150.1.1.0/24 and advertised into RIP. R1
advertises it to R2. Now R2 redistributes it into OSPF. It gets to R4
and R4 passes it to R3 via OSPF. Now R3 gets the RIP advertisement from
R2 and also has the route via OSPF from R4. Which route does R3 use?
R3 uses OSPF due to the lower administrative distance. Since R3 has it
in it's routing table via OSPF now it will also redistribute it into
RIP. Now R3 advertises it to R2 via RIP so R2 has it via R1 and R3.
This is obviously a problem but if you follow the guidelines I outlined
above you would not have this problem because you would know the
"protect" the higher administrative distance protocols routes on the
routers that are in both routing protocol domains.

R1----R2----R3
        - -
        - -
        - -
        - -
        R4

Example 2:

R1----R2----R3
        - -
        - -
        - -
        - -
        R4

Router R1, R2 and R3 are running RIP. Route R2 and R3 are also running
OSPF. OSPF and RIP are being mutually redistributed on R3 only. Lets
say R1's Loopback is 150.1.1.0/24 and advertised into RIP. R1
advertises it to R2. R2 then advertises it onto R3 via RIP. Now R3
redistributes it into OSPF. It gets to R4 and R4 passes it to R2 via
OSPF. Now R2 gets the RIP advertisement from R1 and also has the route
via OSPF from R4. Which route does R2 use? R2 uses OSPF due to the
lower administrative distance. Since R2 does not have the RIP route in
the routing table the RIP route stops being advertised to R3.
Eventually R3 times out the RIP route and it's removed from it's routing
table. This means that R3 also stops redistributing it into OSPF. Once
this stops R2 doesn't receive it from R4 any more it then starts using
the RIP route from R1 again advertises it onto R3 again for the whole
process to start anew. This is obviously a problem but if you follow the
guidelines I outlined above you wouldn't have this problem because you
would know the "protect" the higher administrative distance protocols
routes on the routers that are in both routing protocol domains.

However you decide to solve these problems is up to you but you are in
the end trying to achieve the goal I mentioned of protecting the
"source" of the route redistribution.

Excuse any typos as I'm writing this during my lunch break (London R&S
bootcamp).

-- 
Brian Dennis, CCIEx5 #2210 (R&S/ISP-Dial/Security/SP/Voice)
bdennis_at_ine.com
Internetwork Expert, Inc.
http://www.INE.com
On 02/08/2012 01:02 PM, Aaron wrote:
> Everything was fine until I mutually redistributed between ospf and rip on
> one of my routers..now I'm seeing this adding and deleting of routes from
a
> few of my routers.  What is the best way to find the exact cause of this?
I
> understand that if I remove that mutual redistribution the route
add/delete
> activity stops, but then I lose my reachability that I'm trying to achieve
> by redistributing in the first place.  Appreciate any assistance in
> understanding where to go with something like this
>
>
>
> Aaron
>
>
>
> Debug ip routing..
>
> S3#
>
> S3#
>
> S3#
>
> *Feb  8 12:27:03.455: RT: add 192.10.2.0/24 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:27:03.491: RT: add 192.10.3.0/24 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:27:03.531: RT: add 192.10.4.0/24 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:27:03.531: RT: add 192.10.5.0/24 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:27:03.531: RT: add 192.10.6.0/24 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:27:03.531: RT: add 192.10.7.0/24 via 180.40.7.50, ospf metric
> [110/20]
>
> S3#
>
> *Feb  8 12:27:10.511: RT: del 192.10.2.0 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:27:10.511: RT: delete network route to 192.10.2.0
>
> *Feb  8 12:27:10.551: RT: del 192.10.3.0 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:27:10.551: RT: delete network route to 192.10.3.0
>
> *Feb  8 12:27:10.591: RT: del 192.10.4.0 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:27:10.591: RT: delete network route to 192.10.4.0
>
> *Feb  8 12:27:10.623: RT: del 192.10.5.0 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:27:10.623: RT: delete network route to 192.10.5.0
>
> *Feb  8 12:27:10.623: RT: del 192.10.6.0 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:27:10.623: RT: delete network route to 192.10.6.0
>
> *Feb  8 12:27:10.623: RT: del 192.10.7.0 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:27:10.623: RT: delete network route to 192.10.7.0
>
> S3#
>
> *Feb  8 12:27:29.595: RT: add 192.10.2.0/24 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:27:29.639: RT: add 192.10.3.0/24 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:27:29.679: RT: add 192.10.4.0/24 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:27:29.679: RT: add 192.10.5.0/24 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:27:29.679: RT: add 192.10.6.0/24 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:27:29.679: RT: add 192.10.7.0/24 via 180.40.7.50, ospf metric
> [110/20]
>
> S3#
>
> *Feb  8 12:27:36.663: RT: del 192.10.2.0 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:27:36.663: RT: delete network route to 192.10.2.0
>
> *Feb  8 12:27:36.703: RT: del 192.10.3.0 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:27:36.703: RT: delete network route to 192.10.3.0
>
> *Feb  8 12:27:36.743: RT: del 192.10.4.0 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:27:36.743: RT: delete network route to 192.10.4.0
>
> *Feb  8 12:27:36.775: RT: del 192.10.5.0 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:27:36.775: RT: delete network route to 192.10.5.0
>
> *Feb  8 12:27:36.775: RT: del 192.10.6.0 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:27:36.775: RT: delete network route to 192.10.6.0
>
> *Feb  8 12:27:36.775: RT: del 192.10.7.0 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:27:36.775: RT: delete network route to 192.10.7.0
>
> S3#
>
> *Feb  8 12:27:59.463: RT: add 192.10.2.0/24 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:27:59.503: RT: add 192.10.3.0/24 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:27:59.543: RT: add 192.10.4.0/24 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:27:59.543: RT: add 192.10.5.0/24 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:27:59.543: RT: add 192.10.6.0/24 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:27:59.543: RT: add 192.10.7.0/24 via 180.40.7.50, ospf metric
> [110/20]
>
> S3#
>
> *Feb  8 12:28:06.523: RT: del 192.10.2.0 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:28:06.523: RT: delete network route to 192.10.2.0
>
> *Feb  8 12:28:06.563: RT: del 192.10.3.0 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:28:06.563: RT: delete network route to 192.10.3.0
>
> *Feb  8 12:28:06.599: RT: del 192.10.4.0 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:28:06.599: RT: delete network route to 192.10.4.0
>
> *Feb  8 12:28:06.639: RT: del 192.10.5.0 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:28:06.639: RT: delete network route to 192.10.5.0
>
> *Feb  8 12:28:06.639: RT: del 192.10.6.0 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:28:06.639: RT: delete network route to 192.10.6.0
>
> *Feb  8 12:28:06.639: RT: del 192.10.7.0 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:28:06.639: RT: delete network route to 192.10.7.0
>
> *Feb  8 12:28:26.295: RT: add 192.10.2.0/24 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:28:26.335: RT: add 192.10.3.0/24 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:28:26.367: RT: add 192.10.4.0/24 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:28:26.367: RT: add 192.10.5.0/24 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:28:26.367: RT: add 192.10.6.0/24 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:28:26.367: RT: add 192.10.7.0/24 via 180.40.7.50, ospf metric
> [110/20]
>
> S3#
>
> S3#
>
> S3#
>
> S3#
>
> *Feb  8 12:28:33.363: RT: del 192.10.2.0 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:28:33.363: RT: delete network route to 192.10.2.0
>
> *Feb  8 12:28:33.403: RT: del 192.10.3.0 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:28:33.403: RT: delete network route to 192.10.3.0
>
> *Feb  8 12:28:33.439: RT: del 192.10.4.0 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:28:33.439: RT: delete network route to 192.10.4.0
>
> *Feb  8 12:28:33.439: RT: del 192.10.5.0 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:28:33.439: RT: delete network route to 192.10.5.0
>
> *Feb  8 12:28:33.439: RT: del 192.10.6.0 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:28:33.439: RT: delete network route to 192.10.6.0
>
> *Feb  8 12:28:33.439: RT: del 192.10.7.0 via 180.40.7.50, ospf metric
> [110/20]
>
> *Feb  8 12:28:33.439: RT: delete network route to 192.10.7.0
>
> S3#
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net