[c-nsp] Replacing proper planning with dirty hacks (VLAN extension over GRE & L2TP)

[Brad Henshaw]

Ladies & Gentlemen,
 
I'm looking for some input on what others have managed to achieve / get
away with using GRE & L2TP to virtually flatten routed networks.
 
One of our clients has found themselves in a position where they have
purchased and implemented an extremely expensive mesh radio network
which doesn't meet their requirements - primarily, to allow end to end
carriage of VLANs from the main wired network to remote wired segments
via the radio mesh. They want a solution to this without throwing
away/trading in the existing kit and starting the analysis and design
process from scratch - the latter is not going to happen for various
reasons, and management won't allow me to apply a LART.
 
In a nutshell, each client site has 10-20 VLANs, a 6509 at the core
which provides inter-VLAN routing and WAN access and a mixture of 3560,
3750, 2950 and other switches at the access layer, all operating in
Layer 2 mode only.
 

Typically the topology is as follows:
 
[6509 core]
 | <802.1q trunk>
 |
[3560 L2 access]
 | <access port>
[local radio unit]
 | <wireless mesh - one or more L3 hops>
 |
[remote radio unit 1]........[remote radio unit n]
 | <access port>
[remote L2 switch 1].........[remote L2 switch n]
 |
[PCs and other devices]
 

The challenge is that while the customer wishes to trunk VLANs from end
to end (6509 all the way to the remote L2 switch) the radio network in
the middle is a routed network due to the radio solution selected.
 
We're looking at whether we can use GRE or L2TP, probably on dedicated
routers at the headend (between L2 access switch and local radio unit)
and around 10 remote ends (between remote radio unit and remote L2
switch) to hack a solution into place that will effectively allow the
VLANs to be trunked over the L3 mesh.
 
>From the brief thoughts I've had about this, L2TP is looking more
feasible than GRE because as as far as I can tell we'd need a GRE tunnel
per VLAN/IP subnet to be transported and management would become [more
of] a nightmare due to the number of tunnels. Support for L2TP in
various Cisco kit looks more restrictive though.

The various issues & questions which come to mind are:
 * With L2TP - can we terminate multiple tunnels on a headend router,
and dump these out a single physical interface (a dot1q trunk to an edge
or core switch) probably via a xconnect? Or does each tunnel need a
dedicated phy interface?

 * Is the above a valid topology? Essentially a hub and spoke scenario
with L2TP tunnels carrying multiple 802.1q tagged frames between the hub
and the spoke routers, bearing in mind that each remote 'spoke' segment
would be sharing the same VLAN IDs and IP subnets

 * If yes to the question above, wouldn't the headend router need to
maintain a MAC address table based on the tunnelled, 802.1q tagged
frames received from each remote router? (since a frame received by the
headend on the dot1q trunk to the L2 switch could need to be sent out to
any of the 10 or more remote endpoints/tunnels)

 * If GRE were to be used (along with VRF-lite to segregate the
so-called VLANs if necessary), we'd need tunnels from each remote router
to the headend router, for every VLAN to be transported, would we not?

 * Are any of these options feasible on moderately low-end hardware (say
a 7200 or 3845 at the headend and 1841s(ish) at the remote end) to keep
the solution affordable? Aggregate throughput at the headend really only
needs to be 10-20Mbps.

 * I know the scenario is fairly stupid to begin with, but other than
designing a /real/ L2 radio solution, living with a routed network, or
finding a job where I'm not involved in after-the-fact cleanups, have I
missed any options here?

Any sharing of knowledge and/or experience would be appreciated. (I
don't ask questions often, but when I do, I obviously ask the world)

Regards,
Brad