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

[Vincent De Keyzer]

Hi Brad,

I have been facing more or less the same issue, so you have my sympathy.

I'll reply to the questions I can reply to (mostly the L2TP ones, which 
is what I used then):
> >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.
>   
I've been told that L2TPv3 support has recently gone down to 2621XM, but 
I haven't had a chance to check that personally. For more throughput, 
2821 also works.
> 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?
>   
I don't think so - I'm afraid you will have to go to dedicated physical 
interfaces... or maybe QinQ could help you? Not sure QinQ is supported 
in combination with L2TP.
>  * 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
>   
I don't see any issue with that.
>  * 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)
>   
Well, the nice thing about L2TP is that (AFAIK) it is not a bridging 
technology, it just forwards everything that comes in, without even 
looking at destination MAC address. Of course this means that broadcasts 
are forwarded too.
>  * 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.
>   
Depending on throughput, 7200 is an option at the headend (with a 
certain number of PA-FE-TX if required...); and no idea about the 1841 
(I'd be gladly surprised).

HTH!

Vincent
L2TPv3 fan