Subject: [OSPF] Question on Virtual Link

From: Pradeep Shastry <[email-masked]>
Date: Wed, 04 Jun 2008 10:24:52 +0530

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

****************************************************************************
***********
This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

_______________________________________________
OSPF mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ospf

---

From: Acee Lindem <[email-masked]>
Date: Wed, 4 Jun 2008 01:28:33 -0400

Hi Pradeep,

On Jun 4, 2008, at 12:54 AM, Pradeep Shastry wrote:

> Hi,
>
> I have a question on virtual link. As per the RFC2328, under  
> section 8.2 (Receiving protocol packets)
>
>
>
>                 case, the packet has been sent over a single hop………………
>
>
>
> 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.
>

That is correct. A virtual link through an OSPF transit area will  
only include intra-area paths within that transit area.

Acee

>
>
> Thanks and Regards
>
> -Pradeepa Shastry
>
> ********************************************************************** 
> *****************
> This e-mail and attachments contain confidential information from  
> HUAWEI, which is intended only for the person or entity whose  
> address is listed above. Any use of the information contained  
> herein in any way (including, but not limited to, total or partial  
> disclosure, reproduction, or dissemination) by persons other than  
> the intended recipient's) is prohibited. If you receive this e-mail  
> in error, please notify the sender by phone or email immediately  
> and delete it!
>
>
>

---

From: Dave Katz <[email-masked]>
Date: Wed, 4 Jun 2008 00:27:40 -0600

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)
>

---

From: Richard Ogier <[email-masked]>
Date: Wed, 04 Jun 2008 08:34:51 -0800

I will attempt a different answer to your question, which may or may not
correctly address your concern.

> 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.

If you have a static route between two backbone routers,
it can be configured as a point-to-point link in OSPF (using tunnel
encapsulation). However, in this case, you would not need a virtual
link since you have a direct link between the two backbone routers.
Therefore, if I am correctly interpreting your concern, the answer
might be that you can achieve your goal using tunneling instead of
a virtual link.

Richard

Pradeep Shastry wrote:

> 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
>
> ***************************************************************************************
> HUAWEI, which is intended only for the person or entity whose address 
> is listed above. Any use of the information contained herein in any 
> way (including, but not limited to, total or partial disclosure, 
> reproduction, or dissemination) by persons other than the intended 
> recipient's) is prohibited. If you receive this e-mail in error, 
> please notify the sender by phone or email immediately and delete it!
>
>------------------------------------------------------------------------
>