From: Howard C. Berkowitz (hcb@xxxxxxxxxxxx)
Date: Tue May 07 2002 - 02:04:07 GMT-3
At 8:20 PM -0500 5/6/02, Frank Jimenez wrote:
>Howard, does this feature, intoduced in 12.2(4)T, match what you're
>discussing below?
>
>BGP Conditional Route Injection
>http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft
>/122t/122t4/ftbgpri.htm
>
>Thanks,
>Frank Jimenez, CCIE #5738
>franjime@cisco.com
Yes, for BGP. It would be quite interesting if the redistributing
routers ran BGP as well as their IGPs, and used BGP for the
domain-to-domain redistribution.
Some equivalent functionality for IGPs would be very nice. I realize
I have mixed thoughts about that, however, because the redistribution
scenarios on the lab are rarely the ones you'd see in real-world
practice.
Consider, for example, a general example of an option that might not
be acceptable on the exam:
have Bumble and Grimwig conditionally originate default SEPARATELY
into the OSPF and RIP domains ONLY. You wouldn't need to worry about
AD because default will be less specific than any other route. The
condition that triggers initiation would be the loss of connectivity
on the OTHER redistributing router's interdomain link. I'd make the
routes redistributed into OSPF external type 1.
So if 192.168.3 failed, Grimwig would notice and start advertising
RIP default, which is the only thing Bumble and Monks would see.
Grimwig would also start to advertise external type 2 default into
OSPF, which Blathers and Dunn would see. Since each router has
complete information for its own domain, it will have more specific
routes than the default, which will prevent loops.
Remember these defaults are SEPARATE, so if Bumble tried to send to
192.168.3.0 knowing its direct connection would die, it would send
Monks->Grimwig. Since Grimwig only advertises default but doesn't
have a default of its own, Bumble would get a destination unreachable
from Grimwig. Same thing would happen if Blathers defaulted through
Duff->Grimwig.
Key things to remember: You are not redistributing default, and the
redistributing router has no default of its own.
In the real world, however, I wouldn't redistribute in both
directions. I'd redistribute RIP into OSPF, and have the gateway
routers send default back into RIP. The RIP side would never see the
OSPF routes. True, this might lead to "suboptimal" routing as the RIP
routers would do hot potato/closest exit, but it greatly simplifies
the configuration. Most Internet multihoming winds up working this
way.
If there were multiple failures, however, routing loops would result.
During recovery, there might be transient routing loops.
>
>-----Original Message-----
>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
>Howard C. Berkowitz
>Sent: Monday, May 06, 2002 6:03 PM
>To: ccielab@groupstudy.com
>Subject: RE: Redist: Filtering vs Fail-over
>
>
>I'm going to back up a bit and explore the problem that is to be
>solved, which I recognize may or may not have anything to do with the
>lab solution.
>
>First, let's look for a moment at "optimal routing." Unless both
>links have enough capacity to handle the entire workload, either of
>them going down is going to result in suboptimal performance,
>assuming the IGPs use a closest exit routing policy.
>
>Second, much of large scale routing aims less at always finding the
>optimal route than minimizing routing protocol churn. So, I'll ask
>again, what is being optimized? In a real-world situation, an
>oscillating route situation can crash routers and/or produce huge
>amounts of protocol traffic.
>
>There are several different ways I could conceive of this problem.
>Let's start with the Doyle example. With the 5 router test network,
>real performance isn't an issue, but with many more routers, it might
>be a good and conscious decision to let Bumble be blackholed in the
>interest of the overall network.
>
>If BGP were involved, this might be a very good thing to handle with
>conditional advertisement, even putting a simple BGP "shim" AS on
>Bumble and Grimwig.
>
>I hope Cisco will extend the idea of conditional advertisements to
>IGPs, and/or do something that Bay RS does. In Bay RS, if any
>component of a summary address goes down, the summary is no longer
>advertised, just the more-specifics. Unfortunately, in the Doyle
>example, the addresses aren't aggregatable, so this sort of solution,
>common in BGP even without conditional advertisement, isn't available.
>
>If the idea of optimization is for Bumble never to be blackholed than
>yes, the book solution is probably quite reasonable. It's somewhat
>analogous to restoring a partitioned OSPF backbone with a virtual
>link.
>
>Simply remember, when you are "optimizing," you need to be clear WHAT
>and WHY you are optimizing.
>
>--
>"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:58:52 GMT-3