![]() |
SYSTEM ADMINISTRATOR GUIDE 64/1543-CRA 119 1170/1-V1 Uen C1 | ![]() |
Copyright
© Ericsson AB 2009–2010. All rights reserved. No part of this document may be reproduced in any form without the written permission of the copyright owner.
Disclaimer
The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.
Trademark List
SmartEdge | is a registered trademark of Telefonaktiebolaget LM Ericsson. | |
NetOp | is a trademark of Telefonaktiebolaget LM Ericsson. |
This document describes how to configure, monitor, and troubleshoot Point-to-Point Protocol (PPP) or PPP over Ethernet (PPPoE) on ports, channels, and PPP or PPPoE encapsulated circuits.
For information about troubleshooting PPP or PPPoE, see the BRAS Troubleshooting Guide.
This section provides an overview of the PPP and PPPoE support offered by the SmartEdge OS in the following sections.
PPP and PPPoE features comply with the following RFCs:
The current implementation does not support compression.
The SmartEdge OS supports PPP on the following ports, channels, and circuits:
On ATM PVCs, PPP encapsulation types include virtual circuit-multiplexed (VC-multiplexed), logical link control (LLC), Network Layer Protocol Identifier (NLPID), and serial (High-Level Data Link Control [HDLC]) encapsulations as described in RFC 2364.
PPP-encapsulated ATM PVCs, unlike RFC 1483-encapsulated ATM PVCs, can be dynamically bound to an interface; you can use the bind authentication command (in ATM PVC configuration mode) to dynamically bind a PPP-encapsulated ATM PVC to an interface on the basis of authentication.
If you use the bind subscriber command (in ATM PVC configuration mode), the PPP-encapsulated PVC is brought up unauthenticated, meaning that no authentication data is received from the PPP remote peer. The subscriber name and password are then supplied through the command-line interface (CLI), similar to a PVC with RFC 1483 bridged- or routed-encapsulation.
The bind authentication command allows you to specify the authentication protocol to be used in negotiating the PPP link. If you use the chap pap construct, for example, you indicate that both the Challenge Handshake Authentication Protocol (CHAP) and the Password Authentication Protocol (PAP) can be used, with CHAP negotiated first. CHAP uses a challenge and response protocol to provide authentication without sending clear text passwords over the network. The CHAP challenge value is sent in both the Request Authenticator field and the CHAP-Challenge Attribute (60) field of the RADIUS Access-Request messages. Other authentication protocol options are available. For a complete description of all options, see the description of the bind authentication command in the document, Configuring Bindings
If you are using remote authentication using the Remote Authentication Dial-In User Service (RADIUS), the local subscriber records are replaced by the corresponding subscriber records in the RADIUS database.
If you are using the CHAP, PAP, or both authentication protocols, the response from the RADIUS server (in attribute 18) is forwarded to the PPP client with the reason for the acceptance or rejection of the subscriber.
Another binding option is to use the bind authentication command with the optional context ctx-name construct to create a restricted dynamic binding of a PPP-encapsulated PVC to a specific context; this binding method denies the subscriber the ability to dynamically select a context (service).
An IP address is required. This IP address is assigned to the remote end of the PPP link, and there must be an interface with an IP address or network mask range that includes the IP address assigned to a subscriber during the IP Control Protocol (IPCP) or IPv6 Control Protocol (IPv6CP) phase of PPP (or that includes the IP address that has been directly configured for the subscriber). RADIUS servers must return an IP address for the subscriber that falls within the range of the interface that is configured in the appropriate context.
If the authentication procedure is successful, the PPP link is established and the circuit is implicitly bound to the interface with a network address mask that includes the address of the remote PPP endpoint. If no such interface exists, then the bind command fails.
If the remote PPP device is a router (or the remote segment of any other encapsulation type contains a router), it might be necessary to configure one or more static routes whenever the link is brought up. This is accomplished by one or more Routing Information Protocol (RIP) configuration commands in the subscriber record.
Ordinarily, any bind authentication command causes the subscriber’s session to be counted toward the maximum number of PPP structures allocated (which depends on your router and configuration), whether or not the subscriber is active. The alternative is to configure the system to operate so that only active PPP sessions count toward the maximum number of structures allocated. The effect is that the number of bind authentications you can have is increased, beyond the number that could actually bind and come up (PPP oversubscription).
Oversubscription does not affect the maximum number of subscribers that can be terminated in a particular context (established by the aaa max subscribers command in context configuration mode) or the hard limits allowed by the SmartEdge OS.
You configure PPP oversubscription using ppp auto encapsulation in the atm pvc (or its atm pvc explicit form) command (in ATM OC or ATM DS-3 configuration mode). For a complete description of both forms, see the document, Configuring Circuits.
Multilink PPP (MP) is an extension to PPP that allows a peer to use more than one physical link for communication. When using more than one physical link to connect two peers, you need a mechanism to load balance the connection across the two (or more) links in the bundle. MP is used to fragment the datagrams and send them across the multiple links in the bundle in a way that achieves optimum use of the media.
Both ends of the point-to-point links must be capable of supporting MP connections. The two ends configure the data link by swapping Link Control Protocol (LCP) packets during a link establishment phase. If MP is not successfully negotiated by the two ends of the link, MP is not enabled for the connection.
MP is implemented on the SmartEdge router in four forms:
Using this form of MP, you create a static MP bundle and add specific DS-1 channels, E1 channels, or E1 ports to it. For more information about configuring this form of MP and the constituent channels or ports, see the document, Configuring Link Aggregation.
Using this form of MP, you do not create the MP bundles; instead, the SmartEdge OS creates them dynamically, using the endpoint discriminator sent by the peer during the LCP negotiation and the subscriber name to determine whether to create a new MP bundle or add the session to a current MP bundle. The configuration for this form of MP and the constituent ATM PVCs is described later in this document in the MP Configuration on ATM PVCs section.
Using this form of MP, you do not create the MP bundles; instead, the SmartEdge OS creates them dynamically, using the endpoint discriminator sent by the peer during the LCP negotiation and the subscriber name to determine whether to create a new MP bundle or add the session to a current MP bundle.
To use this form of MP, you must use ports configured on a GE traffic card that has a packet processing ASIC (PPA) version 2 (PPA2) on the LNS. You must also use ports configured on a GE traffic card on the L2TP access concentrator (LAC). These traffic cards include the 4-port GE version 3 (GE3), 10- and 20-port GE 1020, and 10 GE (10GE) traffic cards. The configuration for this form of MP and the constituent L2TP tunnels is described later in this document, in the section MP Configuration for L2TP Subscribers. For more information about L2TP and MP for L2TP subscribers, see the document, Configuring L2TP.
Using this form of MP, you do not create the MP bundles; instead, the SmartEdge OS creates them dynamically, using the endpoint discriminator sent by the peer during the LCP negotiation and the subscriber name to determine whether to create a new MP bundle or add the session to a current MP bundle.
You can use MP using PPPoE with the following types of Ethernet encapsulation:
The system does not allow MP using PPPoE over ATM (PPPoEoA).
To use this form of MP, you must use ports configured on a GE traffic card that has a PPA2; these traffic cards include the GE3, GE1020, and 10GE traffic cards. The configuration for this form of MP is described later in this document in the document, Configure MP over PPPoE.
PPP subscriber and non-subscriber circuits can be single-stack or dual-stack. Single-stack circuits exclusively support one type of traffic (IPv4 or IPv6). Dual-stack circuits are authorized for both IPv4 and IPv6, and can simultaneously support both IPv4 and IPv6 traffic.
Dual-stack non-subscribers must be configured to support both IPv4 and IPv6 traffic.
Dual-stack subscribers use IPCP for IPv4 address negotiation and IPv6CP for IPv6 address negotiation. IPCP and IPv6CP are independent of one another; if IPv6CP fails, IPCP still operates and vice-versa. For details on configuring the SmartEdge router to support IPv6 or dual-stack subscriber services, see Configuring IPv6 Subscriber Services.
Keepalive checks are LCP echo messages sent over PPP sessions in the context to determine if sessions are still active (alive). Normally, when a PPP session is ending, the peer sends the SmartEdge OS an LCP termination request (TERMREQ) message to indicate that it is ending. Keepalive checks detect abnormal disconnects that the SmartEdge OS would not otherwise know about. In addition to facilitating accurate timing of accounting information, it is important to detect these abnormal terminations so that allocated system resources can be reallocated to new sessions.
The keepalive checks feature can be used with or without a data check option. The data check option is recommended when it is preferred to limit the overhead for PPP keepalive processing. However, using the data check option to determine that a session is no longer active can take longer than using the PPP keepalive feature without the data check option, by a length of one check interval. This condition occurs because with the data check enabled, the check interval timer is reset as long as data has been received since the last successful keepalive check.
If a session sends data and then abnormally terminates between keepalive checks, the SmartEdge OS has no indication that the session has terminated until the following check interval timer expires with no data being received. At that point, the SmartEdge OS begins sending LCP echo requests. Without a data check, the SmartEdge OS begins sending LCP echo requests, regardless of whether data has been received since the last check.
Table 1 compares the two scenarios. In both cases, the following configuration applies:
PPP Keepalives Without Data Check Enabled |
PPP Keepalives with Data Check Enabled | ||||
---|---|---|---|---|---|
Step in the Process |
Seconds Elapsed Since Previous Step |
Cumulative Seconds Elapsed |
Step in the Process |
Seconds Elapsed Since Previous Step |
Cumulative Seconds Elapsed |
Successful keepalive check—check interval timer reset to zero |
0 |
Successful keepalive check—check interval timer reset to zero |
0 | ||
Packets sent by the session |
5 |
5 |
Packets sent by the session |
5 |
5 |
Abnormal termination |
2 |
7 |
Abnormal termination |
2 |
7 |
Check interval timer expires; LCP echo request sent |
53 |
60 |
Check interval timer expires; data check indicates data has been received since the last successful keepalive check; check interval timer is reset |
53 |
60 |
Response timer expires; first retry LCP echo request sent |
10 |
70 |
Check interval timer expires; data check indicates no data has been received since the last successful keepalive check; LCP echo request sent |
60 |
120 |
Response timer expires; second retry LCP echo request sent |
10 |
80 |
Response timer expires; first retry LCP echo request sent |
10 |
130 |
Response timer expires; retry limit reached; session is torn down |
10 |
90 |
Response timer expires; second retry LCP echo request sent |
10 |
140 |
Response timer expires; retry limit reached; session is torn down |
10 |
150 | |||
Time elapsed between abnormal session termination and tear down |
83 |
Time elapsed between abnormal session termination and tear down |
143 |
The SmartEdge OS implementation of PPPoE supports the following features:
The SmartEdge OS supports PPPoE encapsulation on the following ports, channels, and circuits:
For information about the tasks and commands used to monitor, troubleshoot, and administer PPP and PPPoE features, see the document, Configuring Circuits.
Other documents with related commands include:
To configure PPP or PPPoE perform the tasks in the following sections.
For information about troubleshooting PPP, see the BRAS Troubleshooting Guide.
This section describes how to configure, PPP global attributes, a PPP-encapsulated port, channel, or ATM PVC, to configure MP on ATM PVCs or for L2TP subscribers and to configure a subscriber record for PPP.
To configure PPP global attributes, perform one or more of the tasks described in Table 2.
Step |
Task |
Root Command |
Notes |
---|---|---|---|
1. |
Specify the range with which the SmartEdge OS negotiates LCP option values for the MRU: | ||
For the SmartEdge router end of PPP sessions. |
Enter this command in global configuration mode. | ||
For the peer at the remote end of PPP sessions. |
Enter this command in global configuration mode. | ||
2. |
Enable MRU negotiation. |
||
3. |
Enable PPP keepalive checks. |
Enter this command in context configuration mode with the check-interval keyword. | |
4. |
Specify timing attributes. |
Enter this command in context configuration mode without the check-interval keyword. | |
5. |
Specify that a PPP termination request is sent to subscribers when they do not negotiate a valid IP address during the IPCP negotiation process. |
Enter this command in global configuration mode. |
To configure a PPP-encapsulated port, perform the tasks described in Table 3.
Step |
Task |
Root Command |
Notes |
---|---|---|---|
1. |
Specify PPP encapsulation for the DS-3, E3, E1, or POS port. |
Enter this command in DS-3, E3, E1, or port configuration mode. Specify the encapsulation type as ppp. | |
2. |
Create a static binding to an interface. |
To configure a PPP-encapsulated channel, perform the tasks described in Table 4.
Step |
Task |
Root Command |
Notes |
---|---|---|---|
1. |
Specify PPP encapsulation for the DS-3, DS-1, E1 channel or DS-0 channel group. |
Enter this command in DS-0, DS-1, DS-3, or E1 configuration mode. Specify the encapsulation type as ppp. | |
2. |
Create a static binding to an interface. |
To configure a PPP-encapsulated ATM PVC, perform the tasks described in Table 5.
Step |
Task |
Root Command |
Notes |
---|---|---|---|
1. |
Create one or more PPP-encapsulated ATM PVCs and access ATM PVC configuration mode. |
Enter this command in ATM OC or ATM DS-3 configuration mode. Specify the encapsulation type as ppp. | |
2. |
Create a binding with one of the following tasks: | ||
Create a static binding for a single ATM PVC through a subscriber record to an interface. |
This type of binding is not supported for ATM PVCs in PPP multilink bundles. | ||
Create static bindings for a set of ATM PVCs through the subscriber records. |
This type of binding is not supported for ATM PVCs in PPP multilink bundles. | ||
Create an unrestricted dynamic binding. |
|||
Create a restricted dynamic binding. |
You must specify the context to create a restricted dynamic binding. |
To configure MP using PPP-encapsulated ATM PVCs, perform the tasks described in Table 6. Enter all commands in global configuration mode.
Step |
Task |
Root Command |
Notes |
---|---|---|---|
1. |
Enable PPP multilink. |
||
2. |
Specify the endpoint discriminator. |
||
3. |
Optional. Specify priority and fragmentation threshold value for subscriber sessions. |
||
4. |
Configure one or more PPP-encapsulated ATM PVCs. |
For the commands to configure a PPP-encapsulated ATM PVC, see Table 5. |
To configure MP for L2TP subscribers, perform the tasks described in Table 7. Enter all commands in global configuration mode.
Step |
Task |
Root Command |
Notes |
---|---|---|---|
1. |
Enable PPP multilink. |
||
2. |
Optional. Specify the endpoint discriminator. |
||
3. |
Optional. Specify priority and fragmentation threshold value for subscriber sessions. |
||
4. |
Configure one or more L2TP tunnels. |
For the commands to configure an L2TP tunnel, see the document, Configuring L2TP |
To configure a circuit for PPP in the subscriber record, perform the tasks described in Table 8. Enter all commands in subscriber configuration mode.
Step |
Task |
Root Command |
Notes |
---|---|---|---|
1. |
Set the MTU used by PPP for the subscriber circuit. |
||
2. |
For subscriber sessions on PPP multilink bundles, limit the number of sessions a subscriber can access simultaneously. |
port-limit |
The maximum number of PPP multilink sessions (links) is 8. |
For descriptions of the basic tasks needed to configure a subscriber record, see the document, Configuring Subscribers.
To configure an interface for static PPP peer router IP address assignment, perform the tasks described in Table 9. Enter all commands in subscriber configuration mode.
Task |
Root Command |
Notes |
---|---|---|
Configures a static IP address that the SmartEdge system can proved to the static PPP peer devices during the establishment of PPP sessions. |
ip-address should belong to the same subnet as the interface. The peer ip-address assignment is only for PPP links (not for PPP subscriber sessions), and is applicable to only T1 cards; such as, the Channelized-DS3 cards. |
For descriptions of the basic tasks needed to configure a subscriber record, see Configuring Subscribers.
To configure Point-to-Point over Ethernet (PPPoE) global and 802.1Q profile attributes, perform one or more of the tasks described in Table 10. Enter all commands in global configuration mode, unless otherwise noted.
For information about troubleshooting PPPoE, see the BRAS Troubleshooting Guide.
Task |
Root Command |
Notes |
---|---|---|
Configure an option inside PPPoE daemon that terminates the PPPoE session after a PPP session is terminated. |
||
Enable acceptance and advertisement of any service name tag that is included in a PADI or PADR message. |
||
Specify which domains in the SmartEdge OS are advertised to PPPoE clients. |
||
Replace the default AC-Name PPPoE tag value. |
||
Specify the delay between sending a PADS packet and an LCP Configuration Request packet if the PPP peer has not started the LCP. |
||
Set the PPPoE PADO delay timer to a specified value for this 802.1Q profile. |
Enter in dot1q profile configuration mode. | |
Limit the number of PPPoE PADI messages that the system accepts in an interval for each MAC address. |
||
Limit the number of PPPoE PADR messages that the system accepts in an interval for each MAC address. |
To configure an Ethernet port for PPPoE, perform the tasks described in Table 11. Enter all commands in port configuration mode, unless otherwise noted.
Step |
Task |
Root Command |
Notes |
---|---|---|---|
1. |
Encapsulate the Ethernet port. |
Specify the encapsulation type as pppoe. | |
2. |
Bind the port with one of the following tasks: | ||
Create an unrestricted dynamic binding. |
You must specify the context to create a restricted dynamic binding. | ||
Create a restricted dynamic binding. |
You must specify the context to create a restricted dynamic binding. |
To configure a PPPoE-encapsulated ATM PVC, perform the tasks described in Table 12.
Step |
Task |
Root Command |
Notes |
---|---|---|---|
1. |
Create one or more PPPoE-encapsulated ATM PVCs and access ATM PVC configuration mode. |
Enter this command in ATM OC or ATM DS-3 configuration mode. Use the explicit keyword to create a range of PVCs. Use the on-demand keyword to configure a range of PVCs that are created only when needed. Specify the encapsulation type as pppoe. | |
2. |
Bind the ATM PVC with one of the following tasks: | ||
Create an unrestricted dynamic binding. |
|||
Create a restricted dynamic binding. |
You must specify the context to create a restricted dynamic binding. |
To configure a PPPoE-encapsulated 802.1Q PVC, perform the tasks described in Table 13.
Step |
Task |
Root Command |
Notes |
---|---|---|---|
1. |
Create a PPPoE-encapsulated 802.1Q PVC and access dot1q PVC configuration mode. |
Enter this command in port configuration mode. Specify the encapsulation type as pppoe. | |
2. |
Bind the 802.1Q PVC with one of the following tasks: | ||
Create an unrestricted dynamic binding. |
|||
Create a restricted dynamic binding. |
You must specify the context to create a restricted dynamic binding. |
To configure a child circuit on an ATM PVC for PPPoE, perform the tasks described in Table 14.
Step |
Task |
Root Command |
Notes |
---|---|---|---|
1. |
Create one or more parent ATM PVCs and access ATM PVC configuration mode. |
Enter this command in ATM OC or ATM DS-3 configuration mode. Use the explicit keyword to create a range of PVCs. Specify the encapsulation type as multi. | |
2. |
Create the PPPoE-encapsulated child circuit and access ATM child protocol configuration mode. |
Specify the encapsulation type as pppoe. | |
3. |
Bind the child circuit with one of the following tasks: | ||
Create an unrestricted dynamic binding. |
|||
Create a restricted dynamic binding. |
You must specify the context to create a restricted dynamic binding. |
To configure a child circuit on an 802.1Q PVC for PPPoE, perform the tasks described in Table 15.
Step |
Task |
Root Command |
Notes |
---|---|---|---|
1. |
Create the parent 802.1Q PVC and access dot1q PVC configuration mode. |
Enter this command in port configuration mode. Specify the encapsulation type as multi. | |
2. |
Create the PPPoE-encapsulated child circuit and access dot1q child protocol configuration mode. |
Specify the encapsulation type as pppoe. | |
3. |
Bind the child circuit with one of the following tasks: | ||
Create an unrestricted dynamic binding. |
|||
Create a restricted dynamic binding. |
You must specify the context to create a restricted dynamic binding. |
To configure a subscriber record for PPPoE, perform the tasks described in Table 16. Enter all commands in subscriber configuration mode.
Step |
Task |
Root Command |
Notes |
---|---|---|---|
1. |
Assign an IP address to a subscriber record or profile. |
||
2. |
Specify a password in the subscriber record. |
Use the same password that is specified in the bind subscriber or bind auto-subscriber command. | |
3. |
Specify optional attributes in the subscriber record or profile: | ||
Configure routes for multiple PPPoE sessions. |
|||
Create a PPPoE MOTM and enable the sending of it to subscribers. |
|||
Point a subscriber’s PPPoE client browser to a specified URL. |
For descriptions of the basic tasks needed to configure a subscriber record, see the document, Configuring Subscribers.
To configure MP using PPPoE, perform the tasks described in Table 17. Enter all commands in global configuration mode.
Step |
Task |
Root Command |
Notes |
---|---|---|---|
1. |
Enable PPP multilink. |
||
2. |
Optional. Specify the endpoint discriminator. |
||
3. |
Optional. Specify priority and fragmentation threshold value for subscriber sessions. |
||
4. |
Configure one or more PPPoE encapsulated Ethernet ports. |
For the commands to configure a PPPoE-encapsulated Ethernet port, see Table 11. |
To enable the generation of debug messages for Point-to-Point Protocol (PPP) events and display PPP information, perform the appropriate task listed in Table 18. Enter the clear and debug commands in exec mode; enter the show commands in any mode.
Task |
Root Command |
---|---|
Clear traffic counters for PPP-encapsulated ports and channels. |
|
Enable the generation of debug messages for various types of PPP events on PPP-encapsulated ports and channels. |
|
Display the current state for one or more PPP-encapsulated ports or channels or a brief summary. |
|
Display traffic counters for PPP-encapsulated ports and channels. |
To debug PPP sessions, examine the output from the show ppp counters and show ppp counters detail commands. If debug messages are needed, start with the debug ppp command with the exception keyword to look for events that indicate a malfunction. To display the most concise view of session negotiations, use the debug ppp command with the packet keyword.
This section provides examples of PPP and PPPoE configurations.
For information about troubleshooting PPP or PPPoE, see the BRAS Troubleshooting Guide.
This section provides examples of configuring PPP with dynamic and restricted dynamic binding, configuring MP on ATM PVCs and for L2TP subscribers.
In Figure 1, the host on the left is configured to run PPP over ATM. The SmartEdge OS is configured to dynamically bind the user to an IP interface assumed to be previously configured with an IP address of 10.1.3.1 and a mask of 255.255.255.0.
The following example shows how to create the ATM PVC, using an existing ATM profile, adsl, and indicates to the system that the PVC is to be bound using an authentication process:
[local]Redback(config)#port atm 3/1 [local]Redback(config-port)#atm pvc 100 300 profile adsl encapsulation ppp [local]Redback(config-pvc)#bind authentication chap pap
The following example constrains a PPP-encapsulated ATM PVC on an ATM OC port to be bound only in the isp.net context:
[local]Redback(config)#port atm 3/1 [local]Redback(config-atm-oc)#atm pvc 100 1011 profile ubr encapsulation ppp [local]Redback(config-pvc)#bind authentication pap context isp.net
The following example shows how to configure MP on PPP-encapsulated ATM PVCs using the IP address of the Ethernet management port, two ATM PVCs with identical configuration on the ATM traffic card in slot 3, and a subscriber with a limit of 2 sessions:
!Configure PPP multilink global attributes with IP address of Ethernet management port [local]Redback(config)#ppp multilink [local]Redback(config)#ppp our-options multilink endpoint-discriminator local-ip-address !Configure the links [local]Redback(config)#port atm 3/1 [local]Redback(config-port)#atm pvc 200 100 profile adsl encapsulation ppp [local]Redback(config-pvc)#bind authentication chap pap [local]Redback(config-pvc)#exit [local]Redback(config-port)#exit [local]Redback(config)#port atm 3/2 [local]Redback(config-port)#atm pvc 200 200 profile adsl encapsulation ppp [local]Redback(config-pvc)#bind authentication chap pap [local]Redback(config-pvc)#exit [local]Redback(config-port)#exit !Configure the subscriber [local]Redback(config)#context local [local]Redback(config-ctx)#subscriber joe [local]Redback(config-sub)#port-limit 2
The following example shows how to configure MP for L2TP subscribers using two Ethernet ports with identical configuration on the GE traffic card in slot 4 while configuring an L2TP network server (LNS). The example assumes that an LAC (L2TP access concentrator) has already been configured.
!Configure PPP multilink global attributes with IP address of Ethernet management port [local]Redback(config)#ppp multilink [local]Redback(config)#ppp our-options multilink endpoint-discriminator local-ip-address !Configure the LNS [local]Redback(config)#context lns [local]Redback(config-ctx)#no ip domain-lookup [local]Redback(config-ctx)#interface sub multibind [local]Redback(config-if)#ip address 100.1.1.1/24 [local]Redback(config-if)#ip pool 100.1.1.0/24 [local]Redback(config-if)#no logging console !Configure the subscriber [local]Redback(config-ctx)#subscriber default [local]Redback(config-ctx)#ip address pool [local]Redback(config-ctx)#exit !Configure the links [local]Redback(config)#card ge-10-port 4 [local]Redback(config)#port ethernet 4/1 [local]Redback(config-port)#no shutdown [local]Redback(config-ports)#bind interface tolns lac [local]Redback(config-port)#exit [local]Redback(config)#exit
This section provides examples of configuring PPPoE.
The following example shows how to configure a SmartEdge OS to advertise all of its domains (isp1, isp2, and isp3) during the PPPoE discovery protocol:
[local]Redback(config)#context isp1.net [local]Redback(config-ctx)#domain isp1 [local]Redback(config-ctx)#exit [local]Redback(config)#context isp2.net [local]Redback(config-ctx)#domain isp2 [local]Redback(config-ctx)#exit [local]Redback(config)#context isp3.net [local]Redback(config-ctx)#domain isp3 [local]Redback(config-ctx)#exit [local]Redback(config)#pppoe services all-domains
The next example shows how to configure a SmartEdge OS to advertise only the indicated domains, namely isp1 and isp2. Domains, corp1 and corp2, are not advertised, because the advertise keyword is not specified in the definitions of the two domains, and the marked-domains keyword is specified in the pppoe services command.
[local]Redback(config)#context isp1.net [local]Redback(config-ctx)#domain isp1 advertise [local]Redback(config-ctx)#exit [local]Redback(config)#context isp2.net [local]Redback(config-ctx)#domain isp2 advertise [local]Redback(config-ctx)#exit [local]Redback(config)#context corp1.com [local]Redback(config-ctx)#domain corp1 [local]Redback(config-ctx)#exit [local]Redback(config)#context corp2.com [local]Redback(config-ctx)#domain corp2 [local]Redback(config-ctx)#exit [local]Redback(config)#pppoe services marked-domains
The following example shows how to create a message of the minute (MOTM):
[local]Redback(config-sub)#pppoe motm System down 0400 today for scheduled maintenance
The following example replaces the first MOTM with a new one:
[local]Redback(config-sub)#pppoe motm Scheduled maintenance canceled for 03/29/2003.
The following example shows how to remove the existing MOTM so that no message is sent to subscribers:
[local]Redback(config-sub)#no pppoe motm
The following example shows how to set the 802.1Q foo profile to have a PADO delay time of 3 seconds:
[local]Redback(config)#dot1q profile foo [local]Redback(config-dot1q-profile)#pppoe pado delay 3
The following example shows how to remove the existing PADO delay:
[local]Redback(config-dot1q-profile)#no pppoe pado delay
The following example causes a PADM with the URL, http://www.loe.com/members/joe@local to be sent to the PPPoE client when the PPP session is established:
[local]Redback(config-ctx)#subscriber name joe [local]Redback(config-sub)#pppoe url http://www.loe.com/members/%U
The next example uses the pppoe url command to configure the subscriber default profile. Unless overridden by a named subscriber profile or the subscriber record itself, a PADM containing http://www.loe.com/members/name is sent to the PPPoE client of each subscriber when the PPP session is established:
[local]Redback(config-ctx)#subscriber default [local]Redback(config-sub)#pppoe url http://www.loe.com/members/%u
The following example shows how to configure MP on PPPoE with two PPPoE sessions for the subscriber. The configuration below results in two active PPP links for an MP subscriber on port 3/1 and port 3/2. The PPPoE client negotiates the same endpoint discriminator for both links:
!Configure PPP multilink global attributes [local]Redback(config)#ppp multilink [local]Redback(config)#ppp our-options multilink endpoint-discriminator local-ip-address !Configure the links [local]Redback(config)#port ethernet 3/1 [local]Redback(config-port)#encapsulation pppoe [local]Redback(config-port)#bind authentication chap pap [local]Redback(config-port)#exit [local]Redback(config)#port ethernet 3/2 [local]Redback(config-port)#encapsulation pppoe [local]Redback(config-port)#bind authentication chap pap [local]Redback(config-port)#exit !Configure the subscriber [local]Redback(config)#context local [local]Redback(config-ctx)#subscriber joe
[1] BRAS Troubleshooting Guide. |
[2] General Troubleshooting Guide. |
[3] Data Collection Guideline. |