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

Rolf Mendelsohn rolf-web at cyberops.biz
Tue Oct 30 09:16:38 EDT 2007


Hi Brad,

What is the Radio network based on and what are the Specs.

i.e. QinQ, Vlan's, MTU, PtP or PtMP (or a hybrid of the 2).

I have worked on many similar systems and with some additional detail, I might 
be able to help.

Regards,
Rolf

On Tuesday 30 October 2007 10:13:30 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.
>
> >  * 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
>
> _______________________________________________
> 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/




More information about the cisco-nsp mailing list