From: Curtis Call (curtiscall@xxxxxxxx)
Date: Mon May 28 2001 - 11:29:33 GMT-3
Sounds like perhaps we are discussing almost the same thing, just using
different words. For the benefit of the lurkers on the list though I think
a clear answer should be given in this regard. Virtual Links are used to
connect discontinuous backbones. Traffic is not actually encapsulated and
sent over this link, in fact routing information is not even encapsulated
and sent over this link, all that occurs is that rather than using the
224.0.0.6 (or 224.0.0.5) destination address a router will address the OSPF
LSAs to the destination address of the other end of the virtual link. You
could think of it just like you do a standard IBGP connection, routing
information is passed only between the partners however if there are any
routers inbetween these IBGP peers those routers had better have the
information necessary to route the packet appropriately (in the case of BGP
a full mesh would be used for a transit AS or selected routes would be
injected into the IGP or default routes would be used). This is the reason
why OSPF requires a virtual link "transit" area to have full routing
information from the OSPF domain (i.e. not a stub). In truth, if the OSPF
designers wanted to be total purists and never allow any inter-area packets
to actually be routed by routers in the transit area they could have had
virtual links be actual tunnels and they could encapsulate any packets
destined for area 0 (or any other area) in a packet with a destination
address of the other end of the virtual link and perhaps an Ethertype of
"VirtualLink-Tunnel" or created a new OSPF packet type for
"VirtualLink-Tunnel". However, the designers did not want to do that, I
think a big reason behind this is that they wanted to avoid IP
fragmentation (see RFC 2328 section A.1 where they mention the packet size
of all packets sent over virtual links should be less than 576 bytes if
possible) and also they probably considered it to be unnecessary and clunky.
For the record, if anyone is particularly interested IS-IS has a concept of
virtual-links and if I remember correctly they actually do encapsulate the
packets with a new CLNS header destined for the other end of the virtual
link, so they do tunnel the packets. Of course, it is a different theory
than OSPF virtual-links and is used for partitioned L1 areas instead of the
backbone area, however I think it is interesting nonetheless (especially
since it's automatic). It's been a few months since I read over the IS-IS
ISO document but if you look in it and read the section talking about
partition recovery I believe that what I said is correct. Of course, in
the Cisco world, this isn't something we need to be concerned about since
they don't support partition recovery anyway. I just thought I'd mention it.
At 08:31 PM 5/27/01, you wrote:
>Mate,
>
>Sorry that CCIE candidates do not seem to understand the basics of
>software tunelling. TUNNELING PROVIDES ALTERNATIVE TO THE NATIVE
>CONNECTIVITY PROCEDURE. In this case there is no physical/datalink
>conectivity, so connectivity is achieved through software interface.
>
>You say "routED traffic follows the best route provided by the routing
>protocol" There is no disagreement as to routing decision here: as I said
>SPF WILL DECIDE (concurs with Curtis in his words"the traffic still goes
>hop by hop throughout the OSPF domain". ) . Your point therefore is
>irrelevant/duplicate.
>
>Curtis writes: " Virtual Links are not tunnels, you can't transport
>traffic over them, they just carry routing information" Well guess what
>:They are TUNNELING this routing information through area 1. THIS IS THE
>PRINCIPLE OF TUNNELLING. IT IS NOT ONLY APPLICATION DATA THAT IS TUNNELED
>: IN THIS CASE ROUTING UPDATES ARE BEING TUNNELED!
>
>You say "The virtual-link provides a kind of "point-to-point
>demand-circuit" ; how vague can you be?
>
>Chaps, you seem to know only Cisco exam material (tunnel interfaces)
>please read further afield and grasp generics/basics of software
>programming principles, you are going to be CCIEs (hopefully). We don't
>want to be paper/exam CCIEs like MCSE/CNE now do we?
>
>Regards,
>
>Eugene
>
> Mas Kato <tealp729@home.com> wrote:
>Sorry Eugene, but Curtis is correct. The virtual-link provides a kind of
>"point-to-point demand-circuit" across area 1 for the routING protocol
>traffic, but the routED traffic follows the best route provided by the
>routing protocol.
>
>Mas
>
>Go Lakers!
>-----Original Message-----
>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
>eugeneonline
>Sent: Sunday, May 27, 2001 10:39 AM
>To: Curtis Call; ANDY NWEBUBE
>Cc: ccielab@groupstudy.com
>Subject: Re: Virtual Links
>
>
>
>Hi Curtis,
>RFC states that all OSPF areas must be connected to area 0. A virtual
>link provides a transparent connection through another area (which must
>itself be connected to area 0) to area 0. This kind of 'virtual
>connection' concept is known as tunnelling; same as DLSW, IPX, IP over
>IP, VOIP tunnels.
>Regards,
>Eugene
>Curtis Call wrote: Traffic from R2 to R1 will go
>directly from R2 to R1. Remember that in
>order to have R2 be a virtual link it will have an interface in Area 1,
>therefore to reach any destination in Area 1 it will always use the
>intra-area route. Besides, Virtual Links are not tunnels, you can't
>transport traffic over them, they just carry routing information, the
>traffic still goes hop by hop throughout the OSPF domain.
>
>At 12:54 AM 5/25/01, you wrote:
> >Guys,
> >
> >I wonder if their is anybody who remembers the discussion on Virtual
> >Links in OSPF. It was posted some time ago but I can't seem to find it.
> >
> >The scenario was something like this:
> >________ _______ _______
> >|Area 0| |Area1| |Area2|
> >| R0 |--| R1 |--| R2 |
> >|______| |_____| |_____|
> >
> >There is a virtual link from area 2 to Area 0 via Area1. Traffic needs
>to
> >get to R1 in Area 1 from R2 in Area 2. Assume that the virtual link has
>to
> >use R1 (To create the V.Link! ). Does the traffic flow passed R1 (in Area
>1)
> >to Area 0 and then back to area 1, or does the actuall flow just to R1
>from R2.
> >
> >I cant remember the conclusion, and I cant seem to find it on the
> >archives. Quite interesting issues.
> >
> >Regards,
> >Andy
> >
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:30:55 GMT-3