From: Howard C. Berkowitz (hcb@xxxxxxxxxxxx)
Date: Mon Apr 08 2002 - 01:11:12 GMT-3
>Your solutions won't work as one uses policing and the other EGP. Your one
>option is to summarize routes, it works.
>
>Hope this helps..
>Ali
Policy, not policing -- with the set default interface
BGP, not EGP -- with conditional advertisement used with default
information originate.
Summarization helps on the OSPF to RIP side, but not the RIP to OSPF,
where RIP really needs to tell OSPF about the /32.
Seriously, I can make it work. I'm just not sure it can be made to
work in a way that is realistic lab practice.
>
>
>
>----- Original Message -----
>From: <talbotpat@cox.net>
>To: "Howard C. Berkowitz" <hcb@gettcomm.com>; <ccielab@groupstudy.com>
>Sent: Sunday, April 07, 2002 7:40 PM
>Subject: Re: Statics, defaults, and the lab
>
>
>> > From: "Howard C. Berkowitz" <hcb@gettcomm.com>
>> > Date: 2002/04/07 Sun PM 08:23:39 EDT
>> > To: ccielab@groupstudy.com
>> > Subject: Statics, defaults, and the lab
>> >
>> > I've been working on a practice scenario, involving, among many other
>> > things, RIP-OSPF mutual redistribution. My challenge is that I wanted
>> > to do something that is real-world good practice: standardizing on
>> > loop0 interface addresses that are /32, postulating the customer
>> > would eventually transition completely to OSPF.
>> >
>> > The challenge is how to ping discontiguous /32's in a RIP network. In
>> > principle, it's not something RIPv1 can do. If this were the real
>> > world, I could solve this trivially with a couple of static and
>> > default routes. I can make it work under some fairly bizarre
>> > constraints, like using extended ping to force a source address to
>> > which has a return path.
>> >
>> > To do what I want to do with routing, however, the alternatives are
>> > so bizarre that I wonder if it's beyond what conceivably could be on
>> > the test. Now, this is NOT a request for NDA information, but it's
>> > my impression from Solie and various CCIE power sessions that the lab
>> > scenarios NEVER use static or default routes. Am I correct here, or
>> > is "NEVER" really "HARDLY EVER"?
>>
>> Don't know for sure as I will visit the lab for the first time May 18, but
>I'm pretty sure that your impression is correct. All practice labs and prep
>materials that I have seen and everything I have heard and/or read would
>seem to back that up. But I guess anything is possible in the real thing.
>>
>> >
>> > Let's see...some of the ways I've hacked it:
>> >
>> > 1. Implement policy routing and set default interface.
>> > 2. Use BGP as an intermediate protocol between RIP and OSPF so I
>> > can use conditional default advertisement
>> >
>>
>> An intermediate routing process has been discussed to solve other
>redistribution issues as well, I think (and hope) this is an acceptable
>approach on the lab exam.
>>
>> > OSPF default-information originate doesn't fit the bill, because I
>> > have two redistribution points. If I had one redistribution point, I
>> > could, in good conscience, do default-information originate always,
>> > because the traffic would blackhole. But with two points of
>> > redistribution, I want default originated only if the point of
>> > redistribution indeed can act as a default router.
>> >
>> > BGP conditional advertisement would do what I want. If I could put a
>> > default route into the OSPF router, and control default origination
>> > by the reachability of the next hop of the default route, I could
>> > also make it work. The OSPF router really wouldn't use the default
>> > route other than as a control mechanism for default information
>> > originate.
>> >
>> > Am I simply creating a situation that is outside the reasonable scope
>> > of the lab?
>>
>> God I hope so.... ;-)
>>
>> >
>> > This scenario and others, incidentally, will be available for free
>> > noncommercial use from Gettlabs, but we need to work out some server
>> > issues that I hope will be done in the next couple of days. It's too
>> > long to post here.
>> > --
>> > "What Problem are you trying to solve?"
>> > ***send Cisco questions to the list, so all can benefit -- not
> > > directly to me***
>> >
>****************************************************************************
>****
>> > Howard C. Berkowitz hcb@gettcomm.com
>> > Chief Technology Officer, GettLab/Gett Communications
>http://www.gettlabs.com
>> > Technical Director, CertificationZone.com
>http://www.certificationzone.com
>> > "retired" Certified Cisco Systems Instructor (CID) #93005
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:57:59 GMT-3