From: David Buechner (dbuechn@attglobal.net)
Date: Thu May 13 2004 - 02:27:18 GMT-3
--=====================_148345299==.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed
Carlos,
I've responded in-line with your comments.
At 05:32 PM 5/12/2004, Carlos G Mendioroz wrote:
>Dave,
>I have been following your debugs of redistribution. Thanks for sharing them!
You're welcome!
>Basically I think mastering redistribution is one big step into being able
>to do the lab (BTW, when are you trying yours ?) and would like to discuss
>with you some items, if you don't mind.
Agreed. My next, fifth (guess I must be dense!), and (hopefully) final
attempt is June 29 in RTP. Of course, a good friend of mine took five
tries too and I was pretty close last time (probably 10-11 points
shy). I'd love to discuss stuff with you - let me know when/how you want
to pursue that! We can do e-mail, IM, etc.
>(For once, I've come to make sense of the distribute OUT list <protocol>
>if it works like you say - and cisco says - :-)
I had the same experience when I did this last weekend!
>I've still some gray areas... like:
>1) at time 10:29:39, OSPF has basically 2 independent type 5 LSAs (one at
>R2 and one at R4) with the same attributes: metric 20 type 2.
>
>How is R4's ospf process able to prefer R2 LSA over its own ?
I think you're referring to the lines that say:
R2: May 8 10:29:39: OSPF: Generate external LSA 10.10.10.0, mask
255.255.255.0, type 5, age 0, metric 20, tag 0, metric-type 2, seq 0x80000001
R4: May 8 10:29:39: OSPF: Generate external LSA 10.10.10.0, mask
255.255.255.0, type 5, age 3600, metric 16777215, tag 1, metric-type 2, seq
0x80000002
Notice the age on the LSA from R4 - it's 3600 which is MAXAGE. This is R4
flushing the LSA from the OSPF database. There's a description of this in
Doyle, Vol I, page 456 (I looked it up to check).
Looking back at this it probably would have been clearer had I not
'redistributed connected' on R2, but had the ethernet interface covered by
a 'network area' statement. Then you would have had different type LSAs
involved.
I also probably should have done microseconds in the timestamps. The R4
messages usually were first in the syslog, because the syslog host was on
the net on R4's ethernet. All other routers' syslog traffic had to come
through the frame cloud to R4 first, so most of the time R4 got there
quicker. I re-arranged things in ways that made sense (for example - R2
must have flooded its LSA for R4 to decide it had a route with a closer
admin distance). This does add a possible "gotcha" to my examples in that
if I'm really wrong on how something worked I could have reordered things
incorrectly. I've reviewed it a couple of times and it makes sense, but I
thought I should mention this.
>Same type of issue on R4, but now in RIP. Once OSPF decided to insert its
>own 10.10.10.0 network in the RIB, then RIP gets it from there and prefers
>it with metric 2 to the previously installed one that had metric 1! Why ?
I believe your talking about these lines:
R4: May 8 10:29:39: RIP-DB: adding 10.10.10.0/24 (metric 2) via R2 on
Serial0.2 to RIP database
R4: May 8 10:29:39: RIP-DB: Remove 10.10.10.0/24, (metric 1) via R1, Serial0.1
R4 has just added a route with lower AD to the routing table (the OSPF
route). Obviously R4 will use this for it's own routing decisions, but I
believe it goes one step further - this route is now considered "better"
because of the lower AD and since we're redistributing OSPF into RIP and we
now have a "better" OSPF route available R4 needs to announce that via
RIP. Therefore, even though the new metric is higher the new route
replaces the entry in the RIP database. R4 then sends this out in updates
- so now R1 is saying "I can get there in 1" and R4 is saying "I can get
there in 2". Each router then makes it's own decision - R1 based on the
RIP metric (and the fact that it now has a CONNECTED route) and R4 based on
the AD of the routes it knows. Does my convoluted 1 am logic make sense?
>On the other side, there's a confirmation in some books that
>redistribution always occurs from the routing table, and never from
>internal protocol tables, so there is no way to have redistribution
>"cascades" so to speak. Somehow routes are marked internally as learned
>from the RIB vs learned from elsewhere, and protocols will not install
>locally a route that comes from the RIB.
"cascades" is a good word for the issue we're describing and I agree with
you, there is no way to have redistribution cascades. And thanks for
finding the right word for it!
For some reason (probably the hour) I'm not grasping your last
statement.....I'll have to read it again tomorrow. :-)
Good discussion - thanks! And thanks for listening to my ramblings - it is
helping me to understand this better trying to explain it. Had another one
of those in March - I did a training class for a client on CIP cards and
DLSW access to SNA hosts. Boy did I finally put some things about DLSW
into place in my head!
Good luck to all!
David
>-Carlos
>
>David Buechner wrote:
>>Hi all!
>>There were some questions in the last couple of months which got me
>>started thinking. The questions were about situations in which you're
>>redistributing with three different protocols on one router, i.e. EIGRP -
>>OSPF - RIP. The question was along the lines of "I redistribute EIGRP
>>into OSPF and OSPF into RIP - why don't the EIGRP routes show up in
>>RIP?" My experience in doing scenarios had been that this was working as
>>designed, but I finally felt compelled to understand this better.
>>I've read some Cisco doc and labbed some situations to prove to myself
>>how this works and thought I'd share my thoughts with you. Hopefully
>>these are helpful to someone. And if I'm wrong in any of this please let
>>me know!
>>One thing I noticed in reading the Cisco doc is that talk about
>>redistributing "derived routes" between "routing domains." The more I
>>read this the more it occurred to me that what they're talking about is
>>routes in the main IP routing table which were learned from a particular
>>protocol. So for example, in the question above: RIP will learn about
>>OSPF routes by searching the main routing table for OSPF derived routes
>>rather than by searching the OSPF database directly. If we track the
>>distribution path for an EIGRP learned route then it would seem that A)
>>the EIGRP route will be installed in the main routing table as it has the
>>lowest distance, B) OSPF will learn the route through redistribution
>>since an EIGRP derived route is in the main routing table, and C) RIP
>>will not learn about the route since there is no OSPF derived route in
>>the main routing table to redistribute. As expected then you must also
>>redistribute EIGRP directly into RIP to get the EIGRP routes.
>>To test all this I set up a small 4 router network which looks like this:
>> R4
>> |
>>------------------------------------ Frame Cloud
>>| | |
>>R1 R2 R3
>>| | |
>>------------------------------------ Ethernet 10.10.10.0/24
>>
>>R4 is the hub of a frame cloud with spokes out to R1, R2, and R3. R1,
>>R2, and R3 all have ethernet interfaces in a common IP subnet. R1 is
>>talking RIP to R4. R2 is talking OPSF to R4. R3 is talking EIGRP to
>>R4. R4 is redistributing every each protocol into both of the others.
>>I then used the 3550 to which these routers are connected to bring
>>interfaces online or take them offline. I did some debugs on the routers
>>which I logged to a syslog server. Rather than send an even longer
>>e-mail I put the results up on a web page at:
>>http://home.comcast.net/~dbuechner/syslog.html
>>What I learned is that my expectations seemed to bear out on the
>>routers. I was able to see routes get modified or dropped based on
>>redistribution criteria. For example if you do the following: the EIGRP
>>router (R3) has the only active ethernet interface. R1 and R2 are
>>learning about this interface from redistribution into RIP and OSPF on
>>R4. If I then configure a STATIC route to 10.10.10.0/24 on R4 the STATIC
>>route replaces the EIGRP route in the main routing table. The lack of
>>the EIGRP route in the main routing table then causes both OSPF and RIP
>>(and therefore R2 and R1) to lose their routes to the interface.
>>I also understand the 'distribution list <x> out <routing-protocol>'
>>statement better now. Essentially what you are doing is applying the
>>access-list <x> to routes derived from <routing-protocol> when you send
>>updates out. So for example I was getting a route from EIGRP which I
>>redistributed into RIP. I then added a distribution list to filter this
>>route by adding 'distribution list 1 out eigrp 1' under the RIP
>>protocol. RIP then lost the route. If i shutdown the R3 interface and
>>brought up the R2 interface I then had an OSPF derived route in the
>>routing table on R4. This route got redistributed through RIP to R1
>>because the distribution list command was specifically looking for
>>EIGRP. Also, when the distribution list is keeping RIP from advertising
>>the route I did notice one (originally confusing) thing: the route still
>>shows up in the RIP database on R4. The distribution list doesn't keep
>>the route out of the database, just out of the updates being sent out.
>>The more I thought about this the more sense it made. While I certainly
>>don't have access to the IOS code I started to remember my CS training -
>>specifically in the areas of algorithms and data structures. It makes
>>sense from a coding perspective for the OSPF process to be isolated from
>>changes to the data structures used by other routing protocols. If
>>everyone just looks at the main routing table it is much cleaner.
>>What's happening also makes sense from a routing perspective. The whole
>>reason behind administrative distances is to handle the mismatch between
>>routing protocol metrics. It makes sense that the same problem would
>>occur when you redistribute. If I'm redistributing two protocols into
>>OSPF, for example, and both have routes to somewhere in common, how else
>>would I decide which route to take on except by utilizing the AD? Since
>>the AD determination is already done for a route to be placed in the main
>>routing table it makes sense to get your routes for redistribution from
>>there as well.
>>I hope this all makes sense and that it is helpful to someone. If I'm
>>out in left field *PLEASE* say so! I'd hate to be wrong myself, and I'd
>>hate to lead others astray. :-)
>>Back to the lab!!
>>David
>>_______________________________________________________________________
>>Please help support GroupStudy by purchasing your study materials from:
>>http://shop.groupstudy.com
>>Subscription information may be found at:
>>http://www.groupstudy.com/list/CCIELab.html
>
>--
>Carlos G Mendioroz <tron@huapi.ba.ar> LW7 EQI Argentina
>
>_______________________________________________________________________
>Please help support GroupStudy by purchasing your study materials from:
>http://shop.groupstudy.com
>
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
--=====================_148345299==.ALT
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html>
<body>
Carlos,<br><br>
I've responded in-line with your comments.<br><br>
At 05:32 PM 5/12/2004, Carlos G Mendioroz wrote:<br>
<blockquote type=3Dcite class=3Dcite cite>Dave,<br>
I have been following your debugs of redistribution. Thanks for sharing
them!</blockquote><br>
You're welcome!<br><br>
<blockquote type=3Dcite class=3Dcite cite>Basically I think mastering
redistribution is one big step into being able to do the lab (BTW, when
are you trying yours ?) and would like to discuss with you some items, if
you don't mind.<br>
</blockquote><br>
Agreed. My next, fifth (guess I must be dense!), and (hopefully)
final attempt is June 29 in RTP. Of course, a good friend of mine
took five tries too and I was pretty close last time (probably 10-11
points shy). I'd love to discuss stuff with you - let me know
when/how you want to pursue that! We can do e-mail, IM,
etc.<br><br>
<blockquote type=3Dcite class=3Dcite cite>(For once, I've come to make sense
of the distribute OUT list <protocol><br>
if it works like you say - and cisco says - :-)<br>
</blockquote><br>
I had the same experience when I did this last weekend!<br><br>
<blockquote type=3Dcite class=3Dcite cite>I've still some gray areas...
like:<br>
1) at time 10:29:39, OSPF has basically 2 independent type 5 LSAs (one at
R2 and one at R4) with the same attributes: metric 20 type 2.<br><br>
How is R4's ospf process able to prefer R2 LSA over its own ?<br>
</blockquote><br>
I think you're referring to the lines that say:<br><br>
<pre>R2: May 8 10:29:39: OSPF: Generate external LSA 10.10.10.0,
mask 255.255.255.0, type 5, age 0, metric 20, tag 0, metric-type 2, seq
0x80000001
R4: May 8 10:29:39: OSPF: Generate external LSA 10.10.10.0, mask
255.255.255.0, type 5, age 3600, metric 16777215, tag 1, metric-type 2,
seq 0x80000002
</pre>Notice the age on the LSA from R4 - it's 3600 which is
MAXAGE. This is R4 flushing the LSA from the OSPF database.
There's a description of this in Doyle, Vol I, page 456 (I looked it up
to check).<br><br>
Looking back at this it probably would have been clearer had I not
'redistributed connected' on R2, but had the ethernet interface covered
by a 'network area' statement. Then you would have had different
type LSAs involved.<br><br>
I also probably should have done microseconds in the timestamps.
The R4 messages usually were first in the syslog, because the syslog host
was on the net on R4's ethernet. All other routers' syslog traffic
had to come through the frame cloud to R4 first, so most of the time R4
got there quicker. I re-arranged things in ways that made sense
(for example - R2 must have flooded its LSA for R4 to decide it had a
route with a closer admin distance). This does add a possible
"gotcha" to my examples in that if I'm really wrong on how
something worked I could have reordered things incorrectly. I've
reviewed it a couple of times and it makes sense, but I thought I should
mention this.<br><br>
<blockquote type=3Dcite class=3Dcite cite>Same type of issue on R4, but now
in RIP. Once OSPF decided to insert its own 10.10.10.0 network in the
RIB, then RIP gets it from there and prefers it with metric 2 to the
previously installed one that had metric 1! Why ?<br>
</blockquote><br>
I believe your talking about these lines:<br><br>
<pre>R4: May 8 10:29:39: RIP-DB: adding 10.10.10.0/24 (metric 2)
via R2 on Serial0.2 to RIP database
R4: May 8 10:29:39: RIP-DB: Remove 10.10.10.0/24, (metric 1) via
R1, Serial0.1
</pre>R4 has just added a route with lower AD to the routing table (the
This archive was generated by hypermail 2.1.4
: Wed Jun 02 2004 - 11:12:11 GMT-3
OSPF route). Obviously R4 will use this for it's own routing
decisions, but I believe it goes one step further - this route is now
considered "better" because of the lower AD and since we're
redistributing OSPF into RIP and we now have a "better" OSPF
route available R4 needs to announce that via RIP. Therefore, even
though the new metric is higher the new route replaces the entry in the
RIP database. R4 then sends this out in updates - so now R1 is
saying "I can get there in 1" and R4 is saying "I can get
there in 2". Each router then makes it's own decision - R1
based on the RIP metric (and the fact that it now has a CONNECTED route)
and R4 based on the AD of the routes it knows. Does my convoluted 1
am logic make sense?<br><br>
<blockquote type=3Dcite class=3Dcite cite>On the other side, there's a
confirmation in some books that redistribution always occurs from the
routing table, and never from internal protocol tables, so there is no
way to have redistribution "cascades" so to speak. Somehow
routes are marked internally as learned from the RIB vs learned from
elsewhere, and protocols will not install locally a route that comes from
the RIB.<br>
</blockquote><br>
"cascades" is a good word for the issue we're describing and I
agree with you, there is no way to have redistribution cascades.
And thanks for finding the right word for it!<br><br>
For some reason (probably the hour) I'm not grasping your last
statement.....I'll have to read it again tomorrow. :-)<br><br>
Good discussion - thanks! And thanks for listening to my ramblings
- it is helping me to understand this better trying to explain it.
Had another one of those in March - I did a training class for a client
on CIP cards and DLSW access to SNA hosts. Boy did I finally put
some things about DLSW into place in my head!<br><br>
Good luck to all!<br><br>
David<br><br>
<blockquote type=3Dcite class=3Dcite cite>-Carlos<br><br>
David Buechner wrote:<br>
<blockquote type=3Dcite class=3Dcite cite>Hi all!<br>
There were some questions in the last couple of months which got me
started thinking. The questions were about situations in which
you're redistributing with three different protocols on one router, i.e.
EIGRP - OSPF - RIP. The question was along the lines of "I
redistribute EIGRP into OSPF and OSPF into RIP - why don't the EIGRP
routes show up in RIP?" My experience in doing scenarios had
been that this was working as designed, but I finally felt compelled to
understand this better. <br>
I've read some Cisco doc and labbed some situations to prove to myself
how this works and thought I'd share my thoughts with you.
Hopefully these are helpful to someone. And if I'm wrong in any of
this please let me know!<br>
One thing I noticed in reading the Cisco doc is that talk about
redistributing "derived routes" between "routing
domains." The more I read this the more it occurred to me that
what they're talking about is routes in the main IP routing table which
were learned from a particular protocol. So for example, in the
question above: RIP will learn about OSPF routes by searching the main
routing table for OSPF derived routes rather than by searching the OSPF
database directly. If we track the distribution path for an EIGRP
learned route then it would seem that A) the EIGRP route will be
installed in the main routing table as it has the lowest distance, B)
OSPF will learn the route through redistribution since an EIGRP derived
route is in the main routing table, and C) RIP will not learn about the
route since there is no OSPF derived route in the main routing table to
redistribute. As expected then you must also redistribute EIGRP
directly into RIP to get the EIGRP routes.<br>
To test all this I set up a small 4 router network which looks like
this:<br>
&nbs=
p;
R4<br>
&nbs=
p;
|<br>
------------------------------------ Frame
Cloud<br>
| &nb=
sp;
| &nb=
sp;
|<br>
R1 &n=
bsp;
R2 &n=
bsp;
R3<br>
| &nb=
sp;
| &nb=
sp;
|<br>
------------------------------------
Ethernet 10.10.10.0/24<br><br>
R4 is the hub of a frame cloud with spokes out to R1, R2, and R3.
R1, R2, and R3 all have ethernet interfaces in a common IP subnet.
R1 is talking RIP to R4. R2 is talking OPSF to R4. R3 is
talking EIGRP to R4. R4 is redistributing every each protocol into
both of the others. <br>
I then used the 3550 to which these routers are connected to bring
interfaces online or take them offline. I did some debugs on the
routers which I logged to a syslog server. Rather than send an even
longer e-mail I put the results up on a web page at:<br>
<a href=3D"http://home.comcast.net/~dbuechner/syslog.html"=
eudora=3D"autourl">http://home.comcast.net/~dbuechner/syslog.html><br>
What I learned is that my expectations seemed to bear out on the
routers. I was able to see routes get modified or dropped based on
redistribution criteria. For example if you do the following: the
EIGRP router (R3) has the only active ethernet interface. R1 and R2
are learning about this interface from redistribution into RIP and OSPF
on R4. If I then configure a STATIC route to 10.10.10.0/24 on R4
the STATIC route replaces the EIGRP route in the main routing
table. The lack of the EIGRP route in the main routing table then
causes both OSPF and RIP (and therefore R2 and R1) to lose their routes
to the interface.<br>
I also understand the 'distribution list <x> out
<routing-protocol>' statement better now. Essentially what
you are doing is applying the access-list <x> to routes derived
from <routing-protocol> when you send updates out. So for
example I was getting a route from EIGRP which I redistributed into
RIP. I then added a distribution list to filter this route by
adding 'distribution list 1 out eigrp 1' under the RIP protocol.
RIP then lost the route. If i shutdown the R3 interface and brought
up the R2 interface I then had an OSPF derived route in the routing table
on R4. This route got redistributed through RIP to R1 because the
distribution list command was specifically looking for EIGRP. Also,
when the distribution list is keeping RIP from advertising the route I
did notice one (originally confusing) thing: the route still shows up in
the RIP database on R4. The distribution list doesn't keep the
route out of the database, just out of the updates being sent out.<br>
The more I thought about this the more sense it made. While I
certainly don't have access to the IOS code I started to remember my CS
training - specifically in the areas of algorithms and data
structures. It makes sense from a coding perspective for the OSPF
process to be isolated from changes to the data structures used by other
routing protocols. If everyone just looks at the main routing table
it is much cleaner.<br>
What's happening also makes sense from a routing perspective. The
whole reason behind administrative distances is to handle the mismatch
between routing protocol metrics. It makes sense that the same
problem would occur when you redistribute. If I'm redistributing
two protocols into OSPF, for example, and both have routes to somewhere
in common, how else would I decide which route to take on except by
utilizing the AD? Since the AD determination is already done for a
route to be placed in the main routing table it makes sense to get your
routes for redistribution from there as well.<br>
I hope this all makes sense and that it is helpful to someone. If
I'm out in left field *PLEASE* say so! I'd hate to be wrong myself,
and I'd hate to lead others astray. :-)<br>
Back to the lab!!<br>
David<br>