From: Sachin D (networker.ccie@gmail.com)
Date: Sun Nov 09 2008 - 11:00:09 ARST
Hi Felix,
Thanks for your response. But only the problem should appear if the area
trying to get connected to area 0 gets external routes.... I should have
asked question this way
area0>>>area1>>>area2
if area 1 is stub and area 2 is totally stub so should virtual links work in
this case as area 2 will not have any type 5
Regards
Sachin
On Sat, Nov 8, 2008 at 10:22 PM, Felix Nkansah <felixnkansah@gmail.com>wrote:
> Hi Sachin,
>
> In short, it has to do with the behavior of OSPF which requires other areas
> of the domain to be connected to the backbone area.
>
> As such, data from one area to another must transit through the backbone
> area.
>
> A virtual link serves as a "point-to-point" extension of the backbone area,
> through which other areas can send their transit data.
>
> Unfortunately, virtual links do not tunnel the transit data, only the
> routing updates are. The transit data is sent natively by the area in which
> it lies.
>
> The routers in the stub area do not have routes for specific external
> destinations. Because data is sent natively, if a packet destined for an
> external destination is sent into a stub area which is also a transit area,
> then the packet is not routed correctly.
>
> To overcome this limitation when the backbone is 'extended' in a stub area,
> we need a 'link' that would tunnel both the routing updates and the transit
> data itself, in the case of data going to external destinations.
>
> GRE tunnels are the ones known to solve such a problem. So you would have
> to use GRE tunnels if you want to extend the backbone through a stub.
>
> I guess it's not a short explanation afterall. Maybe others can make it
> clearer in case this doesn't help.
>
> Happy studies!
>
> Felix Nkansah, CCIE
Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Mon Dec 01 2008 - 08:18:30 ARST