From: Kinton Connelly (kinton@xxxxxxxxxxxx)
Date: Wed Sep 13 2000 - 20:10:38 GMT-3
At 9/13/00, you wrote:
> > 1) Have R2 send an "ip default-network" into IGRP pointing to another
> > classful address that's already in your routing table (if it's not in your
> > routing table already, a static route will be automatically generated and
> > this is usually a bad thing in the lab).
>
>I disagree. I have heard that static routes are not allowed in the lab
>and although I have not yet attempted it, I disagree with that blanket
>statement. Almost ALL classless routing protocols generate a static
>route to null 0 when one configures summarization. The only way to
>remove it is to disable summarization.
Which part are you disagreeing with? The part about static routes usually
NOT being allowed? I don't know what to say except that everything I've
read has indicated that unless you're specifically asked to put in a static
route, they're usually not allowed.
But maybe you were talking about my statement about how a static route will
be automatically generated if the default network isn't already in your
routing table. You're right, I had the spirit of the situation but the
details were a little shabby. :-) My apologies. I should have said:
"A static route will be generated if the default-network specified doesn't
lie along classful boundaries".
Here's an example. Let's say you have two routers - r1 and r2 - set up like
this:
172.16.1.1/24=e0 \ 172.16.2.1/24 172.16.2.2/24 172.16.3.2/24
|--R1--serial0 --------serial0--R2---ether0
192.168.1.1/32=lo0/
OSPF IGRP IGRP
(apologies for the ascii diagram)
If you go into R1 and enter "ip default-network 172.16.1.0" then you'll
find a shiny new static route created for you that looks like this:
ip route 172.16.0.0 255.255.0.0 172.16.1.0
Also, your "ip default-network 172.16.1.0" command won't appear in the
config. The only way to get that ip default-network command to appear is to
use it on a classful boundary: "ip default-network 172.16.0.0" or "ip
default-network 192.168.1.0". But in this case, using the 172.16.0.0
network still won't work because IGRP on R2 will think that network is
locally attached and so it won't send the packets to R1 like you want it to.
The best thing to do here is to not advertise your e0 network but to
advertise a different network that's not on r2 - in this case, lo0's should
work.
Put that ip default-network command in. Now look in R1's routing table -
you'll see that 192.168.1.0 has been flagged as a candidate default-route.
But now go to R2 and check your routing table. You still won't have a
default route. Why? Because: (this is an important thing to understand
about IGRP):
IGRP won't advertise a network as a default route unless it can see that
network in its routing table.
Look at your routing table - no 192.168.x.x networks anywhere. To take care
of this, redistribute between OSPF and IGRP.
As for my comments about the use of distribute-lists, that's just a
practice I got into. They just keep things clean for me. There is probably
a good technical reason or two for doing it this way, but my brain is
already maxxed out on this OSPF/IGRP stuff - I'll leave it to the other
group members to debate the use of distribute-lists.
One more thing (I just re-read this statement):
>True IP default network is a good way to achieve reachability from IGRP
>domains to OSPF (or other classless networks), however, it is mutually
>exclusive with mutual redistribution. In other words, as the goal of
>redistribution is reachability, if one uses ip default network, it makes
>mutual redistribution moot and vice versa.
I disagree here. In my example above, you use "ip default-network" to set
the default-network/route and you use redistribution so that R2 can see the
network that's being tagged as the default. Without one or the other, I
don't think you can get the above scenario to work.
Kinton
P.S. I just set up the scenario I described above in my lab (to make sure
this all worked). Here's a copy of the routing tables from R1 and R2:
R1: (running OSPF and IGRP)
--- Gateway of last resort is not set172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks C 172.16.1.0/24 is directly connected, Ethernet0 C 172.16.2.0/24 is directly connected, Serial0 I 172.16.3.0/24 [100/8576] via 172.16.2.2, 00:01:13, Serial0 * 192.168.1.0/32 is subnetted, 1 subnets C 192.168.1.1 is directly connected, Loopback0
R2: (running IGRP only) --- Gateway of last resort is 172.16.2.1 to network 192.168.1.0
172.16.0.0/24 is subnetted, 3 subnets I 172.16.1.0 [100/8576] via 172.16.2.1, 00:00:50, Serial0 C 172.16.2.0 is directly connected, Serial0 C 172.16.3.0 is directly connected, Ethernet0 I* 192.168.1.0/24 [100/8976] via 172.16.2.1, 00:00:50, Serial0
Mark wrote: >COmments in line > >Kinton Connelly wrote: > > > > I think you almost have it in your #3a (but not b) below. As far as I know, > > the best way to do this is to: > > > > 1) Have R2 send an "ip default-network" into IGRP pointing to another > > classful address that's already in your routing table (if it's not in your > > routing table already, a static route will be automatically generated and > > this is usually a bad thing in the lab). > >I disagree. I have heard that static routes are not allowed in the lab >and although I have not yet attempted it, I disagree with that blanket >statement. Almost ALL classless routing protocols generate a static >route to null 0 when one configures summarization. The only way to >remove it is to disable summarization. > >True IP default network is a good way to achieve reachability from IGRP >domains to OSPF (or other classless networks), however, it is mutually >exclusive with mutual redistribution. In other words, as the goal of >redistribution is reachability, if one uses ip default network, it makes >mutual redistribution moot and vice versa. > >I have not yet seen an automatic generation of a static route (I am >assuming to null 0) by doing ip default network. > > > > > 2) Do your redistribution between OSPF and IGRP on R2 with the proper > > route-maps/distribute-lists. > > > > This should do it for you. R3 won't really see all your redistributed OSPF > > routes because of the classful nature of IGRP - but you'll still be able to > > reach those networks because of the injected default-network - anything the > > router doesn't find in the routing table will be send that way (to R2). > > > > If you search the CCIELAB archives for "ospf;igrp" you'll find a number of > > different suggestions for how to do this. Some of those ways are pretty > > creative (complicated) but the one I listed above is the one that's worked > > for me. > > > >I have not yet seen the need to use distribute list to prevent routing >loops (one major reason to use them) is there is only one path between >networks due to split horizon (one reason to keep split horizon on for >classfull protocols) > >The reason why IGRP will not see all the routes is not because it is a >classful protocol but because of the difference in the subnet mask >length between OSPF and IGRP. Because IGRP does not report SMs in its >pdates, it assumes the sm on the input intgerface for routes it >receives in the network that it has interfaces already configured in. >If the OSPF and IGRP nets are using the same SM lengths, it will see all >the networks (except system routes) > > Kinton > > > > -- > > Kinton Connelly > > CCIE #5867 > > kinton@oldmedia.com > > > > At 9/13/00, you wrote: > > >Just the last few days of cramming here until my lab. > > >I have a question about OSPF and Classless routing protocols such as IGRP. > > > > > >Consider the scenario below. > > > > > > ---------------------\ /---------------- > > > \ / > > > \ / > > >10.10.20.128/25 \ / 10.10.30.0/24 > > > | )( | > > > |---------R1----------R2-----------R3--------| > > > | )( | > > > OSPF AREA 0 / \ IGRP 100 > > > / \ > > > / \ > > > ---------------------/ \----------------- > > > > > >3 routers, R1, R2 and R3. R2 is performing mutual redistribution between > > >IGRP and OSPF. > > >We are using different masks, IGRP is a /24 and OSPF a /25. > > >My question is this, is there any way of getting routes from OSPF into > IGRP? > > >As I understand, > > > > > >1. We must get the mask down to /24 for IGRP to even look at it as it > won't > > >cope with VLSM. > > >2. Normally you could summarize into area 0 with the area range > command but > > >as we are in area 0 with this route we are out of luck there. > > >3. The only way I know of doing this is > > > a. Use the ip default-network and point it to a glassful net > > > other than > > >your own. (still a default route) > > > b. Create a static route on R2 for 10.10.20.0/24 and redistribute > > > that > > >static into IGRP. (A static route) > > > > > >Is there any way other than what I have mentioned above of doing this? I > > >would really appreciate any cool walk arounds for this situation. The > > >easiest thing to do would be to change the area of this route so we could > > >summarize it down to /24, however I am looking for a solution that doesn't > > >involve changing the area. I'm not sure there is a solution to this > > >situation but there's a lot of smart people on this board so who knows. > > >
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 08:24:55 GMT-3