Configuring L2TPv3
Because misconfiguration is so often the cause of L2TPv3 issues, this section contains a review of L2TPv3 (LAC to LAC pseudowire) configuration on Cisco routers.
There are two ways of configuring L2TPv3 on Cisco routers:
Configuring L2TPv3 using dynamic session setup (as described in the section “Technical Overview of L2TPv3”)
Configuring L2TPv3 using static sessions
The sections that follow describe these two configuration methods in greater detail.
Note that when reading this section, it may be useful to reference Figure 5-19 on page 390.
Configuring L2TPv3 for Dynamic Session Setup
When configuring L2TPv3 for dynamic session setup, there are five basic steps to complete on each LCCE router:
Step 1. | Enable Cisco Express Forwarding (CEF). |
Step 2. | Configure loopback interfaces. |
Step 3. | Configure the L2TP class. |
Step 4. | Configure the pseudowire class. |
Step 5. | Configure the attachment circuits. |
The sections that follow describe each of these steps in more detail.
Step 1: Enable CEF
The first step is to enable CEF, as shown in Example 5-1.
Example 5-1. Enabling CEF
ip cef [distributed] |
CEF is enabled in Example 5-1 using the ip cef global configuration mode command.
The distributed keyword is used to enable distributed CEF (dCEF), which is available on some high-end platforms, such as the 7500 and 12000 GSR series.
Step 2: Configure Loopback Interfaces
The next step is to configure a loopback interface to use as a source for L2TPv3 packets. If a loopback interface is not used, L2TPv3 might not function correctly.
Example 5-2 shows the configuration of the loopback interface.
Example 5-2. Configuration of the Loopback Interface
interface Loopback0 ip address 10.1.1.1 255.255.255.255 |
Note that if you are configuring local switching, multiple loopback interfaces should be configured. Local switching is used to switch traffic from one interface to another on the same router.
Step 3: Configure the L2TPv3 Class
The third step is the configuration of the L2TP class. An L2TP class can be used to configure control connection parameters such as authentication, hidden AVPs, and hello interval. The L2TP class can later be applied to a particular neighbor or neighbors.
Example 5-3 shows the configuration of the L2TPv3 class.
Example 5-3. Configuration of the L2TPv3 Class
l2tp-class FrankfurtV3Class authentication password 0 cisco |
In Example 5-3, an L2TP class called FrankfurtV3Class is created using the l2tp-class name command. The authentication command is then used to enable L2TPv3 authentication. Finally, the shared password is configured using the password password command.
Step 4: Configure the Pseudowire Class
The next step is to configure the pseudowire class. The pseudowire class is used to configure parameters such as encapsulation and source IP address used when building a pseudowire.
If an L2TP class has been configured (see Step 3), then it is associated with the pseudowire during this step.
Example 5-4 shows the configuration of a pseudowire class.
Example 5-4. Configuration of the Pseudowire Class
pseudowire-class FrankfurtPW encapsulation l2tpv3 protocol l2tpv3 FrankfurtV3Class ip local interface Loopback0 |
In Example 5-4, the pseudowire class FrankfurtPW is configured using the pseudowire-class name command. The pseudowire encapsulation type is specified using the encapsulation l2tpv3 command.
The signaling protocol is then specified, and the L2TP class is linked to the pseudowire class using the protocol l2tpv3 l2tp-class-name command. In this example, the signaling protocol is specified as L2TPv3, which enables dynamic session setup. The L2TP class is specified as FrankfurtV3Class.
The local (source) IP address used by L2TPv3 is then configured using the ip local interface interface command. The interface specified here is the loopback interface configured in Step 2.
Step 5: Configure the Attachment Circuits
Once the pseudowire class has been configured, the next step is to configure the attachment circuits. Precise configuration depends on the attachment circuit type. Types of attachment circuit include Ethernet, VLAN (802.1Q), Frame Relay, HDLC, PPP, and ATM.
The sections that follow detail the configuration of each of these interface types.
Ethernet Encapsulation
If you are using an Ethernet encapsulation, you should configure the attachment circuit interface as shown in Example 5-5.
Example 5-5. Configuration of an Ethernet Interface
interface FastEthernet1/0 xconnect 10.1.1.2 120 pw-class FrankfurtPW |
In Example 5-5, the xconnect command is used to bind interface fast Ethernet 1/0 to the pseudowire to the peer with the IP address 10.1.1.2 (the peer's loopback address), VCID 120, dand pseudowire class FrankfurtPW.
Note that the VCID must be the same at both end of the pseudowire on both peers.
VLAN (802.1Q) Encapsulation
Configuration of a VLAN (802.1Q) interface is shown in Example 5-6.
Example 5-6. Configuration of a VLAN (802.1Q) Interface
interface FastEthernet1/0.1 encapsulation dot1Q 10 xconnect 10.1.1.2 120 pw-class FrankfurtPW |
In Example 5-6, interface fast Ethernet 1/0.1 and VLAN 10 is bound to the pseudowire with VCID 120 to peer 10.1.1.2.
Frame Relay Encapsulation
Two ways exist to configure a Frame Relay pseudowire. You can configure either DLCI-to-DLCI switching or a Frame Relay trunk.
If DLCI to DLCI switching is used, the router performs Frame Relay switching, and participates in the Local Management Interface (LMI).
If a Frame Relay trunk is used, Frame Relay frames are transparently forwarded over the pseudowire by the router.
Frame Relay DLCI-to-DLCI Switching
Example 5-7 shows the configuration of Frame Relay DLCI-to-DLCI switching.
Example 5-7. Configuration of a Frame Relay DLCI to DLCI Pseudowire
frame-relay switching interface Serial4/1 encapsulation frame-relay frame-relay intf-type dce |
In Example 5-7, the frame-relay switching global configuration mode command is used to enable switching of Frame Relay permanent virtual circuits (PVCs).
The attachment circuit interface is configured for Frame Relay encapsulation using the encapsulation frame-relay command.
The interface is then configured as type DCE using the frame-relay intf-type [dce | dte | nni] command. Note that the dce and dte keywords specify User-to-Network-Interface DCE and DTE interface types, while the nni keyword is used to specify a network-to-network-interface type.
Once the interface has been configured, the PVC is associated with an L2TPv3 session using the connect name Serial interface_number dlci l2transport and xconnect peer_ip_address pw-class name commands, as shown in Example 5-8.
Example 5-8. Association of PVC to L2TPv3 Session
connect PVCtoFrank Serial4/1 60 l2transport xconnect 10.1.1.2 121 pw-class FrankfurtPW |
In Example 5-8, a PVC with DLCI 60 on interface serial 4/1 is associated with a pseudowire to a peer with IP address 10.1.1.2 (its loopback interface) using pseudowire class FrankfurtPW, defined in Step 3.
Frame Relay Trunks
Another option with Frame Relay is to configure a trunk connection over the pseudowire. In this case, the LCCE does not function as a Frame Relay switch and so does not participate in LMI.
Example 5-9 shows the configuration of a Frame Relay trunk.
Example 5-9. Frame Relay Trunk Configuration
interface Serial4/2 xconnect 10.1.1.2 121 pw-class FrankfurtPW |
In Example 5-9, interface serial 4/2 is bound to a pseudowire with VCID 121 (to peer 10.1.1.2).
It is worth noting that the encapsulation configured on the interface is HDLC (the default, so it is not explicitly shown). The fact that HDLC encapsulation is used might be surprising considering that the pseudowire in Example 5-9 transports Frame Relay traffic. By configuring HDLC, the pseudowire is configured to transport HDLC or HDLC-like frames (Frame Relay or PPP, for example).
HDLC and PPP Encapsulations
Configuration for HDLC and PPP encapsulation types is identical to that for a Frame Relay trunk (shown in Example 5-9).
ATM VP Cell Relay
ATM cells can also be transported over an L2TPv3 pseudowire. To transport ATM cells, a permanent virtual path (PVP) connection is bound to a pseudowire, as shown in Example 5-10.
Example 5-10. Configuration of a PVP Pseudowire
interface ATM3/0 atm pvp 10 l2transport xconnect 10.1.1.2 131 pw-class FrankfurtPW |
In Example 5-10, an ATM PVP with a Virtual Path Identifier (VPI) of 10 is bound to a pseudowire with VCID 131 to peer LCCE 10.1.1.2.
Configuring L2TPv3 for Static Sessions
An alternative to configuring L2TPv3 with dynamic session establishment is to configure sessions statically. Note that a control connection can still be used with static sessions. In this case, the control connection can be used to provide authentication and a keepalive mechanism.
Configuration of L2TPv3 with static sessions consists of five basic steps that must be completed on each LCCE:
Step 1. | Enable CEF. |
Step 2. | Configure loopback interfaces. |
Step 3. | Configure the L2TP class (optional). |
Step 4. | Configure the pseudowire class. |
Step 5. | Configure the attachment circuit. |
Configuration of Step 1 through Step 3 is identical to that described in the previous section, “Configuring L2TPv3 for Dynamic Session Setup,” and so is not discussed further here.
The sections that follow discuss the configuration of Step 4 and Step 5.
Step 4: Configure the Pseudowire Class
After enabling CEF, the loopback interfaces, and, optionally, the L2TP class, the next step is to configure the pseudowire class.
Example 5-11 shows the configuration of the pseudowire class.
Example 5-11. Configuration of the Pseudowire Class
pseudowire-class FrankfurtPW encapsulation l2tpv3 protocol none ip local interface Loopback0 |
Most of the configuration of the pseudowire class is the same as that described in the section on dynamic session setup. The one difference is shown in highlighted line 1, which shows the protocol none command. The protocol none command configures the router not to use dynamic session setup.
Step 5: Configure the Attachment Circuit
After configuring the pseudowire class, the next step is to configure the attachment circuits. When configuring attachment circuits with static sessions, you must specify local and remote session IDs, together with local and remote cookie values on each peer router. Session IDs and cookie values must be mirrored between peer routers.
Example 5-12 shows the configuration of attachment circuits when using static sessions. Note that the configuration of peer routers London_PE and Frankfurt_PE is shown for DLCI-to-DLCI switching.
Example 5-12. Configuration of Attachment Circuits with Static Sessions
! On London_PE: frame-relay switching ! interface Serial4/1 encapsulation frame-relay frame-relay intf-type dce ! connect PVCtoFrankfurt Serial4/1 60 l2transport xconnect 10.1.1.2 123 encapsulation l2tpv3 manual pw-class FrankfurtPW l2tp id 1002 2001 l2tp cookie local 4 102 l2tp cookie remote 4 201 l2tp hello FrankfurtV3Class ________________________________________________________________ ! On Frankfurt_PE: frame-relay switching ! interface Serial2/1 encapsulation frame-relay frame-relay intf-type dce ! connect PVCtoLondon Serial2/1 70 l2transport xconnect 10.1.1.1 123 encapsulation l2tpv3 manual pw-class LondonPW l2tp id 2001 1002 l2tp cookie local 4 201 l2tp cookie remote 4 102 l2tp hello LondonV3Class |
As you can see, some of the configuration is the same as that for dynamic session establishment. The crucial difference is the xconnect peer_ip_address encapsulation l2tpv3 manual pw-class name command configuration.
In highlighted lines 1 and 2, the PVC with DLCI 60 on interface serial 4/1 is bound to a static session to peer router 10.1.1.2 (Frankfurt_PE).
Note the VCID (123) configured in highlighted line 2. When using dynamic session establishment, the VCID must be identical on peer routers, but when using static sessions, there is no such requirement. It is still good practice, though.
In highlighted line 3, the local and remote session IDs are configured using the l2tp id local_session_id remote_session_id command. Compare these to the local and remote session IDs configured on the peer router, Frankfurt_PE in highlighted line 7. Notice that they mirror each other.
In highlighted lines 4 and 5, local and remote cookie values are configured using the l2tp cookie local size low_value [high_value] and l2tp cookie remote size low_value [high_value]. Again, notice that they mirror the cookies on Frankfurt_PE in highlighted lines 8 and 9.
Finally, in highlighted line 6, the (optional) command l2tp hello l2tp_class_name command is used to specify that a control connection will be setup (and keepalives sent) between the peers. Again, notice that the peer is similarly configured (highlighted line 10).
Note that session IDs, cookie values, and (optionally) a control connection must similarly be configured under the xconnect command for other encapsulation types. That concludes the configuration of L2TPv3.
Complete Sample L2TPv3 Configurations
Example 5-13 shows complete basic configurations of two peer LCCEs using dynamic session establishment.
Again, it may be useful to reference Figure 5-19 on page 390 when examining these configurations.
Example 5-13. Complete Configuration of Peer LCCEs
London_LCCE#show running-config Building configuration... Current configuration : 2457 bytes ! version 12.0 service nagle no service pad service tcp-keepalives-in service timestamps debug datetime msec localtime show-timezone service timestamps log datetime msec localtime show-timezone service password-encryption ! hostname London_LCCE ! logging buffered 16384 debugging no logging console enable secret 5 $1$4vTL$YY8dhLhFk7RAVy.lI.TtH/ ! ip subnet-zero no ip source-route ! Enable Cisco Express Forwarding (CEF) ip cef ! ! no ip finger no ip bootp server ! ! Configure frame-relay switching (for DLCI-to-DCLI switching) frame-relay switching ! ! Configure the L2TPv3 class for Stockholm_LCCE l2tp-class StockholmV3Class authentication password 0 cisco ! ! Configure the L2TPv3 class for Frankfurt_LCCE l2tp-class FrankfurtV3Class authentication password 0 cisco ! ! Configure the pseudowire class for Stockholm_LCCE pseudowire-class StockholmPW encapsulation l2tpv3 protocol l2tpv3 StockholmV3Class ip local interface Loopback0 ! ! Configure the pseudowire class for Frankfurt_LCCE pseudowire-class FrankfurtPW encapsulation l2tpv3 protocol l2tpv3 FrankfurtV3Class ip local interface Loopback0 ! ! Configure the loopback interface interface Loopback0 ip address 10.1.1.1 255.255.255.255 ! interface FastEthernet1/0 no ip address no ip directed-broadcast ! ! Configure a VLAN (802.1q) attachment circuit (pseudowire to Frankfurt_LCCE) interface FastEthernet1/0.1 encapsulation dot1Q 10 no ip directed-broadcast no cdp enable xconnect 10.1.1.2 120 pw-class FrankfurtPW ! interface Serial4/0 ip address 172.16.1.1 255.255.255.0 no ip redirects no ip directed-broadcast no ip proxy-arp ip router isis no cdp enable ! ! Configure frame-relay DLCI-to-DLCI switching interface Serial4/1 no ip address no ip redirects no ip directed-broadcast no ip proxy-arp encapsulation frame-relay frame-relay intf-type dce ! ! router isis passive-interface Loopback0 net 49.0001.0000.0000.0001.00 is-type level-2-only ! ip classless ! ! logging trap debugging ! ! Bind DLCI 50 to pseudowire (to Stockholm_LCCE) connect PVCtoStock Serial4/1 50 l2transport xconnect 10.1.1.3 131 pw-class StockholmPW ! ! ! Bind DLCI 60 to pseudowire (to Frankfurt_LCCE) connect PVCtoFrank Serial4/1 60 l2transport xconnect 10.1.1.2 121 pw-class FrankfurtPW ! ! ! line con 0 password 7 094F471A1A0A login line aux 0 line vty 0 4 password 7 094F471A1A0A login ! end ________________________________________________________________ Frankfurt_LCCE#show running-config Building configuration... Current configuration : 2610 bytes ! version 12.0 service config service nagle no service pad service tcp-keepalives-in service timestamps debug datetime msec localtime show-timezone service timestamps log datetime msec localtime show-timezone service password-encryption ! hostname Frankfurt_LCCE ! ! logging buffered 16384 debugging enable secret 5 $1$4vTL$YY8dhLhFk7RAVy.lI.TtH/ ! ip subnet-zero no ip source-route ! ! Enable Cisco Express Forwarding (CEF) ip cef no ip finger no ip bootp server ! ! Configure frame-relay switching (for DLCI-to-DCLI switching) frame-relay switching ! ! Configure the L2TPv3 class for Stockholm_LCCE l2tp-class StockholmV3Class authentication password 0 cisco ! ! Configure the L2TPv3 class for London_LCCE l2tp-class LondonV3Class authentication password 0 cisco ! ! Configure the pseudowire class for Stockholm_LCCE pseudowire-class StockholmPW encapsulation l2tpv3 protocol l2tpv3 StockholmV3Class ip local interface Loopback0 ! ! Configure the pseudowire class for London_LCCE pseudowire-class LondonPW encapsulation l2tpv3 protocol l2tpv3 LondonV3Class ip local interface Loopback0 ! ! Configure the loopback interface interface Loopback0 ip address 10.1.1.2 255.255.255.255 no ip directed-broadcast ! ! Configure a VLAN (802.1q) attachment circuit (pseudowire to London_LCCE) interface FastEthernet0/0.1 encapsulation dot1Q 10 no ip directed-broadcast no cdp enable xconnect 10.1.1.1 120 pw-class LondonPW ! ! interface Serial2/0 ip address 172.16.2.2 255.255.255.0 no ip redirects no ip directed-broadcast no ip proxy-arp ip router isis no cdp enable ! ! Configure frame-relay DLCI-to-DLCI switching interface Serial2/1 no ip address no ip redirects no ip directed-broadcast no ip proxy-arp encapsulation frame-relay frame-relay intf-type dce ! ! router isis net 49.0001.0000.0000.0002.00 is-type level-2-only passive-interface Loopback0 ! ip classless ! logging trap debugging ! ! Bind DLCI 80 to pseudowire (to Stockholm_LCCE) connect PVCtoStock Serial2/1 80 l2transport xconnect 10.1.1.3 131 pw-class StockholmPW ! ! ! Bind DLCI 70 to pseudowire (to London_LCCE) connect PVCtoFrank Serial2/1 70 l2transport xconnect 10.1.1.1 121 pw-class LondonPW ! ! line con 0 password 7 094F471A1A0A login line aux 0 line vty 0 4 password 7 094F471A1A0A login ! end |
You will notice that the configuration for London_LCCE in Example 5-13 specifies three pseudowires:
One VLAN (VCID 120) to Frankfurt_LCCE (10.1.1.2)
One Frame Relay (switching) pseudowire for DLCI 60 (VCID 121) to Frankfurt_LCCE (10.1.1.2)
One Frame Relay (switching) pseudowire for DLCI 50 to Stockholm_LCCE (10.1.1.3, not shown in Figure 5-19)
The configuration for Frankfurt_LCCE similarly specifies three pseudowires:
One VLAN (VCID 120) to London_LCCE (10.1.1.1)
One Frame Relay for DLCI 70 (VCID 121) to London_LCCE (10.1.1.1)
One Frame Relay pseudowire for DLCI 80 to Stockholm_LCCE
MTU Issues with L2TPv3
When configuring L2TPv3, you need to be aware of Maximum Transmission Unit (MTU) issues that may result from the transport of large data frames.
If large data frames are transported over the pseudowire, this may result in either fragmentation or even the dropping of L2TPv3 packets. If L2TPv3 packets are fragmented, the receiving LCCE has to perform packet reassembly, and this increases CPU utilization. The fragmentation or dropping of L2TPv3 packets can result if the MTU of any links between peer LCCEs is smaller than the L2TPv3 packet size (see Figure 5-8).
To calculate the L2TPv3 packet size, add the IP header (20 bytes), the L2TPv3 session header (12 bytes, assuming a 64-bit cookie size), the optional Layer 2 specific sublayer (4 bytes, if using the default Layer 2 specific sublayer), and the payload (the frame received on the attachment circuit). When calculating the payload size, do not forget to include the attachment circuit Layer 2 header—this is in addition to the MTU of the attachment circuit.
For example, a 1504-byte frame received on a Frame Relay attachment circuit (including the 4 byte Frame-Relay header) would yield an L2TPv3 packet size of: 20 bytes (IP packet header) + 12 bytes (L2TPv3 session header) + 4 bytes (the default Layer 2 specific sublayer, which only has to be included if sequencing is enabled) + 1504 (the frame received on the attachment circuit) = 1540 bytes.
There are several ways to address the MTU issue, including enabling Path MTU Discovery for L2TPv3.
Enabling Path MTU Discovery allows the LCCE to detect the smallest MTU in the path to its peer LCCE and dynamically adjust the MTU for L2TPv3 sessions. This feature can be enabled using the ip dfbit set and ip pmtu commands.
The ip dfbit set command sets the Don't Fragment (DF) bit in the IP header of L2TPv3 packets, which prevents fragmentation of L2TPv3 packets.
If a router in the path between the peer LCCEs needs to fragment an L2TPv3 packet but is prevented from doing so because the Don't Fragment (DF) bit is set, it should send an Internet Control Message Protocol (ICMP) unreachable message (ICMP message type 3, code 4) back to the sending LCCE specifying that fragmentation is required but that the DF bit is set. If the ip pmtu command is configured on the sending LCCE, it then reduces the size of L2TPv3 packets it sends.
Example 5-14 shows the configuration of both of these commands.
Example 5-14. Configuring the ip pmtu and ip dfbit set Commands
pseudowire-class FrankfurtPW ip pmtu ip dfbit set |
Example 5-14 shows the configuration of the ip pmtu and ip dfbit set commands within a pseudowire class called FrankfurtPW.
If switches are being used in the service provider point-of-presence (PoP), also ensure that these switches are configured to support large L2TPv3 packets. To support large L2TPv3 packets, you should enable jumbo frame support. See the following URL for more details on the configuration of jumbo frame support on Cisco Catalyst switches: