Layer Two Tunneling Protocol "L2TP" Management Information Base
Extracted elements (29)
At the LNS, L2TP tunnel interfaces are not at the top of the ifStack because PPP interfaces are layered on top; at the LAC, tunnel interfaces appear at the top of the stack. This asymmetry reflects the role difference: LNS terminates PPP sessions while LAC originates them.
Future L2TP transports (e.g., Frame Relay) are expected to create their own branch under l2tpTransports rather than extending the UDP/IP objects. This forward-compatible OID structure isolates transport-specific state and statistics from the transport-independent tunnel objects.
The l2tpSessionMapTable exists because the LAC cannot use ifStackTable to express the binding between a physical PPP-terminating interface and the L2TP tunnel session carrying that PPP link. The explicit mapping table compensates for this architectural limitation.
A MIB conforming to SMIv1 can be produced from this SMIv2 MIB by translation, except that Counter64 objects must be omitted since SMIv1 has no equivalent. Machine-readable SMIv2 annotations become textual descriptions in SMIv1 but this is not considered a semantic change.
Creating a tunnelIfEntry in the IP Tunnel MIB (RFC 2667) with encapsulation method 'l2tp' automatically creates entries in l2tpTunnelConfigTable, l2tpTunnelStatsTable, and l2tpUdpStatsTable. L2TP tunnel creation for non-IP transports is defined in the transport-specific MIB.
For L2TP tunnel interfaces, ifTable.ifType must be tunnel(131), ifTable.ifMtu for UDP/IP transport should be 65467 (65535−60 for IP−8 for UDP), ifTable.ifPhyAddress returns the assigned tunnel identifier, and ifTable.ifSpeed returns zero.
All Interface MIB objects not listed in the ifGeneralInformationGroup tables for L2TP tunnel interfaces MUST be supported as described in RFC 2863. Implementations must support ifGeneralInformationGroup and one of ifPacketGroup, ifHCPacketGroup, or ifVHCPacketGroup.
Implementation of the IP Tunnel MIB (RFC 2667) is required for L2TP tunnels over IP. The L2TP MIB extends the IP Tunnel MIB with encapsulation-specific objects.
The l2tpConfigGroup and l2tpStatsGroup are mandatory for all implementors of this MIB. These groups provide configuration, state, and statistics for the L2TP protocol, its tunnels, and sessions.
The l2tpDomainConfigSecret object MUST be accessible only via SNMP requests using both authentication and privacy. The agent MUST report an empty string in response to get, get-next, and get-bulk requests.
The l2tpIpUdpGroup is mandatory for L2TP implementations that support L2TP over UDP/IP. It provides state and statistics information specific to that transport.
The l2tpTunnelConfigSecret object MUST be accessible only via requests using both authentication and privacy. The agent MUST report an empty string in response to get, get-next, and get-bulk requests to prevent exposure of the shared secret.
l2tpAdminState controls the administrative state of the entire L2TP protocol stack. Setting it to disabled(2) immediately disconnects all tunnels and prevents new tunnels from being initiated or accepted. Its value must be maintained in non-volatile memory.
l2tpDomainConfigAuth configures tunnel peer authentication for a domain: none(1) disables it, simple(2) authenticates by Host Name AVP only, and challenge(3) requires peers to prove identification via the L2TP challenge mechanism (RFC 2661 Section 5.1).
l2tpDomainConfigReassemblyTO (default 0 ms) defines how long local peers wait before processing out-of-sequence payload packets. Zero causes all delayed packets to be lost; high values may queue packets and degrade throughput if packets are truly lost.
l2tpDomainConfigTable provides per-domain tunnel configuration including authentication mode (none/simple/challenge), shared secret, IPsec security requirements, hello interval, idle timeout, control receive window size, max retransmissions, and payload sequencing policy.
l2tpDrainTunnels enables graceful shutdown by preventing new tunnels and sessions while keeping active ones alive. Setting to true(1) transitions all domains and tunnels to the draining state; the value must be maintained in non-volatile memory.
l2tpProtocolVersions is an OCTET STRING (SIZE 2..256) encoding a vector of supported L2TP protocol version/revision pairs. Each supported version occupies two octets: the first is the version number and the second is the revision number.
l2tpSessionMapTable allows management applications to map a PPP or DS0 interface to a specific L2TP tunnel session. On the LAC it also maps physical or virtual PPP-terminating interfaces to tunnels, compensating for the inability to use ifStackTable at the LAC.
l2tpTunnelConfigControlRWS (default 4, range 1..65535) defines the control channel receive window size — the maximum number of packets the tunnel peer can send without waiting for acknowledgement. Cannot be modified when the tunnel is connecting or connected.
l2tpTunnelConfigSecurity specifies whether tunnel packets must carry IPsec headers (ipsec(3)), covering both control and session packets. The type of IPsec headers (AH, ESP, etc.) is outside scope. Cannot be modified when the tunnel is connecting or connected.
l2tpTunnelConfigTable provides per-tunnel configuration mirroring domain-level defaults, indexed by ifIndex. Entries are created as a side effect of instantiating a tunnelConfigTable row with encapsulation method 'l2tp' in RFC 2667.
l2tpTunnelStatsRemoteProtocolVer is a 2-octet OCTET STRING where the first octet encodes the remote peer's L2TP protocol version and the second encodes the protocol revision, as negotiated during tunnel establishment.
l2tpTunnelStatsTable augments l2tpTunnelConfigTable with read-only per-tunnel statistics including local/remote TIDs, remote peer identity (hostname, vendor, firmware, protocol version), control channel sequence numbers (TxSeq, TxSeqAck, RxSeq, RxSeqAck), ZLB counts, out-of-sequence/window counters, and last result/error codes.
The L2TP MIB module is assigned OID { transmission 95 } and defines the following major branches: l2tpNotifications (l2tp 0), l2tpObjects (l2tp 1), l2tpTransports (l2tp 3), and l2tpConformance (l2tp 4).
The l2tpHCPacketGroup provides 64-bit (Counter64) versions of all 32-bit domain-level statistics counters. It is optional but recommended for implementations where 32-bit counters could overflow in under an hour.
Shared secret objects (l2tpDomainConfigSecret, l2tpTunnelConfigSecret) must only be accessible via SNMP messages with both authentication and privacy enabled, and agents must return an empty string to read requests to prevent key disclosure over the network.
The l2tpSecurityGroup is optional for SNMP agents that support both authentication and privacy of SNMP messages for management of L2TP keys. SNMPv3 with auth+priv is the intended mechanism for securing access to sensitive L2TP keying material.
L2TP tunnel control state machine as exposed by l2tpTunnelStatsState: tunnelIdle(1) → tunnelConnecting(2) → tunnelEstablished(3) → tunnelDisconnecting(4). Setting ifAdminStatus to 'up' injects a 'Local Open' request and 'down' injects a 'Tunnel Close' event into the tunnel FSM.