A Broadband Remote Access Server (BRAS) is a device that terminates PPPoE sessions. The Point-to-Point Protocol (PPP) is used for communications between a client and a server. Point-to-Point Protocol over Ethernet (PPPoE) is a network protocol used to encapsulate PPP frames inside Ethernet frames.
Ethernet networks are packet-based, unaware of connections or circuits. Using PPPoE, Nokia users can dial from one router to another over an Ethernet network, then establish a point-to-point connection and transport data packets over the connection. In this application subscriber hosts can connect to the router using a PPPoE tunnel. There are two command available under PPPoE to limit the number of PPPoE hosts, one to set a limit that is applied on each SAP of the group-interface and one to set the limit per group-interface.
PPPoE is commonly used in subscriber DSL networks to provide point-to-point connectivity to subscriber clients running the PPP protocol encapsulated in Ethernet. IP packets are tunneled over PPP using Ethernet ports to provide the client’s software or RG the ability to dial into the provider network. Most DSL networks were built with the use of PPPoE clients as a natural upgrade path from using PPP over dial-up connections. Because the PPP packets were used, many of the client software was reusable while enhancements were made such that the client could use an Ethernet port in a similar manner as it did a serial port. The protocol is defined by RFC 2516, A Method for Transmitting PPP Over Ethernet (PPPoE).
PPPoE has two phases, the discovery phase and the session phase.
Discovery: The client identifies the available servers. To complete the phase the client and server must communicate a session-id. During the discovery phase all packets are delivered to the PPPoE control plane (CPM or MDA). The IOM identifies these packets by their Ethertype (0x8863).
PPPoE Active Discovery Initiation (PADI)
This broadcast packet is used by the client to search for an active server (Access Concentrator) providing access to a service.
PPPoE Active Discovery Offer (PADO)
If the access server can provide the service it should respond with a unicast PADO to signal the client it may request connectivity. Multiple servers may respond and the client may choose a server to connect to.
PPPoE Active Discovery Request (PADR)
After the client receives a PADO it uses this unicast packet to connect to a server and request service.
PPPoE Active Discovery Session-confirmation (PADS)
A server may respond to the client with this unicast packet to establish the session and provide the session-id. After the PADS was provided the PPP phase begins.
Session
After the session ID is established connectivity is available for the duration of the session, using Ethertype 0x8864. Either client or server can terminate a session.
During the life of the session the packets may be uniquely identified by the client’s MAC address and session-id. The session can terminate either by PADT sent by the client or server or by an LCP Terminate-Request packet.
During session creation, the following occurs:
PADI (control packet upstream)
This packet is delivered to the control plane. The control plane checks the service tag for service name. In the case multiple nodes are in the same broadcast domain the service tag can be used to decide whether to respond to the client. A relay tag can also be present.
PADO (control packet downstream)
The packet is generated by the control plane as response to the PADI message. The packet is forwarded to the client using the unicast packet directed at the client’s MAC address. The node populates the AC-name tag and service tag. The packet sources the forwarding Ethernet MAC address of the node. If SRRP is used on the interface, it uses the gateway address as the source MAC. When in a backup state, the packet is not generated.
PADR (control packet upstream)
This packet is delivered to the control plane. The packet is destined for the node’s MAC address. The control plane then generates the PADS to create the session for this request.
PADS (control packet downstream)
The control plane prepares for the session creation and sends it to the client using the client’s MAC address. The session-id (16-bit value) is unique per client. The session-id is populated in the response. After a session-id is generated, the client uses it in all packets. When the server does not agree with the client’s populated service tags, the PADS can be used to send a service error tag with a zero session-id to indicate the failure.
PADT (control packet upstream/downstream)
The packet is used to terminate a session. It can be generated by either the control plane or the client. The session-id must be populated. The packet is a unicast packet.
PPP session creation supports the LCP authentication phase.
During a session, the following forwarding actions occur:
Upstream, in the PPPoE before PPP phase, there is no anti-spoofing. All packets are sent to the CPM. During anti-spoof lookup with IP and MAC addressing, regular filtering, QoS and routing in context continue. All unicast packets are destined for the node’s MAC address. Only control packets (broadcast) are sent to the control plane. Keep-alive packets are handled by the CPM.
Downstream, packets are matched in the subscriber lookup table. The subscriber information provides queue and filter resources. The subscriber information also provides PPPoE information, such as the dest-mac-address and session-id, to build the packet sent to the client.
PPPoE-capable interfaces can be created in a subscriber interface in both IES and VPRN services (VPRN is supported on the 7750 SR only). Each SAP can support one or more PPPoE sessions depending on the configuration. A SAP can simultaneously have static hosts, DHCP leases and PPPoE sessions. See Limiting subscribers, hosts, and sessions for a detailed description of the configuration options to limit the number of PPPoE sessions per SAP, per group-interface, per SLA profile instance, or per subscriber.
RADIUS can be used for authentication. IP addresses can be provided by both RADIUS and the local IP pool, with the possibility of choosing the IP pool through RADIUS.
DHCP clients and PPPoE clients are allowed on a single SAP or group interface. If DHCP clients are not allowed, the operator should not enable lease-populate and similarly if PPPoE clients are not allowed, the operator should not enable the PPPoE node.
The DHCP lease-populate is for DHCP leases only. A similar command host-limit is made available under PPPoE for limits on the number of PPPoE hosts. The existing per sla-profile instance host limit is for combined DHCP and PPPoE hosts for that instance.
For authentication, local and RADIUS are supported.
RADIUS is supported through an existing policy. A username attribute has been added.
For PAP/CHAP, a local user database is supported and must be referenced from the interface configuration.
The host configuration can come directly from the local user database or from the RADIUS or DHCP server. A local host configuration is allowed through a local DHCP server with a local user database.
IP information can be obtained from the local user database, RADIUS, a DHCP server, or a local DHCP server.
If IP information is returned from a DHCP server. PPPoE options such as the DNS name are retrieved from the DHCP ACK and provided to the PPPoE client. An open authentication option is maintained for compatibility with existing DHCP-based infrastructure.
The DHCP server can be configured to run on a loopback address with a relay defined in the subscriber or group interfaces. The DHCP proxy functionality that is provided by the DHCP relay (getting information from RADIUS, lease-split, option 82 rewriting) cannot be used for requests for PPPoE clients.