RFC 3371
Layer Two Tunneling Protocol "L2TP" Management Information Base
RFC 3371: Layer Two Tunneling Protocol "L2TP" Management Information Base 🎀
okay bestie, this is RFC 3371, a Standards Track doc from the Network Working Group, published August 2002. 🦋 It's one of the MIB specs for L2TP, so it defines the managed objects you use to keep an eye on L2TP devices. The title block lists Network Working Group as the group, Standards Track as the category, and "Request for Comments: 3371" as the number. It doesn't list anything it obsoletes or updates, so no drama there. ✨
The authors are E. Caves (Occam Networks), P. Calhoun (Black Storm Networks), and R. Wheeler (DoubleWide Software). The three of them made this together. 💜
Status of this Memo 📜
So this doc is a real Internet standards track protocol for the Internet community, and it's basically inviting everyone to talk about it and suggest improvements. 🫶 For the official standardization state and status, check the current edition of the "Internet Official Protocol Standards" (STD 1). And the distribution is unlimited, so anyone can read it. 🌈
Copyright Notice ©️
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract 🌸
This memo defines part of the Management Information Base (MIB) for network management protocols in TCP/IP-based internets. Specifically, it gives you objects for managing networks that use Layer 2 Tunneling Protocol (L2TP). It's giving "here's your toolkit" energy. 💅
Table of Contents 🗂️
1.0 Introduction .......................................... 2
2.0 The SNMP Management Framework ........................... 2
3.0 Overview ................................................ 4
3.1 Relationship to the Interface MIB........................ 5
3.1.1 Layering Model .......................................... 5
3.1.2 Interface MIB Object..................................... 7
3.1.2.1 L2TP Tunnel Interfaces .................................. 7
3.2 Relationship to other MIBs .............................. 10
3.2.1 Relationship to the IP Tunnel MIB ....................... 10
3.3 L2TP Tunnel Creation .................................... 10
3.4 L2TP Session Mapping .................................... 10
4.0 L2TP Object Definitions ................................. 11
5.0 Security Considerations ................................. 66
6.0 Acknowledgements ........................................ 67
7.0 References .............................................. 67
8.0 Authors' Addresses ...................................... 69
9.0 Full Copyright Statement ................................ 701.0 Introduction 🎀
Okay so this memo defines part of the MIB for network management protocols in the Internet Community. The main point is that it describes managed objects for managing L2TP devices. Super useful, no notes. ✨
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Those are the capitalised words you need to read carefully, bestie. 🧐
2.0 The SNMP Management Framework 🧚
The SNMP Management Framework is made of five major components. Here's the lineup. 💖
- An overall architecture, described in RFC 2571 [RFC2571].
- Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and is described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].
- Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and is described in STD 15, RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and is described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and is described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574].
- Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905].
- A set of fundamental applications described in RFC 2573 [RFC2573], and the view-based access control mechanism described in RFC 2575 [RFC2575].
If you want a more detailed intro to the current SNMP Management Framework, check out RFC 2570 [RFC2570]. 📚
Managed objects are accessed through a virtual information store called the Management Information Base, or MIB. The objects in the MIB are defined using the mechanisms in the SMI. It's all connected, bestie. 🕸️
This memo specifies a MIB module that is compliant to SMIv2. A MIB conforming to SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine-readable information in SMIv2 will be converted into textual descriptions in SMIv1 during translation. However, losing that machine-readable information is not considered to change the semantics of the MIB. Not a big deal, lowkey. 🙈
3.0 Overview 🦋
The objects defined in this MIB are used when you're describing Layer Two Tunneling Protocol (L2TP) tunnels. The L2TP protocol itself is defined in [RFC2661]. This MIB has seven groups, which are briefly described below. 🌈
l2tpConfigGroupandl2tpStatsGroup: These two groups provide information on the configuration, state and statistics of the L2TP protocol, its tunnels and its sessions. They are mandatory for implementors of this MIB. Non-negotiable, bestie. 💅l2tpDomainGroup: This optional group provides configuration, state and statistical information for L2TP tunnel endpoint domains. An L2TP tunnel endpoint domain is considered to be a collection of L2TP devices, typically belonging to a common administrative domain or geographic location.l2tpMappingGroup: This optional group contains mapping tables that help management applications map between protocol identifiers and table indices.l2tpIpUdpGroup: This group provides the state and statistics information for L2TP tunnels that are being transported by UDP/IP. It is mandatory for L2TP implementations that support L2TP over UDP/IP.l2tpSecurityGroup: This group is optional for SNMP agents that support both authentication and privacy of SNMP messages for the management of L2TP keys.l2tpTrapGroup: This group contains the notifications that could be generated by an L2TP implementation.l2tpHCPacketGroup: This group is optional for L2TP implementations that could potentially overflow the L2TP Domain tables' 32-bit statistics counters in less than an hour. Speed demon energy. 🔥
3.1 Relationship to the Interface MIB 🔗
This section explains how this MIB relates to the Interfaces MIB [RFC2863]. Several areas of correlation are covered in the subsections that follow. If you want the general intent behind these areas, the implementor should go read the Interfaces MIB document. 📖
3.1.1 Layering Model 🍰
This MIB contains several tables that extend the IP Tunnel MIB described in [RFC2667], which itself extends the Interface MIB [RFC2863]. An L2TP tunnel is represented as its own identifiable logical interface sub-layer. The tunnel stack layering model is described in [RFC2667]. 🧁
On top of what [RFC2667] describes, an L2TP tunnel will not be at the top of the ifStack on an L2TP device that is acting as an L2TP Network Server (LNS). In this case, PPP interfaces are layered on top of the tunnel interface. Little bit of a twist, but it's cute. ✨
The example diagram below shows how the interface layering looks at the LNS. 🖼️
+--------------------------------------------+
| Network Layer Protocol |
+-+-----------+-------------+--------+-------+
| | | |
| +-+--+ | |
| |MPPP| | | <=== PPP Multilink I/F
| ++--++ | |
| | | | |
| +--+ +--+ | |
| | | | |
| +-+-+ +-+-+ +-+-+ +-+-+
| |PPP| |PPP| |PPP| |PPP| <=== PPP I/F
| +-+-+ +-+-+ +-+-+ +-+-+
| | | | |
| +----+--------+--------+--------+----+
| | L2TP Tunnel I/F |
| +------------------+-----------------+
| |
+-+---------------------+------+
| Ethernet |
+------------------------------+The ifStackTable describes how the interface sub-layers are stacked. For the example above, the ifTable and ifStackTable might look like this. 💕
ifIndex ifType Tunnel MIB tables Description
1 ethernetCsmacd(6) Ethernet interface
2 tunnel(131) tunnelIfTable Tunnel interface
l2tpTunnelConfigTable
l2tpTunnelStatsTable
3 ppp(23) PPP interface #1
4 ppp(23) PPP interface #2
5 ppp(23) PPP interface #3
6 ppp(23) PPP interface #4
7 mlppp(108) MLPPP interfaceThe matching ifStackTable entries would then be:
ifStackTable Entries
HigherLayer LowerLayer
0 5
0 6
0 7
1 0
2 1
3 2
4 2
5 2
6 2
7 3
7 4L2TP Access Concentrator (LAC) tunnel interfaces, on the other hand, appear at the top of the interface layering stack. In that case the layering model is as described in [RFC2667]. 🧠
But here's the plot twist: to support tunneling packets received from interfaces that carry framed PPP packets on the LAC over to the LNS (and passing decapsulated PPP packets back to that interface), extra configuration is required. That's covered in section 3.4. Stay tuned. 👀
3.1.2 Interface MIB Objects 📋
Except where noted in the tables below, all objects MUST be supported from the ifGeneralInformationGroup and from one of the following three groups:
- ifPacketGroup OR
- ifHCPacketGroup OR
- ifVHCPacketGroup
Which one depends on the particular implementation. Pick your fighter, bestie. ⚔️
The following tables describe how objects from the ifGeneralInformationGroup and ifPacketGroup should be interpreted and supported for L2TP tunnel interfaces. Similar support should be provided for the high and very high capacity packet groups. 🫧
To be continued... 🩷
3.1.2.1 L2TP Tunnel Interfaces ✨
okay so bestie, every Interface MIB object that ISN'T listed in the groups above for L2TP tunnel interfaces MUST be supported the way [RFC2863] describes it 🫶 no skipping!! the table below is basically the cheat sheet for what each object should return or do 💅
Interface MIB Object Support Description
==================== ========================================
ifTable.ifDescr Refer to the Interface MIB.
ifTable.ifType tunnel(131).
ifTable.ifMtu Dependent on the tunnel transport layer.
For UDP/IP transports the MTU should
be 65467 (65535-60(IP)-8(UDP)).
ifTable.ifSpeed Return zero.
ifTable.ifPhyAddress The assigned tunnel identifier.
ifTable.ifAdminStatus Setting ifAdminStatus to 'up' injects a
'Local Open' request into the tunnel FSM.
Setting ifAdminStatus to 'down' injects
a 'Tunnel Close' event into the tunnel
FSM. Setting ifAdminStatus to 'testing'
is not currently defined but could be
used to test tunnel connectivity.
ifTable.ifOperStatus ifOperStatus values are to be interpreted
as follows:
'up' - tunnel is established.
'down' - administratively down
or peer unreachable.
'testing' - in some test mode.
'unknown' - status cannot be
determined for some
reason.
'dormant' - operational but
waiting for local or
remote trigger to bring
up the tunnel.
'notPresent' - configuration missing.
'lowerLayerDown' - down due to state of
lower-layer
interface(s).
ifTable.ifInOctets The total number of octets received on the
tunnel including control and payload
octets.
ifTable.ifInUcastPkts The total number of packets received on
the tunnel including control and payload
packets.
ifTable.ifInDiscards The total number of received packets that
were discarded on both control and payload
channels.
ifTable.ifInErrors The total number of packets received in
error including control and payload
packets.
ifTable.ifInUnknownProtos
Return zero.
ifTable.ifOutOctets The total number of octets transmitted
from the tunnel including control and
payload octets.
ifTable.ifOutUcastPkts The total number of packets transmitted
from the tunnel including control and
payload packets.
ifTable.ifOutDiscards The total number of discarded packets that
were requested to be transmitted including
control and payload packets.
ifTable.ifOutErrors The total number of packets that were
requested to be transmitted that were in
error including control and payload
packets.
ifXTable.ifName Refer to the Interface MIB.
ifXTable.ifInMulticastPkts
Return zero.
ifXTable.ifInBroadcastPkts
Return zero.
ifXTable.ifOutMulticastPkts
Return zero.
ifXTable.ifOutBroadcastPkts
Return zero.
ifXTable.ifOutBroadcastPkts
Return zero.
ifXTable.ifLinkUpDownTrapEnable
Default set to enabled(1).
ifXTable.ifHighSpeed Return zero.
ifXTable.ifPromiscuousMode
Set to false(2).
ifXTable.ifConnectorPresent
Set to false(2).3.2. Relationship to other MIBs 🦋
3.2.1. Relationship to the IP Tunnel MIB 🎀
the IP Tunnel MIB [RFC2667] is all about tunnel interfaces with an ifType of tunnel(131) 🌸 it's basically a shared bucket of objects that every IP tunneling protocol can use, L2TP included. tunnel encapsulation specific MIBs (like this one!) extend the IP Tunnel MIB to add the extra details that are specific to their own encapsulation 💜 so it's like a base layer plus custom add-ons, iykyk 🧚
and the big one: implementing the IP Tunnel MIB is required for L2TP tunnels over IP ✨
3.3. L2TP Tunnel Creation 🌈
tunnel creation for tunnels over IP is detailed in the IP Tunnel MIB, so go check there 👀 when a tunnelIfEntry gets created in [RFC2667] with the encapsulation method set to "l2tp", it has the side effect of also creating entries in the l2tpTunnelConfigTable, l2tpTunnelStatsTable, and the l2tpUdpStatsTable's. it's giving domino effect 🍓
for L2TP tunnel interfaces over transports that aren't IP, the creation is expected to be defined in the MIB definition for that specific L2TP tunnel transport 🫶
3.4. L2TP Session Mapping 💖
the l2tpSessionMapTable is the table that lets management apps figure out which session inside a tunnel a given interface (a PPP or DS0 interface) is mapped to 🔥 on the LAC, it also lets an app map a particular physical or virtual interface that terminates a PPP link onto a particular L2TP tunnel 💅 this is needed because the interface stacking that happens on the LNS (and gets tracked in the ifStackTable) can't be applied at the LAC, so it's lowkey essential 😭
here's the conceptual binding, visualized:
+---------------------------------------+
| L2TP Session Map Database |
+----------+-----------------+----------+
| |
+---+---+ +-----+------+
| ds0 | | Tunnel I/F |
+---+---+ +-----+------+
| |
+---+---+ +-----+------+
| ds1 | | Ethernet |
+-------+ +------------+the stacking of the individual interface stacks would be described by the ifStackTable 🧚
4.0 L2TP Object Definitions 👑
L2TP-MIB DEFINITIONS ::= BEGIN
IMPORTS
Integer32, Unsigned32, Counter32, Gauge32,
Counter64, transmission, MODULE-IDENTITY,
OBJECT-TYPE, NOTIFICATION-TYPE
FROM SNMPv2-SMI
TEXTUAL-CONVENTION, RowStatus, TruthValue,
StorageType
FROM SNMPv2-TC
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB
OBJECT-GROUP, MODULE-COMPLIANCE, NOTIFICATION-GROUP
FROM SNMPv2-CONF
InterfaceIndex
FROM IF-MIB;
l2tp MODULE-IDENTITY
LAST-UPDATED "200208230000Z" -- 23 August 2002
ORGANIZATION "IETF L2TP Working Group"
CONTACT-INFO
"Evan Caves
Postal: Occam Networks
77 Robin Hill Road
Santa Barbara, CA, 93117
Tel: +1 805692 2900
Email: evan@occamnetworks.com
Pat R. Calhoun
Postal: Black Storm Networks
110 Nortech Parkway
San Jose, CA, 95143
Tel: +1 408 941-0500
Email: pcalhoun@bstormnetworks.com
Ross Wheeler
Postal: DoubleWide Software, Inc.
2953 Bunker Hill Lane
Suite 101
Santa Clara, CA 95054
Tel: +1 6509260599
Email: ross@doublewidesoft.com
Layer Two Tunneling Protocol Extensions WG
Working Group Area: Internet
Working Group Name: l2tpext
General Discussion: l2tp@l2tp.net"
DESCRIPTION
"The MIB module that describes managed objects of
general use by the Layer Two Transport Protocol."
-- revision log
REVISION "200208230000Z" -- 23 August 2002
DESCRIPTION
"First revision, published as RFC 3371."
::= { transmission 95 }
--
-- Textual Conventions
--
L2tpMilliSeconds ::= TEXTUAL-CONVENTION
DISPLAY-HINT "d-3"
STATUS current
DESCRIPTION
"A period of time measured in units of .001 of seconds
when used in conjunction with the DISPLAY-HINT will
show seconds and fractions of second with a resolution
of .001 of a second."
SYNTAX Integer32 (0..2147483646)
--
-- Definitions of significant branches
--
l2tpNotifications OBJECT IDENTIFIER ::= { l2tp 0 }
l2tpObjects OBJECT IDENTIFIER ::= { l2tp 1 }
l2tpTransports OBJECT IDENTIFIER ::= { l2tp 3 }
l2tpConformance OBJECT IDENTIFIER ::= { l2tp 4 }
--
-- Definitions of significant branches under l2tpObjects
--
l2tpScalar OBJECT IDENTIFIER ::= { l2tpObjects 1 }
l2tpConfig OBJECT IDENTIFIER ::= { l2tpScalar 1 }
l2tpStats OBJECT IDENTIFIER ::= { l2tpScalar 2 }
--
-- Definitions of significant branches under l2tpTransports
--
-- Note that future transports of L2TP (e.g.: Frame relay)
-- should create their own branch under l2tpTransports.
l2tpTransportIpUdp OBJECT IDENTIFIER ::= { l2tpTransports 1 }
l2tpIpUdpObjects OBJECT IDENTIFIER ::= { l2tpTransportIpUdp 1 }
l2tpIpUdpTraps OBJECT IDENTIFIER ::= { l2tpTransportIpUdp 2 }
--
-- The L2TP Scalar Configuration Group
--
-- This group of objects is used to manage configuration
-- of the L2TP protocol environment.
l2tpAdminState OBJECT-TYPE
SYNTAX INTEGER {
enabled(1),
disabled(2)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object defines the administrative state of
the L2TP protocol. Setting this object to
'disabled' causes all tunnels to be immediately
disconnected and no further tunnels to be either
initiated or accepted. The value of this object
must be maintained in non-volatile memory."
::= { l2tpConfig 1 }okay so this is where the big stuff lives 💅 l2tpDrainTunnels is basically the main "pause everything" switch, and the description has the whole vibe of "don't take new calls but keep the ones already happening" 📞🫶
l2tpDrainTunnels OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Setting this object to 'true' will prevent any new
tunnels and/or sessions to be either initiated or
accepted but does NOT disconnect any active
tunnels/sessions. Setting this object to true(1)
causes all domains and their respective tunnels
to transition to the draining state. Note that
when this occurs the 'xxxDraining' status objects
of the domains and their tunnels should reflect
that they are 'draining'. Setting this object has
no affect on the domains or their tunnels
'xxxDrainTunnels' configuration objects. To cancel
a drain this object should be set to false(2).
The object l2tpDrainingTunnels reflects
the current L2TP draining state. The value of
this object must be maintained in non-volatile
memory."
::= { l2tpConfig 2 }
--
-- The L2TP Scalar Status and Statistics Group
--
-- This group of objects describe the current state and
-- statistics of L2TP.
l2tpProtocolVersions OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(2..256))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Vector of supported L2TP protocol version and
revision numbers. Supported versions are identified
via a two octet pairing where the first octet indicates
the version and the second octet contains the revision."
::= { l2tpStats 1 }
l2tpVendorName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object identifies the Vendor name of the L2TP
protocol stack."
::= { l2tpStats 2 }
l2tpFirmwareRev OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object defines the firmware revision for the
L2TP protocol stack."
::= { l2tpStats 3 }
l2tpDrainingTunnels OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates if the local L2TP is draining
off sessions from all tunnels."
::= { l2tpStats 4 }
--
-- The L2TP Domain Configuration Table
--
l2tpDomainConfigTable OBJECT-TYPE
SYNTAX SEQUENCE OF L2tpDomainConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The L2TP Domain configuration table. This table
contains objects that can be used to configure
the operational characteristics of a tunnel
domain. There is a 1-1 correspondence between
conceptual rows of this table and conceptual
rows of the l2tpDomainStatsTable."
::= { l2tpObjects 2 }
l2tpDomainConfigEntry OBJECT-TYPE
SYNTAX L2tpDomainConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An L2TP Domain configuration entry. An entry in this
table may correspond to a single endpoint or a group
of tunnel endpoints."
INDEX { l2tpDomainConfigId }
::= { l2tpDomainConfigTable 1 }
L2tpDomainConfigEntry ::=
SEQUENCE {
l2tpDomainConfigId
SnmpAdminString,
l2tpDomainConfigAdminState
INTEGER,
l2tpDomainConfigDrainTunnels
TruthValue,
l2tpDomainConfigAuth
INTEGER,
l2tpDomainConfigSecret
SnmpAdminString,
l2tpDomainConfigTunnelSecurity
INTEGER,
l2tpDomainConfigTunnelHelloInt
Integer32,
l2tpDomainConfigTunnelIdleTO
Integer32,
l2tpDomainConfigControlRWS
Integer32,
l2tpDomainConfigControlMaxRetx
Integer32,
l2tpDomainConfigControlMaxRetxTO
Integer32,
l2tpDomainConfigPayloadSeq
INTEGER,
l2tpDomainConfigReassemblyTO
L2tpMilliSeconds,
l2tpDomainConfigProxyPPPAuth
TruthValue,
l2tpDomainConfigStorageType
StorageType,
l2tpDomainConfigStatus
RowStatus
}
l2tpDomainConfigId OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (1..80))
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The identifier, usually in the form of a Domain
Name (full or partial), describing a single tunnel
endpoint or a domain of tunnel endpoints. This is
typically used as a 'handle' to identify the
tunnel configuration requirements for both incoming
and outgoing tunnel connection attempts. Both the
LAC and LNS could use information provided in the
Host Name AVP attribute however the tunnel initiator
could use other means not specified to identify
the domain's tunnel configuration requirements.
For example; three rows in this table have
l2tpDomainConfigId values of 'lac1.isp.com',
'isp.com' and 'com'. A tunnel endpoint then identifies
itself as 'lac1.isp.com' which would match the
'lac1.isp.com' entry in this table. A second tunnel
endpoint then identifies itself as 'lac2.isp.com'.
This endpoint is then associated with the 'isp.com'
entry of this table."
::= { l2tpDomainConfigEntry 1 }
l2tpDomainConfigAdminState OBJECT-TYPE
SYNTAX INTEGER {
enabled(1),
disabled(2)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object defines the administrative state of this
tunnel domain. Setting this object to disabled(2)
causes all tunnels to be immediately disconnected
and no further tunnels to be either initiated or
accepted. Note that all columnar objects corresponding
to this conceptual row cannot be modified when
the administrative state is enabled EXCEPT those
objects which specifically state otherwise."
DEFVAL { enabled }
::= { l2tpDomainConfigEntry 2 }
l2tpDomainConfigDrainTunnels OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Setting this object to 'true' will prevent any new
tunnels and/or sessions from being either initiated
or accepted but does NOT disconnect any active
tunnels/sessions for this tunnel domain. Setting
this object to true(1) causes all tunnels within
this domain to transition to the draining state.
Note that when this occurs the
l2tpTunnelStatsDrainingTunnel status objects of
all of this domain's tunnels should reflect that
they are 'draining'. Setting this object has no
effect on this domain's associated tunnels
l2tpTunnelConfigDrainTunnel configuration objects.
To cancel a drain this object should be set to
false(2). Setting this object to false(2) when
the L2TP object l2tpDrainTunnels is true(1) has
no affect, all domains and their tunnels will
continue to drain."
DEFVAL { false }
::= { l2tpDomainConfigEntry 3 }
l2tpDomainConfigAuth OBJECT-TYPE
SYNTAX INTEGER {
none(1),
simple(2),
challenge(3)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object describes how tunnel peers belonging
to this domain are to be authenticated. The value
simple(2) indicates that peers are authenticated
simply by their host name as described in the Host
Name AVP. The value challenge(3) indicates that
all peers are challenged to prove their identification.
This mechanism is described in the L2TP protocol."
REFERENCE "RFC 2661 Section 5.1"
DEFVAL { none }
::= { l2tpDomainConfigEntry 4 }
l2tpDomainConfigSecret OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (0..255))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object is used to configure the shared secret
used during the tunnel authentication phase of
tunnel establishment. This 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."
::= { l2tpDomainConfigEntry 5 }
l2tpDomainConfigTunnelSecurity OBJECT-TYPE
SYNTAX INTEGER {
none(1),
other(2),
ipSec(3)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object defines whether this tunnel domain
requires that all tunnels are to be secured. The
value of ipsec(3) indicates that all tunnel packets,
control and session, have IP Security headers. The
type of IP Security headers (AH, ESP etc) and how
they are further described is outside the scope of
this document."
DEFVAL { none }
::= { l2tpDomainConfigEntry 6 }
l2tpDomainConfigTunnelHelloInt OBJECT-TYPE
SYNTAX Integer32 (0..3600)
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object defines the interval in which Hello
(or keep-alive) packets are to be sent by local
peers belonging to this tunnel domain. The value
zero effectively disables the sending of Hello
packets. This object may be modified when the
administrative state is enabled for this conceptual
row."
DEFVAL { 60 }
::= { l2tpDomainConfigEntry 7 }ok the domain config table is where the real fun is 🎀 each row is basically its own little domain with its own settings, and the l2tpDomainConfigId is the name tag that matches who's calling in 📞
okay so the domain config table is about to get spicy 🎀 we're still in the knobs-and-dials zone, and bestie, the idle timeout is first 🌸
The idle timeout is how long an established tunnel hangs around with zero sessions before it disconnects. 0 means it drops the second the last session leaves, and -1 means it stays up forever 💅 You can only change it while the row's administrative state is enabled.
l2tpDomainConfigTunnelIdleTO OBJECT-TYPE
SYNTAX Integer32 (-1..86400)
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object defines the period of time that an
established tunnel belonging to this tunnel
domain with no active sessions will wait before
disconnecting the tunnel. A value of zero indicates
that the tunnel will disconnect immediately after the
last session disconnects. A value of -1 leaves the
tunnel up indefinitely. This object may be modified
when the administrative state is enabled for this
conceptual row."
DEFVAL { 0 }
::= { l2tpDomainConfigEntry 8 }Next up is the control channel receive window, which is basically how many packets the peer can fire off before it has to wait for an ACK 🦋 The default is 4, and it can go anywhere from 1 to 65535.
l2tpDomainConfigControlRWS OBJECT-TYPE
SYNTAX Integer32 (1..65535)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object defines the control channel receive
window size for tunnels belonging to this domain. It
specifies the maximum number of packets the tunnel
peer belonging to this domain can send without waiting
for an acknowledgement from this peer."
DEFVAL { 4 }
::= { l2tpDomainConfigEntry 9 }Retries are next 🍓 This one caps how many times the stack will retransmit before it decides the peer is ghosting, with a default of 5 and a range of 0 to 32.
l2tpDomainConfigControlMaxRetx OBJECT-TYPE
SYNTAX Integer32 (0..32)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object defines the maximum number of retransmissions
which the L2TP stack will attempt for tunnels belonging
to this domain before assuming that the peer is no
longer responding."
DEFVAL { 5 }
::= { l2tpDomainConfigEntry 10 }The retransmission timeout is the wait time between retries for unacknowledged control packets. It defaults to 16 seconds and ranges from 1 to 32 seconds 🧚
l2tpDomainConfigControlMaxRetxTO OBJECT-TYPE
SYNTAX Integer32 (1..32)
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object defines the maximum retransmission timeout
interval which the L2TP stack will wait for tunnels
belonging to this domain before retransmitting a
control packet that has not been acknowledged."
DEFVAL { 16 }
::= { l2tpDomainConfigEntry 11 }Now payload sequencing, which is giving three-option drama 👑 onDemand(1) lets the implementation turn sequencing on when it needs it, based on local info like LCP/NCP negotiation or CCP. never(2) means it never starts sequencing itself, but it will do it if asked. always(3) means the Sequencing Required AVP gets sent during session establishment. The default is onDemand.
l2tpDomainConfigPayloadSeq OBJECT-TYPE
SYNTAX INTEGER {
onDemand(1),
never(2),
always(3)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object determines whether or not session payload
packets will be requested to be sent with sequence
numbers from tunnel peers belonging to this domain.
The value onDemand(1) allows the L2TP implementation
to initiate payload sequencing when necessary based
on local information (e.g: during LCP/NCP negotiations
or for CCP). The value never(2) indicates that L2TP
will never initiate sequencing but will do sequencing
if asked. The value always(3) indicates that L2TP
will send the Sequencing Required AVP during session
establishment."
DEFVAL { onDemand }
::= { l2tpDomainConfigEntry 12 }Reassembly timeout is a little bit of a tightrope 🌈 It's how many milliseconds peers wait for out-of-sequence payload packets to fill their gaps. Set it low and you risk dropping delayed packets, which can make the PPP decompression engine reset. Set it high and you get more queuing, which can hurt throughput if packets are actually lost. The default is 0, and that means every delayed packet gets lost.
l2tpDomainConfigReassemblyTO OBJECT-TYPE
SYNTAX L2tpMilliSeconds
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object defines the number of milliseconds that
local peers of this tunnel domain will wait before
processing payload packets that were received out of
sequence (which are waiting for the packet(s) to put
them in sequence). A low value increases the chance
of delayed packets to be discarded (which MAY cause
the PPP decompression engine to reset) while a high
value may cause more queuing and possibly degrade
throughput if packets are truly lost. The default
value for this object is zero which will result in
all delayed packets being lost."
DEFVAL { 0 }
::= { l2tpDomainConfigEntry 13 }Proxy PPP auth is a simple on/off switch that controls whether the Proxy Authentication AVPs get sent or accepted on the LAC or LNS. It defaults to true ✨
l2tpDomainConfigProxyPPPAuth OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object is used to configure the sending
or acceptance of the PPP Proxy Authentication
AVP's on the LAC or LNS."
DEFVAL { true }
::= { l2tpDomainConfigEntry 14 }Storage type is where things get a little serious 😭 Rows marked permanent have to keep write access for at least l2tpDomainConfigAdminState and l2tpDomainConfigDrainTunnels, always. l2tpDomainConfigSecret also needs write access if l2tpDomainConfigAuth is set to challenge. Whether a SET on a readOnly or permanent row is accepted at all is up to the implementation. If it isn't accepted, the agent has to return a wrongValue error.
l2tpDomainConfigStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The storage type for this conceptual row.
Conceptual rows having the value 'permanent' must
allow write-access at a minimum to:
- l2tpDomainConfigAdminState and
l2tpDomainConfigDrainTunnels at all times
- l2tpDomainConfigSecret if l2tpDomainConfigAuth
has been configured as 'challenge'
It is an implementation issue to decide if a SET for
a readOnly or permanent row is accepted at all. In some
contexts this may make sense, in others it may not. If
a SET for a readOnly or permanent row is not accepted
at all, then a 'wrongValue' error must be returned."
::= { l2tpDomainConfigEntry 15 }And the RowStatus column is the on switch for the whole entry. Columnar objects can be changed, according to their own descriptions, when this one is active 💜
l2tpDomainConfigStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of this Domain entry. Columnar objects
corresponding to this conceptual row may be modified
according to their description clauses when this
RowStatus object is 'active'."
::= { l2tpDomainConfigEntry 16 }Okay bestie, now we're in the stats era 📊 This section is the L2TP Domain Status and Statistics table, and it's basically the scoreboard for each tunnel domain. Every row lines up one-to-one with a row in the config table, so they're basically twins 👯
--
-- The L2TP Domain Status and Statistics Table
--
l2tpDomainStatsTable OBJECT-TYPE
SYNTAX SEQUENCE OF L2tpDomainStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The L2TP Domain Status and Statistics table. This
table contains objects that can be used to describe
the current status and statistics of a tunnel domain.
There is a 1-1 correspondence between conceptual
rows of this table and conceptual rows of the
l2tpDomainConfigTable."
::= { l2tpObjects 3 }
l2tpDomainStatsEntry OBJECT-TYPE
SYNTAX L2tpDomainStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An L2TP Domain Stats entry. An entry in this table
may correspond to a single endpoint or a group of
tunnel endpoints."
AUGMENTS { l2tpDomainConfigEntry }
::= { l2tpDomainStatsTable 1 }
L2tpDomainStatsEntry ::=
SEQUENCE {
l2tpDomainStatsTotalTunnels
Counter32,
l2tpDomainStatsFailedTunnels
Counter32,
l2tpDomainStatsFailedAuths
Counter32,
l2tpDomainStatsActiveTunnels
Gauge32,
l2tpDomainStatsTotalSessions
Counter32,
l2tpDomainStatsFailedSessions
Counter32,
l2tpDomainStatsActiveSessions
Gauge32,
l2tpDomainStatsDrainingTunnels
TruthValue,
l2tpDomainStatsControlRxOctets
Counter32,
l2tpDomainStatsControlRxPkts
Counter32,
l2tpDomainStatsControlTxOctets
Counter32,
l2tpDomainStatsControlTxPkts
Counter32,
l2tpDomainStatsPayloadRxOctets
Counter32,
l2tpDomainStatsPayloadRxPkts
Counter32,
l2tpDomainStatsPayloadRxDiscs
Counter32,
l2tpDomainStatsPayloadTxOctets
Counter32,
l2tpDomainStatsPayloadTxPkts
Counter32,
l2tpDomainStatsControlHCRxOctets
Counter64,
l2tpDomainStatsControlHCRxPkts
Counter64,
l2tpDomainStatsControlHCTxOctets
Counter64,
l2tpDomainStatsControlHCTxPkts
Counter64,
l2tpDomainStatsPayloadHCRxOctets
Counter64,
l2tpDomainStatsPayloadHCRxPkts
Counter64,
l2tpDomainStatsPayloadHCRxDiscs
Counter64,
l2tpDomainStatsPayloadHCTxOctets
Counter64,
l2tpDomainStatsPayloadHCTxPkts
Counter64
}Now for the counters themselves, starting with the tunnel ones 🦋 l2tpDomainStatsTotalTunnels counts tunnels that made it to established, and l2tpDomainStatsFailedTunnels counts the ones that flopped on the way there (think connection timeouts or unsupported or malformed AVPs). l2tpDomainStatsFailedAuths is specifically for tunnel peers that failed auth. l2tpDomainStatsActiveTunnels is how many tunnels are active right now.
l2tpDomainStatsTotalTunnels OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object returns the total number of tunnels
that have successfully reached the established
state for this tunnel domain."
::= { l2tpDomainStatsEntry 1 }
l2tpDomainStatsFailedTunnels OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object returns the number of tunnels that
failed (eg: connection timeout, unsupported
or malformed AVP's etc) to reach the established
state for this tunnel domain."
::= { l2tpDomainStatsEntry 2 }
l2tpDomainStatsFailedAuths OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object returns the number of failed tunnel
connection attempts for this domain because the
tunnel peer failed authentication."
::= { l2tpDomainStatsEntry 3 }
l2tpDomainStatsActiveTunnels OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object returns the number of tunnels that
are currently active for this domain."
::= { l2tpDomainStatsEntry 4 }Session counters are next, and they mirror the tunnel ones 💖 l2tpDomainStatsTotalSessions tallies sessions that reached established, and l2tpDomainStatsFailedSessions tallies the ones that failed to get there.
l2tpDomainStatsTotalSessions OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object returns the total number of sessions
that have successfully reached the established
state for this tunnel domain."
::= { l2tpDomainStatsEntry 5 }
l2tpDomainStatsFailedSessions OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object returns the number of sessions that
failed (eg: connection timeout, unsupported
or malformed AVP's etc) to reach the established
state for this tunnel domain."
::= { l2tpDomainStatsEntry 6 }Okay bestie, the domain stats are where we pick up 💅 Here's how the active-session count, the draining flag, and all those octet and packet counters are defined 📊
Active sessions and draining status first! 🌸
l2tpDomainStatsActiveSessions OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object returns the number of sessions that
are currently active for this domain."
::= { l2tpDomainStatsEntry 7 }
l2tpDomainStatsDrainingTunnels OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates if this domain is draining
off sessions from all tunnels."
::= { l2tpDomainStatsEntry 8 }Now the control channel counters 🎀 They count what's received and transmitted, in octets and in packets.
l2tpDomainStatsControlRxOctets OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object returns the number of control channel
octets received for this tunnel domain."
::= { l2tpDomainStatsEntry 9 }
l2tpDomainStatsControlRxPkts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object returns the number of control packets
received for this tunnel domain."
::= { l2tpDomainStatsEntry 10 }
l2tpDomainStatsControlTxOctets OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object returns the number of control channel
octets that were transmitted to tunnel endpoints
for this domain."
::= { l2tpDomainStatsEntry 11 }
l2tpDomainStatsControlTxPkts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object returns the number of control packets
that were transmitted to tunnel endpoints for
this domain."
::= { l2tpDomainStatsEntry 12 }Payload counters next! 🦋 These track the data side of things, including the discards on the receive path.
l2tpDomainStatsPayloadRxOctets OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object returns the number of payload channel
octets that were received for this tunnel domain."
::= { l2tpDomainStatsEntry 13 }
l2tpDomainStatsPayloadRxPkts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object returns the number of payload packets
that were received for this tunnel domain."
::= { l2tpDomainStatsEntry 14 }
l2tpDomainStatsPayloadRxDiscs OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object returns the number of received payload
packets that were discarded by this tunnel domain."
::= { l2tpDomainStatsEntry 15 }
l2tpDomainStatsPayloadTxOctets OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object returns the number of payload channel
octets that were transmitted to tunnel peers
within this tunnel domain."
::= { l2tpDomainStatsEntry 16 }
l2tpDomainStatsPayloadTxPkts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object returns the number of payload packets
that were transmitted to tunnel peers within
this tunnel domain."
::= { l2tpDomainStatsEntry 17 }
--
-- High Capacity Counter objects. These objects are all
-- 64 bit versions of the above 32-bit counters. These
-- objects all have the same basic semantics as their
-- 32-bit counterparts, however, their syntax has been
-- extended to 64 bits.
--The high-capacity (HC) versions are the 64-bit upgrades of those 32-bit counters. Same meaning, bigger numbers! 👑
l2tpDomainStatsControlHCRxOctets OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object is a 64-bit version of
l2tpDomainStatsControlRxOctets."
::= { l2tpDomainStatsEntry 18 }
l2tpDomainStatsControlHCRxPkts OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object is a 64-bit version of
l2tpDomainStatsControlRxPkts."
::= { l2tpDomainStatsEntry 19 }
l2tpDomainStatsControlHCTxOctets OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object is a 64-bit version of
l2tpDomainStatsControlTxOctets."
::= { l2tpDomainStatsEntry 20 }
l2tpDomainStatsControlHCTxPkts OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object is a 64-bit version of
l2tpDomainStatsControlTxPkts."
::= { l2tpDomainStatsEntry 21 }
l2tpDomainStatsPayloadHCRxOctets OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object is a 64-bit version of
l2tpDomainStatsPayloadRxOctets."
::= { l2tpDomainStatsEntry 22 }
l2tpDomainStatsPayloadHCRxPkts OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object is a 64-bit version of
l2tpDomainStatsPayloadRxPkts."
::= { l2tpDomainStatsEntry 23 }
l2tpDomainStatsPayloadHCRxDiscs OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object is a 64-bit version of
l2tpDomainStatsPayloadRxDiscs."
::= { l2tpDomainStatsEntry 24 }
l2tpDomainStatsPayloadHCTxOctets OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object is a 64-bit version of
l2tpDomainStatsPayloadTxOctets."
::= { l2tpDomainStatsEntry 25 }
l2tpDomainStatsPayloadHCTxPkts OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object is a 64-bit version of
l2tpDomainStatsPayloadTxPkts."
::= { l2tpDomainStatsEntry 26 }Okay, that's the whole domain stats table! Next up is the tunnel configuration table, where you can (re)configure a single tunnel's operational characteristics 🧚✨
--
-- The L2TP Tunnel Configuration Table
--
l2tpTunnelConfigTable OBJECT-TYPE
SYNTAX SEQUENCE OF L2tpTunnelConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The L2TP tunnel configuration table. This
table contains objects that can be used to
(re)configure the operational characteristics
of a single L2TP tunnel. There is a 1-1
correspondence between conceptual rows of
this table and conceptual rows of the
l2tpTunnelStatsTable. Entries in this table
have the same persistency characteristics as
that of the tunnelConfigTable."
REFERENCE "RFC 2667"
::= { l2tpObjects 4 }
l2tpTunnelConfigEntry OBJECT-TYPE
SYNTAX L2tpTunnelConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A L2TP tunnel interface configuration entry.
Entries in this table come and go as a result
of protocol interactions or on management
operations. The latter occurs when a row is
instantiated in the tunnelConfigTable row
and the encapsulation method is 'l2tp'."
REFERENCE "RFC 2667"
INDEX { l2tpTunnelConfigIfIndex }
::= { l2tpTunnelConfigTable 1 }
L2tpTunnelConfigEntry ::=
SEQUENCE {
l2tpTunnelConfigIfIndex
InterfaceIndex,
l2tpTunnelConfigDomainId
SnmpAdminString,
l2tpTunnelConfigAuth
INTEGER,
l2tpTunnelConfigSecret
SnmpAdminString,
l2tpTunnelConfigSecurity
INTEGER,
l2tpTunnelConfigHelloInterval
Integer32,
l2tpTunnelConfigIdleTimeout
Integer32,
l2tpTunnelConfigControlRWS
Integer32,
l2tpTunnelConfigControlMaxRetx
Integer32,
l2tpTunnelConfigControlMaxRetxTO
Integer32,
l2tpTunnelConfigPayloadSeq
INTEGER,
l2tpTunnelConfigReassemblyTO
L2tpMilliSeconds,
l2tpTunnelConfigTransport
INTEGER,
l2tpTunnelConfigDrainTunnel
TruthValue,
l2tpTunnelConfigProxyPPPAuth
TruthValue
}
l2tpTunnelConfigIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This value for this object is equal to the value
of ifIndex of the Interfaces MIB for tunnel
interfaces of type L2TP."
::= { l2tpTunnelConfigEntry 1 }
l2tpTunnelConfigDomainId OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (1..80))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The tunnel domain that this tunnel belongs
to. A LNS tunnel endpoint will typically inherit
this value from the endpoint domain table. A
LAC may be provided with this information during
tunnel setup. When a zero length string is returned
this tunnel does not belong belong to any particular
domain."
::= { l2tpTunnelConfigEntry 2 }
l2tpTunnelConfigAuth OBJECT-TYPE
SYNTAX INTEGER {
none(1),
simple(2),
challenge(3)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object describes how L2TP tunnel peers are
to be authenticated. The value 'simple' indicates
that peers are authenticated simply by their host
name as described in the Host Name AVP. The value
'challenge' indicates that all peers are challenged
to prove their identification. This mechanism is
described in the L2TP protocol. This object cannot
be modified when the tunnel is in a connecting or
connected state."
DEFVAL { none }
::= { l2tpTunnelConfigEntry 3 }That's the tunnel config entry setup and the first few objects! More is coming, so stay tuned, bestie 🫶💜
okay so the config table keeps going and it's getting spicy 🌶️ we've got the shared secret, security mode, hello timers, idle timeouts, and retransmission knobs, all lined up like a glam squad 💅
l2tpTunnelConfigSecret OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE (0..255))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object is used to configure the shared secret
used during the tunnel authentication phase of
tunnel establishment. This object cannot be modified
when the tunnel is in a connecting or connected
state. This 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."
::= { l2tpTunnelConfigEntry 4 }
l2tpTunnelConfigSecurity OBJECT-TYPE
SYNTAX INTEGER {
none(1),
other(2),
ipsec(3)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object defines whether this tunnel is to be
secured. The value of 'ipSec' indicates that all
tunnel packets, control and session, have IP
Security headers. The type of IP Security headers
(AH, ESP etc) and how they are further described
is outside the scope of this document. This object
cannot be modified when the tunnel is in a connecting
or connected state."
DEFVAL { none }
::= { l2tpTunnelConfigEntry 5 }First up is the secret 🔐 It's the shared password used during tunnel authentication, and you can't change it while the tunnel is connecting or connected. The really important bit is that it's only reachable through requests that use both authentication and privacy, and the agent always hands back an empty string when you ask for it with get, get-next, or get-bulk. Basically, it's a locked diary, bestie 🤫
Then there's the security one 🛡️ It's a little switch that says whether the tunnel is secured. When it's set to ipSec, every tunnel packet, control and session, gets IP Security headers. The document says exactly which header types (AH, ESP etc.) get used is out of scope here, so we're not going there. Same deal: you can't flip it while the tunnel is connecting or connected. The default is none, which is giving "no drama" energy ✨
l2tpTunnelConfigHelloInterval OBJECT-TYPE
SYNTAX Integer32 (0..3600)
UNITS "seconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object defines the interval in which Hello
(or keep-alive) packets are to be sent to the
tunnel peer. The value zero effectively disables
the sending of Hello packets. Modifications to this
object have immediate effect."
DEFVAL { 60 }
::= { l2tpTunnelConfigEntry 6 }
l2tpTunnelConfigIdleTimeout OBJECT-TYPE
SYNTAX Integer32 (-1..86400)
UNITS "seconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object defines the period of time that an
established tunnel with no sessions will wait
before disconnecting the tunnel. A value of
zero indicates that the tunnel will disconnect
immediately after the last session disconnects.
A value of -1 leaves the tunnel up indefinitely.
Modifications to this object have immediate
effect."
DEFVAL { 0 }
::= { l2tpTunnelConfigEntry 7 }The hello interval is the heartbeat 💓 It sets how often Hello (keep-alive) packets go out to the tunnel peer, in seconds, with a default of 60. Set it to zero and the hellos are effectively off, which is a whole vibe if you're into silence 🙈 Changes take effect right away, no waiting.
The idle timeout is for when a tunnel is established but has zero sessions, aka a very lonely tunnel 🥺 It says how long that tunnel hangs around before disconnecting. Zero means it drops the moment the last session leaves, and -1 means it stays up forever, no expiry. Default is zero, and again, changes apply immediately.
l2tpTunnelConfigControlRWS OBJECT-TYPE
SYNTAX Integer32 (1..65535)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object defines the control channel receive
window size. It specifies the maximum number of
packets the tunnel peer can send without waiting
for an acknowledgement from this peer. This object
cannot be modified when the tunnel is in a con-
necting or connected state."
DEFVAL { 4 }
::= { l2tpTunnelConfigEntry 8 }
l2tpTunnelConfigControlMaxRetx OBJECT-TYPE
SYNTAX Integer32 (0..32)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object defines the number of retransmissions
which the tunnel will attempt before assuming that
the peer is no longer responding. A value of zero
indicates that this peer will not attempt to
retransmit an unacknowledged control packet.
Modifications to this object have immediate
effect."
DEFVAL { 5 }
::= { l2tpTunnelConfigEntry 9 }
l2tpTunnelConfigControlMaxRetxTO OBJECT-TYPE
SYNTAX Integer32 (1..32)
UNITS "seconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object defines the maximum retransmission timeout
interval which the tunnel will wait before retrans-
mitting a control packet that has not been acknowledged.
Modifications to this object have immediate effect."
DEFVAL { 16 }
::= { l2tpTunnelConfigEntry 10 }Now the control channel's flow-control and retry crew 🚦 The receive window size is how many packets the peer can blast at you before it has to wait for an acknowledgement. Default is 4, and you can't touch it mid-connection, so plan ahead, babe 📦
Max retransmissions is how many times the tunnel tries resending a control packet before deciding the peer has ghosted it 👻 Zero means no retries at all. Default is 5, and changes are instant.
The retransmission timeout is how long the tunnel waits before resending an unacknowledged control packet, with a max of 32 seconds and a default of 16. Also instant changes. Honestly the three of these together are giving reliability queen energy 👑
l2tpTunnelConfigPayloadSeq OBJECT-TYPE
SYNTAX INTEGER {
onDemand(1),
never(2),
always(3)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object determines whether or not session payload
packets will be requested to be sent with sequence
numbers from tunnel peers belonging to this domain.
The value onDemand(1) allows the L2TP implementation
to initiate payload sequencing when necessary based
on local information (e.g: during LCP/NCP negotiations
or for CCP). The value never(2) indicates that L2TP
will never initiate sequencing but will do sequencing
if asked. The value always(3) indicates that L2TP
will send the Sequencing Required AVP during session
establishment. Modifications to this object have
immediate effect."
DEFVAL { onDemand }
::= { l2tpTunnelConfigEntry 11 }
l2tpTunnelConfigReassemblyTO OBJECT-TYPE
SYNTAX L2tpMilliSeconds
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object defines the number of milliseconds that
this tunnel will wait before processing payload packets
that were received out of sequence (which are waiting
for the packet(s) to put them in sequence). A low value
increases the chance of delayed packets to be discarded
(which MAY cause the PPP decompression engine to
reset) while a high value may cause more queuing and
possibly degrade throughput if packets are truly lost.
The default value for this object is zero which will
result in all delayed packets being lost. Modifications
to this object have immediate effect."
DEFVAL { 0 }
::= { l2tpTunnelConfigEntry 12 }Payload sequencing is the "do you want your packets in order?" setting 📬 It's got three flavours. onDemand(1) is the default, and it lets the implementation turn sequencing on when it needs to, based on local stuff like LCP/NCP negotiations or CCP. never(2) means L2TP won't start sequencing itself, but it'll still do it if somebody asks. always(3) means it sends the Sequencing Required AVP during session setup, no questions asked 💅 Changes apply right away.
The reassembly timeout is how many milliseconds the tunnel waits for out-of-order payload packets to show up so it can put them back in line 🧩 Go low and you risk delayed packets getting tossed, which can make the PPP decompression engine reset. Go high and you get more queuing, which can hurt throughput when stuff is actually lost. The default is zero, and that means any delayed packet just gets dropped. Ruthless, but make it make sense 💀
l2tpTunnelConfigTransport OBJECT-TYPE
SYNTAX INTEGER {
other(1),
none(2),
udpIp(3),
frameRelay(4),
atm(5)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object defines the underlying transport media
that is in use for this tunnel entry. Different tunnel
transports may define MIB extensions to the L2TP tunnel
table to realize the transport layer. For example if the
value of this object is 'udpIp' then the value of ifIndex
for this table may be used to determine state from the
l2tpUdpStatsTable. This object cannot be modified when
the tunnel is in a connecting or connected state."
::= { l2tpTunnelConfigEntry 13 }
l2tpTunnelConfigDrainTunnel OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"Setting this object to 'true' will prevent any new
session from being either initiated or accepted but
does NOT disconnect any active sessions for this
tunnel. Note that when this occurs the
l2tpTunnelStatsDrainingTunnel status object of
this tunnel should reflect that it is 'draining'.
To cancel a drain this object should be set to
false(2). Setting this object to false(2) when
the L2TP objects l2tpDrainTunnels or
l2tpDomainConfigDrainTunnels is true(1) has
no affect, this tunnels will continue to drain."
DEFVAL { false }
::= { l2tpTunnelConfigEntry 14 }
l2tpTunnelConfigProxyPPPAuth OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"This object is used to configure the sending
or acceptance of the session PPP Proxy
Authentication AVP's on the LAC or LNS."
DEFVAL { true }
::= { l2tpTunnelConfigEntry 15 }The transport object says what media the tunnel is running over 🚇 The options are other, none, udpIp, frameRelay, and atm. Different transports can bring their own MIB extensions to the tunnel table, and the example here is udpIp, where the ifIndex can be used to look up state in the l2tpUdpStatsTable. Like the security knob, you can't change it while the tunnel is connecting or connected.
Drain is my favourite little drama 🌊 Setting it to true stops any brand-new sessions from being started or accepted, but it does not kick out the sessions already there. The draining status object is supposed to show "draining" when this happens. To stop draining, set it back to false(2). And there's a catch: if the global l2tpDrainTunnels or the domain-level l2tpDomainConfigDrainTunnels is true(1), setting this one to false(2) does nothing, and the tunnel keeps draining anyway. Plot twist 🙃
Last up is the proxy PPP auth flag 🎟️ It controls whether the session PPP Proxy Authentication AVPs get sent or accepted on the LAC or LNS. It defaults to true, and that's the whole story.
--
-- The L2TP Tunnel Status and Statisticss Table
--
l2tpTunnelStatsTable OBJECT-TYPE
SYNTAX SEQUENCE OF L2tpTunnelStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The L2TP tunnel status and statistics table. This
table contains objects that can be used to describe
the current status and statistics of a single L2TP
tunnel. There is a 1-1 correspondence between
conceptual rows of this table and conceptual rows of
the l2tpTunnelConfigTable."
::= { l2tpObjects 5 }
l2tpTunnelStatsEntry OBJECT-TYPE
SYNTAX L2tpTunnelStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An L2TP tunnel interface stats entry."
AUGMENTS { l2tpTunnelConfigEntry }
::= { l2tpTunnelStatsTable 1 }
L2tpTunnelStatsEntry ::=
SEQUENCE {
l2tpTunnelStatsLocalTID
Integer32,
l2tpTunnelStatsRemoteTID
Integer32,
l2tpTunnelStatsState
INTEGER,
l2tpTunnelStatsInitiated
INTEGER,
l2tpTunnelStatsRemoteHostName
SnmpAdminString,
l2tpTunnelStatsRemoteVendorName
SnmpAdminString,
l2tpTunnelStatsRemoteFirmwareRev
Integer32,
l2tpTunnelStatsRemoteProtocolVer
OCTET STRING,And now we're moving into the status and statistics table 📊 This is the read-only companion to the config table, with exactly one row for every row in l2tpTunnelConfigTable, so they always pair up 👯 It's augmented onto the config entry, so each tunnel gets its own stats row. Then the SEQUENCE lists off the columns we'll be looking at next, like local and remote TIDs, state, who initiated it, and the remote peer's host name, vendor, firmware, and protocol version. Stay tuned, it's about to get juicy 🦋
l2tpTunnelStatsInitialRemoteRWS
Integer32,
l2tpTunnelStatsBearerCaps
INTEGER,
l2tpTunnelStatsFramingCaps
INTEGER,
l2tpTunnelStatsControlRxPkts
Counter32,
l2tpTunnelStatsControlRxZLB
Counter32,
l2tpTunnelStatsControlOutOfSeq
Counter32,
l2tpTunnelStatsControlOutOfWin
Counter32,
l2tpTunnelStatsControlTxPkts
Counter32,
l2tpTunnelStatsControlTxZLB
Counter32,
l2tpTunnelStatsControlAckTO
Counter32,
l2tpTunnelStatsCurrentRemoteRWS
Gauge32,
l2tpTunnelStatsTxSeq
Integer32,
l2tpTunnelStatsTxSeqAck
Integer32,
l2tpTunnelStatsRxSeq
Integer32,
l2tpTunnelStatsRxSeqAck
Integer32,
l2tpTunnelStatsTotalSessions
Counter32,
l2tpTunnelStatsFailedSessions
Counter32,
l2tpTunnelStatsActiveSessions
Gauge32,
l2tpTunnelStatsLastResultCode
Integer32,
l2tpTunnelStatsLastErrorCode
Integer32,
l2tpTunnelStatsLastErrorMessage
SnmpAdminString,
l2tpTunnelStatsDrainingTunnel
TruthValue
}Okay bestie, this is where the per-tunnel stats table really starts to shine 🦋 Each column below is one object in the l2tpTunnelStatsEntry row, and every single one is read-only, so you look but you don't touch 👀✨
l2tpTunnelStatsLocalTID OBJECT-TYPE
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains the local tunnel Identifier."
REFERENCE "RFC 2661, Section 3.1"
::= { l2tpTunnelStatsEntry 1 }
l2tpTunnelStatsRemoteTID OBJECT-TYPE
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains the remote tunnel Identifier."
REFERENCE "RFC 2661, Section 3.1"
::= { l2tpTunnelStatsEntry 2 }
l2tpTunnelStatsState OBJECT-TYPE
SYNTAX INTEGER {
tunnelIdle(1),
tunnelConnecting(2),
tunnelEstablished(3),
tunnelDisconnecting(4)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This field contains the current state of the
control tunnel."
::= { l2tpTunnelStatsEntry 3 }
l2tpTunnelStatsInitiated OBJECT-TYPE
SYNTAX INTEGER {
locally(1),
remotely(2)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates whether the tunnel was
initiated locally or by the remote tunnel peer."
::= { l2tpTunnelStatsEntry 4 }Now the remote-peer details, the stuff your tunnel buddy shares during setup 💅 A few of these hang onto their last value when the tunnel goes idle, so they remember the vibes from the last connection 🧚
l2tpTunnelStatsRemoteHostName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains the host name as discovered
during the tunnel establishment phase (via the Host
Name AVP) of the L2TP peer. If the tunnel is idle
this object should maintain its value from the last
time it was connected."
::= { l2tpTunnelStatsEntry 5 }
l2tpTunnelStatsRemoteVendorName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object identifies the vendor name of the peer's
L2TP implementation. If the tunnel is idle this
object should maintain its value from the last time
it was connected."
::= { l2tpTunnelStatsEntry 6 }
l2tpTunnelStatsRemoteFirmwareRev OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains the tunnel peer's firmware
revision number. If the tunnel is idle this object
should maintain its value from the last time it
was connected."
::= { l2tpTunnelStatsEntry 7 }
l2tpTunnelStatsRemoteProtocolVer OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(2))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object describes the protocol version and
revision of the tunnel peers implementation. The
first octet contains the protocol version. The
second octet contains the protocol revision."
::= { l2tpTunnelStatsEntry 8 }
l2tpTunnelStatsInitialRemoteRWS OBJECT-TYPE
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains the initial remote peer's
receive window size as indicated by the tunnel peer
(in the RWS AVP) during the tunnel establishment
phase. If the tunnel is idle this object should
maintain its value from the last time it was
connected."
::= { l2tpTunnelStatsEntry 9 }
l2tpTunnelStatsBearerCaps OBJECT-TYPE
SYNTAX INTEGER {
none(1),
digital(2),
analog(3),
digitalAnalog(4)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object describes the Bearer Capabilities of
the tunnel peer. If the tunnel is idle this object
should maintain its value from the last time it was
connected."
::= { l2tpTunnelStatsEntry 10 }
l2tpTunnelStatsFramingCaps OBJECT-TYPE
SYNTAX INTEGER {
none(1),
sync(2),
async(3),
syncAsync(4)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object describes the Framing Capabilities of
the tunnel peer. If the tunnel is idle this object
should maintain its value from the last time it was
connected."
::= { l2tpTunnelStatsEntry 11 }Next up are the packet counters, the receipts for every control message that goes back and forth 🧾🎀 The out-of-window one is a little choosy: whether those packets get queued or dropped is up to the implementation, so that part is totally its call 💜
l2tpTunnelStatsControlRxPkts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains the number of control packets
received on the tunnel."
::= { l2tpTunnelStatsEntry 12 }
l2tpTunnelStatsControlRxZLB OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object returns a count of the number of Zero
Length Body control packet acknowledgement packets
that were received."
::= { l2tpTunnelStatsEntry 13 }
l2tpTunnelStatsControlOutOfSeq OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object returns a count of the number of
control packets that were not received in the
correct order (as per the sequence number)
on this tunnel including out of window
packets."
::= { l2tpTunnelStatsEntry 14 }
l2tpTunnelStatsControlOutOfWin OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains the number of control
packets that were received outside of the
offered receive window. It is implementation
specific as to whether these packets are queued
or discarded."
::= { l2tpTunnelStatsEntry 15 }
l2tpTunnelStatsControlTxPkts OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains the number of control
packets that were transmitted to the tunnel
peer."
::= { l2tpTunnelStatsEntry 16 }
l2tpTunnelStatsControlTxZLB OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains the number of Zero Length
Body control packets transmitted to the tunnel
peer."
::= { l2tpTunnelStatsEntry 17 }
l2tpTunnelStatsControlAckTO OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object returns a count of the number of
control packet timeouts due to the lack of a
timely acknowledgement from the tunnel peer."
::= { l2tpTunnelStatsEntry 18 }And now the sequence-number and flow-control bits, which are kinda the heart of the whole reliability thing 🫶 Pay attention to the TxSeqAck one, bestie. It's basically the math for figuring out how much room the peer has left, and it's the only one with a little calculation in its description 🧮
l2tpTunnelStatsCurrentRemoteRWS OBJECT-TYPE
SYNTAX Gauge32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains the current remote receive
window size as determined by the local flow
control mechanism employed."
::= { l2tpTunnelStatsEntry 19 }
l2tpTunnelStatsTxSeq OBJECT-TYPE
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains the next send sequence number
for the control channel."
::= { l2tpTunnelStatsEntry 20 }
l2tpTunnelStatsTxSeqAck OBJECT-TYPE
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains the send sequence number that
the tunnel peer has acknowledged for the control
channel. The flow control state can be determined
by subtracting the l2tpTunnelStatsTxSeq from
l2tpTunnelStatsTxSeqAck and comparing this value
to l2tpTunnelStatsCurrentRemoteRWS (taking into
consideration sequence number wraps)."
::= { l2tpTunnelStatsEntry 21 }
l2tpTunnelStatsRxSeq OBJECT-TYPE
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains the next receive sequence
number expected to be received on this control
channel."
::= { l2tpTunnelStatsEntry 22 }Okay bestie, we're still in the L2TP object definitions 💅✨ picking up right where the tunnel stats left off, so let's keep going 🦋
l2tpTunnelStatsRxSeqAck OBJECT-TYPE
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains the last receive sequence
number that was acknowledged back to the tunnel
peer for the control channel."
::= { l2tpTunnelStatsEntry 23 }
l2tpTunnelStatsTotalSessions OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains the total number of sessions
that this tunnel has successfully connected through
to its tunnel peer since this tunnel was created."
::= { l2tpTunnelStatsEntry 24 }
l2tpTunnelStatsFailedSessions OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains the total number of sessions
that were initiated but failed to reach the
established phase."
::= { l2tpTunnelStatsEntry 25 }
l2tpTunnelStatsActiveSessions OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains the total number of sessions
in the established state for this tunnel."
::= { l2tpTunnelStatsEntry 26 }
l2tpTunnelStatsLastResultCode OBJECT-TYPE
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains the last value of the result
code as described in the Result Code AVP which
caused the tunnel to disconnect."
::= { l2tpTunnelStatsEntry 27 }
l2tpTunnelStatsLastErrorCode OBJECT-TYPE
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains the last value of the error
code as described in the Result Code AVP which
caused the tunnel to disconnect."
::= { l2tpTunnelStatsEntry 28 }
l2tpTunnelStatsLastErrorMessage OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains the last value of the optional
message as described in the Result Code AVP which
caused the tunnel to disconnect."
::= { l2tpTunnelStatsEntry 29 }
l2tpTunnelStatsDrainingTunnel OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates if this tunnel is draining
off sessions. This object will return false(2) when
the tunnel is not draining sessions or after the
last session has disconnected when the tunnel is in
the draining state."
::= { l2tpTunnelStatsEntry 30 }
--
-- { l2tpObjects 6 } reserved for future use
--
--
-- The L2TP Session Status and Statistics Table
--
l2tpSessionStatsTable OBJECT-TYPE
SYNTAX SEQUENCE OF L2tpSessionStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The L2TP session status and statistics table. This
table contains the objects that can be used to
describe the current status and statistics of a
single L2TP tunneled session."
::= { l2tpObjects 7 }
l2tpSessionStatsEntry OBJECT-TYPE
SYNTAX L2tpSessionStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An L2TP session interface stats entry."
INDEX { l2tpSessionStatsTunnelIfIndex,
l2tpSessionStatsLocalSID }
::= { l2tpSessionStatsTable 1 }
L2tpSessionStatsEntry ::=
SEQUENCE {
l2tpSessionStatsTunnelIfIndex
InterfaceIndex,
l2tpSessionStatsIfIndex
InterfaceIndex,
l2tpSessionStatsLocalSID
Integer32,
l2tpSessionStatsRemoteSID
Integer32,
l2tpSessionStatsUserName
SnmpAdminString,
l2tpSessionStatsState
INTEGER,
l2tpSessionStatsCallType
INTEGER,
l2tpSessionStatsCallSerialNumber
Unsigned32,
l2tpSessionStatsTxConnectSpeed
Unsigned32,
l2tpSessionStatsRxConnectSpeed
Unsigned32,
l2tpSessionStatsCallBearerType
INTEGER,
l2tpSessionStatsFramingType
INTEGER,
l2tpSessionStatsPhysChanId
Unsigned32,
l2tpSessionStatsDNIS
SnmpAdminString,
l2tpSessionStatsCLID
SnmpAdminString,
l2tpSessionStatsSubAddress
SnmpAdminString,
l2tpSessionStatsPrivateGroupID
SnmpAdminString,
l2tpSessionStatsProxyLcp
TruthValue,
l2tpSessionStatsAuthMethod
INTEGER,
l2tpSessionStatsSequencingState
INTEGER,
l2tpSessionStatsOutSequence
Counter32,
l2tpSessionStatsReassemblyTO
Counter32,
l2tpSessionStatsTxSeq
Integer32,
l2tpSessionStatsRxSeq
Integer32
}
l2tpSessionStatsTunnelIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object identifies the session's associated
L2TP tunnel ifIndex value."
::= { l2tpSessionStatsEntry 1 }
l2tpSessionStatsIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object identifies the ifIndex value of the
interface from which PPP packets are being tunneled.
For example this could be a DS0 ifIndex on a
LAC or it would be the PPP ifIndex on the LNS."
::= { l2tpSessionStatsEntry 2 }
l2tpSessionStatsLocalSID OBJECT-TYPE
SYNTAX Integer32 (1..65535)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object contains the local assigned session
identifier for this session."
REFERENCE "RFC 2661, Section 3.1"
::= { l2tpSessionStatsEntry 3 }
l2tpSessionStatsRemoteSID OBJECT-TYPE
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains the remote assigned session
identifier for this session. When a session is
starting this value may be zero until the remote
tunnel endpoint has responded."
REFERENCE "RFC 2661, Section 3.1"
::= { l2tpSessionStatsEntry 4 }
l2tpSessionStatsUserName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object identifies the peer session name on
this interface. This is typically the login name
of the remote user. If the user name is unknown to
the local tunnel peer then this object will contain
a null string."
::= { l2tpSessionStatsEntry 5 }
l2tpSessionStatsState OBJECT-TYPE
SYNTAX INTEGER {
sessionIdle(1),
sessionConnecting(2),
sessionEstablished(3),
sessionDisconnecting(4)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains the current state of the
session."
::= { l2tpSessionStatsEntry 6 }
l2tpSessionStatsCallType OBJECT-TYPE
SYNTAX INTEGER {
lacIncoming(1),
lnsIncoming(2),
lacOutgoing(3),
lnsOutgoing(4)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object indicates the type of call and the
role this tunnel peer is providing for this
session. For example, lacIncoming(1) indicates
that this tunnel peer is acting as a LAC and
generated a Incoming-Call-Request to the tunnel
peer (the LNS). Note that tunnel peers can be
both LAC and LNS simultaneously."
::= { l2tpSessionStatsEntry 7 }
l2tpSessionStatsCallSerialNumber OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains the serial number that has
been assigned to this session."
::= { l2tpSessionStatsEntry 8 }
l2tpSessionStatsTxConnectSpeed OBJECT-TYPE
SYNTAX Unsigned32
UNITS "bits per second"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object returns the last known transmit
baud rate for this session."
::= { l2tpSessionStatsEntry 9 }
l2tpSessionStatsRxConnectSpeed OBJECT-TYPE
SYNTAX Unsigned32
UNITS "bits per second"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object returns the last known receive
baud rate for this session established."
::= { l2tpSessionStatsEntry 10 }
l2tpSessionStatsCallBearerType OBJECT-TYPE
SYNTAX INTEGER {
none(1),
digital(2),
analog(3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object describes the bearer type of this
session."
::= { l2tpSessionStatsEntry 11 }
l2tpSessionStatsFramingType OBJECT-TYPE
SYNTAX INTEGER {
none(1),
sync(2),
async(3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object describes the framing type of this
session."
::= { l2tpSessionStatsEntry 12 }The tunnel stats objects wrap up with a little reserved slot, then the big session stats table rolls in with its index, its SEQUENCE layout, and a bunch of per-session objects 🎀 Wowww, the session objects are giving full main character energy 🌸🧚
Okay bestie, we're picking up right where the session stats columns left off 💖 The rest of the session stats are next: the physical channel ID, DNIS, CLID, sub address, private group ID, proxy LCP, auth method, sequencing state, and the sequence counters 🧚
l2tpSessionStatsPhysChanId OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains the physical channel
identifier for the session."
::= { l2tpSessionStatsEntry 13 }
l2tpSessionStatsDNIS OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object identifies the Dialed Number
Information String that the LAC obtained from
the network for the session. If no DNIS was
provided then a null string will be returned."
::= { l2tpSessionStatsEntry 14 }
l2tpSessionStatsCLID OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object identifies the Calling Line ID
that the LAC obtained from the network for
the session. If no CLID was provided then a
null string will be returned."
::= { l2tpSessionStatsEntry 15 }
l2tpSessionStatsSubAddress OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object identifies the Sub Address that
the LAC obtained from the network for the
session. If no Sub Address was provided then
a null string will be returned."
::= { l2tpSessionStatsEntry 16 }
l2tpSessionStatsPrivateGroupID OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object identifies the Private Group
Identifier used for this tunneled session.
If no Private Group Identifier was provided
then a null string will be returned."
::= { l2tpSessionStatsEntry 17 }
l2tpSessionStatsProxyLcp OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Indicates whether the LAC performed proxy LCP
for this session."
::= { l2tpSessionStatsEntry 18 }
l2tpSessionStatsAuthMethod OBJECT-TYPE
SYNTAX INTEGER {
none(1),
text(2),
pppChap(3),
pppPap(4),
pppEap(5),
pppMsChapV1(6),
pppMsChapV2(7),
other(8)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains the proxy authentication
method employed by the LAC for the session. If
l2tpSessionProxyLcp is false(2) this object
should not be interpreted."
::= { l2tpSessionStatsEntry 19 }
l2tpSessionStatsSequencingState OBJECT-TYPE
SYNTAX INTEGER {
none(1),
remote(2),
local(3),
both(4)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object defines which tunnel peers have
requested payload sequencing. The value of
both(4) indicates that both peers have requested
payload sequencing."
::= { l2tpSessionStatsEntry 20 }
l2tpSessionStatsOutSequence OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object returns the total number of packets
received for this session which were received out
of sequence."
::= { l2tpSessionStatsEntry 21 }
l2tpSessionStatsReassemblyTO OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object returns the number of reassembly
timeouts that have occurred for this session."
::= { l2tpSessionStatsEntry 22 }
l2tpSessionStatsTxSeq OBJECT-TYPE
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains the next send sequence number
for for this session."
::= { l2tpSessionStatsEntry 23 }
l2tpSessionStatsRxSeq OBJECT-TYPE
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains the next receive sequence
number expected to be received on this session."
::= { l2tpSessionStatsEntry 24 }Now for the mapping tables, which are my absolute favourite part 🦋 The tunnel map helps management apps quickly figure out the ifIndex for a local tunnel ID, and the session map links interfaces to a tunnel and session ID 🫶
--
-- The L2TP Tunnel Mapping Table
--
l2tpTunnelMapTable OBJECT-TYPE
SYNTAX SEQUENCE OF L2tpTunnelMapEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The L2TP Tunnel index mapping table. This table
is intended to assist management applications
to quickly determine what the ifIndex value is
for a given local tunnel identifier."
::= { l2tpObjects 8 }
l2tpTunnelMapEntry OBJECT-TYPE
SYNTAX L2tpTunnelMapEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An L2TP tunnel index map entry."
INDEX { l2tpTunnelMapLocalTID }
::= { l2tpTunnelMapTable 1 }
L2tpTunnelMapEntry ::=
SEQUENCE {
l2tpTunnelMapLocalTID
Integer32,
l2tpTunnelMapIfIndex
InterfaceIndex
}
l2tpTunnelMapLocalTID OBJECT-TYPE
SYNTAX Integer32 (1..65535)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object contains the local tunnel Identifier."
REFERENCE "RFC 2661, Section 3.1"
::= { l2tpTunnelMapEntry 1 }
l2tpTunnelMapIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This value for this object is equal to the value
of ifIndex of the Interfaces MIB for tunnel
interfaces of type L2TP."
::= { l2tpTunnelMapEntry 2 }
--
-- The L2TP Session Mapping Table
--
l2tpSessionMapTable OBJECT-TYPE
SYNTAX SEQUENCE OF L2tpSessionMapEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The L2TP Session index mapping table. This table
is intended to assist management applications
to map interfaces to a tunnel and session
identifier."
::= { l2tpObjects 9 }
l2tpSessionMapEntry OBJECT-TYPE
SYNTAX L2tpSessionMapEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An L2TP Session index map entry."
INDEX { l2tpSessionMapIfIndex }
::= { l2tpSessionMapTable 1 }
L2tpSessionMapEntry ::=
SEQUENCE {
l2tpSessionMapIfIndex
InterfaceIndex,
l2tpSessionMapTunnelIfIndex
InterfaceIndex,
l2tpSessionMapLocalSID
Integer32,
l2tpSessionMapStatus
RowStatus
}
l2tpSessionMapIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This object identifies the ifIndex value of the
interface which is receiving or sending its packets
over an L2TP tunnel. For example this could be a DS0
ifIndex on a LAC or a PPP ifIndex on the LNS."
::= { l2tpSessionMapEntry 1 }
l2tpSessionMapTunnelIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This object identifies the sessions associated
L2TP tunnel ifIndex value. When this object is
set it provides a binding between a particular
interface identified by l2tpSessionMapIfIndex
to a particular tunnel."
::= { l2tpSessionMapEntry 2 }
l2tpSessionMapLocalSID OBJECT-TYPE
SYNTAX Integer32 (1..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object contains the local assigned session
identifier for this session."
REFERENCE "RFC 2661, Section 3.1"
::= { l2tpSessionMapEntry 3 }
l2tpSessionMapStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of this session map entry."
::= { l2tpSessionMapEntry 4 }Last up in this chunk is the UDP/IP transport stats table, which has a reserved spot at { l2tpIpUdpObjects 1 } for future use 🌸
--
-- { l2tpIpUdpObjects 1 } reserved for future use
--
-- The L2TP UDP/IP Transport Status and Statistics Table
--
l2tpUdpStatsTable OBJECT-TYPE
SYNTAX SEQUENCE OF L2tpUdpStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The L2TP UDP/IP transport stats table. This table
contains objects that can be used to describe the
current status and statistics of the UDP/IP L2TP
tunnel transport."
::= { l2tpIpUdpObjects 2 }
l2tpUdpStatsEntry OBJECT-TYPE
SYNTAX L2tpUdpStatsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An L2TP UDP/IP transport stats entry."
INDEX { l2tpUdpStatsIfIndex }
::= { l2tpUdpStatsTable 1 }
L2tpUdpStatsEntry ::=
SEQUENCE {
l2tpUdpStatsIfIndex
InterfaceIndex,
l2tpUdpStatsPeerPort
Integer32,
l2tpUdpStatsLocalPort
Integer32
}
l2tpUdpStatsIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This value for this object is equal to the
value of ifIndex of the Interfaces MIB for
tunnel interfaces of type L2TP and which have
a L2TP transport of UDP/IP."
::= { l2tpUdpStatsEntry 1 }
l2tpUdpStatsPeerPort OBJECT-TYPE
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object reflects the peer's UDP port number
used for this tunnel. When not known a value of
zero should be returned."
::= { l2tpUdpStatsEntry 2 }okay so this is where the object definitions get their finishing touches 💅✨
l2tpUdpStatsLocalPort OBJECT-TYPE
SYNTAX Integer32 (0..65535)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object reflects the local UDP port number
that this tunnel is bound to."
::= { l2tpUdpStatsEntry 3 }
--
-- Definition of generic L2TP notifications
--
l2tpTunnelAuthFailure NOTIFICATION-TYPE
OBJECTS {
l2tpTunnelStatsInitiated,
l2tpTunnelStatsRemoteHostName
}
STATUS current
DESCRIPTION
"A l2tpTunnelAuthFailure trap signifies that an
attempt to establish a tunnel to a remote peer
has failed authentication."
::= { l2tpNotifications 1 }So l2tpUdpStatsLocalPort is a read-only object that tells you the local UDP port a tunnel is bound to 🦋. Pretty chill, no notes. Then we get our first notification, l2tpTunnelAuthFailure 🚨. It's basically the "hey, that tunnel attempt got rejected at the auth step" alarm 💀. It packages up two objects, the tunnel stats initiated thing and the remote host name, so you know who tried and when. Iconic for debugging 🔥.
Next up is the conformance section, where the groups and compliance statements get organised 🎀.
--
-- conformance information
--
l2tpGroups OBJECT IDENTIFIER ::= { l2tpConformance 1 }
l2tpCompliances OBJECT IDENTIFIER ::= { l2tpConformance 2 }
--
-- compliance statements
--
l2tpMIBFullCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"When this MIB is implemented with support for
read-create and read-write, then such an
implementation can claim full compliance. Such
an implementation can then be both monitored
and configured with this MIB."
MODULE -- this module
-- unconditionally mandatory groups
MANDATORY-GROUPS {
l2tpConfigGroup,
l2tpStatsGroup,
l2tpTrapGroup
}
-- conditionally mandatory groups
GROUP l2tpIpUdpGroup
DESCRIPTION
"This group is mandatory for implementations that
support L2TP over UDP/IP."
-- optional groups
GROUP l2tpDomainGroup
DESCRIPTION
"This group is optional for L2TP devices that
group tunnel endpoints into tunnel domains."
-- optional Mapping Group
GROUP l2tpMappingGroup
DESCRIPTION
"This group is optional for L2TP devices that
provide index mapping."
-- optional Security Group
GROUP l2tpSecurityGroup
DESCRIPTION
"This group is optional for SNMP agents which support
both authentication and privacy of SNMP messages for
the management of L2TP keys."
-- optional High Capacity Group
GROUP l2tpHCPacketGroup
DESCRIPTION
"This group is mandatory for implementations that
support the l2tpDomainGroup AND could potentially
overflow the L2TP Domain 32-bit counters is less
than one hour."
::= { l2tpCompliances 1 }So l2tpGroups and l2tpCompliances are just the two folders 📁 that hold the groups and the compliance statements. Then the full compliance one is the "go big or go home" version 💅. If your implementation does read-create and read-write, you can claim full compliance, meaning you can both watch and configure things 🌈. The config, stats and trap groups are on the mandatory list no matter what 👑. The IP/UDP group is required only if you do L2TP over UDP/IP 🫶. The domain, mapping, security and high capacity groups are optional with their own little conditions, and the high capacity one has that long, slightly messy wording about 32-bit counters overflowing in less than an hour 😭. Keep it as is, it's giving precise.
Now the read-only version, which is the "look but don't touch" option 👀.
l2tpMIBReadOnlyCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"When this MIB is implemented without support for
read-create and read-write (i.e. in read-only mode),
then such an implementation can claim read-only
compliance. Such an implementation can then be
monitored but can not be configured with this MIB."
MODULE -- this module
-- unconditionally mandatory groups
MANDATORY-GROUPS {
l2tpConfigGroup,
l2tpStatsGroup,
l2tpTrapGroup
}
OBJECT l2tpAdminState
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT l2tpDrainTunnels
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT l2tpTunnelConfigDomainId
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT l2tpTunnelConfigHelloInterval
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT l2tpTunnelConfigIdleTimeout
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT l2tpTunnelConfigControlRWS
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT l2tpTunnelConfigControlMaxRetx
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT l2tpTunnelConfigControlMaxRetxTO
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT l2tpTunnelConfigPayloadSeq
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT l2tpTunnelConfigReassemblyTO
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT l2tpTunnelConfigTransport
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT l2tpTunnelConfigDrainTunnel
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT l2tpTunnelConfigProxyPPPAuth
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
-- conditionally mandatory groups
GROUP l2tpIpUdpGroup
DESCRIPTION
"This group is mandatory for implementations that
support L2TP over UDP/IP."
-- optional groups
GROUP l2tpDomainGroup
DESCRIPTION
"This group is optional for L2TP devices that
group tunnel endpoints into tunnel domains."
OBJECT l2tpDomainConfigAdminState
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT l2tpDomainConfigDrainTunnels
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT l2tpDomainConfigTunnelHelloInt
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT l2tpDomainConfigTunnelIdleTO
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT l2tpDomainConfigControlRWS
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT l2tpDomainConfigControlMaxRetx
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT l2tpDomainConfigControlMaxRetxTO
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT l2tpDomainConfigPayloadSeq
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT l2tpDomainConfigReassemblyTO
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT l2tpDomainConfigProxyPPPAuth
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT l2tpDomainConfigStorageType
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT l2tpDomainConfigStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
-- optional Mapping Group
GROUP l2tpMappingGroup
DESCRIPTION
"This group is optional for L2TP devices that
provide index mapping."
OBJECT l2tpSessionMapTunnelIfIndex
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT l2tpSessionMapStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
-- optional Security Group
GROUP l2tpSecurityGroup
DESCRIPTION
"This group is optional for SNMP agents which support
both authentication and privacy of SNMP messages for
the management of L2TP keys."
OBJECT l2tpDomainConfigAuth
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT l2tpDomainConfigSecret
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT l2tpDomainConfigTunnelSecurity
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT l2tpTunnelConfigAuth
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT l2tpTunnelConfigSecret
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT l2tpTunnelConfigSecurity
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
-- optional High Capacity Group
GROUP l2tpHCPacketGroup
DESCRIPTION
"This group is mandatory for implementations that
support the l2tpDomainGroup AND could potentially
overflow the L2TP Domain 32-bit counters is less
than one hour."
::= { l2tpCompliances 2 }So the read-only one is for devices that can be monitored but not configured 👀🧚. It keeps the same mandatory config, stats and trap groups, but every writable object gets downgraded to read-only, and the repeated "Write access is not required." line is basically the tag on each one 💅. The domain, mapping, security and high capacity groups show up again with their own conditions, just like before 🌸.
Last bit for this part: the units of conformance, where the actual config group gets defined 🍓.
-- units of conformance
l2tpConfigGroup OBJECT-GROUP
OBJECTS {
l2tpAdminState,
l2tpDrainTunnels,
l2tpTunnelConfigDomainId,
l2tpTunnelConfigHelloInterval,
l2tpTunnelConfigIdleTimeout,
l2tpTunnelConfigControlRWS,
l2tpTunnelConfigControlMaxRetx,
l2tpTunnelConfigControlMaxRetxTO,
l2tpTunnelConfigPayloadSeq,
l2tpTunnelConfigReassemblyTO,
l2tpTunnelConfigTransport,
l2tpTunnelConfigDrainTunnel,
l2tpTunnelConfigProxyPPPAuth
}
STATUS current
DESCRIPTION
"A collection of objects providing configuration
information of the L2TP protocol, tunnels and
sessions."
::= { l2tpGroups 1 }So l2tpConfigGroup is the big bundle of config objects covering the L2TP protocol, tunnels and sessions 🫶✨. It's the group the mandatory list refers to, so it's kind of the main character of this whole section 👑🔥.
The MIB module's object groups come first, then the security, acknowledgements and references sections, all kept verbatim or in full.
l2tpStatsGroup OBJECT-GROUP
OBJECTS {
l2tpProtocolVersions,
l2tpVendorName,
l2tpFirmwareRev,
l2tpDrainingTunnels,
l2tpTunnelStatsLocalTID,
l2tpTunnelStatsRemoteTID,
l2tpTunnelStatsState,
l2tpTunnelStatsInitiated,
l2tpTunnelStatsRemoteHostName,
l2tpTunnelStatsRemoteVendorName,
l2tpTunnelStatsRemoteFirmwareRev,
l2tpTunnelStatsRemoteProtocolVer,
l2tpTunnelStatsInitialRemoteRWS,
l2tpTunnelStatsBearerCaps,
l2tpTunnelStatsFramingCaps,
l2tpTunnelStatsControlRxPkts,
l2tpTunnelStatsControlRxZLB,
l2tpTunnelStatsControlOutOfSeq,
l2tpTunnelStatsControlOutOfWin,
l2tpTunnelStatsControlTxPkts,
l2tpTunnelStatsControlTxZLB,
l2tpTunnelStatsControlAckTO,
l2tpTunnelStatsCurrentRemoteRWS,
l2tpTunnelStatsTxSeq,
l2tpTunnelStatsTxSeqAck,
l2tpTunnelStatsRxSeq,
l2tpTunnelStatsRxSeqAck,
l2tpTunnelStatsTotalSessions,
l2tpTunnelStatsFailedSessions,
l2tpTunnelStatsActiveSessions,
l2tpTunnelStatsLastResultCode,
l2tpTunnelStatsLastErrorCode,
l2tpTunnelStatsLastErrorMessage,
l2tpTunnelStatsDrainingTunnel,
l2tpSessionStatsIfIndex,
l2tpSessionStatsRemoteSID,
l2tpSessionStatsUserName,
l2tpSessionStatsState,
l2tpSessionStatsCallType,
l2tpSessionStatsCallSerialNumber,
l2tpSessionStatsTxConnectSpeed,
l2tpSessionStatsRxConnectSpeed,
l2tpSessionStatsCallBearerType,
l2tpSessionStatsFramingType,
l2tpSessionStatsPhysChanId,
l2tpSessionStatsDNIS,
l2tpSessionStatsCLID,
l2tpSessionStatsSubAddress,
l2tpSessionStatsPrivateGroupID,
l2tpSessionStatsProxyLcp,
l2tpSessionStatsAuthMethod,
l2tpSessionStatsSequencingState,
l2tpSessionStatsOutSequence,
l2tpSessionStatsReassemblyTO,
l2tpSessionStatsTxSeq,
l2tpSessionStatsRxSeq
}
STATUS current
DESCRIPTION
"A collection of objects providing status and
statistics of the L2TP protocol, tunnels and
sessions."
::= { l2tpGroups 2 }
l2tpIpUdpGroup OBJECT-GROUP
OBJECTS {
l2tpUdpStatsPeerPort,
l2tpUdpStatsLocalPort
}
STATUS current
DESCRIPTION
"A collection of objects providing status and
statistics of the L2TP UDP/IP transport layer."
::= { l2tpGroups 3 }
l2tpDomainGroup OBJECT-GROUP
OBJECTS {
l2tpDomainConfigAdminState,
l2tpDomainConfigDrainTunnels,
l2tpDomainConfigTunnelHelloInt,
l2tpDomainConfigTunnelIdleTO,
l2tpDomainConfigControlRWS,
l2tpDomainConfigControlMaxRetx,
l2tpDomainConfigControlMaxRetxTO,
l2tpDomainConfigPayloadSeq,
l2tpDomainConfigReassemblyTO,
l2tpDomainConfigProxyPPPAuth,
l2tpDomainConfigStorageType,
l2tpDomainConfigStatus,
l2tpDomainStatsTotalTunnels,
l2tpDomainStatsFailedTunnels,
l2tpDomainStatsFailedAuths,
l2tpDomainStatsActiveTunnels,
l2tpDomainStatsTotalSessions,
l2tpDomainStatsFailedSessions,
l2tpDomainStatsActiveSessions,
l2tpDomainStatsDrainingTunnels,
l2tpDomainStatsControlRxOctets,
l2tpDomainStatsControlRxPkts,
l2tpDomainStatsControlTxOctets,
l2tpDomainStatsControlTxPkts,
l2tpDomainStatsPayloadRxOctets,
l2tpDomainStatsPayloadRxPkts,
l2tpDomainStatsPayloadRxDiscs,
l2tpDomainStatsPayloadTxOctets,
l2tpDomainStatsPayloadTxPkts
}
STATUS current
DESCRIPTION
"A collection of objects providing configuration,
status and statistics of L2TP tunnel domains."
::= { l2tpGroups 4 }
l2tpMappingGroup OBJECT-GROUP
OBJECTS {
l2tpTunnelMapIfIndex,
l2tpSessionMapTunnelIfIndex,
l2tpSessionMapLocalSID,
l2tpSessionMapStatus
}
STATUS current
DESCRIPTION
"A collection of objects providing index mapping."
::= { l2tpGroups 5 }
l2tpSecurityGroup OBJECT-GROUP
OBJECTS {
l2tpDomainConfigAuth,
l2tpDomainConfigSecret,
l2tpDomainConfigTunnelSecurity,
l2tpTunnelConfigAuth,
l2tpTunnelConfigSecret,
l2tpTunnelConfigSecurity
}
STATUS current
DESCRIPTION
"A collection of objects providing L2TP security
configuration."
::= { l2tpGroups 6 }
l2tpTrapGroup NOTIFICATION-GROUP
NOTIFICATIONS {
l2tpTunnelAuthFailure
}
STATUS current
DESCRIPTION
"A collection of L2TP trap events as specified
in NOTIFICATION-TYPE constructs."
::= { l2tpGroups 7 }
l2tpHCPacketGroup OBJECT-GROUP
OBJECTS {
l2tpDomainStatsControlHCRxOctets,
l2tpDomainStatsControlHCRxPkts,
l2tpDomainStatsControlHCTxOctets,
l2tpDomainStatsControlHCTxPkts,
l2tpDomainStatsPayloadHCRxOctets,
l2tpDomainStatsPayloadHCRxPkts,
l2tpDomainStatsPayloadHCRxDiscs,
l2tpDomainStatsPayloadHCTxOctets,
l2tpDomainStatsPayloadHCTxPkts
}
STATUS current
DESCRIPTION
"A collection of objects providing High Capacity
64-bit counter objects."
::= { l2tpGroups 8 }
END5.0 Security Considerations 🔒
Okay bestie, this part is SERIOUS, so read it slowly 🫶 This MIB has readable objects that spill info about L2TP tunnel interfaces, which is fine. But it also has a bunch of objects with a MAX-ACCESS of read-write and/or read-create, like the ones that let an admin spin up or tweak tunnels on the fly 💅.
Reading the readable stuff without permission is pretty low-key harmless. Writing to the write-able objects without permission is a whole different vibe 💀. Someone could cause a denial of service, or sneak in and create or mess with tunnels they have no business touching. So if you allow SET operations in an insecure environment with no real protection, that can wreck network operations. Yikes 😭.
SNMPv1 by itself is that insecure environment 🚨. Even if the network underneath is locked down (say, with IPSec [RFC2401]), there's still zero control over who on that secure network can get in and SET (change, create, or delete) the objects in this MIB 🙈.
Now the keys. If the agent lets you configure keys over SNMP (like with the l2tpDomainConfigSecret object) so L2TP can use them, then L2TP is only as secure as SNMP is, and that's it 🔑. That's why all objects in the l2tpSecurityGroup MUST NOT be accessible via unencrypted messages 🛑. It's also recommended that keys not show up in SNMP GET (or GET-NEXT or GET-BULK) responses, even when encryption is in use 🤫.
Implementers should really look at the security features in the SNMPv3 framework 🌈. Specifically, the User-based Security Model in RFC 2574 [RFC2574] and the View-based Access Control Model in RFC 2575 [RFC2575] are recommended 👑.
And finally, it's the customer or user's job to make sure the SNMP entity giving access to this MIB is configured so only principals (users) with legitimate rights can reach those objects 🧚. Nobody else gets in, bestie 💖.
6.0 Acknowledgements 🌸
Huge thanks to the L2TP working group members who helped shape the content and structure of this MIB 🫶✨.
7.0 References 📚
- [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999.
- [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990.
- [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991.
- [RFC1215] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991.
- [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
- [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
- [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
- [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990.
- [RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996.
- [RFC1906] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996.
- [RFC2572] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999.
- [RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999.
- [RFC1905] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
- [RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999.
- [RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999.
- [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999.
- [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Palter, "Layer Two Tunneling Protocol - L2TP", RFC 2661, August 1999.
- [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
- [RFC2667] Thaler, D., "IP Tunnel MIB", RFC 2667, August 1999.
- [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
8. Authors' Addresses ✨
Okay bestie, time to meet the squad behind this one 🫶 Here are the three people who wrote it:
Evan Caves Occam Networks Inc. 77 Robin Hill Road Santa Barbara, CA 93117
EMail: evan@occamnetworks.com
Pat Calhoun Black Storm Networks 110 Nortech Parkway San Jose, CA 95134
EMail: pcalhoun@bstormnetworks.com
Ross Wheeler DoubleWide Software, Inc. 2953 Bunker Hill Lane Suite 101 Santa Clara, CA 95054
Email: ross@doublewidesoft.com
9. Full Copyright Statement 💅
Copyright (C) The Internet Society (2002). All Rights Reserved. 🌈
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💖
Acknowledgement 🎀
Funding for the RFC Editor function is currently provided by the Internet Society. 🦋
📦 where this page comes from
- ietf: rfc3371 2002-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms