[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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
_______________________________________________
OSPF mailing list
OSPF at ietf.org
https://www.ietf.org/mailman/listinfo/ospf