Introduction to Subscriber Management

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 ([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.

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.

It is possible to configure multiple RADIUS authentication and accounting servers for redundancy and or load-balancing.

The following two algorithms are supported:

The RADIUS attribute NAS-Port-Id (87) is constructed as shown below:

The Agent-Circuit-Id (ACI) and Agent-Remote-Id (ARI) are replaced with an empty string (##) if not available.

As defined in RFC2516, the PPPoE session-id field is an unsigned 16-bit number with the reserved values 0 for PADI/PADO and 65535 for future use. The session-id will be guaranteed unique per broadcast domain (IFP and VLANs) and client MAC address, but either not unique per device or app instance. The session-id changes every time the session is reconnected.

The last service name from the request (PADI or PADR) is internally ignored but copied to the response (PADO or PADS). If the request does not include any service name, the response includes the default service name access for compatibility with some clients like Linux pppd.

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.

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.

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.

It is also possible that multiple customers share the same VLAN which is called N:1 VLAN mode. This mode typically requires a per VLAN limitation set to the maximum number of sessions per VLAN with an additional limitation of one session per MAC.

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.

The PPP protocol allows each endpoint to negotiate a maximum receive unit (MRU). This MRU is applied as the maximum transmission unit (MTU) on the other end of the PPP connection. Each endpoint negotiates its own MRU with the other peer. Thus using a different MTU per direction is not uncommon for PPP, even if not desired.

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 or pppoe. The last one is reserved for use with PPPoE sessions and applies to IPv4 and IPv6 traffic.

A configured size of 1492 bytes limits the size of the IPv4 or IPv6 header plus payload.

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.

The Q2C platform supports up to 8 MTU profiles in total. The amount of pppoe profiles is limited to 6 including the default profile _default_pppoe_. The default profile can’t be deleted but overwritten to change size and action.

The command show pppoe mtu-profile lists all PPPoE MTU profiles in increasing order, with two statistics about the exact and best match.

If a client requests an MRU via PPP LCP Configure-Request, this value is used to search for an appropriate MTU profile. This is done by iterating over the ordered list of MTU profiles, as long as the received MRU is greater than the MTU size. If the requested MRU is found in the list of MTU profiles, the exact match counter is incremented, and the MRU is accepted.

In case the requested MRU is not found, the last MTU profile found is selected and the best match counter is incremented. The selected MTU is then offered to the client via PPP LCP Configure-Nak. If the offered MRU is not accepted by the client after three offers, a fallback profile is applied. This means that the requested MRU from the client is accepted, but the largest pppoe MTU profile is applied. This algorithm was built to ensure most client compatibility.

Let’s assume a client requests the MRU 1482, but only profiles for 1472 and 1492 are configured. In this case, 1472 is offered as the best match via PPP LCP Configure-Nak. The client could either accept the offer by sending a PPP LCP Configure-Request with the MRU 1472 or try again with the original value of 1482. This is repeated up to three times before the fallback profile is applied. In this case, the client MRU of 1482 is accepted but the maximum MTU of 1492 is applied. The majority of CPE devices support TCP MSS clamping using the negotiated MRU of 1482. So at least TCP traffic is still limited to the negotiated MRU. This is the reason for applying a larger MTU profile as the fallback profile. It’s also common that a CPE still accepts packets larger than the negotiated MRU.

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.

The negotiated MRU and applied MTU can be verified with the following command for every single PPPoE session.

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.

This configuration allows to optionally enforce an MTU on LAC if needed.

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:

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.

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.

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.

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 RADOM algorithm selects the tunnel randomly whereas BALANCED selects the least filled tunnel based on a number of sessions.

Following the L2TP tunnel pool order/priority in case, there are multiple pools available for a single subscriber:

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.

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.

It is also possible that multiple customers share the same VLAN which is called N:1 VLAN mode. This mode typically requires a per VLAN limitation set to the maximum number of subscribers per VLAN.

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.

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

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.