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 33 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 Chapter 7, Configuring Point-to-Point Protocol, runs above the PPPoE layer.
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:
- The host (PPPoE client) broadcasts a PPPoE Active Discovery Initiation (PADI) packet to all remote ACs in the network.
- 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.
- The host sends a unicast PPPoE Active Discovery Request (PADR) packet to the AC to which it wants to connect.
- 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 Chapter 15, Configuring Dynamic Interfaces and Chapter 16, 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 specific service name tag in the PADI packet that it broadcasts to remote ACs, or it can include an empty service name tag of zero length to indicate that any service is acceptable.
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.
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. You can configure up to 16 different PPPoE service name tables per E-series router to:
- Define the set of specific service name tags that the router advertises in the PADO packets sent to PPPoE clients.
- Control whether the router responds to (terminate) or ignores (drop) PADI requests containing an empty service name tag.
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. Every PPPoE service name table includes one empty service name tag, which is a tag of zero length used to represent any service. In addition, you can configure up to 16 specific service name tags per table to specify custom values such as an ISP name or class of service.
- Action—Each service name tag has an associated action: terminate (the default action) or drop. For the empty service name tag, you can specify that the router ignore (drop), rather than respond to (terminate), all PADI requests containing the empty service name tag. By contrast, when you configure a specific (custom) service name tag, you cannot specify the action; the default action, terminate, is always used.
For example, Table 15 shows a PPPoE service name table containing four entries: an empty service name tag (" ") associated with the drop action, and three specific service name tags. Note that the only action currently supported for a specific service name tag is terminate.
Enabling the 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 16.
Include only the agent-remote-id suboption (suboption 2) of the tags supplied by the PPPoE intermediate agent |
host1(config)#radius remote-circuit-id-format agent-remote-id |
Include both the agent-circuit-id suboption (suboption 1) and the agent-remote-id suboption (suboption 2) of the tags supplied by the PPPoE intermediate agent |
host1(config)#radius remote-circuit-id-format agent-circuit-id agent-remote-id |
Include the NAS-Identifier [32] RADIUS attribute with either or both of the agent-circuit-id and agent-remote-id suboptions of the tags supplied by the PPPoE intermediate agent |
host1(config)#radius remote-circuit-id-format nas-identifier agent-circuit-id host1(config)#radius remote-circuit-id-format nas-identifier agent-remote-id host1(config)#radius remote-circuit-id-format nas-identifier agent-circuit-id agent-remote-id |
Append the agent-circuit-id suboption 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). For details about how the router implements this format, see Format for dsl-forum-1 Keyword. |
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
- 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 router or the E320 router, the router uses the actual adapter value (0 or 1) in the dsl-forum-1 format. For ERX-14xx models, ERX-7xx models, and the ERX-310 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.
Format Examples for dsl-forum-1 Keyword
Table 17 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 router or E320 router, and adapter 0 (no adapter value) for interfaces on ERX-14xx models, ERX-7xx models, and the ERX-310 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 JUNOSe System Event Logging Reference Guide, Chapter 1, System Logging Overview.
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: