RE: RE: OSPF to IGRP redistribution (I know this has been killed, th i s is short I promise)

From: Narvaez, Pablo (Pablo.Narvaez@xxxxxxxxxxxxx)
Date: Fri Apr 05 2002 - 12:30:51 GMT-3


   
Sure thing Mas Kato, I agree with you and sorry for the lack of explanation I g
ave .... I meant that you cannot redistribute from OSPF into another protocolo
 if you do not have such routes in the routing table, depsite you have them in
the database. Of course ALL the routers in the same OSPF domain must be sync an
d have same database in order for the SPF alg to work properly ...

:-)

cheers,

hockito

-----Original Message-----
From: Mas Kato [mailto:loomis_towcar@speedracer.com]
Sent: Viernes, 05 de Abril de 2002 03:39 a.m.
To: Narvaez, Pablo
Cc: ccielab@groupstudy.com
Subject: RE: RE: OSPF to IGRP redistribution (I know this has been
killed, th i s is short I promise)

Mmmm...you might want to reconsider part of what you said: "...what
you really send between 2 OSPF routers is what you got in the local routing tab
le, not the database..."

In order for OSPF to converge quickly, all the OSPF-speaking routers in the sam
e domain need to do the same SPF calculation against identical databases. That'
s the only way they can all end up with the same "view" of the network.

But it's all about route control, right? And if somebody's telling you to do it
... Prior to like 11.1 or so, there was no way to filter LSAs, per se (you coul
d only reduce their number) so you had to install a 'distribute-list in' in eve
ry OSPF router that you didn't want the routes installed into. It was a hassle,
 but relatively safe, since its effects were only local.

Filtering LSAs from the source seems easier, but modifying the database synchro
nization across the domain is not without peril and could conceivably cause rou
ting loops and/or instability if not done correctly. And if you're not careful,
 what might seem to be working for "the moment" could, hypothetically of course
, break later on during the course of an unreal, challenging day where things a
re being piled on and on... ;)

Regards,

Mas Kato
https://ecardfile.com/id/mkato

> RE: RE: OSPF to IGRP redistribution (I know this has been killed, th i s i
s short I promise)Date: Thu, 4 Apr 2002 20:41:10 -0600
> "Narvaez, Pablo" <Pablo.Narvaez@getronics.com>Cc: "'Mas Kato' " <loomis_towca
r@speedracer.com>, <ccielab@groupstudy.com>
>
>I've tried that and from my experience, a distribute list will remove the null
0 route from the routing table and also
>will avoid this route to be propagated. It makes sense, doesn't it? .... what
you really send between 2 OSPF routers is what you got in the local routing tab
le, not the database. For example, if you have problems with your local OSPF da
tabase due to an external forwarding address known thru an external route, netw
ork-type mismatch or whatever, you'll see those routes in the database but not
in the routing table; in turn, you will not be able to propagate those routes t
o your neighbor.
>
>Am I right? ....
>
>hockito
>
>
>-----Original Message-----
>From: Jason [mailto:jgraun@attbi.com]
>Sent: Jueves, 04 de Abril de 2002 08:16 p.m.
>To: 'Ahmed Mamoor Amimi'; neiby@ureach.com; Guy.Lupi@eurekaggn.com;
>'Warren J Dubose '
>Cc: ''Mas Kato' '; ccielab@groupstudy.com
>Subject: RE: RE: OSPF to IGRP redistribution (I know this has been
>killed, th i s is short I promise)
>
>
>If you use a distribute list you can remove the route from the route
>table but still have the summary LSA propagated to the rest of the
>routers.
>
>-----Original Message-----
>From: Ahmed Mamoor Amimi [mailto:mamoor@ieee.org]
>Sent: Thursday, April 04, 2002 10:01 AM
>To: Jason; neiby@ureach.com; Guy.Lupi@eurekaggn.com; 'Warren J Dubose '
>Cc: ''Mas Kato' '; ccielab@groupstudy.com
>Subject: Re: RE: OSPF to IGRP redistribution (I know this has been
>killed, th i s is short I promise)
>
>I want to be a CCIE ..... can u please explain how to remove the route
>that
>is
>created through route-to-null-zero by OSPF with anyother method expect
>removing the summary or range command....
>
>-Mamoor
>
>
>
>----- Original Message -----
>From: Jason <jgraun@attbi.com>
>To: <neiby@ureach.com>; <Guy.Lupi@eurekaggn.com>; 'Warren J Dubose '
><wdubose@cisco.com>
>Cc: ''Mas Kato' ' <loomis_towcar@speedracer.com>;
><ccielab@groupstudy.com>
>Sent: Thursday, April 04, 2002 8:58 AM
>Subject: RE: RE: OSPF to IGRP redistribution (I know this has been
>killed,
>th i s is short I promise)
>
>
>> Well if you want to be a CCIE you will have to learn how to remove it.
>> :)
>>
>>
>> Jason
>>
>> -----Original Message-----
>> From: John Neiberger [mailto:neiby@ureach.com]
>> Sent: Wednesday, April 03, 2002 9:46 PM
>> To: Jason; <Guy.Lupi@eurekaggn.com>; 'Warren J Dubose '
>> Cc: ''Mas Kato' '; ccielab@groupstudy.com
>> Subject: RE: RE: OSPF to IGRP redistribution (I know this has been
>> killed, th i s is short I promise)
>>
>> The mask between R2 and R4 is a /27.
>>
>> Why would I want to remove the null0 route after I went through
>> all that work to get it in there! :-) That's what's allowing
>> me to summarize into IGRP. Since R2 is aware of all the more-
>> specific routes this isn't a problem.
>>
>> John
>>
>>
>>
>> ---- On Wed, 3 Apr 2002, Jason (jgraun@attbi.com) wrote:
>>
>> > I have had problems with that in the past, I would be very
>> careful when
>> > using that cause to it may not work in every case. What is
>> the mask
>> > between R2 and R4? Also how do you remove the null 0 route
>> from the
>> > routing table?
>> >
>> >
>> > Have fun with that
>> >
>> > Jason
>> >
>> > -----Original Message-----
>> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
>> Behalf Of
>> > John Neiberger
>> > Sent: Wednesday, April 03, 2002 8:41 PM
>> > To: Lupi, Guy; 'Warren J Dubose '
>> > Cc: ''Mas Kato' '; 'ccielab@groupstudy.com '
>> > Subject: Re: RE: OSPF to IGRP redistribution (I know this has
>> been
>> > killed, th i s is short I promise)
>> >
>> > At this point I'm not sure who is saying what! But I'd like
>> to
>> > chime in. I just did a test with three routers:
>> >
>> > [R3]-----(IGRP)-----[R2]-----(OSPF)------[R4]
>> >
>> > The R2-R4 link is in area 0. R4 has a mixture of prefixes
>> from
>> > 10/8 that are various lengths, all longer than /24. R3 to R2
>> > is a /24, also in the 10/8 range.
>> >
>> > As a test prefix I also added a /24 on R4. On R2 I turned on
>> > OSPF to IGRP redistribution and, as expected, saw only
>> > the /24. I then added a loopback on R2, also in 10/8, and
>> > placed it into area 1. Then, for each prefix I added
>> an 'area
>> > 0 range a.b.c.d 255.255.255.0'.
>> >
>> > And now, on R3 I see:
>> >
>> > R3#sho ip route
>> >
>> > Gateway of last resort is not set
>> >
>> > 10.0.0.0/24 is subnetted, 6 subnets
>> > I 10.3.1.0 [100/8976] via 10.2.1.1, 00:00:04, Serial0
>> > C 10.2.1.0 is directly connected, Serial0
>> > I 10.1.1.0 [100/9666] via 10.2.1.1, 00:00:04, Serial0
>> > I 10.1.30.0 [100/9666] via 10.2.1.1, 00:00:04, Serial0
>> > I 10.1.20.0 [100/9666] via 10.2.1.1, 00:00:04, Serial0
>> > I 10.1.40.0 [100/9666] via 10.2.1.1, 00:00:04, Serial0
>> > R3#
>> >
>> > All of the above except for two were originally not /24
>> > prefixes. So, at least in some cases, an area 0 range
>> command
>> > works just fine. If you redistribute OSPF into IGRP, IGRP
>> will
>> > pick up the summarized routes pointing at Null0.
>> >
>> > John
>> >
>> >
>> >
>> >
>> > ---- On Wed, 3 Apr 2002, Lupi, Guy (Guy.Lupi@eurekaggn.com)
>> > wrote:
>> >
>> > > I have a loopback on it that I put in area 1, is that no
>> > good? Anyway,
>> > > here
>> > > is the config and routing table for r1, the summary route
>> to
>> > null 0 is
>> > > there, is that not allowed on the lab? It isn't a static
>> > route, thanks
>> > > for
>> > > your time.
>> > >
>> > > r1#sh ip route
>> > > 141.63.0.0/16 is variably subnetted, 7 subnets, 4 masks
>> > > O 141.63.1.0/24 is a summary, 04:54:06, Null0
>> > > C 141.63.1.0/26 is directly connected, Loopback0
>> > > C 141.63.7.0/24 is directly connected, Serial0
>> > > C 141.63.7.0/25 is directly connected, Serial0
>> > > O IA 141.63.5.0/27 [110/65] via 141.63.7.5, 02:53:23,
>> > Serial0
>> > > C 141.63.10.0/25 is directly connected, Loopback99
>> > > C 141.63.12.0/24 is directly connected, Ethernet0
>> > > r1#
>> > >
>> > > r1#sh run
>> > > Building configuration...
>> > >
>> > > Current configuration : 1532 bytes
>> > > !
>> > > version 12.1
>> > > no service single-slot-reload-enable
>> > > service timestamps debug uptime
>> > > service timestamps log uptime
>> > > no service password-encryption
>> > > !
>> > > hostname r1
>> > > !
>> > > logging rate-limit console 10 except errors
>> > > no logging console
>> > > !
>> > > ip subnet-zero
>> > > no ip finger
>> > > no ip domain-lookup
>> > > !
>> > > cns event-service server
>> > > !
>> > > !
>> > > !
>> > > !
>> > > !
>> > > interface Loopback0
>> > > ip address 141.63.1.1 255.255.255.192
>> > > ip ospf network point-to-point
>> > > !
>> > > interface Loopback99
>> > > ip address 141.63.10.1 255.255.255.128
>> > > ip ospf network point-to-point
>> > > !
>> > > interface Ethernet0
>> > > ip address 141.63.12.1 255.255.255.0
>> > > !
>> > > interface Ethernet1
>> > > no ip address
>> > > shutdown
>> > > !
>> > > interface Serial0
>> > > ip address 141.63.7.11 255.255.255.0 secondary
>> > > ip address 141.63.7.1 255.255.255.128
>> > > encapsulation frame-relay
>> > > ip ospf network broadcast
>> > > no fair-queue
>> > > no arp frame-relay
>> > > frame-relay map ip 141.63.7.5 115 broadcast
>> > > no frame-relay inverse-arp
>> > > !
>> > > interface Serial1
>> > > no ip address
>> > > shutdown
>> > > !
>> > > router ospf 100
>> > > log-adjacency-changes
>> > > area 0 range 141.63.5.0 255.255.255.0
>> > > summary-address 141.63.1.0 255.255.255.0
>> > > redistribute connected subnets
>> > > network 141.63.7.0 0.0.0.127 area 0
>> > > network 141.63.10.0 0.0.0.127 area 1
>> > > !
>> > > router igrp 100
>> > > redistribute ospf 100
>> > > passive-interface default
>> > > no passive-interface Ethernet0
>> > > network 141.63.0.0
>> > > default-metric 1500 128 128 128 128
>> > > !
>> > > ip kerberos source-interface any
>> > > ip classless
>> > > no ip http server
>> > > !
>> > > !
>> > > !
>> > > line con 0
>> > > transport input none
>> > > line aux 0
>> > > line vty 0 4
>> > > login
>> > > !
>> > > end
>> > >
>> > > r1#
>> > >
>> > > -----Original Message-----
>> > > From: Warren J Dubose
>> > > To: Lupi, Guy
>> > > Cc: 'Mas Kato'; ccielab@groupstudy.com
>> > > Sent: 4/3/2002 5:13 PM
>> > > Subject: RE: OSPF to IGRP redistribution (I know this has
>> > been killed,
>> > > thi
>> > > s is short I promise)
>> > >
>> > > Guy,
>> > >
>> > > MAS is correct.
>> > >
>> > > How can r1 belong to 2 areas when it is connected to r1
>> > talking IGRP?
>> > >
>> > > There are two types of summarization in ospf:
>> > >
>> > > Intra-area route summarization
>> > > ---- summarization can occur at two points in an OSPF
>> network
>> > at
>> > > "AREA BORDERS", where ABRs can be configured to announce a
>> > single
>> > > Summary
>> > > LSA for the range of networks residing within a "specific
>> > area"
>> > >
>> > > Inter-routing Domain Route Summarization
>> > > --- on ASBRs at "route redistribution points" where ospf
>> > routes are
>> > > being
>> > > exported to another routing protocol, or non-ospf routes
>> are
>> > being
>> > > imported into opsf.
>> > >
>> > > Check out Doyle's or Caslow's book pertaining to
>> > summarization of OSPF.
>> > > This should help ;)
>> > >
>> > > Regards,
>> > > Warren
>> > >
>> > >
>> > >
>> > > On Wed, 3 Apr 2002, Lupi, Guy wrote:
>> > >
>> > > > Right, that is what I did, R1 is a member of 2 areas,
>> area
>> > 1 and area
>> > > 0.
>> > > > Here is a partial output of "show ip ospf". This is why
>> I
>> > don't
>> > > understand
>> > > > why it isn't working. I thought that as long as the
>> router
>> > was an
>> > > ABR, you
>> > > > could use area range to summarize and inject into IGRP.
>> > > >
>> > > > r1#sh ip os
>> > > > Routing Process "ospf 100" with ID 141.63.10.1 and
>> Domain
>> > ID
>> > > 0.0.0.100
>> > > > Supports only single TOS(TOS0) routes
>> > > > Supports opaque LSA
>> > > > It is an area border and autonomous system boundary
>> router
>> > > >
>> > > > -----Original Message-----
>> > > > From: Mas Kato [mailto:loomis_towcar@speedracer.com]
>> > > > Sent: Wednesday, April 03, 2002 4:30 PM
>> > > > To: Lupi, Guy
>> > > > Cc: ccielab@groupstudy.com
>> > > > Subject: RE: OSPF to IGRP redistribution (I know this has
>> > been killed,
>> > > > this is short I promise)
>> > > >
>> > > >
>> > > > Guy,
>> > > >
>> > > > Although router1 is certainly an ASBR, it really doesn't
>> > become an ABR
>> > > until
>> > > > it becomes a member of two or more OSPF areas. If you
>> hung
>> > another
>> > > > OSPF-speaking router off of router1 and placed it in an
>> > area different
>> > > from
>> > > > router5, you would then see the results of your 'area
>> > range' command
>> > > on that
>> > > > new router, because that new router would know how to
>> read
>> > the type 3
>> > > > summary LSAs being originated by router1.
>> > > >
>> > > > Regards,
>> > > >
>> > > > Mas Kato
>> > > > https://ecardfile.com/id/mkato
>> > > >
>> > > > > "Lupi, Guy"
>> > <Guy.Lupi@eurekaggn.com> "'ccielab@groupstudy.com'"
>> > > > <ccielab@groupstudy.com>Date: Wed, 3 Apr 2002 14:44:12 -
>> 0500
>> > > > >Reply-To: "Lupi, Guy" <Guy.Lupi@eurekaggn.com>
>> > > > >
>> > > > >I know this has been covered in detail before, I just
>> want
>> > to verify
>> > > > >something. I have the following:
>> > > > >
>> > > > >router2---------router1--------router5
>> > > > >
>> > > > >Router 5 and router 1 are OSPF, router 2 and router 1 is
>> > igrp only.
>> > > I know
>> > > > >how to use the secondary address, tunnel, and route-map
>> > methods. I
>> > > know
>> > > > how
>> > > > >to use summary address on router 1 to get connected
>> routes
>> > that are
>> > > not in
>> > > > >OSPF onto router 2. I cannot get routes from router 5
>> to
>> > router 2
>> > > using
>> > > > >area range on router 1. Router 1 is an ASBR, and an
>> ABR.
>> > I cannot
>> > > use the
>> > > > >area range command to get the route from r5 to r2, and
>> > summary
>> > > address
>> > > > would
>> > > > >never work, but tunnels, route-maps, and secondary
>> > addresses work. I
>> > > > >thought that if the router was an ABR, you could
>> do "area-
>> > range [area
>> > > route
>> > > > >is from] x.x.x.x x.x.x.x". Thanks.
>> > > >
>> >



This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:57:56 GMT-3