From: Chuck Larrieu (chuck@xxxxxxxxxxxxx)
Date: Sun May 27 2001 - 20:31:21 GMT-3
I'm sorry, but I have to disagree here.
If you set up a tunnel between two interfaces, there are definite
characteristics to that tunnel. Even though there may be dozens of routers
between the two tunnel endpoint interfaces, those two interfaces are by
virtue of the tunnel directly connected. The metric for any routing protocol
using the tunnel is clearly defined. In RIP for example, the metric would be
1. Tunnel interfaces require an IP address. If they are IPX they require an
IPX network assignment.
If you have a tunnel between two interfaces, and several routers in between,
and a router over which the tunnel traverses routes a packet to a network
off of one tunnel interface or the other, that packet will have to go to the
router where the tunnel terminates, then across the tunnel to the other
router, and then beyond. This does not happen in the OSPF case. In the
situation below, it is conceivable that traffic from network_A destined for
ROUTER_Y would have to travel to router_X and back because the tunnel shows
a better metric than any other router - even though this is suboptimal. This
would not be true for an OPF packet. Read RFC 1812 for more on router
behaviour in the forwarding of packets.
Network_A----Router---router-----router-----ROUTER_Y-------ROUTER_X-----netw
ork
<-------------------tunnel------------------->
A virtual link, on the other hand, has no such requirements. Nor does the
existence of a virtual link have any effect on the metric between area 0 and
the other discontiguous area. It is for purposes of meeting OSPF
requirements only.
Make sense?
Chuck
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
eugeneonline
Sent: Sunday, May 27, 2001 3:58 PM
To: Curtis Call
Cc: ccielab@groupstudy.com
Subject: Re: Virtual Links
Hi Curtis,
My reference is to software tunneling, not IOS tunnel interfaces. Andy, I
appreciate your diplomacy, but myself and Curtis cannot both be right. I
believe there is a misunderstanding here which is now hopefully explained:
Software tunneling describes the provisioning of functionality normally
provided through a native means; ie physical/datalink connection in this
case. Since a physical connection is not present and is required, we provide
the connection through software, thus 'software tunnelling' principle is
implemented by IOS. This same kind of virtual connection over non-native
means is also used by IOS in DLSW to connect NetBIOS/SNA segments, IPX
segments over IP cloud etc.
You must understand that IOS 'Tunnel Interface' is something different
(versatile ready-made IOS tool used to implement the tunneling principle).
Vlink allows area 2 to simulate a direct connection to area 0 through
tunneling principle. 'Tunnel Interface' is just an IOS feature.With Vlink,
IOS provides layer 1/2 functionality at layer 3.
I rest my case.
Best regards,
Eugene Akhanoba
Curtis Call <curtiscall@home.com> wrote: I'm afraid I have to differ with
you on this one, but I'm doing so from
theory, I'll have to test this out in the lab on Monday. A virtual link
just transports routing information. When you setup a virtual link on your
router and so a show interfaces, do you see a "tunnel" interface for your
virtual link? I am assuming the answer is no, again when you debug ip
packets do you see them being sent on the virtual link? Once again, I
believe the answer is no. (But I have no routers to test this on at the
moment).
If a virtual link was a tunnel then there would be no requirement for a
transit area to not be a stub area. Since all traffic going over the link
would be encapsulated the routers in that particular area wouldn't need to
know how to reach any routers other than the two ABRs that made up the
virtual link and that are present in the area. However, given that a
virtual link is not a tunnel and is solely a transport of routing
information all packets will be sent hop by hop through the transit area,
that's why that area must have full routing information of the OSPF domain.
At 11:38 AM 5/27/01, you wrote:
>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:54 GMT-3