As I mentioned last time, L2TPv3 has a plethora of capabilities, including the capability to be used for remote access VPNs, the capability to transport a number of Layer-2 protocols in a pseudowire configuration, the capability to transport MPLS Layer-3 VPN traffic, and the capability to transport IPv6 over an IPv4 backbone network.
In this blog post, I am going to focus on the most popular application for L2TPv3 - pseudowires.
The first question to answer in regard to L2TPv3 pseudowire configuration is, ‘What is a pseudowire?'. As I mentioned briefly last time, a pseudowire is simply an emulated circuit. By using L2TPv3, it is possible to extend a number of layer-2 circuit types over an IP backbone network.
Many service providers use L2TPv3 or MPLS-based pseudowires to offer Ethernet services. Service providers also use pseudowires to consolidate their legacy ATM/Frame-relay/other networks and their IP/MPLS networks. Enterprises use pseudowires to extend layer-2 circuits over their IP networks.
Before diving into the configuration of L2TPv pseudowires, it's a good idea to take a quick look at how they work.
I'll start by taking a look at the two types of L2TPv3 messages: control connection messages and data (channel) messages.
Control channel messages are used for signalling between the two routers that are the endpoints of the L2TPv3 pseudowire (these endpoints can be referred to as L2TP Control Connection Endpoints [LCCEs]). Control connection messages can be used by the LCCEs to setup the control connection itself, to establish L2TPv3 sessions, to indicate circuit status changes, to tear down sessions, to terminate the control connection, and to provide a keepalive mechanism.
Data channel messages, on the other hand, are the messages that actually carry the Layer-2 protocols and connections over the IP backbone.
Below is a figure that I'll use to illustrate the various concepts and configuration details.
As already mentioned, an L2TPv3 pseudowire can be used to transport a variety of Layer-2 circuit types, but I'll use an Ethernet port pseudowire between ‘London.PE' and ‘Amsterdam.PE' as an example here. The following figure illustrates the process that ‘London.PE' uses to send Ethernet frames over the pseudowire to ‘Amsterdam.PE.':
When ‘London.PE' receives an Ethernet frame on the attachment circuit from ‘mjlnet.London.CE', it encapsulates that frame with an L2TPv3 header/sublayer and send the resulting packet across the IP backbone network to ‘Amsterdam.PE'.
When ‘Amsterdam.PE' receives the L2TPv3 packet from ‘London.PE', it removes the L2TPv3 header/sublayer, and sends the Ethernet frame over the attachment circuit to ‘mjlnet.Amsterdam.CE'.
Of course, the same process happens in reverse when ‘Amsterdam.PE' receives an Ethernet frame from ‘mjlnet.Amsterdam.CE' - it encapsulates the Ethernet frame with an L2TPv3 header/sublayer and sends it over the IP backbone network to ‘London.PE'. ‘London.PE' decapsulates the Ethernet frame and sends it across the attachment circuit to ‘mjlnet.London.CE'.
The configuration of an L2TPv3 pseudowire (with dynamic session establishment) can be broken down into five steps:
The five steps must be configured on both endpoints (both LCCEs). In the figure above, these endpoints are named ‘London.PE' and ‘Amsterdam.PE'.
The configuration for an Ethernet port pseudowire (used to transport ‘raw' Ethernet frames) on ‘London.PE' is shown below:
!
hostname London.PE
!
interface Loopback0
ip address 172.16.1.1 255.255.255.255
!
l2tp-class mjlnet.Class.To.Amsterdam
digest secret mjlnet hash sha
!
pseudowire-class mjlnet.PW.To.Amsterdam
encapsulation l2tpv3
protocol l2tpv3 mjlnet.Class.To.Amsterdam
ip local interface Loopback0
!
!
interface FastEthernet0/0
xconnect 172.16.1.3 1001 pw-class mjlnet.PW.To.Amsterdam
!
As previously mentioned, the first step in configuring an L2TPv3 pseudowire is to ensure that CEF is enabled. CEF is enabled by default, so the ip cef command, which is used to enable CEF, is not explicitly shown above. But if it is disabled, make sure that you enable it, otherwise L2TPv3 pseudowires will not function.
Once CEF has been enabled, you should configure a loopback interface to use as an endpoint for L2TPv3 pseudowires (interface loopback 0 on ‘London.PE'). The address on this interface is the address from which and to which L2TPv3 packets will be sent. It's a very good idea to use a loopback interface for this purpose as they do not go down (unlike physical interfaces). Make sure that there is IP reachability between the loopback interfaces at either end of the L2TPv3 pseudowire (here ‘London.PE' and ‘Amsterdam.PE') otherwise the L2TPv3 pseudowire will not function.
Next is the L2TPv3 class, which is configured using the l2tp-class name command. An L2TPv3 class is optional, but recommended because it allows you configure a number of control channel parameters such as authentication.
The digest [secret [0 | 7] password] [hash {md5 | sha}] command is used to configure digest secret authentication, specify a password, and configure the hash algorithm (Message Digest 5 [MD5] or Secret Hash Algorithm [SHA-1]). The password and hash algorithm must be configured identically between the peer LCCEs or L2TPv3 control channel setup will fail.
The pseudowire-class [pw-class-name] command is used to configure a pseudowire class, which allows you to specify the pseudowire encapsulation type (encapsulation l2tpv3), the local pseudowire endpoint address (ip local interface loopback-interface-name), and control channel protocol (protocol {l2tpv3 | none} [l2tpv3-class-name]). Note that the protocol {l2tpv3 | none} [l2tpv3-class-name] command is also used to link to the previously specified L2TPv3 class.
Finally, the xconnect peer-ip-address vcid pw-class name command is used specify the IP address of the peer LCCE, the previously configured pseudowire class name, and to bind the attachment circuit (the circuit between ‘mjlnet.London.CE' and ‘London.PE') to the L2TPv3 pseudowire.
The configuration of ‘Amerstam.PE' is very similar to that of ‘London.PE':
!
hostname Amsterdam.PE
!
interface Loopback0
ip address 172.16.1.3 255.255.255.255
!
l2tp-class mjlnet.Class.To.London
digest secret mjlnet hash sha
!
!
pseudowire-class mjlnet.PW.To.London
encapsulation l2tpv3
protocol l2tpv3 mjlnet.Class.To.London
ip local interface Loopback0
!
!
interface FastEthernet0/0
xconnect 172.16.1.1 1001 pw-class mjlnet.PW.To.London
!
So, as you can see, the configuration of an L2TPv3 pseudowire can be pretty simple.
Mark
Advertisement: |
Mark Lewis (CCIE#6280) is an independent consultant who helps service provider and large enterprise clients design and implement leading-edge technologies. Over the last couple of years, Mark has designed and implemented a variety of large-scale technology solutions including VPN, MPLS, QoS, data center, and IP telephony. Mark is the author of three books for Cisco Press: Comparing, Designing, and Deploying VPNs, Troubleshooting Virtual Private Networks, and CCIE Voice Exam Quick Reference Sheets.
The Leader in Network Knowledge
pass VLANs across IP...
Can you send me a simple config to transport a VLAN across this pseudowire? I'm trying to accomplish having the same VLAN in two different cities...
pass VLANs across IP...
Configuration example will do it. No need to specify what you want to transfer (VLANs, CDP, DHCP, etc.).
Multiple VLANS in 2 sites
Everything makes sense to me except on how to pass multiple vlans across the the WAN. How does the traffic from vlan1 at headquarters know how to get to vlan1 at remote site, and at the same time vlan2 from HQ to remote site
Thanks