Re: LA bit setting in IA for virtual link

[Sina Mirtorabi <sina at CISCO.COM>]

Vanitha,


->Hi,
->
->        As per the section 3.4.3.7 in RFC 2740, "If RTX has
->one or more virtual links configured through the area, it
->includes one of its site-local or global scope IPv6 interface
->addresses in the LSA (if it hasn't already), setting the
->LA-bit in the PrefixOptions field, and setting the
->PrefixLength to 128 and the Metric to 0. This information
->will be used later in the routing calculation so that the two
->ends of the virtual link can discover each other's IPv6 addresses. "
->
->Setting LA bit to any of the interface prefix is not
->sufficient to handle multiple virtual links. The prefix
->should belong to one of the interfaces in transit area.


Typically you would set the LA bit for one of the interface's prefix in
transit area if that interface has a global IPv6 address. Otherwise you
will advertise any of your global IPv6 address *in_the_tranist_area*
with LA bit set


->Consider the below situation
->
->        |-------------|         1       |-----------|
->        |       R1      |---------------|   R2      |--------------R3
->      |         |---------------|           |   3
->        --------------          2       ------------
->
->
->Link 1 is in area 1 with metric as 1 at R2
->Link 2 is in area 2  with metric as 10 at R2
->Link 3 is in area backbone.
->virtual link is configured between R1 and R2 through the
->transit area 2. (Say virtual Link 1) one more virtual link is
->configured between R1 and R2 through the transit area 1. (Say
->virtual link 2)
->
->If R1 adds link 1 prefix with LA bit set in both the transit
->areas, then Route at R2 for the LA bit set prefix will be
->through the link 1  because of the lower cost. For both the
->virtual link, the packet will be send on link 1.

Note that for VL control packet, the path taken is always through the
corresponding transit area. Now for data traffic through the backbone,
you have two paths (each through different transit area) and naturally
you will take the shortest path, this is not any different than if you
had both physical link in area 0

->
->The packets will be always associated with the virtual link 2
->because of the validation procedures told in 8.2 section of
->RFC2328. "The receiving interface must also attach to the
->virtual link's configured Transit area. If all of these
->checks succeed, the packet is accepted and is from now on
->associated with the virtual link " So virtuallink1 will never come up.
->

It will, as long as you have an intra-area path to the other end of VL
through transit area...


->Instead if we mandate that the LA bit should be set for a
->prefix of one of the interfaces of transit area, then things
->will work fine.

Again your transit area may not have a global IPv6 address therefore you
can announce any global IPv6 address into each transit area with LA bit
set

Sina



->If there is no prefix in the transit area,
->virtual link will fail. This is in line with OSPFv2.
->Reference--> Section 15 Virtual Links. "Note that when one
->(or both) of
->Reference--> the
->virtual link endpoints connect to the Transit area via an
->unnumbered point-to-point link, it may be impossible to
->calculate either the virtual interface's IP address and/or
->the virtual neighbor's IP address, thereby causing the
->virtual link to fail. "
->
->Regards,
->Vanitha N.
->
->
->
->
->
->**************************************************************
->*************
->This message is proprietary to Future Software Limited (FSL)
->and is intended solely for the use of the individual to whom
->it is addressed. It may contain  privileged or confidential
->information and should not be circulated or used for any
->purpose other than for what it is intended.
->
->If you have received this message in error, please notify the
->originator immediately. If you are not the intended
->recipient, you are notified that you are strictly prohibited
->from using, copying, altering, or disclosing the contents of
->this message. FSL accepts no responsibility for loss or
->damage arising from the use of the information transmitted by
->this email including damage from virus.
->**************************************************************
->*************
->