Subscriber Management Overview
RtBrick’s modular and scalable subscriber management, referred to as next-generation access infrastructure (ng-access), supports a range of access protocols including PPPoE, L2TPv2, IPoE (DHCPv4/v6), and RADIUS. This system is designed to deliver carrier-grade internet access services, with a focus on scalability, interoperability, and robustness. By providing support for multiple access protocols, RBFS ensures flexibility in deployment and compatibility with various network configurations, which is crucial for operators looking to provide consistent and high-quality services to their customers.
In this context, a subscriber refers to a customer connected through a Broadband Network Gateway (BNG). The BNG manages the connection by handling various protocols and sessions. Each subscriber is associated with a unique MAC address within a VLAN.
Providers that use separate VLANs for different services (e.g. internet and voice) may create multiple independent subscribers for the same customer or household. Although these subscribers might share certain QoS hierarchies, they are otherwise completely independent. Usually, VLANs used for services like IPTV or voice do not require subscriber management using static L3 interfaces with a traditional DHCP relay (non-subscriber).
A subscriber may have different forms of connectivity, depending on the access method used, such as PPPoE or IPoE. Thus, subscriber management involves overseeing customer connections, ensuring proper authentication, authorization, and accounting (AAA) of each subscriber, and maintaining the smooth operation of these sessions within a BNG. Effective subscriber management is key to maintaining high levels of customer satisfaction, as it directly impacts the reliability and performance of the internet services provided.
RBFS supports the following different protocol combinations to tailor an access network:
-
PPPoE Subscriber: PPPoE/PPP Session and DHCPv6 (Prefix Delegation)
-
L2TP Subscriber: PPPoE/PPP Session and L2TP Session
-
IPoE Subscriber: DHCPv4 or DHCPv6
RtBrick’s implementation utilizes a distributed architecture to enhance both scalability and stability. The distributed nature of this architecture allows multiple processes to manage different aspects of subscriber connections concurrently, reducing bottlenecks and ensuring that the system can handle a large number of subscribers efficiently. Carrier networks often need to interoperate with a wide variety of client devices from different vendors, each requiring adherence to established industry standards and RFCs. This complexity necessitates a robust and flexible approach to managing different network interactions.
Furthermore, these networks must cope with the diverse behaviors of numerous access devices, some of which may have non-standard implementations but cannot be easily replaced due to logistical or cost-related constraints. This adds to the complexity of subscriber management, as non-standard devices may behave unpredictably, requiring additional handling to maintain stable connections. To address these challenges, RBFS provides a protocol stack specifically tailored to offer best-in-class interoperability, ensuring reliable connectivity across a diverse range of client devices. This approach not only ensures that the network can interoperate with devices from various vendors but also allows for customization and adaptation to unique network scenarios.
Overall, RtBrick’s subscriber management solution is designed to meet the needs of modern carrier networks by providing a flexible, scalable, and reliable platform for managing customer connections. Its distributed architecture, combined with support for a wide array of protocols and strong adherence to industry standards, makes it well-suited to handle the challenges posed by diverse client environments and evolving network requirements. This ensures that network operators can provide a seamless and high-quality experience to their customers, even in the face of varying device capabilities and non-standard behaviors.
Supported Platforms
Not all features are necessarily supported on each hardware platform. Refer to the Platform Guide for the features and the sub-features that are or are not supported by each platform.
Subscriber Management Daemons
There are four main daemons in the RtBrick distributed access architecture:
The subscriber daemon (subscriberd) serves as the central component, managing the current subscriber state and handling Authentication, Authorization, and Accounting (AAA). The roles of each daemon are as follows:
-
subscriberd: The subscriber daemon is responsible for subscriber management and AAA, which can be performed locally, via RADIUS, or through other methods. It also serves as the interface to the forwarding infrastructure, responsible to request per-subscriber QoS, filters, and more.
-
pppoed: The PPPoE daemon handles PPPoE and PPP sessions for subscribers including subprotocols as ICMPv6 and DHCPv6 where the implemenation for PPPoE differs compared to IPoE.
-
l2tpd: The L2TP daemon is responsible to manage L2TPv2 tunnels and sessions.
-
ipoed: The IPoE (IP-over-Ethernet) daemon handles protocols related to IPoE subscribers like DHCPv4 and DHCPv6.
Subscriber Identifier
Each subscriber in RBFS is uniquely identified by a 64-bit number called subscriber-id, which remains unique across all RBFS processes and even across chassis in the context of high availability.
This uniqueness is achieved through the following format:
-
The first 4 bits identify the chassis, starting from 0.
-
The next 4 bits identify the process:
-
0x00 subscriberd (e.g. L2BSA, test, …)
-
0x01 pppoed (PPPoE sessions)
-
0x02 l2tpd (reserved for LNS)
-
0x03 ipoed (DHCPv4/v6)
-
-
The following 8 bits are used to identify the application sharding instance. For example, instances such as
pppoed.1,pppoed.2, and so on. While currently not in use, these bits provide the ability to partition load across multiple instances of the same process if needed to enhance scalability. -
The remaining 48 bits uniquely identify the subscriber, allowing for up to 281,474,976,710,656 unique subscribers per application instance before repetition, but even in the unlikely case of rollover, RBFS ensures uniqueness.
The subscriber portion always starts at '1', meaning that after a reboot, the subscriber identifiers will begin from the same value. These identifiers are consistent across multiple BNG, unless the chassis-id is explicitly set, which is required only for stateful high-availability configurations. Therefore, this number should not be used as a globally unique, non-repeating identifier in customer databases or management systems.
VLAN Modes and Encapsulations
RBFS supports both 1:1 VLAN (VLAN-per-subscriber) and N:1 VLAN (shared VLAN) models for PPPoE and IPoE subscribers. It supports various VLAN encapsulations. Subscriber VLANs are dynamically created by specifying VLAN ranges with corresponding configurations. After successful authentication, RBFS generates the subscriber IFL, which includes the dynamic VLAN.
1:1 VLAN Model (VLAN-per-subscriber)
In the 1:1 VLAN model, each subscriber is assigned a unique VLAN. This provides a direct one-to-one mapping between VLANs and subscribers. New services can be added easily without affecting others. The 1:1 model is recommended because it is simple and offers flexibility for features like backhauling, bitstream access, and QoS. As a result, more providers are migrating from the N:1 to the 1:1 VLAN model.
The following diagram illustrates a dedicated customer VLAN for each subscriber, showing the one VLAN per subscriber setup.
This model is defined by the maximum number of subscribers per VLAN in the access-interface configuration, which has a default value of 1. As a result, the 1:1 VLAN model is also the default in RBFS.
N:1 VLAN Model (shared-VLAN)
The shared VLAN model offers many-to-one (N:1) subscriber-to-service connectivity, where multiple subscribers share a single VLAN. Unlike the 1:1 model, where each subscriber has a dedicated VLAN, the N:1 model provides a shared VLAN for many subscribers. A drawback of the shared VLAN model is the lack of logical isolation between subscribers at the VLAN level.
This results in certain limitations for IPoE subscribers, such as the lack of support for features like HTTP redirect, subscriber ACL, NAT, and IGMP for IPoE N:1 subscribers.
The following diagram shows a single VLAN that is connected to many subscribers.
This model is defined by the maximum number of subscribers per VLAN in the access-interface configuration, which defaults to 1. Increasing this value beyond 1 enables the N:1 VLAN model for the corresponding access-interface.
Auto-sensing VLAN TPID
In modern telecommunications networks, managing traffic for wholesale partners presents challenges, especially when the network operator lacks knowledge of the specific TPID (Tag Protocol Identifier) used in arriving traffic. This can lead to inefficiencies in network handling and potential service disruptions. To address this issue, RBFS supports Auto-sensing VLAN TPID which automatically detects and processes traffic tagged with different TPIDs. Specifically, this functionality will support both TPID 0x8100, commonly referred to as 802.1q, and TPID 0x88a8, referred to as 802.1ad.
The auto-sensing mechanism will utilize the initial subscriber-initiated packet, such as PPPoE Discovery packets (PADI, PADR), DHCP Discovery, or DHCPv6 Solicit packets, to determine the appropriate TPID. This ensures that the system can adapt to the tagging method used by the incoming traffic without requiring prior knowledge.
The default behavior is auto-sensing the TPID based on the first incoming packet, offering maximum flexibility. However, network operators will still have the option to explicitly define the outer-vlan-encapsulation in the access-interface configuration if required, overriding the auto-sensing functionality when needed. This approach enhances the scalability and efficiency of handling wholesale traffic across various network environments.
This applies to double-tagged profiles only! For single-tagged profiles, the default is 802.1q and cannot be changed, while for untagged profiles, no TPID check is performed as there is no VLAN present.
Authentication, Authorization, and Accounting Using RADIUS
Remote Authentication Dial-In User Service (RADIUS) is a protocol that provides centralized Authentication, Authorization, and Accounting (AAA) for all types of subscribers. RADIUS servers can perform as authentication and accounting servers. Authentication servers maintain authentication records for subscribers.
The subscriber daemon optionally requests authentication using RADIUS access request messages before permitting subscribers access. Accounting servers handle accounting records for subscribers. The subscriber daemon transmits RADIUS accounting-on, start, interim, and stop messages to the servers. Accounting is the process of tracking subscriber activity and network resource usage in a subscriber session. This includes the session time called time accounting and the number of packets and bytes transmitted during the session called volume accounting. A RADIUS server can behave as a change of authorization (CoA) client, allowing dynamic changes for subscriber sessions. The subscriber daemon supports both RADIUS CoA messages and disconnects messages. CoA messages can modify the characteristics of existing subscriber sessions without loss of service, disconnect messages can terminate subscriber sessions. Each RADIUS request from the subscriber daemon includes the RADIUS accounting-session-id attribute (type 44) with a format that is configurable in the AAA configuration profile and includes at least the subscriber-id to identify the corresponding subscriber. The default format (<subscriber-id>.<timestamp>) includes also a Unix timestamp to ensure that the tuple of NAS-Identifier (e.g. hostname) and Accounting-Session-Id is global and unique to be usable as a key in RADIUS databases.
Additionally, to subscriber-id and accounting-session-id each subscriber consists also of a subscriber-ifl build based on physical port information and subscriber-id (ifp: ifp-0/0/1 and subscriber-id: 72339069014638610 → subscriber-ifl: ppp 0/0/1/72339069014638610) which is required as a handle in the RBFS forwarding infrastructure.
| The subscriber-id is an unsigned 64-bit integer which is shown as a hex number in Wireshark. |
Each subscriber is formed based on configuration profiles and individual settings retrieved via RADIUS. Conflicts between RADIUS-defined attributes and profile attributes are solved by prioritizing those received from RADIUS which is common best practice for broadband access concentrators. New subscribers are signalled via RADIUS access request and either accepted by RADIUS access-accept or rejected by RADIUS access-reject message from the RADIUS server. The RADIUS access-accept includes all attributes required to form the subscriber like IP addresses, DNS servers, and referenced configuration profiles. Some of those attributes can be changed by RADIUS dynamically using CoA requests without disconnecting the subscriber.
RADIUS Accounting
A RADIUS Acct-Status-Type attribute is used by the RADIUS client (subscriber daemon) to mark the start of accounting (for example, upon booting) by specifying Accounting-On and to mark the end of accounting (for example, just before a scheduled reboot) by specifying Accounting-Off. This message is often used by RADIUS servers to automatically close/terminate all open accounting records/sessions for the corresponding client, and therefore must not be sent to servers belonging to a profile that was already used/started for accounting.
Per default, the assumption is that all servers referenced by a RADIUS profile share the same states and therefore accounting-on must be only sent to one of those before the first accounting-start is sent.
RADIUS Accounting-On/Off messages are optionally enabled in the RADIUS Profile Configuration using the accounting-on-off attribute. The additional attribute accounting-on-wait prevents any new session until accounting has started meaning that the Accounting-On response is received.
Currently, Accounting-Off is not implemented.
|
RADIUS accounting requests are often used for billing and therefore should be able to store and retry over a more extended period (commonly up to 24 hours or more) which can be optionally enabled in the RADIUS profile configuration using the accounting-backup attribute. The maximum backup accounting hold time in seconds is defined in the attribute accounting-backup-max.
RADIUS Redundancy
RBFS allows configuring multiple RADIUS authentication and accounting servers for redundancy and or load-balancing. RADIUS redundancy ensures high availability in subscriber authentication, authorization, and accounting services. You can configure multiple RADIUS servers, and when one goes down, another takes over.
The following algorithms are supported:
-
DIRECT (default): Requests are sent to the same server where the last request was sent. If the subscriber daemon receives no response from the server, requests are sent to the next server.
-
ROUND-ROBIN: Requests are sent to servers in sequence, starting with the one following the server that handled the last request. If the subscriber daemon router receives no response from the server, requests are sent to the next server.
RADIUS NAS Port Identifier
RADIUS NAS-Port-id is used to identify the port of a network access router that the subscriber management feature uses to authenticate subscribers.
The RADIUS attribute NAS-Port-Id (87) is formatted such as the following:
<NAS-IDENTIFIER>#<IFP>#<OUTER-VLAN>#<INNER-VLAN>#<ACI>#<ARI>
The Agent-Circuit-Id (ACI) and Agent-Remote-Id (ARI) are replaced with an empty string (##) if not available.
PPP over Ethernet (PPPoE)
PPP over Ethernet (PPPoE) is the common standard for internet access in the market.
PPPoE Session ID
The PPPoE session ID field is an unsigned 16-bit number as described in RFC2516. The values 0 and 65535 are reserved, with 0 used for PADI/PADO messages and 65535 reserved for future use. The session ID is unique within a broadcast domain (including IFP and VLANs) and for each subscriber device’s MAC address. However, it is not unique per device or application instance. The session ID will change each time the session is reconnected.
PPPoE Service Name
When a subscriber device sends a PADI or PADR packet, the packet may include a service name field that specifies a particular service the client is requesting. Though, the system internally ignores the service name from the request, the name is still copied to the response packet sent back to the subscriber device.
If the request does not include any service name, the server’s response (PADO or PADS) will include a default service name called access that ensures compatibility with certain clients, such as the Linux ‘pppd’.
PPPoE AC-Cookie
This TAG is actually used to aid in protecting against denial-of-service attacks, but it is primarily used in RBFS to decide if a received PADR is a retry for an already answered (PADS send) one. The value itself is unpredictable and generated securely but it does not protect from reply attacks.
If a client receives this TAG in PADO, it MUST return the TAG unmodified in the following PADR. The TAG_VALUE is binary data of any value and length and is not interpreted by the Host.
The AC-Cookie is generated based on 8-bit salt followed by MD5 hash of salt, client MAC and dynamic PPPoE cookie secret.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SALT | MD5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The PPPoE cookie secret is randomly generated during the PPPoE daemon startup.
The AC-Cookie in the PADR creating the session is stored in the PPPoE PPP session object. For any received PADR it can be checked if there is a session on the same broadcast domain (IFP and VLAN’s) and MAC with the same AC-Cookie. In this case, the PADS is just retried.
If the broadcast domain and MAC is equal but AC-Cookie is different, this PADR must be considered as a new request.
This allows to separate two different PPPoE sessions on the same VLAN from the same MAC as frequently used by some service providers.
PPPoE Session Limit
A customer line is typically represented by one (single-tagged) or two VLAN (double-tagged) on a physical interface with a limitation to one session, which is also called the 1:1 VLAN mode.
In some cases, the customer CPE will set up multiple PPPoE sessions on a single VLAN which requires MAC limitations greater than one but less or equal to the per VLAN limitation.
Therefore RBFS supports two different session limitations in the access interface configuration (Access Interface Configuration), one per VLAN (max-subscribers-per-vlan) and an additional per client MAC address (max-subscribers-per-mac) both set to 1 per default as required for 1:1 VLAN mode.
The limitation of sessions per client MAC address must be less or equal the sessions per VLAN and the default set to one for both limits.
MTU Profiles
Bare metal switch hardware is typically limited in the number of supported MTU values.
So RBFS has introduced the concept of MTU profiles with different types like physical,
ip, IPoE, or pppoe. The last one is reserved for use with PPPoE sessions and applies to
IPv4 and IPv6 traffic.
supervisor@switch: cfg> show config forwarding-options mtu-profile
{
"rtbrick-config:mtu-profile": [
{
"mtu-profile-name": "IP-MTU-1500",
"size": 1500,
"type": "ip",
"action": "redirect-to-cpu"
},
{
"mtu-profile-name": "IP-MTU-9202",
"size": 9202,
"type": "ip",
"action": "drop"
},
{
"mtu-profile-name": "__default_pppoe__",
"size": 1492,
"type": "pppoe",
"action": "redirect-to-cpu"
}
]
}
| The physical access interface should be configured with an MTU profile large enough to serve all IPoE and PPPoE MTU profiles, including the additional overhead for PPPoE and VLAN headers. Further details about interface MTU profiles can be found in the Interfaces Configuration Guide. |
The Q2a/Q2c platform supports up to 8 MTU profiles in total including the default PPPoE
profile default_pppoe. The default profile cannot be deleted but overwritten
to change size and action.
The action could be either drop or redirect-to-cpu. The action drop silently discards
all oversized packets. The action redirect-to-cpu punts oversized packets to the CPU where
those could be either fragmented or dropped with ICMP response.
Fragmentation in software (cpu) must be explicitly enabled:
supervisor@switch: cfg> show config forwarding-options fragmentation
{
"rtbrick-config:fragmentation": {
"ipv4": {
"state": "cpu"
}
}
}
MTU Profile Support for PPPeE Subscribers
The Point-to-Point Protocol (PPP) facilitates the negotiation of a Maximum Receive Unit (MRU) between endpoints, which is then applied as the Maximum Transmission Unit (MTU) on the opposite end of the PPP link. It is standard for each endpoint to independently negotiate its MRU, leading to potentially different MTU values for each direction of the PPP connection.
As an Internet Service Provider (ISP), control over the MTU/MRU sizes utilized for PPP over Ethernet (PPPoE) is not completely under your control. To address this, RBFS adopts a unique approach to managing PPPoE MTU profiles. Within RBFS, you can configure multiple PPPoE MTU profiles, however, they collectively count as a single entity against the eight MTU profile slots available on the Q2a/Q2c platform.
When a client initiates an MRU request via PPP Link Control Protocol (LCP) Configure-Request, RBFS employs this value to identify a matching MTU profile. This process involves sequentially comparing the requested MRU against an ordered list of MTU profiles until a profile with an MTU size equal to or greater than the requested MRU is located. If an exact match is found, the corresponding profile is selected, the exact match counter is incremented, and the MRU is deemed acceptable.
If no exact match exists, the system selects the closest, yet smaller, MTU profile from the list. This selection
increments the best match counter, and the MTU from this profile is proposed to the client through a
PPP LCP Configure-Nak message. Should the client reject the proposed MRU after three attempts, RBFS applies the
default MTU profile default_pppoe as fallback MTU profile. This protocol ensures that the client’s requested
MRU is honored, but the transmission is governed by the largest available PPPoE MTU profile, thereby maximizing
client compatibility.
For example, if a client requests an MRU of 1482 bytes but only profiles for 1472 and 1492 bytes are configured, the system will offer 1472 bytes as the best match through a PPP LCP Configure-Nak. The client may accept this offer by submitting a new PPP LCP Configure-Request for 1472 bytes or persist with the initial request of 1482 bytes. After three iterations without agreement, the fallback profile is activated, accepting the client’s MRU of 1482 bytes but applying the default MTU of 1492 bytes. This approach is justified as most Customer Premises Equipment (CPE) devices support TCP Maximum Segment Size (MSS) clamping based on the negotiated MRU, ensuring that at least TCP traffic adheres to the negotiated limit. Furthermore, it is not unusual for CPEs to accept packets exceeding the negotiated MRU, which is why a larger MTU profile is designated as the fallback.
The negotiated MRU and applied MTU can be verified with the following command for every single PPPoE session.
user@switch: op> show pppoe session 72339069014638648 detail
Subscriber-Id: 72339069014638648
State: ESTABLISHED
...
PPP LCP:
...
MRU: 1492 Peer: 1492
MTU: 1492 Profile: __default_pppoe__
...
The command show pppoe mtu-profile lists all PPPoE MTU profiles
in increasing order, with two statistics about the exact and best match.
supervisor@switch: op> show pppoe mtu-profile Profile MTU Exact Match Best Match PPPoE-MTU-1320 1320 0 0 PPPoE-MTU-1456 1456 0 0 PPPoE-MTU-1472 1472 0 0 __default_pppoe__ 1492 0 0
The exact and best match counters can be used by operators to verify if the configured MTU profiles fit their environment or should be adopted.
As specified in RFC 2516, the Point-to-Point Protocol over Ethernet (PPPoE) requires a maximum negotiated MTU/MRU of 1492 bytes. However, RFC 4638 introduces the PPP-Max-Payload Tag, which extends the maximum negotiable MTU/MRU beyond 1492 bytes. This enhancement aims to reduce fragmentation within emerging broadband networks.
To configure an MTU/MRU exceeding 1492 bytes, a PPPoE client must incorporate the PPP-Max-Payload Tag within the PADI and PADR packets. Should the PPP-Max-Payload Tag specify a value greater than 1492 bytes, and if either the PPP LCP MRU or the MTU outlined in the access-profile is also configured above 1492, the tag will be replicated into the PADO and PADS packets issued by the RBFS. Echoing the PPP-Max-Payload Tag to the client signales support for MTU/MRU beyond 1492 bytes.
The value indicated by the PPP-Max-Payload Tag establishes the maximum threshold for both MTU and MRU settings.
Therefore, the highest permissible MTU/MRU is determined by the smaller of the two values, the configured PPP LCP MTU/MRU or the PPP-Max-Payload Tag’s value.
At least one of the following values must be set to a value of more than 1492 bytes:
set access access-profile pppoe-dual protocol ppp lcp mru 1500 set access access-profile pppoe-dual protocol ppp lcp mtu 1500
It is also required to set an MTU profile with the desired MTU size:
set forwarding-options mtu-profile pppoe-1500 set forwarding-options mtu-profile pppoe-1500 size 1500 set forwarding-options mtu-profile pppoe-1500 type pppoe set forwarding-options mtu-profile pppoe-1500 action redirect-to-cpu
For L2TPv2 tunneled PPPoE sessions, the MTU is enforced by the LNS. It’s usual behavior that the LNS renegotiates the MTU. So LAC may not know the actual MTU. This is the reason why RBFS does not apply an MTU profile for such sessions.
RBFS overwrites the selected MTU profile with default_l2tp for L2TPv2 sessions. This profile must be explicitly created, otherwise it is ignored. The action must be drop because ICMP or fragmentation is not supported for tunneled sessions.
supervisor@switch: cfg> show config forwarding-options mtu-profile __default_l2tp__
{
"rtbrick-config:mtu-profile": [
{
"mtu-profile-name": "__default_l2tp__",
"size": 1492,
"type": "pppoe",
"action": "drop"
}
]
}
This configuration allows to optionally enforce an MTU on LAC if needed.
Following an example MTU profile configuariton for PPPoE supporting all MTU values between the minimum of 1280 and maximum of 1500 in steps of 8 bytes.
supervisor@switch: cfg> show config forwarding-options mtu-profile
{
"rtbrick-config:mtu-profile": [
{
"mtu-profile-name": "__default_pppoe__",
"size": 1492,
"type": "pppoe",
"action": "redirect-to-cpu"
},
{
"mtu-profile-name": "PPPoE-MTU-1280",
"size": 1280,
"type": "pppoe",
"action": "redirect-to-cpu"
},
{
"mtu-profile-name": "PPPoE-MTU-1288",
"size": 1288,
"type": "pppoe",
"action": "redirect-to-cpu"
},
{
"mtu-profile-name": "PPPoE-MTU-1296",
"size": 1296,
"type": "pppoe",
"action": "redirect-to-cpu"
},
{
"mtu-profile-name": "PPPoE-MTU-1304",
"size": 1304,
"type": "pppoe",
"action": "redirect-to-cpu"
},
{
"mtu-profile-name": "PPPoE-MTU-1312",
"size": 1312,
"type": "pppoe",
"action": "redirect-to-cpu"
},
{
"mtu-profile-name": "PPPoE-MTU-1320",
"size": 1320,
"type": "pppoe",
"action": "redirect-to-cpu"
},
{
"mtu-profile-name": "PPPoE-MTU-1328",
"size": 1328,
"type": "pppoe",
"action": "redirect-to-cpu"
},
{
"mtu-profile-name": "PPPoE-MTU-1336",
"size": 1336,
"type": "pppoe",
"action": "redirect-to-cpu"
},
{
"mtu-profile-name": "PPPoE-MTU-1344",
"size": 1344,
"type": "pppoe",
"action": "redirect-to-cpu"
},
{
"mtu-profile-name": "PPPoE-MTU-1352",
"size": 1352,
"type": "pppoe",
"action": "redirect-to-cpu"
},
{
"mtu-profile-name": "PPPoE-MTU-1360",
"size": 1360,
"type": "pppoe",
"action": "redirect-to-cpu"
},
{
"mtu-profile-name": "PPPoE-MTU-1368",
"size": 1368,
"type": "pppoe",
"action": "redirect-to-cpu"
},
{
"mtu-profile-name": "PPPoE-MTU-1376",
"size": 1376,
"type": "pppoe",
"action": "redirect-to-cpu"
},
{
"mtu-profile-name": "PPPoE-MTU-1384",
"size": 1384,
"type": "pppoe",
"action": "redirect-to-cpu"
},
{
"mtu-profile-name": "PPPoE-MTU-1392",
"size": 1392,
"type": "pppoe",
"action": "redirect-to-cpu"
},
{
"mtu-profile-name": "PPPoE-MTU-1400",
"size": 1400,
"type": "pppoe",
"action": "redirect-to-cpu"
},
{
"mtu-profile-name": "PPPoE-MTU-1408",
"size": 1408,
"type": "pppoe",
"action": "redirect-to-cpu"
},
{
"mtu-profile-name": "PPPoE-MTU-1416",
"size": 1416,
"type": "pppoe",
"action": "redirect-to-cpu"
},
{
"mtu-profile-name": "PPPoE-MTU-1424",
"size": 1424,
"type": "pppoe",
"action": "redirect-to-cpu"
},
{
"mtu-profile-name": "PPPoE-MTU-1432",
"size": 1432,
"type": "pppoe",
"action": "redirect-to-cpu"
},
{
"mtu-profile-name": "PPPoE-MTU-1440",
"size": 1440,
"type": "pppoe",
"action": "redirect-to-cpu"
},
{
"mtu-profile-name": "PPPoE-MTU-1448",
"size": 1448,
"type": "pppoe",
"action": "redirect-to-cpu"
},
{
"mtu-profile-name": "PPPoE-MTU-1456",
"size": 1456,
"type": "pppoe",
"action": "redirect-to-cpu"
},
{
"mtu-profile-name": "PPPoE-MTU-1464",
"size": 1464,
"type": "pppoe",
"action": "redirect-to-cpu"
},
{
"mtu-profile-name": "PPPoE-MTU-1472",
"size": 1472,
"type": "pppoe",
"action": "redirect-to-cpu"
},
{
"mtu-profile-name": "PPPoE-MTU-1480",
"size": 1480,
"type": "pppoe",
"action": "redirect-to-cpu"
},
{
"mtu-profile-name": "PPPoE-MTU-1488",
"size": 1488,
"type": "pppoe",
"action": "redirect-to-cpu"
},
{
"mtu-profile-name": "PPPoE-MTU-1490",
"size": 1490,
"type": "pppoe",
"action": "redirect-to-cpu"
},
{
"mtu-profile-name": "PPPoE-MTU-1500",
"size": 1500,
"type": "pppoe",
"action": "redirect-to-cpu"
}
]
}
MTU Profile Support for IPoE Subscribers
Unlike the PPPoE protocol, which can negotiate MTU dynamically, IPoE relies on a fixed MTU setting. The MTU value is predefined and remains constant for all IPoE subscribers using the configured access interface.
For IPoE subscribers, MTU is statically configured and is applied at the access interface level.
Configuration commands for the MTU profile for IPoE subscribers.
set access access-profile ipoe set access access-profile ipoe instance default set access access-profile ipoe protocol dhcp enable true set access access-profile ipoe protocol dhcp lease-time 3600 set access access-profile ipoe protocol dhcpv6 enable true set access access-profile ipoe protocol dhcpv6 lifetime 3600 set access access-profile ipoe protocol ipoe ip-mtu-profile ipoe_mtu_1500
It is also required to set an MTU profile with the desired MTU size:
set forwarding-options mtu-profile ipoe_mtu_1500 set forwarding-options mtu-profile ipoe_mtu_1500 size 1500 set forwarding-options mtu-profile ipoe_mtu_1500 type ip set forwarding-options mtu-profile ipoe_mtu_1500 action drop
Following is an example of access profile IPoE:
supervisor@rtbrick.net: cfg> show config access access-profile ipoe
{
"rtbrick-config:access-profile": [
{
"profile-name": "ipoe",
"instance": "default",
"protocol": {
"dhcp": {
"enable": "true",
"lease-time": 3600
},
"dhcpv6": {
"enable": "true",
"lifetime": 3600
},
"ipoe": {
"ip-mtu-profile": "ipoe_mtu_1500"
}
},
"address-family": {
"ipv4": {
"enable": "true",
"pool-name": "poolv4"
},
"ipv6": {
"enable": "true",
"pool-name": "poolv6",
"prefix-delegation-pool-name": "poolv6pd"
}
}
}
]
}
Following an example MTU profile configuariton for IPoE:
supervisor@DT-STD-23-2401>bm13-tst.fsn.rtbrick.net: cfg> show config forwarding-options mtu-profile
{
"rtbrick-config:mtu-profile": [
{
"mtu-profile-name": "ipoe_mtu_1500",
"size": 1500,
"type": "ip",
"action": "drop"
}
]
}
PPPoE VLAN Profiles
This chapter describes the VLAN profile feature. If enabled for the access interface, then incoming sessions (e.g. PPPoE PADI/PADR) are not honored unless matching vlan-profile is found.
The VLAN profiles must be added to the table global.vlan.profile owned by PPPoE daemon.
All entries in this table are ephemeral and therefore lost after reboot or PPPoE daemon restart.
Example:
{
"table": {
"table_name": "global.vlan.profile"
},
"objects": [
{
"attribute": {
"ifp_name": "ifp-0/1/2",
"outer_vlan_min": 128,
"outer_vlan_max": 128,
"inner_vlan_min": 1,
"inner_vlan_max": 4095,
"access_profile_name": "access-profile-vlan"
}
}
]
}
PPPoE Dual-Stack IPv4/IPv6 with DHCPv6
The whole IPv6 control plane of a PPPoE session like ICMPv6 router-solicitation (RS), ICMPv6 router-advertisement (RA) and DHCPv6 is handled in the PPPoE daemon (pppoed).
The PPPoE daemon handles received router solicitations by responding with router advertisements and is sending frequent router advertisements based on configured intervals.
The other-config flag in the router-advertisement is automatically set if DHCPv6 is enabled for this particular subscriber. This flag signals that there is more information available via DHCPv6.
DHCPv6 over PPPoE is different to DHCPv6 over Ethernet because of the special characteristics of point-to-point protocols. DHCPv6 over PPPoE is supporting delegated IPv6 prefixes (IA_PD) and DNS options only. Unsupported IA options (IA_NA and IA_TA) or options that can be served will be rejected with status code options as defined per RFC.
The delegated IPv6 prefix served by DHCPv6 will be assigned to the subscriber via RADIUS
or local pool regardless of the protocols negotiated with the client. DHCPv6 was primarily
designed for use in Ethernet networks. The fact that Ethernet is connectionless requires
that DHCPv6 servers must manage releases for the clients and free them automatically if a lease
expires. Such extensive release management is not needed for connection-oriented protocols
like PPPoE where addresses are assigned to the PPPoE session. This fact allows to
implementing DHCPv6 nearly stateless on the server side by just tracking if an assigned prefix
is assigned or released. This is tracked in the attribute ipv6pd_negotiated of the PPPoED/SubscriberD (global.ppp.1.subscriber.result) result object and copied to the
actual subscriber object (local.access.subscriber). As this use case is covered by PPPoE, there is no lease expiry implemented.
The delegated-prefix is added to the subscriber-ifl only if negotiated and removed if not negotiated. The presence of delegated prefix in the subscriber-ifl is used by IFMD to add or remove the forwarding entry.
If DHCPv6 is enabled but no delegated prefix provided, only DNS is served in response if available.
PPPoE DHCPv6 Server DUID
The DHCPv6 server identifier DUID is generated based on IP6CP negotiated interface-identifier as shown below:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DUID-Type 3 (DUID-LL) | hardware type 27 (EUI64) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| interface-identifier |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Layer Two Tunneling Protocol (L2TPv2)
This chapter describes the RtBrick Layer Two Tunneling Protocol (L2TPv2) implementation. This document describes also the corresponding configuration and operations commands for PPPoE access services with PPP tunneling using the Layer Two Tunneling Protocol version 2 (L2TPv2) on RtBRick FullStack (RBFS).
Typically, a user obtains a Layer 2 (L2) point-to-point connection to a Broadband Network Gateway (BNG) using the PPPoE protocol as described in RFC 2516 and runs PPP over that connection. In the most common case, the L2 termination point and PPP session endpoint reside on the same physical device. Tunneling protocols, such as L2TPv2 provide a dynamic mechanism for extending PPP by allowing the L2 and PPP endpoints reside on different devices that are interconnected by an IP network. This separation allows the actual processing of PPP packets to be divorced from the termination of the L2 circuit. The L2TP access concentrator (LAC) physically terminates the L2 connection and tunnels the PPP packets across an IP network to the L2TP network server (LNS). The LNS then terminates the logical PPP connection.
| RFC and draft compliance are partial except as specified. |
To establish a PPPoE session via L2TP, the tunnel-type must be configured as L2TP. This configuration can be achieved either for local users or by utilizing the corresponding tunnel-type attribute through RADIUS.
# Local User
cfg> set access user-profile local@l2tp tunnel-type L2TP
# FreeRADIUS
"radius@l2tp" Cleartext-Password := "test"
Service-Type = Framed-User,
Framed-Protocol = PPP,
Tunnel-Type:0 = L2TP
Defining an L2TP configuration profile is essential, which can be referenced through an access-profile or by employing the appropriate RADIUS VSA. The actual tunnels may either be defined locally via an L2TP pool configuration or set up dynamically through RADIUS.
| Currently, RBFS supports L2TP subscriber sessions with EtherType 0x8100 (802.1Q) only; it does not support EtherType 0x88a8 (802.1ad). |
L2TP LAC
The L2TP Access Concentrator (LAC) is a node that acts as one side of an L2TP tunnel endpoint, and is a peer to the L2TP Network Server L2TP LNS. The LAC sits between a LNS and a remote system, and forwards packets to and from each.
L2TP LNS
The L2TP Network Server (LNS) is a node that acts as one side of an L2TP tunnel endpoint and is a peer to the L2TP Access Concentrator L2TP LAC. The LNS is the logical termination point of a PPP session that is being tunneled from the remote system by the LAC.
| The LNS role is currently not supported! |
L2TP Tunnel Selection
Each new session creates a session request object (local.l2tp.session.request) to track the tunnel selection progress, the currently selected ones, and which are already tried. This object is automatically deleted if the session setup is successful.
All tunnels in state DEAD are skipped in the tunnel selection but considered at the end if no other tunnels are available. Tunnels with a session limit reached are not considered for further sessions. To select a tunnel, the L2TP daemon first generates list of preferred tunnels based on tunnel preference, where the lowest value has the highest priority. The configured L2TP tunnel selection algorithm decides how to select a tunnel out of the remaining tunnels with the same preference. The RANDOM algorithm selects the tunnel randomly whereas BALANCED selects the least filled tunnel based on the number of sessions.
Following the L2TP tunnel pool order/priority in case, there are multiple pools available for a single subscriber:
-
RADIUS defined tunnel (RFC2866)
-
RADIUS VSA (RtBrick-L2TP-Pool) or local user profile
-
L2TP configuration profile
L2TP Control Channel
The control channel is responsible for the orderly passing of control messages between the tunnel endpoints and acts as a transport layer for reliable delivery of control messages and tunnel keep alive services for the tunnel.
Each L2TP tunnel is split into the actual tunnel object with all the information exchanged during tunnel establishment plus the FSM state and a separate control channel with the sequence numbers, window size, and thresholds changed with every sent and received packet.
RBFS sent a ZLB ACK only if there are no further messages waiting in queue for that peer, as well as to acknowledge multiple packets at once.
The HELLO keep-alive messages are also part of the control channel and only send if there is no other message sent if the queue is empty and no other message send during the hello interval.
L2TP Access Line Information (RFC5515)
Connect-Speed-Update-Notification (CSUN)
The Connect-Speed-Update-Notification (CSUN) is an L2TP control message sent by the LAC to the LNS to provide transmit and receive connection speed updates for one or more sessions.
| This implementation will send one CSUN request per session! |
CSUN requests are disabled per default and can be enabled in the L2TP profile L2TP Profile Configuration.
CSUN messages are defined in RFC5515, which is not widely supported. Therefore those messages are marked as not mandatory in RBFS to allow interwork with LNS servers not supporting RFC5515.
RFC2661:
The Mandatory (M) bit within the Message Type AVP has special meaning. Rather than an indication of whether the AVP itself should be ignored if not recognized, it is an indication as to whether the control message itself should be ignored. Thus, if the M-bit is set within the Message Type AVP and the Message Type is unknown to the implementation, the tunnel MUST be cleared. If the M-bit is not set, then the implementation may ignore an unknown message type.
| RFC and draft compliance are partial except as specified. |
Connect-Speed-Update-Request (CSURQ)
The Connect-Speed-Update-Request (CSURQ) is an L2TP control message sent by the LNS to the LAC to request the current transmission and receive connection speed for one or more sessions.
| Sending or responding to CSURQ requests is currently not supported! |
Access Line Information L2TP Attribute Value Pair Extensions
The corresponding access line information for a subscriber is included in the ICRQ message as defined in RFC5515.
Connect Speed Values
The default value for TX and RX Connect Speed is set to 1000000000 (1G) which is replaced by the actual data rate upstream/downstream of the corresponding access line information object or directly set using the RADIUS attributes RtBrick-L2TP-Tx-Connect-Speed (42) and RtBrick-L2TP-Rx-Connect-Speed (43).
IPoE
IP-over-Ethernet (IPoE) is a popular alternative to PPPoE based access using DHCP for IPv4 and DHCPv6 for IPv6 where both protocols are handled in the IPoE daemon (ipoed).
IPoE subscribers are identified by IFP, optional VLAN and client MAC address.
The dynamic creation of IPoE subscribers is triggered by the first DHCPv4 discovery or
DHCPv6 solicit request received. Any response is postponed until the subscriber is
successfully authenticated using known authentication methods like none, local
or RADIUS. For DHCP mode server all addresses are assigned during authentication to the subscriber and used by DHCPv4 and DHCPv6 to handle client requests. For the DHCP relay mode, all IP addresses are allocated by an external DHCP server.
IPoE subscribers will be terminated automatically if all protocol bindings are deleted.
IPoE 1:1 VLAN Support
RBFS supports both 1:1 VLAN (VLAN Per Subscriber) model for subscriber traffic for IPoE subscribers.
1:1 VLAN (VLAN-per-subscriber) Model
In the 1:1 VLAN model, there is a unique dedicated customer VLAN for a subscriber, that is one VLAN per Subscriber. This model establishes a unique path between each subscriber interface and the router for data transmission by providing traffic separation for every subscriber.
1:1 model operations are relatively simple as it provides one-to-one mapping of specific VLANs to specific subscribers. New services can be added easily without affecting other subscribers and services with this model. However, in a large-scale deployment, this model demands highly scalable and robust routers that can manage many hundreds of VLANs.
The following diagram shows a dedicated customer VLAN for a subscriber, that is, one VLAN per Subscriber.
N:1 VLAN (Shared VLAN) Model
The Shared VLAN model provides many-to-one (N:1) subscriber-to-service connectivity. This model provides a single VLAN to many subscribers. Unlike in the 1:1 model, in which the VLAN is dedicated to a customer, N:1 provides a shared VLAN to many subscribers, and this VLAN carries all types of service (i.e., data, voice, video, etc.). One disadvantage of shared VLAN is the lack of logical isolation between user sessions at the VLAN level.
The following diagram shows a single VLAN that is connected to many subscribers.
Limitations for IPoE N:1 VLAN
Access services such as http-redirect, subscriber-acl, NAT, IGMP are not supported for IPoE N:1 subscribers.
IPoE Session Limit
A customer line is typically represented by one (single-tagged) or two VLAN (double-tagged) on a physical interface with a limitation to one subscriber, which is also called the 1:1 VLAN mode.
IPoE subscribers are implicitly limited to max one per MAC address, as client MAC address is used as part of the key to identify subscribers.
IPoE Username
For each IPoE subscriber, a username is generated automatically using
the client’s MAC address followed by @ipoe.
Example: fe:08:e8:ea:1d:32@ipoe
IPoE DHCPv6 Server DUID
The generated DHCPv6 server identifier DUID is from type 3 (DUID-LL) with hardware type 27 (EUI64) and IFP MAC address to derive the EUI64 interface identifier.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DUID-Type 3 (DUID-LL) | hardware type 27 (EUI64) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| interface-identifier |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPoE DHCP Relay
When IPoE is configured on relay mode, the system relies on an external DHCP server for IP address allocation and client configuration functions. The DHCP server contains a pool of IP addresses, and from that pool, it allocates addresses to subscribers. RBFS acts as a DHCP relay during its interaction with the DHCP server. The feature allows multiple RBFS instances to use a single centralized DHCP server for their IP allocation.
For information on how to configure IPoE in relay mode, see the section DHCPv4.
