- A virtual community of network engineers
 Home  BookStore  StudyNotes  Links  Archives  StudyRooms  HelpWanted  Discounts  Login
Re: Statics, defaults, and the lab posted 04/08/2002
[Chronological Index] [Thread Index] [Top] [Date Prev][Date Next] [Thread Prev][Thread Next]

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..

----- Original Message -----
From: <talbotpat@xxxxxxx>
To: "Howard C. Berkowitz" <hcb@xxxxxxxxxxxx>; <ccielab@xxxxxxxxxxxxxx>
Sent: Sunday, April 07, 2002 7:40 PM
Subject: Re: Statics, defaults, and the lab

> > From: "Howard C. Berkowitz" <hcb@xxxxxxxxxxxx>
> > Date: 2002/04/07 Sun PM 08:23:39 EDT
> > To: ccielab@xxxxxxxxxxxxxx
> > 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@xxxxxxxxxxxx
> > Chief Technology Officer, GettLab/Gett Communications
> > Technical Director,
> > "retired" Certified Cisco Systems Instructor (CID) #93005
> > _________________________________________________________________
> > Commercial lab list:
> > Please discuss commercial lab solutions on this list.
> _________________________________________________________________
> Commercial lab list:
> Please discuss commercial lab solutions on this list.
Commercial lab list:
Please discuss commercial lab solutions on this list.
To unsubscribe from the CCIELAB list, send a message to
majordomo@xxxxxxxxxxxxxx with the body containing:
unsubscribe ccielab