From: Scott M Vermillion (scott@it-ag.com)
Date: Sat Dec 22 2007 - 16:44:49 ART
Hi Kim,
Yes, your assumption was correct. In the topology of this lab (IEWB #7 for
anyone who cares), I have an FR link 163.1.12.0/24 which attaches R1 to R2
via OSPF only. I then have an Ethernet segment which attaches R1 to SW2 via
RIP only. Regardless of the presence of the 'redistribute connected' under
RIP on R1, I was "unexpectedly" seeing 163.1.12.0/24 as a RIP route on SW2
with a metric of 2. While there exists a physical link which would make it
possible for SW2 to learn of this network via RIP from another router
besides R1, I had verified that SW2 was learning of this network via RIP
from R1:
Rack1SW2#sh ip route 163.1.12.0
Routing entry for 163.1.12.0/24
Known via "rip", distance 120, metric 2
Redistributing via rip
Last update from 163.1.18.1 on FastEthernet0/5, 00:00:01 ago
Routing Descriptor Blocks:
* 163.1.18.1, from 163.1.18.1, 00:00:01 ago, via FastEthernet0/5
Route metric is 2, traffic share count is 1
R1 is attached to SW2 via 163.1.18.0/24. The purpose of running the debug
on R1 was to see if it in any way changed *how* this route was being
advertised. That should have been enough to guide me in to the answer, but
I was completely out of mental momentum by midnight. Here's the skinny, and
it's embarrassingly simple:
Even RIPv2 network statements are classful. Sure, you can do
'passive-interface default' all day long, but the fact that I had a network
statement for 163.1.0.0 under RIP meant that 163.1.12.0/24 was going to be
advertised into RIP, regardless of any redistribution that might be going
on. I purposefully assign a metric of 8 to all routes I redistribute into
RIP exactly because of this type of issue; you want to clearly be able to
see how a given route is propagating through your network, and the "metric
is 2" above was a clear indication that this was not arriving at SW2 as a
result of OSPF redistribution into RIP. I somehow just failed to put 2 and
2 together. Changing the R1-R2 subnet to 102.1.1.0/24 brings about the
behavior I was looking for. Sans any redistribution of connected into RIP
on R1, the 102.1.1.0/24 network appears in the SW2 routing table with a
metric of 9, as a result of it's being both directly attached to R1 and
covered by a network statement under OSPF on R1. What's missing at SW2 with
this configuration is R1's Lo0, which does not get advertised to SW2 by way
of having been redistributed into OSPF and then OSPF into RIP, because
(everyone sing along) there is no three-way redistribution. If I finally
understand things correctly, the 'redistribute connected' on R1 is because
of the loopback, which most definitely needs to be advertised into RIP to
meet other requirements.
So in answer to my own question, I was most assuredly on something last
night, but nothing good. I think my philosophy of upping my game as I enter
into these last weeks of lab prep may need to be reconsidered. I really
accomplished nothing last night other than to waste a bunch of my own time
and yours as well.
Thanks all for taking the time to help me along on this one. Although I
don't feel that redistribution is quite as soft a spot today as it was
yesterday, I'm definitely going to revisit that topic very soon. I'm way
too close to lab day to be having such a fundamental sticking point as this.
Regards,
Scott
From: Kim teu [mailto:kim.teu@gmail.com]
Sent: Saturday, December 22, 2007 8:04 AM
To: Scott M Vermillion
Cc: ccielab@groupstudy.com
Subject: Re: Has Redistribution Behavior Changed Or Am I High?
When you said "I find no apparent difference in any routing table... ", I
assume you mean the routing table of the router that's adjacent to the
router you perform redistribution because if you look at the routing table
that you perform redistribution on, you shouldn't see any difference. One
way to find out on the redistribution router is to do "sho ip route x.x.x.x"
to see if a particular interface IP is being redistributed or not.
HTH,
Kim
On 12/21/07, Scott M Vermillion <scott@it-ag.com> wrote:
Hi Kim,
Just to clarify, there was a separate task to redistribute my Lo0 into OSPF
early on in the lab (and the task requirement can only be met via
redistribution - a network statement or 'ip ospf 100 area 0' at the
interface level are both expressly prohibited). Then, separately, at the
end of the IGP section, I'm to redistribute OSPF into RIP and RIP into OSPF.
In the SG, they have 'redistribute connected' under the RIP process. A
brief mention is made in the lab breakdown video that this is because of the
earlier redistribution of connected into OSPF. However, I find no apparent
difference in any routing table regardless of this commands presence or
absence under RIP. Of course, it's been a long day and I haven't been
focused at all since I started out this morning. So maybe a good night's
sleep will help. Also, I'll try to navigate back to that section of the IE
ATC CoD. I remember this being discussed at length but I apparently don't
yet have it all committed to memory.
Thanks much,
Scott
From: Kim teu [mailto:kim.teu@gmail.com ]
Sent: Friday, December 21, 2007 10:41 PM
To: Scott M Vermillion
Cc: ccielab@groupstudy.com
Subject: Re: Has Redistribution Behavior Changed Or Am I High?
Scott,
The "redistribute connec route-map LOOPBACK_ONLY" should be under RIP
process, not OSPF process. Then, when you redistribute ospf under RIP, only
loopback interface get redistributed, but not other OSPF enabled interfaces.
HTH,
Kim
On 12/21/07, Scott M Vermillion <scott@it-ag.com> wrote:
OK folks, admittedly a soft spot in my underbelly here.
Redistribution rules as I have come to understand them (not necessarily in
any kind of order):
--redistribute any routes learned from the protocol being redistributed
--redistribute any connected interfaces that are covered by network
statement under the protocol being redistributed
--however, if a 'redistribute connected' statement exists in the protocol
being redistributed, only redistribute those connected interfaces which are
allowed in the manual 'redistribute connected' statement
So, for example, if I have router R1 running both RIP and OSPF, and I have
redistributed my loopback interface into OSPF with a route-map permitting
*only* the loopback to go into OSPF, then if I then later redistribute OSPF
into RIP, I will get all routes learned by OSPF in RIP but I will not get
the networks of directly connected links/interfaces running OSPF, because my
route-map didn't encompass anything but the loopback interface.
I thought I finally understood this concept correctly. Do I?
Because in my lab, I'm not seeing this. I have the exact scenario above
configured. In a Solutions Guide, it shows doing a 'redistribute connected'
under the RIP process, presumably in an effort to pull in directly connected
non-RIP/OSPF networks as well as those *learned* by OSPF. Right? Or wrong?
Because I am observing zero difference whether this manual redistribution of
connected exists under the RIP process or not. I do in fact seem to get the
directly connected non-RIP/OSPF networks showing up in and being advertised
into RIP, even sans a manual redistribution of connected under RIP.
So I ask you once again, am I on something good? Are my pupils perhaps a
little dilated this evening? Please advise.
Regards all,
Scott
This archive was generated by hypermail 2.1.4 : Tue Jan 01 2008 - 12:04:31 ARST