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

[Rubens Kuhl Jr.]

Beware that all tunneling methods have overheads that will make
packets that are of valid size on the client-side (IP MTU 1500,
Ethernet MTU 1518 with no .1q, 1522 with .1q)  generate packets that
when tunneled will overflow the mesh radios MTUs, which is usually
Ethernet 1522 but maybe 1518 considering their lack of VLAN transport
support. Before going into decision phase on how to fix this mess,
it's good to do a field test on what MTU size you can pass from one
point of the a network to a neighbor hop and to a far end hop. Your
problems may be bigger than you think.



Rubens


> 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
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>