From: Chua, Parry (Parry.Chua@xxxxxxxxxx)
Date: Mon Dec 17 2001 - 22:07:18 GMT-3
Since it is the same major network 141.1.0.0, I don't think without
breaking the subnet /22 into /24 is going to work for IGRP. One of the
solution given before is to assign secondary address /24 to the same
interface /22, since IGRP is running in this router, no redistribution
is necessary.
The other solution is to generate a default into the IGRP which may not
what you intend to do.
Regrads
Parry
-----Original Message-----
From: Lupi, Guy [mailto:Guy.Lupi@eurekaggn.com]
Sent: Friday, December 14, 2001 12:10 PM
To: 'EA Louie '; 'ccielab@groupstudy.com '
Subject: RE: OSPF to IGRP redistribution
This appears to be a solution designed for when the OSPF subnet is
smaller,
such as getting a /28 from OSPF to a /24 in IGRP, and they are not part
of
the same classful network. This works no problem for me using either
the
summary-address or area range command, thanks for the link.
I am trying to put a route of 147.1.77.0/24, which is a subset of the
147.1.76.0/22 that is actually on the interface. It might help if I
give a
more detailed explanation.
I have a frame cloud, each interface on the frame cloud is
147.1.77.x/22,
these are in OSPF. I have an IGRP router connected to one of the OSPF
routers, it's interface IP is 147.1.5.1/24. So, the OSPF router will
not
send 147.1.76.0/22 down to the IGRP neighbor because the subnet mask is
larger than that on the IGRP interface and they are part of the same
major
network. I tried making the ospf router an ABR and using area range,
still
doesn't work, I have tried it using 147.1.77.0/24, and 147.1.64.0/19,
neither of them get advertised to the IGRP router. Anyone know of a way
to
get these routes in if they are part of the same major network? This
would
break one of the rules of IGRP, so I am wondering if it can be done,
this is
from a fatkid.com lab that gives the solution as the summary-address
command, which doesn't work in recent IOS. Thanks.
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:32:44 GMT-3