From: ccie candidate (ccie1@xxxxxxxxx)
Date: Sat Jul 27 2002 - 08:33:39 GMT-3
make sense :)
--On Sat, 27 Jul 2002 01:11:05 Harish DV/peakxv wrote: > >I would say the dual-process is more acceptable than the sec interface or >tunnel interface. > > > >
> "ccie candidate"
> <ccie1@lycos.com> To: ccie1@lycos.com, cwag ner@logosinc.com, "kym blair" <kymblair@hotmail.com> > Sent by: cc: ccielab@groupstudy.co m > nobody@groupstudy Subject: RE: Redistributing fr om OSPF to RIP/IGRP > .com
>
>
> 07/27/2002 12:09
> AM
> Please respond to
> "ccie candidate"
>
>
> > > > >kym ; >let me get this clear . >dual-process can be or cannot be acceptable . > > > >-- > >On Sat, 27 Jul 2002 06:07:33 > kym blair wrote: >>This is exactly right. Successful candidates have said they used the >>dual-process method, so if you have an OSPF-IGRP scenario, ask the proctor > >>if you can use that method. If not, go to another (method that is, not >>proctor). >> >>Kym >> >> >>>From: "ccie candidate" <ccie1@lycos.com> >>>Reply-To: "ccie candidate" <ccie1@lycos.com> >>>To: "'ccie candidate'" <ccie1@lycos.com>, "Cade Wagner" >>><cwagner@logosinc.com> >>>CC: "'ccielab@groupstudy.com'" <ccielab@groupstudy.com> >>>Subject: RE: Redistributing from OSPF to RIP/IGRP >>>Date: Fri, 26 Jul 2002 20:41:53 -0700 >>> >>>there are 3 other methods to solve this problem , however all of them >>>should introduce something new ( like IP addressing )which are not >>>particularly on the lab >>> >>> >>>1- create loopbacks inside your ospf domain on the redistribution router >, >>>those loopbacks are all of the same mask as the IGRP , put those >loopbacks >>>in the same subnet as your OSPF subnets which of different mask . >>> >>>for example assume you have 172.3.10.0/28 somewhere on your ospf domain >>>..create loopback with 172.3.10.0/24 on the redistribution router , this >>>network will propagate to the IGRP domain , the redistribution router >will >>>have two subnets now , the more specific network will work . >>> >>>2-create secondary addresses on the IGRP domain redistribution router ( >>>this to allow the IGRP routers to accept differnt subnet masks) to the >>>downstream routers . >>> >>>3-create tunnels instead of secondary addresses to do the same like 2 >>> >>> >>> >>>the easist way to do this is also to create another ospf process on the >>>redistributionn router , summarize ospf1 to ospf2 and redistribute both >>>into IGRP >>> >>>however one of the guys on the list claim that the last method should be >>>unacceptable . >>> >>> >>>if anyone has different opinion ,can post please >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>>-- >>> >>>On Fri, 26 Jul 2002 22:38:55 >>> Cade Wagner wrote: >>> > I am curious how these other two methods work. (tunnel and >secondary >>> >addressing) Could someone explain these? I have some ideas, but they >are >>> >untested: >>> > >>> >Tunnel: >>> > >>> >1. Use addressing in the same subnet with the same mask as what needs >to >>>be >>> >distributed. >>> >2. Use addressing in an entirely different subnet so that you get the >>> >summarization effect. >>> > >>> >Secondary: >>> > >>> >1. Not sure here. >>> > >>> >Any help is greatly appreciated. >>> > >>> >Cade >>> > >>> >-----Original Message----- >>> >From: ccie candidate [mailto:ccie1@lycos.com] >>> >Sent: Thursday, July 25, 2002 3:42 PM >>> >To: Donny MATEO; Anthony Pace >>> >Cc: ccielab@groupstudy.com >>> >Subject: Re: Redistrbuting from OSPF to RIP/IGRP >>> > >>> > on previous post by one CCIE guy >>> >he said this technique is not allowed on the lab ?? >>> >however techniques like tunnel and secodary ip addresses is acceptable >. >>> >can anyone confirm this ? and why ?? >>> > >>> > >>> > >>> > >>> > >>> >-- >>> > >>> >On Thu, 25 Jul 2002 18:48:57 >>> > Anthony Pace wrote: >>> >>Donny, >>> >> >>> >>THis sounds correct. It sounds like the same principle which causes >you >>> >>to have to do "full mesh", 3 way redistribution on a router with 3 >>> >>routing protocols to be redistributed. I have noticed that in this >>> >>scenario the same thing happens. >>> >> >>> >>Anthony PAce >>> >> >>> >> >>> >>On Thu, 25 Jul 2002 11:43:04 +0800, "Donny MATEO" >>> >><donny.mateo@sg.ca-indosuez.com> said: >>> >>> >>> >>> I'm not sure but perhaps >>> >>> >>> >>> ospf 1 is distributed to ospf 2. >>> >>> then ospf 2 is distribute to igrp. >>> >>> All this is done under one router. >>> >>> >>> >>> The question is why the route of ospf 1 does not appear in the >routing >>> >>> table of igrp. >>> >>> I'm not sure but perhaps it has something to do with the fact that >the >>> >>> route that is distributed to >>> >>> other routing protocol has to appear in the routing table ( this is >>> >>> where I might be wrong... ) >>> >>> If this happens in a single router, the routing table would be that >of >>> >>> the ospf 1 process (as in >>> >>> ospf 2 it would be external). So when you redistribute to ospf 2 to >>> >>> igrp, only the "summarized" >>> >>> route appears cause that one is in the routing table and known from >>> >>> ospf 2. While the rest of the >>> >>> route osfp 2 knows are external and are know in ospf 1 as internal, >>> >>> which is prefered and listed in >>> >>> the routing table. >>> >>> I will have to test this to verify, but I'm sure someone in the list >>> >>> would have the answer by now. >>> >>> Search the archive, I believe this had been discussed before. >>> >>> >>> >>> Donny >>> >>> >>> >>> >>> >>> >>> > >>> >>> "Anthony Pace" >>> >>> <anthonypace@fast To: "ccie >>> >>> candidate" <ccie1@lycos.com>, >>> >>> ccielab@groupstudy.com, "jin" >>> >>> mail.fm> >>> >>> <jin10101010@hotmail.com> >>> >>> Sent by: cc: >>> >>> nobody@groupstudy Subject: Re: >>> >>> Redistrbuting from OSPF to RIP/IGRP >>> >>> .com >>> >>> >>> > >>> >>> >>> > >>> >>> 25-07-2002 01:18 >>> >>> Please respond to >>> >>> "Anthony Pace" >>> >>> >>> > >>> >>> >>> > >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> I had a question earlier in this thread: >>> >>> >>> >>> I have also used this 2 process method but still am curious as to >why >>> >>> both OSPF processes need to be REDISTRIBUTED into IGRP. I have found >>> >>> that this is needed; but it seems like the second process would >>>contain >>> >>> a full set of the OSPF routes and I would think it would be the only >>> >>> thing that would need to be RED into IGRP. DOes anyone know why both >>> >>> need to go into IGRP? >>> >>> >>> >>> The answer seemed to "the requirements of the lab asked for the >first >>> >>> process to be redistributed". Setting the requiremments of the lab >>> >>> aside, why won't this work (it won't work for me): >>> >>> >>> >>> OSPF1 => OSPF2 => IGRP >>> >>> >>> >>> This works: >>> >>> >>> >>> OSPF1 => OSPF2 => IGRP >>> >>> OSPF1 => IGRP >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Wed, 24 Jul 2002 03:08:55 -0700, "ccie candidate" ><ccie1@lycos.com> >>> >>> said: >>> >>> > well i didnt get all your points ..however the two ospf processes >is >>> >>> > just working as perfect solution for the summary problem . >>> >>> > the question is to redistribute the ospf running on the interfaces > >>>into >>> >>> > IGRP , so you SHOULD fulfill this requirement , the other process >is >>> >>> > your own way to solve the summarization issue ..so you end up >>> >>> > redistibuting both .. >>> >>> > >>> >>> > >>> >>> > good luck >>> >>> > -- >>> >>> > >>> >>> > On Wed, 24 Jul 2002 13:37:52 >>> >>> > jin wrote: >>> >>> > >Right, >>> >>> > >ospf and igrp should be redistributed mutually. >>> >>> > >but he told us 'redistributed' , only about 'redistributed'. >>> >>> > >If we already made static route or default route, we can use the >>> >static and default route >>> >>> origination. >>> >>> > >but if we not make that already, we can't use anything. >>> >>> > >Should Be only Redistributed. >>> >>> > > >>> >>> > >I think. >>> >>> > >Only way for that problem is Understanding how to use of Summary >>> >address command on the ospf. >>> >>> > >The important thing is that summary address command can summarize > >>>the >>> >any routes that isn't exist >>> >>> on the routing table Tagging OSPF. >>> >>> > >If you can understand this, You can redistrubute the ospf into >igrp >>> >and rip. >>> >>> > >And I already make a success on that situation. >>> >>> > > >>> >>> > >Thanks. >>> >>> > > >>> >>> > >----- Original Message ----- >>> >>> > >From: "ccie candidate" <ccie1@lycos.com> >>> >>> > >To: "kym blair" <kymblair@hotmail.com>; <ccie1@lycos.com>; >>> ><fangloma@pacific.net.hk>; >>> >>> <Darryl.Munro@computerland.co.nz>; "Anthony Pace" >>> >>> <anthonypace@fastmail.fm> >>> >>> > >Cc: <ccielab@groupstudy.com> >>> >>> > >Sent: Tuesday, July 23, 2002 5:03 AM >>> >>> > >Subject: Re: Redistrbuting from OSPF to RIP/IGRP >>> >>> > > >>> >>> > > >>> >>> > >> probably because the question is asking you to redistribute the > >>>ospf >>> >(ospf1) into IGRP on that >>> >>> router .:)))) >>> >>> > >> >>> >>> > >> good point ..HAH >>> >>> > >> >>> >>> > >> >>> >>> > >> -- >>> >>> > >> >>> >>> > >> On Mon, 22 Jul 2002 18:28:40 >>> >>> > >> Anthony Pace wrote: >>> >>> > >> >I have also used this 2 process method but still am curious as > >>>to >>> >why >>> >>> > >> >both OSPF processes need to be REDISTRIBUTED into IGRP. I have >>> >found >>> >>> > >> >that this is needed; but it seems like the second process >would >>> >contain >>> >>> > >> >a full set of the OSPF routes and I would think it would be >the >>> >only >>> >>> > >> >thing that would need to be RED into IGRP. DOes anyone know >why >>> >both >>> >>> > >> >need to go into IGRP? >>> >>> > >> > >>> >>> > >> >Anthony Pace >>> >>> > >> > >>> >>> > >> > >>> >>> > >> > >>> >>> > >> >On Sat, 20 Jul 2002 23:28:26 +0000, "kym blair" >>> ><kymblair@hotmail.com> >>> >>> > >> >said: >>> >>> > >> >> C, >>> >>> > >> >> >>> >>> > >> >> Example OSPF1 area, you have: >>> >>> > >> >> >>> >>> > >> >> 192.168.1.0/24 >>> >>> > >> >> 192.168.2.0/24 >>> >>> > >> >> 192.168.3.0/26 >>> >>> > >> >> >>> >>> > >> >> redistribute ospf1 into IGRP, but IGRP only receives .1 and >.2 >>> >>> > >> >> networks. >>> >>> > >> >> Solution: >>> >>> > >> >> >>> >>> > >> >> router ospf 2 >>> >>> > >> >> redistribute ospf 1 metric-type 1 subnets >>> >>> > >> >> summary-address 192.168.3.0 255.255.255.0 >>> >>> > >> >> >>> >>> > >> >> router igrp 100 >>> >>> > >> >> redistribute ospf 1 metric 1000 100 255 1 1500 >>> >>> > >> >> redistribute ospf 2 metric 1000 100 255 1 1500 >>> >>> > >> >> >>> >>> > >> >> Of course add appropriate filtering and passive-interfaces. >>> >>> > >> >> >>> >>> > >> >> HTH, Kym >>> >>> > >> >> >>> >>> > >> >> >>> >>> > >> >> >From: "ccie candidate" <ccie1@lycos.com> >>> >>> > >> >> >Reply-To: "ccie candidate" <ccie1@lycos.com> >>> >>> > >> >> >To: fangloma@pacific.net.hk, >Darryl.Munro@computerland.co.nz, >>> >"kym >>> >>> > >> >> >blair" <kymblair@hotmail.com> >>> >>> > >> >> >CC: ccielab@groupstudy.com >>> >>> > >> >> >Subject: Re: Redistrbuting from OSPF to RIP/IGRP >>> >>> > >> >> >Date: Sat, 20 Jul 2002 14:44:23 -0700 >>> >>> > >> >> > >>> >>> > >> >> > guys ; >>> >>> > >> >> >im still having confusing about this method . >>> >>> > >> >> > >>> >>> > >> >> >if you create an OSPF2 process , and you want to >summarize >>>the >>> >OSPF1 into >>> >>> > >> >> >it , again you are using the summary command into the wrong >>> >direction !!! >>> >>> > >> >> >,summary address is supposed to summarize external routes >>>into >>> >OSPF1 and >>> >>> > >> >> >not OSPF1 internal non-classful routes into OSPF2 ...am i >>>right >>> >or im >>> >>> > >> >> >missing something here . >>> >>> > >> >> > >>> >>> > >> >> >this subject has been killed on this mailing list hundered >of >>> >times >>> >>> > >> >> >..however i didnt find any clue for it . >>> >>> > >> >> > >>> >>> > >> >> >can any folk post the right dierctions to solve this >problem >>>..i >>> >would >>> >>> > >> >> >appreciate if anyone correct my concepts. >>> >>> > >> >> > >>> >>> > >> >> >candidate >>> >>> > >> >> > >>> >>> > >> >> > >>> >>> > >> >> > >>> >>> > >> >> > >>> >>> > >> >> >-- >>> >>> > >> >> > >>> >>> > >> >> >On Sat, 20 Jul 2002 13:44:32 >>> >>> > >> >> > kym blair wrote: >>> >>> > >> >> > >Darryl, >>> >>> > >> >> > > >>> >>> > >> >> > >There are a couple methods. The one many people like is >to >>> >create a >>> >>> > >> >> >second >>> >>> > >> >> > >OSPF process, redistribute the first ospf process into >the >>> >second, >>> >>> > >> >> >summarize >>> >>> > >> >> > >each non-classful network under the second ospf process, >>>then >>> >>> > >> >> >redistribute >>> >>> > >> >> > >both ospf processes into RIP/IGRP. >>> >>> > >> >> > > >>> >>> > >> >> > >HTH, Kym >>> >>> > >> >> > > >>> >>> > >> >> > > >>> >>> > >> >> > > >>> >>> > >> >> > > >>> >>> > >> >> > >>From: Fanglo MA <fangloma@pacific.net.hk> >>> >>> > >> >> > >>Reply-To: Fanglo MA <fangloma@pacific.net.hk> >>> >>> > >> >> > >>To: Darryl Munro <Darryl.Munro@computerland.co.nz> >>> >>> > >> >> > >>CC: Group Study <ccielab@groupstudy.com> >>> >>> > >> >> > >>Subject: Re: Redistrbuting from OSPF to RIP/IGRP >>> >>> > >> >> > >>Date: Sat, 20 Jul 2002 15:59:03 +0800 (HKT) >>> >>> > >> >> > >> >>> >>> > >> >> > >>Would you consider using route-map to direct summary >>>address >>> >point to >>> >>> > >> >> > >>null0 to replace the static route functionality? >>> >>> > >> >> > >> >>> >>> > >> >> > >>Regards, >>> >>> > >> >> > >>Fanglo >>> >>> > >> >> > >> >>> >>> > >> >> > >>On Sat, 20 Jul 2002, Darryl Munro wrote: >>> >>> > >> >> > >> >>> >>> > >> >> > >> > How is it possible to redistribute from OSPF to >>>IGRP/RIP >>> >without >>> >>> > >> >> >using >>> >>> > >> >> > >> > statics to Null0? I know that the mask needs to be >the >>> >same as the >>> >>> > >> >> > >>IGRP/RIP >>> >>> > >> >> > >> > domain, however is it achievable to do this with area >>> >range commands >>> >>> > >> >> >and >>> >>> > >> >> > >> > summary-address's positioned at the right the places >in >>> >your OSPF >>> >>> > >> >> > >>domain? >>> >>> > >> >> > >> > Area range should take care of all of the OSPF inter >>>area >>> >routes and >>> >>> > >> >> > >>summary >>> >>> > >> >> > >> > address the external addresses from other routing >>> >protocols. I just >>> >>> > >> >> > >>can't >>> >>> > >> >> > >> > seem to work this one out in my lab. Any suggestions >>>would >>> >be >>> >>> > >> >> > >>appreciated. >>> >>> > >> >> > >> > >>> >>> > >> >> > >> > >>> >>> > >> >> > >> > >>> >>> > >> >> > >> > TIA >>> >>> > >> >> > >> > >>> >>> > >> >> > >> > >>> >>> > >> >> > >> > >>> >>> > >> >> > >> > Darryl Munro >>> >>> > >> >> > >> > >>> >>> > >> >> > >> > CNE, MCSE, CCNP, CCDP, CCEA >>> >>> > >> >> > >> > >>> >>> > >> >> > >> > Systems Consultant >>> >>> > >> >> > >> > >>> >>> > >> >> > >> > Computerland NZ >>> >>> > >> >> > >> > >>> >>> > >> >> > >> > 104-106 Customs St West >>> >>> > >> >> > >> > >>> >>> > >> >> > >> > PO Box 3631, Auckland >>> >>> > >> >> > >> > >>> >>> > >> >> > >> > Phone: 09 306 8700 >>> >>> > >> >> > >> > >>> >>> > >> >> > >> > Cell Phone 027 2897786 >>> >>> > >> >> > >> > >>> >>> > >> >> > >> > Darryl <mailto:darryl.munro@computerland.co.nz> >Munro >>> >>> > >> >> > >> > >>> >>> > >> >> > >> > >>> >>> > >> >> > >> > >>> >>> > >> >> > >> > CAUTION: This e-mail message and accompanying data >may >>> >contain >>> >>> > >> >> > >>information >>> >>> > >> >> > >> > that is confidential and subject to privilege. If >you >>>are >>> >not the >>> >>> > >> >> > >>intended >>> >>> > >> >> > >> > recipient, you are notified that any use, >>>dissemination, >>> >distribution >>> >>> > >> >> >or >>> >>> > >> >> > >> > copying of this message or data is prohibited. If >you >>> >have received >>> >>> > >> >> > >>this >>> >>> > >> >> > >> > e-mail in error, please notify me immediately and >>>delete >>> >all material >>> >>> > >> >> > >> > pertaining to this e-mail. Ceritas / Computerland >will >>>not >>> >accept >>> >>> > >> >> > >>liability >>> >>> > >> >> > >> > for any loss or damage caused by using any material >or >>> >attachments >>> >>> > >> >> > >>contained >>> >>> > >> >> > >> > in this message. While every best practice has been >>>taken >>> >to, no >>> >>> > >> >> > >>warranty is >>> >>> > >> >> > >> > made that this material is free from computer virus >or >>> >other defect. >>> >>> > >> >> > >> > Ceritas/Computerland's entire liability will be >limited >>>to >>> >>> > >> >> >resupplying >>> >>> > >> >> > >>the >>> >>> > >> >> > >> > material. Thank you >>> >>> > >> >> > >> >
This archive was generated by hypermail 2.1.4 : Sat Sep 07 2002 - 19:36:46 GMT-3