Layer 2 Vpn Architectures [Electronic resources]

Figure 11-1. L2TPv3 Connectivity Model

Chapter 12, "WAN Protocols over L2TPv3 Case Studies") L2TPv3 pseudowire sessions can be defined statically or have an optional control channel exist between the L2TPv3 endpoints to negotiate session details (such as session IDs and sequencing) and endpoint information (that is, control channel authentication and hidden Attribute-Value Pairs [AVP]).

From a configuration perspective, you need a method to tie the attachment circuit to the pseudowire session. For scalability purposes, the CLI should also allow multiple sessions to share the same session characteristic's template (that is, sequencing and source IP address) and multiple dynamic sessions to share the same control channel parameters. Essentially, the L2TPv3 configuration syntax fulfills these requirements through the use of the xconnect, pseudowire-class, and l2tp-class command syntax and configuration modes.

xconnect Command Syntax

In the case of Ethernet transport, L2TPv3 supports two types of attachment circuits, as described in the previous section:

Port tunneling on Ethernet interface

VLAN tunneling on Ethernet VLAN subinterface

The xconnect command that is configured under these interface types locally binds the attachment circuit to the pseudowire session and employs the following syntax:

xconnect peer-ip-address vcid pseudowire-parameters [sequencing
{transmit  receive  both}]

The following list explains the arguments in the syntax:

Chapter 10, you can configure L2TPv3 in three modes:

Manual mode Manual mode requires all session characteristics to be configured on each end of the L2TPv3 endpoint. In this setting, the attachment circuit state cannot be signaled to the remote end, and reachability to the remote L2TPv3 endpoint is not monitored.

Manual mode with keepalive Manual mode with keepalive operates in the same manner as manual mode but enables a simple peer keepalive mechanism for dead peer detection.

Dynamic mode Dynamic mode utilizes the control channel for peer capability and pseudowire session negotiation so that manual preconfiguration is unnecessary.

Because of these variations, the xconnect syntax must handle both manually defined and dynamically negotiated sessions. As described earlier, the pseudowire-parameters field is merely a placeholder for an expanded set of command options. pseudowire-parameters takes the following form:

encapsulation {l2tpv3 [manual]  mpls} pw-class
{pseudowire-class-name}

The following list explains the syntax:

encapsulation {l2tpv3 [manual] | mpls} The encapsulation command defines the tunneling method used. The manual keyword indicates that session negotiation is nonexistent. Configuring the session into manual mode forces the user into a config-if-xconn configuration submode for manual definition of session parameters, such as session cookies and session IDs. The case studies in this chapter discuss the various modes in more detail.

pw-class {pseudowire-class-name} The pw-class option references a pseudowire-class template that defines whether a control channel is used in addition to other shared session characteristics, which are explored later in this section. The pw-class command is a mandatory argument when L2TPv3 manual mode is selected as the encapsulation method.

sequencing {transmit | receive | both} The sequencing syntax is an optional argument that is used primarily when configuring L2TPv3 in manual mode. The transmit and receive options configure sequencing of L2TPv3 data packets sent and received over the pseudowire, respectively. Selecting both enables transmit and receive sequencing. Packets received from the pseudowire session that are considered out of order are dropped.

pseudowire-class Command Syntax

The pseudowire-class command defines a named template containing a series of session characteristics. The pseudowire adopts these session characteristics when the xconnect pw-class pseudowire-class-name argument refers to the respective template. The syntax has the following format:

pseudowire-class [ pseudowire-class-name]

pseudowire-class-name is a locally significant, unique identifier of the template. When you enter this argument, the CLI enters into config-pw-class configuration submode, and the following options are available:

Chapter 13, "Advanced L2TPv3 Case Studies."

ip tos {value value | reflect} When enabled, the ip tos option uses the configured type of service (ToS) value in the IP header of the L2TPv3 packet. If the payload of the Layer 2 frame is IP, the reflect option reflects the ToS value that is stored in the inner IP header to the outer IP header. If ip tos value and ip tos reflect are configured simultaneously, the configured ToS value is used on the outer IP header when the Layer 2 frame payload is not IP, while reflection would occur when the payload is IP.

ip ttl value The IP Time to Live (TTL) of the outer IP packet is configured with the defined TTL value that is configured in this command.

ip protocol {l2tp | uti} To allow for interoperability with Universal Transport Interface (UTI), you can adjust the IP protocol field to identify the IP packet as either L2TPv3 using IP protocol 115 or UTI using IP protocol 120.

Note

It is highly recommended as a best practice that every xconnect command reference a pseudowire-class template so that the source address of the L2TPv3 packets is defined to a virtual interface, such as a loopback interface. If you do not define a source address using the ip local interface command, the source address is not deterministic; it uses the PE's egress interface address that is closest to the destination, which might change depending on the network topology.

l2tp-class Command Syntax

Similar to the pseudowire-class command, which acts as a template of pseudowire session characteristics, the l2tp-class command defines a named template containing a series of control channel characteristics, such as control channel authentication and hidden AVPs. You can reference the l2tp-class command in the pseudowire-class definition via the protocol l2tpv3 syntax for dynamic session negotiation or via the config-if-xconn configuration submode when defining a manual L2TPv3 session with keepalive support. This chapter examines the latter case in more detail in "Case Study 11-2: Ethernet Port-to-Port Manual Session with Keepalive" and "Case Study 11-3: Ethernet Port-to-Port Dynamic Session." The following syntax is used when defining the l2tp-class:

l2tp-class [ l2tp-class-name]

l2tp-class-name is the locally unique name for this template. Configuring this places the user in a config-l2tp-class configuration submode. When the user is in this mode, several control channel parameters are available, falling into four categories, as follows:

Local cookie size

Control channel timing

Control channel authentication and integrity checking

Control channel maintenance

The optional L2TPv3 local cookie size contains a single command and has the following form:

cookie size [4 | 8] [size] The cookie size defines the size of the locally unique cookie for each dynamically negotiated pseudowire session that shares this l2tp-class template. Only two options are offered: a 4- or 8-byte cookie value. The default assumes a 0-byte cookie (that is, no local cookie is defined). As such, the local peer does not pass a Cookie AVP to the remote peer.

L2TPv3 control channel timing parameters include the following options:

receive-window [size] The L2TPv3 control channel utilizes a sliding window implementation using Ns, the sequence number found in the L2TPv3 control message that was sent, and Nr, the sequence number expected in the next L2TPv3 control message to be received. The receive window value determines the number of outstanding messages that the remote device can send before receiving an acknowledgement from the local device.

retransmit {initial retries initial-retries | retries retries | timeout {max | min} timeout} The retransmit retries retries interval defines the number of retransmission attempts before declaring the remote end as unresponsive. More specifically, initial retries initial-retries defines the number of Start-Control-Connection Request (SCCRQ) attempts made when trying to initialize the control channel. The first retransmission is sent at the timeout min timeout value after the first unacknowledged request. The time between each subsequent retransmission increases exponentially until it reaches the value specified in the timeout max timeout configuration.

timeout setup [seconds] This specifies the maximum amount of time permitted to set up the control channel.

L2TPv3 control channel authentication and integrity checking parameters implement two forms of control channel authentication. The old implementation utilized a simple Challenge Handshake Authentication Protocol (CHAP) mechanism borrowed from L2TPv2, which utilizes challenge and challenge response messages for peer authentication. Cisco later extended L2TPv3 to implement a new authentication method that utilizes a control message hash. This new authentication system follows the method described in Chapter 10's "L2TPv3 Control Channel Signaling" section. One advantage of the new authentication mechanism is that this feature performs the cryptographic hash against the entire L2TPv3 control message, whereas the old mechanism performed the hash only against specific AVPs. Another benefit is that the control message hashing feature includes the resultant hash output referred to as the message digest in all L2TPv3 control messages. The old mechanism only exchanged challenge and challenge responses against SCCRQ and Start-Control-Connection Reply (SCCRP) messages.

The L2TPv3 control connection authentication and integrity checking parameters contain the following options:

authentication This option enables the old CHAP-like lightweight control channel authentication between peers.

hostname [host name] The hostname option explicitly defines the host name to identify the local device in the old CHAP-like control channel authentication. If you do not explicitly use the hostname command, the host name of the router is used.

password {encryption-type}[password] The password definition establishes the predefined shared secret between peers used in the old CHAP-like control channel authentication mechanism. This value along with several other fields is hashed, and the resultant value is passed to the peer for control message authentication. If this value is not specified, the password value is taken from the globally configured username [username] password [password] value, where username is the host name of the local device.

digest [secret [0 | 7] password] [hash {md5 | sha}] The digest secret defines the shared secret and hashing mechanism used in the new control message hashing authentication mechanism. The [0 | 7] input type option defines the format of the password that is defined. A 0 indicates that the subsequent password is entered in plaintext, whereas a 7 indicates that the password is encrypted. The hash {md5 | sha} option defines the hashing mechanism that calculates the message digest. The default assumes a 0 input type option and hash md5. Both peers should use the same shared digest secret and hashing mechanism for the control message.

digest check The digest check enables validation of the contained message digest. By default, this option is enabled. You can disable it only when digest secret is not configured to obtain a slight performance improvement by obviating the checking for a message digest.

hidden When you define the hidden keyword in a l2tp-class, AVPs are encoded to hide sensitive information. If the hidden keyword is not configured, AVPs are sent in the clear. The Cookie AVP that protects against blind insertion attacks is an example of an AVP that would be hidden when the hidden keyword is configured along with a digest secret command. The length of the hidden AVP is different from the original AVP because of potential padding and additional overhead in the process of hiding the AVP.

Note

When you use a digest secret option, you perform control connection authentication of the remote peer. In this case, the message digest is calculated against the L2TPv3 control message content along with the configured digest secret password and the local and remote Control Message Authentication Nonce.

However, you can configure the digest keyword by itself to simply perform a control connection integrity check. In this scenario, the message digest is calculated against the L2TPv3 control message content and provides a unidirectional integrity check.

L2TPv3 control channel maintenance parameters involve the following option:

hello [interval] The hello interval defines the interval in seconds between Hello messages after the control channel is initialized. The hello mechanism provides a simple dead peer detection mechanism and defaults to 60 seconds if it is not configured explicitly.