L2TPv3 revision notes – architecture

11 03 2008

L2TPv3 has been designed to transport layer-2 frames of various types over a layer-3 backbone.  Some aspects of the configuration are similar to that of EoMPLS – just without the need to deploy MPLS!

Packets are tunneled across the layer-3 network completely transparently, such that the two devices appear to be connected together. In the case of ethernet tunneling, there is no learning of MAC addresses – what goes in one side, comes out the other. That includes CDP, Spanning Tree and so on.

From what I can tell, L2TPv3 has been available for 7200s, 7500, 10K and 12K since 12.0(23)S – the service-provider train.

Its also available for more enterprise-focussed routers too – so you don’t need to be running SP code for this to get you out of a network design hole… 3800 and 2800 ISRs since 12.3(14)T, 3700s since 12.3(2)T etc.

Basically, you either signal or nail up a tunnel between two routers, preferably specifying loopbacks as the source and destination addresses.  Make sure the loopbacks are routable to.

Once that’s done, you go into the edge interface you want to tunnel from, and using the “xconnect” command, specify the remote peer’s loopback address and a unique VC ID.  Do the same at the other end, and your tunnel will come up once the edge interfaces get carrier.

There are a few options for authentication, timeouts, retries and so on. I’ll go into those at a later date when I’ve had a chance to play with this more.

What’s going on under the hood?

Layer 2 packets being received by the ‘head-end’ router are being given an extra header to transit the network. The header is stripped off at the decapsulating router and the packet is transmitted on the far end interface.  Actually there are two headers:

1. The L2TPv3 header, which contains a session ID (4 bytes), a cookie (0, 4 or 8 bytes) and a pseudowire control encapsulation (4 bytes).  This header is stuck on the front of the received L2 packet.

2. A standard 20-byte IP header is then stuck on the front of that to transport the whole lot to the decapsulating router.

The session ID is unique and has to agree at both ends – this is the information that the decapsulating router uses to know which interface to transmit the packet on, once it has had the headers removed.  (The decapsulating router could be serving many L2TPv3 pseudowires, so the session ID is crucial).

The cookie is optional, according to RFC3931.  It provides an extra level of guarantee that the received packet will be put onto the right outgoing interface, in the event of the session ID being corrupted or something.  It can be 0, 4 or 8 bytes long, and both ends must agree.

The pseudowire control encapsulation field contains information about sequencing and so on.

Creating the Circuit

As mentioned before, the circuit can be created manually, or signalled. Here are the steps for a manual L2TPv3 circuit in overview, cutting out all the optional bits:

1. Create a pseudowire-class – a template that holds config parameters for this circuit

2. Tell the pseudowire-class that the encapsulation will be L2TPv3

3. Tell the pseudowire-class that the protocol will be ‘none’ – i.e. don’t do any L2TPv3 signalling.

4. Specify the local interface – ideally a loopback.

5. Go into the edge interface, and do an xconnect, specifying the remote peer,  the virtual circuit ID and the pseudowire-class you just made.

5. Configure the local and remote session IDs for this circuit.
6. Go to the other end and do the same.


Signalling the circuit 

There’s always a chance you’ll get your session IDs in a twist if you do it the manual way, so perhaps signalling the circuit parameters is a better way to go.  In this scenario, L2TPv3 messages are sent between the routers containing “attribute/value pairs” – AVPs.  Among these AVPs are the session ID and cookie, of course.

In fact, the configuration of this is even simpler than with the manual method.   The config is the same, except:

– in the pseudowire-class you specify that L2TPv3 is the protocol to be used rather than ‘none’.

– under the interface, there is no need to specify the local and remote session IDs.

Actually, using the L2TPv3 control channel has two extra advantages.  It can do ‘dead peer detection’ for you, and it can also support authentication of the end-points.  As far as I can tell, authentication is probably plain-text password only though.




4 responses

11 03 2008
Robert Michel

I found your blog on google and read a few of your other posts. I just added you to my Google News Reader. Keep up the good work. Look forward to reading more from you in the future.

Robert Michel

19 10 2008

Thanks Robert! Glad you think this stuff is helpful – I put it out there, but don’t know if it makes sense, so it is pleasing to think it is useful to someone!

7 07 2010

How do you feel that his compares with OTV? Cisco has been pushing that with their Nexus 7K series. It is also supposed to become available to the ISR series routers.

20 07 2010

Hi Bryce – what’s OTV? Unfortunately we’re not selling the Nexus just yet (for some reason I don’t understand)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: