RE: Weird ospf topologies

From: Pearson John (jnhpearson@yahoo.co.jp)
Date: Thu Apr 28 2005 - 01:18:59 GMT-3


If virtual-links are not permitted in the question, then
Tunnels would be another option, placing the tunnel
interfaces in OSPF area 0 for scenarios that required it.

John

--- "Hoonpongsimanont, Chalermchai"
<chalermchai.hoonpongsimanont@atosorigin.com>
$B$+$i$N%a%C%;!<%8!'(B
> Hi Tim,
>
> What if you are not allowed to use virtual link?
>
> Cheers,
> David
> -14141
>
> -----Original Message-----
> From: ccie2be [mailto:ccie2be@nyc.rr.com]
> Sent: Thursday, April 28, 2005 12:46 AM
> To: Group Study
> Subject: Weird ospf topologies
>
> Hi guys,
>
> I'm trying to collect all the weird, non-standard
> ospf topologies that are
> never used in the real world but that Cisco loves to
> come up with in the
> lab.
>
> For example, consider this topology:
>
> area 1 rtr-1 area 2 rtr-2 area 3
>
> At first, this looks like an illegal topology
> because there's no area 0.
> However, if a virtual link is configured between
> rtr-1 and rtr-2, all is
> well.
>
> Here's another one.
>
> area 0 rtr-1 area 2 rtr-2 area 3 rtr-3
> area 4
>
> At first, this looks also illegal but by adding a
> 2nd virtual-link between
> rtr-2 and rtr-3, this will also work since it's OK
> to chain v-links
> together. (BTW, off-hand, I don't know if area 0
> were changed to area 1 if
> this would still work but I imagine it would. Any
> comments?
>
> So, this is a call for all weird, non-standard ospf
> topologies.
>
> Be creative. Try to think of anything outside of
> the norm because you know
> Cisco is doing the same.
>
> Don't limit your responses to just things having to
> do with virtual-links
> either. If you know of or can think of a
> non-intuitive way for a certain
> ospf requirement to be worded, please share your
> thoughts whether it's about
> summarization, network type, a seldom used ospf
> feature, nssa areas, or
> anything else regarding ospf.
>
>
> I know that Cisco can find other things to trip us
> up on during the lab but
> let's at least remove ospf as a potential pitfall.
>
> Tim
>
>



This archive was generated by hypermail 2.1.4 : Tue May 03 2005 - 07:55:10 GMT-3