Overview

E Series routers use PPP over Ethernet (PPPoE) to enable multiple hosts to open PPP sessions to the router using one or more bridging modems. When service providers want to maintain the session abstraction associated with PPP, PPPoE is used with Broadband Remote Access Server (B-RAS) technologies that provide a bridged Ethernet topology. PPPoE can be configured over ATM or on Ethernet modules with or without VLANs.

Figure 37 shows how PPPoE allows the router to handle multiple PPP sessions originating on an Ethernet module to be multiplexed over one PVC on an ATM interface. PPP, as described in Configuring Point-to-Point Protocol, runs above the PPPoE layer.

Figure 37: PPPoE over ATM

The router handles the server part of PPPoE session management and never initiates a setup of a PPPoE session. The router only responds to session requests that are sent to it by the remote PPP client. After the sessions are set up, the router demultiplexes the sessions based on session identifiers assigned to a specific connection.

PPPoE Stages

PPPoE has two distinct stages: Discovery and Session.

Discovery

PPPoE includes a Discovery protocol that allows each PPP session to learn the Ethernet address of the remote peer, as well as establish a unique session identifier. When a host wants to initiate a PPPoE session, it must first perform Discovery to identify the Ethernet MAC address of the peer and establish a PPPoE session ID.

Although PPP defines a peer-to-peer relationship, Discovery is inherently a client-server relationship. In the Discovery process, a host acting as a client discovers a remote access concentrator (AC), which acts as the server.

Based on the network topology, there may be more than one remote AC with whom the host can communicate. The Discovery stage allows the host to discover all remote ACs and then select the one to which it wants to connect.

In summary, the Discovery stage consists of the following four steps:

1. The host (PPPoE client) broadcasts a PPPoE Active Discovery Initiation (PADI) packet to all remote ACs in the network.
2. One or more remote ACs respond to the PADI packet by sending a PPPoE Active Discovery Offer (PADO) packet, indicating that they can serve the client request. The PADO packet includes the name of the AC from which it was sent.
3. The host sends a unicast PPPoE Active Discovery Request (PADR) packet to the AC to which it wants to connect.
4. The selected AC sends a PPPoE Active Discovery Session (PADS) packet to confirm the session.

Session

When Discovery is successfully completed, both the host and the selected remote AC have the information they need to build their point-to-point connection over Ethernet.

The only parameter that you can configure is the number of PPPoE sessions.

Note: The router supports dynamic PPPoE interfaces. Also, profiles support PPPoE interfaces. See Configuring Dynamic Interfaces and Configuring Dynamic Interfaces Using Bulk Configuration, for more information.

PPPoE Service Name Tables

PPPoE clients use service name tags, as defined in RFC 2516, to request that an AC support certain services. The client includes a custom service name tag in the PADI packet that it broadcasts to remote ACs. Alternatively, the client can include an empty service name tag of zero length to indicate that any service is acceptable, or an unknown service name tag to represent a service not yet configured in the PPPoE service name table.

On receipt of a PADI packet that it can serve, the AC responds with a PADO packet. The PADO packet contains a service name tag that is identical to the one in the PADI, as well as one or more additional service name tags indicating other services that the AC offers.

A PPPoE service name table consists of one or more service name entries and their associated action. The PPPoE service name table can include three types of service name tags:

• Custom service name tag (serviceName) — A service entry that represents a specific client service that an AC can support. The length of the custom service name tag can be up to 31 alphanumeric characters; for example, myQoSClass or my ISPService. You can optionally associate an action (drop or terminate) with a custom service. The default action for a custom service is terminate.
• Empty service name tag (empty-service-name) — A service entry of zero length that is used to represent any service. The router either responds with a PADO packet to all PADI requests containing an empty service name tag, or denies (drops) all PADI requests based on the action configured for the service.
• Unknown service name tag (unknown-service-name) — A service entry that has not been configured in the PPPoE service name table. When a PPPoE client includes an unknown service name tag in the PPPoE service name table, the router responds based on the action (drop or terminate) associated with the unknown service name entry.

  The default action associated with the unknown service name tag depends on the PPPoE service name table configuration. If all the services in the table are configured to drop, the default action for the unknown service name tag is terminate. If all the services in the table are configured to terminate, the default action for the unknown service name tag is drop. If both terminate and drop are configured for services in the table, all unknown service name tags are dropped by default.

Features

PPPoE service name tables enable an AC, such as an E Series router, to support multiple service name tags in addition to the empty service name tag and the unknown service name tag. You can configure up to 16 PPPoE service name tables per E Series router to:

• Define the set of service name tags (empty service name, custom service name, and unknown service name) that the router advertises in the PADO packets sent to PPPoE clients.
• Control whether the router responds to (terminate) or denies (drop) PADI requests based on the action associated with the service name tags.

Table Structure

Each entry, or row, in a PPPoE service name table consists of the following components:

• Service name tag—Service name tags specify the client services that an AC supports. You can add three types of service name tags to the PPPoE service name table: empty service name, custom service name (serviceName), and unknown service name. Every PPPoE service name table includes one empty service name tag and one unknown service name service tag. An empty service name tag is a service tag of zero length that is used to represent any service. An unknown service name service tag is used to represent a service tag that has not been configured in the service name table. In addition to these two tags, you can configure up to 16 custom service name tags per table.
• Action—Each service name tag has an associated action: terminate (the default action) or drop. For empty service name and unknown service name entries, you can use the action keyword with the service command to modify the default action associated with the service. For custom service name (serviceName) entries, using the action keyword with the service command is optional. The default action for a custom service tag entry is terminate.

For example, Table 19 shows a PPPoE service name table containing five entries: three custom service name tags, two associated with the terminate action and one associated with the drop action; an empty service name tag (“ ” ) associated with the drop action; and an unknown service name tag associated with the drop action.

Note: You can associate the drop action with a maximum of eight service tags in a PPPoE service name table.

Enabling the Service Name Table for Use

After you create a PPPoE service name table and populate it with entries, you must enable it for use with a static or dynamic PPPoE interface. To enable a PPPoE service name table for use with a static interface, you assign the table to the PPPoE major interface. To enable a PPPoE service name table for use with a dynamic interface, you add the table to a profile that is dynamically assigned to a PPPoE interface column. For details about configuring and using PPPoE service name tables, see Configuring PPPoE Service Name Tables.

Using the PPPoE Remote Circuit ID to Identify Subscribers

You can enable the router to capture and format a vendor-specific tag containing a PPPoE remote circuit ID transmitted from a digital subscriber line access multiplexer (DSLAM) device. The router can then send this value to a Remote Authentication Dial-In User Service (RADIUS) server or to a Layer 2 Tunneling Protocol (L2TP) network server (LNS) to uniquely identify subscriber locations.

This feature is supported on all modules on which you can configure PPPoE interfaces. The feature is particularly useful in Ethernet-based Broadband Remote Access Server (B-RAS) configurations as a means of uniquely identifying subscribers connected to the router on a single Ethernet link.

For detailed configuration instructions, see Configuring PPPoE Remote Circuit ID Capture.

Application

When a connection between an E Series router and a DSLAM is on an ATM interface, subscribers are typically assigned an ATM PVC to communicate with the router. Each ATM PVC is created on a different ATM 1483 subinterface. When a RADIUS server in this configuration sends messages to the router containing the NAS-Port-Id [87] RADIUS attribute, each ATM 1483 subinterface produces a unique NAS-Port-Id that can differentiate subscribers on the ATM link.

By contrast, when the connection between the router and the DSLAM is on an Ethernet interface that does not use either virtual LANs (VLANs) or stacked VLANs (S-VLANs), the NAS-Port-Id value is the same for all subscribers on the Ethernet link. Enabling the router to capture the remote circuit ID sent from the DSLAM and use it as a RADIUS or L2TP attribute facilitates the process of identifying individual subscribers on an Ethernet link.

PPPoE Remote Circuit ID Capture

When you enable capture of the PPPoE remote circuit ID by issuing the pppoe remote-circuit-id command, the E Series router captures the remote circuit ID value if it is sent from the DSLAM. The PPPoE intermediate agent on the DSLAM appends a vendor-specific tag containing the remote circuit ID to the existing PPPoE PADI or PADR packet and sends this packet to the E Series router. The PPPoE remote circuit ID value can be a maximum of 64 characters. The router stores this value on the line module on which the PPPoE interface is configured.

PPPoE Remote Circuit ID Format

By default, the router formats the captured PPPoE remote circuit ID to include only the agent-circuit-id suboption (suboption 1) of the PPPoE intermediate agent tags sent from the DSLAM. To configure a nondefault format for the captured PPPoE remote circuit ID, you can use one of the radius remote-circuit-id-format commands listed in Table 20.

For more information about configuring the format of the PPPoE remote circuit ID value, see radius remote-circuit-id-format.

Remote Circuit ID Delimiter

If the format of the PPPoE remote circuit ID consists of two or more components, the router uses a # character by default to delimit the components. Optionally, you can use the radius remote-circuit-id-delimiter command to configure a nondefault delimiter character (for example, ! or %) to separate multiple components in the PPPoE remote circuit ID value. For information about how to use this command, see radius remote-circuit-id-delimiter.

Format for dsl-forum-1 Keyword

When you specify the radius remote-circuit-id-format command with the dsl-forum-1 keyword, the router appends the agent-circuit-id suboption value to an interface specifier that is consistent with the recommended format in the DSL Forum Technical Report (TR)-101—Migration to Ethernet-Based DSL Aggregation (April 2006).

The format of the PPPoE remote circuit ID when you use the dsl-forum-1 keyword is as follows:

dslForum1InterfaceSpecifier#agent-circuit-id

where:

• dslForum1InterfaceSpecifier is the interface specifier in dsl-forum-1 format
• # is the default delimiter character
• agent-circuit-id is the agent-circuit-id suboption (suboption 1) of the PPPoE intermediate agent tags sent from the DSLAM

If the DSLAM transmits empty data for agent-circuit-id, the router appends the value 0/0/0/0/0/0 to dslForum1InterfaceSpecifier.

To obtain the value for dslForum1InterfaceSpecifier, the router translates an internally generated interface specifier into the format for the dsl-forum-1 keyword, using the following conventions:

• The dsl-forum-1 format for ATM interfaces is atm slot/adapter/port:vpi.vci
• The dsl-forum-1 format for Ethernet interfaces is eth slot/adapter/port:svlanId.vlanId
• For the E120 or the E320 routers, the router uses the actual adapter value (0 or 1) in the dsl-forum-1 format. For ERX14xx models, ERX7xx models, and the ERX310 router, which do not support an adapter value, the router sets the adapter value to 0 (zero).
• For Ethernet interfaces that use VLANs but do not use S-VLANs, the router sets the svlanId value to 4096 and uses the actual vlanId value in the dsl-forum-1 format.
• For Ethernet interfaces that use neither S-VLANs nor VLANs, the router sets both the svlanId value and the vlanId value to 4096 in the dsl-forum-1 format.
• The router ignores subinterface values for ATM and Ethernet interfaces in the translated dsl-forum-1 format.

  Note: The format of the interface specifier that the router generates internally is different from the interface specifier format that you use to configure interfaces on the router. For information about the interface types and specifiers to use when configuring interfaces on E Series routers, see Interface Types and Specifiers in JunosE Command Reference Guide.

Format Examples for dsl-forum-1 Keyword

Table 21 provides several examples of how the router uses the conventions described in Format for dsl-forum-1 Keyword to translate internally generated interface specifiers into the format of the dslForum1InterfaceSpecifier value. The examples in the table use adapter 1 for interfaces on an E120 or E320 router, and adapter 0 (no adapter value) for interfaces on ERX14xx models, ERX7xx models, and the ERX310 router.

Use by RADIUS or L2TP

Enabling the router to capture and format the PPPoE remote circuit ID sent from the DSLAM has no effect by itself. To use the PPPoE remote circuit ID value, you must send it to a RADIUS server, to an L2TP network server (LNS), or to both by doing one or more of the following:

• Issue the radius override calling-station-id remote-circuit-id command to substitute the remote circuit ID value for the standard Calling-Station-Id [31] RADIUS attribute.
• Issue the radius override nas-port-id remote-circuit-id command to substitute the remote circuit ID value for the standard NAS-Port-Id [87] RADIUS attribute.
• Issue the aaa tunnel calling-number-format command to generate L2TP Calling Number attribute value pair (AVP) 22 in a descriptive format that includes either or both of the agent-circuit-id (suboption 1) and agent-remote-id (suboption 2) suboptions of the PPPoE intermediate agent tags.

For more information about configuring RADIUS and L2TP on E Series routers, see the JunosE Broadband Access Configuration Guide.

System Event Log

You can use the radiusSendAttributes system event log category to troubleshoot applications that use PPPoE remote circuit ID capture. The radiusSendAttributes event category logs RADIUS attributes added to outbound RADIUS requests.

You can also use the log severity debug pppoeControlPacket command to configure a packet trace log for a PPPoE interface that includes the PPPoE remote circuit ID value captured on that interface. For information about how to use the log severity debug pppoeControlPacket command, see Troubleshooting.

For information about how to log system events, see Overview of System Logging.

PPPoE MTU Configuration

To avoid fragmentation and reassembly, Ethernet access networks require larger MTU sizes for PPP traffic. With JunosE PPPoE MTU, you can control the deployment of larger packet sizes. You can configure PPPoE MTU directly on the PPPoE interface or use a dynamic configuration profile. When you use the PPPoE MTU tag, each PPPoE subinterface can have a unique MTU value. Operational MTU is the lesser of the PPPoE MTU or the lower layer MTU minus the PPPoE overhead.

You can use the pppoe mtu command to set the MTU using a combination of lower layer restrictions and controls:

• Greater MTU than the current maximum permitted by RFC 2516, with the default equal to the current maximum setting (1494 octets)
• Optional setting for absolute maximum PPPoE MTU
• Optional use of a larger lower layer MTU
• Optional use of the PPPoE-Max-Mtu tag transmitted from the client