Virtual links OSPF from one area to the backbone through two differents areas.

Hi folks,

hope this is the right place to post my question. I'll try to be as
concise as I can.
I'm studying OSPF with dynamips/IOS and I have read many sources. So far
I was told that virtual links can link areas to the bacbone (area 0)
through one non-backbone area. The main purpose being the fact that
this way the topology of the OSPF areas is always a star topology and
hence loop free.

But what happens if I connect the same area to the backbone through two
different areas?

Is this allowed? So far I haven't seen anything on such configuration.
I'm playing with IOS and dynamips and I'm getting some weird results.
But before moving forward with my questions I'd like to know if this is
allowed in OSPF and supposed to work.

Thanks in advance,

Alex

P.S.
I'm also aware that virtual links are a temporary solution

 

Hi,
I think it is not allowed. You can have *one* transit area only.

However, you can get the same result with a daisy chain of ospf virtual
links. It's interesting to try on dynamips!

Check this url for an in-depth explanation...
http://blog.ine.com/2009/09/14/understanding-ospf-transit-capability/

 

grazie mille!

 

I've just posted a comment on it since I have a small doubt. Hopefully
somebody will reply and I don't know if anyone here agrees with my
comment I left. Anyone willing?

 

then you are not linking to the nearest backbone connection.

If that matters, then you need to think about your backbone + area
structure - if you need to push past the topology required by the
protocol it is a good indication that the design is sub optimal.

Since each aera needs to be linked to the backbone, you should be able
to link by going through a single area.

There were some add on tinkering for OSPF ABR setups as a way to allow
an ABR to keep on working when it loses its backbone connection - this
makes resilience easier with some ABR setups.

The RFC might have something to say about transiting 2 areas.....
http://tools.ietf.org/html/rfc3509