Re: Is trunking over WAN possible ?

From: Howard C. Berkowitz (hcb@gettcomm.com)
Date: Tue May 11 2004 - 13:37:28 GMT-3


At 10:00 AM -0500 5/11/04, MADMAN wrote:
>Howard C. Berkowitz wrote:
>
>>At 1:00 PM +0530 5/11/04, Sachin Shenoy wrote:
>>
>>>Hi,
>>>
>>>I was wondering if trunking over WAN is possible ...
>>>What I mean by that is
>>>
>>>
>>> Serial Link
>>> SW1----R1<------------->R2--SW2
>>>
>>>Is it possible to trunk VLANs from SW1 to SW2 ???
>>>(So LAN IP ranges for VLANs on SW1 and SW2 will be the same !)
>>
>>
>>In certain, restricted, cases, usually requiring gigabit or faster
>>transmision media, yes. See such things as Private VLAN Service
>>(more the IETF term) and QinQ encapsulation (although the latter is
>>not a WAN protocol, but the distinction between LAN and WAN is less
>>and less useful). It's also possible using MPLS.
>
> Not that restricted actually and on speeds as low as 100M.

/* begin Hindenburg news announcement voice
   "Oh, the humanity!"
/* end announcer voice

Do remember, Sir, that you are speaking to one whose first
interactive terminal ran at 110 bps. 100 Mbps. Slow. (makes noises
about impetuosity of youth, then goes into hysterical giggles).

Seriously, I've dealt with the desire to have LANs-across-wide-areas
[0] for several years, and I still think that while it will work in
some restricted cases, it's a system collapse waiting to happen.

Broadcasts and multicasts are a significant issue. If the topology
is simply straight-line, I suppose you can just pass the multicast
addresses and not worry about replication. That gets more complex in
a branching tree topology that stil is perfectly valid under spanning
tree, but where you will HAVE to have a replication function, or at
least nontrivial forwarding logic that looks inside the tunnels [1],
to handle multicasts at branching nodes.

While host processor speeds have improved, you still remain
vulnerable to broadcast storms.

Remember, too, when extending what is essentially an L2 service, you
lose many of the standard tools such as ping, traceroute, and
possible ARP cache checks. Yes, Cisco is coming up with L2 traceroute
equivalents, but this is not a trivial problem.

[0] Let me emphasize my concern is with end-to-end use. Using 802.1q over
     dark fiber or even WDM, with a QoS-enabled L2 switch at the customer
     premises connected to the POP is perfectly reasonanle. One can then
     map VLANs to VPNs, and use (G)MPLS in the core. Again, there is L3
     intelligence in such a system.

[1] 802.1q over dark fiber, or even WDM, isn't necessarily tunneled.
     If your scaling technique is QinQ, or other things like L2TP, carrier-
     scale equipment may have to look awfully deeply into the frame.

>We are rolling out a new service that will provide this using 6500s
>in the core and 3550's at the customer site, MPLS is also being
>used. The customer can route, trunk or whatever they desire.
>
> Dave

I know customers _want_ it.

At 2AM last night, I _wanted_ ice cream. I wasn't dressed, my car
wasn't working, and I'm a diabetic.

>
>>
>>Why do you consider this a good idea? It has potential scalability
>>issues, for example, involving both absolute delay greater than
>>expected by LAN devices. Another scalability issue is that
>>uncontrolled growth at both locations may cause the safe number of
>>devices in a broadcast domain to be exceeded.
>>
>>I've been asked to do this many times, on the basis that "layer 2
>>is simpler." At a certain level of scaling, it is not. In general,
>>in the circumstance you describe, I'd route between the sites
>>without overwhelming evidence to the contrary. I can even keep VLAN
>>numbers consistent at both sites.
>>
>>Unfortunately, studying for the CCIE lab overempasizes lots of
>>things that may be possible, but not a good idea in the real world.
>>
\\



This archive was generated by hypermail 2.1.4 : Wed Jun 02 2004 - 11:12:09 GMT-3