Re: The old problem of getting /32 loopbacks with class b address es into IGRP as /24 and then advertised out of IGRP elsewhere

From: Nick Shah (nshah@xxxxxxxxxxxxxx)
Date: Tue Jun 11 2002 - 23:44:45 GMT-3


   
yes, either disabling auto redistribution between same process id's or
assigning different process id's would work.

rgds
Nick
----- Original Message -----
From: <WRHale@NECBNS.com>
To: <nshah@connect.com.au>; <tlarus@cox.net>; <ccielab@groupstudy.com>
Sent: Wednesday, June 12, 2002 11:16 AM
Subject: RE: The old problem of getting /32 loopbacks with class b address
es into IGRP as /24 and then advertised out of IGRP elsewhere

> 2) You don't have to disable eigrp/igrp redistribution manually. Just
give
> the igrp process a different number. I tried your suggestion and it
works.
>
>
> interface Loopback9
> ip address 170.10.98.1 255.255.255.0
> !
> interface Ethernet0
> ip address 170.10.1.1 255.255.255.192
> ip summary-address eigrp 1 170.10.1.0 255.255.255.0 5
> !
> router eigrp 1
> passive-interface BRI0
> passive-interface Serial0.1
> network 170.10.0.0
> no auto-summary
> no eigrp log-neighbor-changes
> !
> router igrp 2
> redistribute eigrp 1 metric 1544 20000 255 1 1500
> passive-interface BRI0
> passive-interface Ethernet0
> passive-interface Loopback0
> passive-interface Serial0.1
> network 170.10.0.0
>
> Gateway of last resort is not set
>
> 170.10.0.0/16 is variably subnetted, 9 subnets, 3 masks
> C 170.10.0.0/24 is directly connected, Loopback0
> D 170.10.1.0/24 is a summary, 00:06:47, Null0
> C 170.10.1.0/26 is directly connected, Ethernet0
> C 170.10.9.0/24 is directly connected, BRI0
> O IA 170.10.16.0/26 [110/74] via 170.10.8.1, 00:38:33, Serial0.1
> O 170.10.8.16/28 [110/128] via 170.10.8.1, 00:38:33, Serial0.1
> C 170.10.98.0/24 is directly connected, Loopback9
>
>
> 01:05:34: IGRP: sending update to 255.255.255.255 via Loopback9
> (170.10.98.1)
> 01:05:34: subnet 170.10.0.0, metric=501
> 01:05:34: subnet 170.10.1.0, metric=1100
> 01:05:34: subnet 170.10.9.0, metric=158250
> 01:05:34: IGRP: Update contains 3 interior, 0 system, and 0 exterior
routes.
> 01:05:34: IGRP: Total routes in update: 3
>
> -----Original Message-----
> From: Nick Shah [mailto:nshah@connect.com.au]
> Sent: Tuesday, June 11, 2002 5:16 PM
> To: Thomas Larus; ccielab@groupstudy.com
> Subject: Re: The old problem of getting /32 loopbacks with class b
> addresses into IGRP as /24 and then advertised out of IGRP elsewhere
>
>
> 1) Static redistribution seems to be the only way (unless there are other
> routing prots. where you could summarize it and inject it back, but if its
> connected route, I doubt it can be done)
>
> 2) Disable eigrp/igrp redistribution, create summary of eigrp routes,
> manually inject those summaries..
>
> Since you havent presented an actual scenario, this is best I could come
up
> with.
>
> rgds
> Nick
> ----- Original Message -----
> From: Thomas Larus <tlarus@cox.net>
> To: <ccielab@groupstudy.com>
> Sent: Wednesday, June 12, 2002 8:17 AM
> Subject: The old problem of getting /32 loopbacks with class b addresses
> into IGRP as /24 and then advertised out of IGRP elsewhere
>
>
> > 1 )Does anyone have a quick and dirty approach to getting those pesky
> class
> > b IGRP /32 loopbacks into IGRP as /24 routes.
> >
> > I have searched my personal archives of groupstudy; I cannot get
searches
> of
> > the groupstudy archives to work very often. I just tried. What I found
> in
> > my personal archives more than once is an article from Cisco that
> discusses
> > the problem. I did not see a solution in it, though.
> >
> > If you are thinking of posting this Cisco article
> > http://www.cisco.com/warp/public/105/54.html,
> > please don't. I just looked at this again, and followed a link or two
to
> > other Cisco items.
> >
> > 2 ) Also, is there any way to summarize an EIGRP route into IGRP (same
AS
> > number) ON THE SAME ROUTER. Since EIGRP does summarization out an
> > interface, I can't see how one could summarize from EIGRP to IGRP on the
> > same router.



This archive was generated by hypermail 2.1.4 : Tue Jul 02 2002 - 08:12:31 GMT-3