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

[Phil Bedard]

Responses inline.


On Oct 30, 2007, at 5:13 AM, Vincent De Keyzer wrote:

> 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.

You can use dot1q subinterfaces and multiple xconnect statements.  I  
would call it vlan mode EoMPLS/GRE/L2TPv3, as opposed to port mode  
where you do a one to one transparent physical port mapping.   I've  
done this in a wholesale internet type of situation where remote  
customers are connecting to a provider over an MPLS network.


>>  * 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.

I think the original poster had a VPLS-like scenario in mind, where  
the headend is
acting like a virtual switch of sorts.    You aren't going to find  
VPLS support on any of the lower end
models of routers.   If you just tunnel everything through to a  
switch outside the routers, then you would be
fine.

Alcatel's 7750/7450 has a feature called spoke-sdp which will use GRE  
tunnels (or native MPLS) to create VPLS instances between
a hub (7750) and spokes (7450), that works very well.   I think Cisco  
is working on similar features since they just came out with AToGRE with
SRB on the 7600, but I wouldn't expect that to be supported on any  
lower end platforms.

If it were me I'd leave at L3, since building a big L2 mesh network  
of sorts may end up with some weird routing, broadcast/multicast  
issues, etc...but I don't know that much about the requirements or  
the topology.    I saw something about support for VRFs for  
multipoint VPNs I think, so you may be able to use a few multipoint  
GRE tunnels on the headend, one for each service so to speak, as  
opposed to one for every service on every router...sounds like fun  
any way you slice it.  :)


Phil