Re: [OSPF] Question on Virtual Link

The fundamental issue is that a particular virtual link is a <router  
ID, transit area> tuple, so you need some mechanism for mapping an  
incoming packet (which has an address but no transit area encoded in  
it)  to that tuple.

How you achieve this mapping, and under what deployment conditions, is  
an implementation exercise, which as always has equal parts creativity  
and danger.

--Dave

On Jun 3, 2008, at 10:54 PM, Pradeep Shastry wrote:

> Hi,
> I have a question on virtual link. As per the RFC2328, under section  
> 8.2 (Receiving protocol packets)
>
> The Area ID specified in the header must either:
>             (1) Match the Area ID of the receiving interface.  In this
>                 case, the packet has been sent over a single hop………………
>
>         (2) Indicate the backbone.  In this case, the packet has
>                 been sent over a virtual link.  The receiving router
>                 must be an area border router, and the Router ID
>                 specified in the packet (the source router) must be  
> the
>                 other end of a configured virtual link.  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 (and the backbone
>                 area)
>
> Here the assumption is that OSPF should be enabled on the interface  
> on which OSPF packet is received (In case of virtual link, to find  
> out transit area id). Is this is correct? If this is correct then I  
> can’t have virtual link end points having multiple paths, some are  
> through OSPF and some other through other protocols like static  
> routes, in this case OSPF packets can be received through the  
> interfaces which are not enabled with OSPF.
>
> Thanks and Regards
> -Pradeepa Shastry