Unit 4

PPP over ATM

PPP over ATM Rev. 3.2 Page: 4-1

 PPP over ATM Unit Objectives

• List the benefits of using PPP over ATM

• Compare and contrast IP addressing options in a PPP over ATM
environment
• Describe the basic Life of a Packet in a PPP over ATM
environment
• Describe the three different ways a PC can obtain its IP address
dynamically in a PPP over ATM environment
• Describe the purpose of the Domain Map
• Describe the function and use of Profiles
• Configure the ERX for PPP over ATM
• Describe ERX logging capabilities
• Verify PPP over ATM operation using show commands
and logging

PPP over ATM Rev. 3.2 Page: 4-2

 Remote Access… in the ‘Old Days’

Modem
RADIUS
tyler@isp1.com
Routers ISP1
RAS
PPP Session

Modem

RADIUS ISP2
paul@isp2.com

• Relatively slow access rates using dedicated POTS line

• Point to point session between PC and RAS
• RAS terminated the PPP session
• Packets sent to appropriate routers

In the remote access world of yesterday, relatively slow speed connections were made
using a dedicated POTS line. These connections, with speeds from 28.8 kbps to 56 kbps,
were one to one in nature. One PC, one phone line. This scenario worked relatively well
for the home environment when most families were lucky to have one PC. In this
scenario, the phone lines were terminated in a Remote Access Server (RAS), which also
terminated the PPP session and handled, in conjunction with RADIUS, all the
authentication work. From the RAS, the packets were sent on to the appropriate routers.
However, times have changed and needs have changed. More and more often, families
have more than one PC, yet only have one additional phone line to use for connectivity. In
addition, more and more users are demanding higher access rates. There must be a
better solution.

PPP over ATM Rev. 3.2 Page: 4-3

 Authentication in a xDSL Environment
PC w/Ethernet
Bridged 1483 NIC PC w/xDSL
PPP over ATM Modem PPP over
xDSL
Modem Ethernet
xDSL xDSL
Bridge Modem
Network
DSL
of PCs
PC w/ATM NIC Modem

Routed 1483
DSLAM xDSL
DSLAM Concentrator
Customer U

Network DSL ATM

Router Internet

ATM
DSL Switch
Customer Router RADIUS
Network
DHCP

• To maintain current dial-up model, complete with RADIUS

Authentication and Accounting Services
- PPP over ATM
- PPPoE over ATM

We just covered the first two B-RAS connection types, Bridged 1483 and Routed 1483.
These connection types are always on and do not provide any centralized user
authentication an authorization.
The second category of B-RAS connections attempts to maintain the current dial-up
model, complete with centralized user authentication and authorization. The DSL users
are still always on, but initially the users must authenticate through a RADIUS server.
They will also obtain their IP address from RADIUS or DHCP. This approach is often
referred to as PPP over ATM for a single user environment or PPP over Ethernet for a
multi-user environment.
With this approach, the customer can be billed based on usage if RADIUS accounting is
implemented.

PPP over ATM Rev. 3.2 Page: 4-4

 PPP over ATM - Single User per ATM PVC

DSL
Modem
PPP Session
tyler@isp1.com
ISP1
U

DSL ATM RADIUS

Customer Router
Network
PVC
ATM per Modem
Switch ERX
DSL DSLAM
Modem
ISP2
paul@isp2.com
RADIUS

• Single high speed interface supporting thousands of ATM

PVCs
• An ATM PVC or subinterface per modem supporting a
single PPP session
• PPP session between the user and the ERX

In our scenario, the ERX is servicing 2 ISPs - ISP1 and ISP2.

These ISPs have two types of customer connections to service using the ERX. The first
type is a single user connecting to a xDSL modem. This user’s PC will have an ATM NIC
installed which connects to the xDSL modem.
The ERX will support a single client on a single ATM subinterface. In other words, a one-
to-one relationship is formed.
This scenario uses PPP over ATM. An ATM PVC is configured for each user.
A PPP session will be established across this PVC between the user and the ERX. The
ERX will terminate this PPP session and act as a liaison or client for the authentication,
authorization, accounting, and address assignment associated with the user’s PPP client.
Over a single, high speed interface, thousands of ATM Permanent Virtual Circuits can be
configured to support thousands of remote DSL users.
To support this configuration, each ATM PVC will be configured with a single PPP
encapsulation to support a single user.

PPP over ATM Rev. 3.2 Page: 4-5

 IP Addressing Scheme ISP 1 - Option 1

DSL
Modem
tyler@isp1.com
192.168.1.2

Internet
DSL
Modem
gary@isp1.com U

192.168.1.6
DSL
Modem
IP Addresses on the ERX
PVC to tyler = 192.168.1.1/30
rich@isp1.com ERX PVC to gary = 192.168.1.5/30
192.168.1.10
PVC to rich = 192.168.1.9/30

• View each ATM PVC as a unique point-to-

point network
• Assign a single subnet to each ATM PVC
• Burns IP addresses

The ERX views all ATM PVCs as simple point-to-point IP interfaces. Each PVC is an
interface, and each interface is assigned an IP address.
In a PPP over ATM environment, IP addressing can be approached two ways. The first
way is to view each ATM PVC as a unique, point-to-point network. With this approach,
each PVC would be assigned a unique subnet. This approach is very straight-forward,
easy to manage, but it burns or uses up IP addresses quickly.

PPP over ATM Rev. 3.2 Page: 4-6

 IP Addressing Scheme - ISP1
Redistribute Connected
192.168.1.0/24
192.168.1.0
DSL
Modem
tyler@isp1.com
192.168.1.2
Loopback 1= Internet
DSL 192.168.1.1/24
Modem
gary@isp1.com U

192.168.1.3
DSL
Modem

rich@isp1.com ERX
192.168.1.4

• Think of the DSL users as one large LAN

• Assign a single subnet to the DSL users
• Use Unnumbered Interfaces on the ERX’s PVCs
- Reference a Loopback Interface on the ERX in the same subnet
• DSL user host routes cached dynamically into the IP routing table
- ip access-routes command
• Redistribute Directly Connected Networks
- Advertises the entire group of DSL users

With the second approach to IP address assignment in a PPP over ATM environment, the
ATM cloud is viewed as a large LAN. From the ERX’s perspective, a single subnet is
assigned to the group of xDSL users. Each DSL user is assigned a numbered IP address
from the subnet. On the ERX, a loopback interface is created and assigned an IP address
from the same subnet. The ATM PVCs on the ERX are not assigned numbered IP
addresses. Instead, the PVCs are configured as unnumbered IP interfaces, and reference
the loopback interface created with the IP address from the same subnet. This approach
conserves valuable IP address space.
In a PPP over ATM environment, the DSL users will typically obtain their IP addresses
dynamically. They may or may not obtain the same IP address every time they connect to
the network. In addition, this IP address must be inserted into the ERX’s routing table, tied
to the appropriate ATM PVC. To have the ERX automatically insert the DSL users host
route into the routing table, use the configuration command ip access-routes for each IP
interface.

PPP over ATM Rev. 3.2 Page: 4-7

 PPP over ATM Configuration Options

IP Datagram
PPP
DSL
Modem
RFC 2364 PPP
tyler@isp1.com
PPP Client ATM
ATM NIC
ISP1
U

ATM RADIUS
DSL
Customer Router PPP
Network over
ATM
DSLAM Switch ATM ERX
DSL
Modem
ISP2
paul@isp2.com RADIUS
PPP Client

There are several ways PPP over ATM can be implemented.

With the first method, a PC could have an ATM NIC card installed together with PPP over
ATM drivers. This PC is then connected to a xDSL modem. In this scenario, when the
PC wants to send IP data, that data is encapsulated into a PPP frame.
With the second method, a customer may use a DSL router with an integrated DSL/ATM
interface. This router may provide NAT services to devices within the customer’s network.
The router receives frames from the customer’s PCs, performs any necessary address
translation and encapsulates the IP datagrams in PPP.
The PPP frame is then fragmented into 53 byte ATM cells and sent over the appropriate
ATM interface.
These frames are then transmitted across the POTS connection, to the DSLAM, across
the ATM switch (if necessary) and are received by the ERX.
From the ERX’s perspective, both approaches are equivalent in that the ATM cells
received will first have a RFC 2364 header indicating PPP, then the PPP frame and finally
the IP datagram. The ERX reassembles the PPP frame and routes the packet out the
appropriate interface.
From this point on, we will focus our attention on the PPP side of the connection,
remembering that this PPP session is carried over in an ATM PVC.

PPP over ATM Rev. 3.2 Page: 4-8

 Life of a Packet - Session Initiation
1-PPP LCP
Request

DSL
Modem 2 -PPP LCP default
Tyler@isp1.com Request - Chap
ISP1
AAA
PPP Process
over RADIUS
ATM
VR2
PVC
per
DSLAM Modem
DSL
Modem
ISP2
Paul@isp2.com
ERX RADIUS

• User initiates PPP connection via LCP

• PPP client and ERX agree on PPP
authentication protocol (CHAP or PAP)

Let’s take a look at the details of the configuration as well as how a user’s session will be
established using this configuration.
The ERX has been configured for 2 Virtual routers. ISP1 is using the default virtual router
and ISP2 is using the Virtual router VR2.
Tyler@isp1.com (the PPP client) initiates a network connection via PPP LCP to the ERX.
LCP Negotiation occurs. The ERX can negotiate the following LCP options: MRU, Magic
Number (for loopback detection), and authentication protocol (PAP or CHAP).

PPP over ATM Rev. 3.2 Page: 4-9

 Determine Authentication Server
GLOBAL
DOMAIN MAP DOMAIN VR
aaa domain-map isp1.com default
aaa domain-map isp2.com VR2
DSL
Modem default
Tyler@isp1.com
AAA ISP1
Tyler@isp1.com Process

VR2 RADIUS

DSLAM
DSL
Modem
ISP2
Paul@isp2.com
ERX
RADIUS

• User sends login: Tyler@isp1.com

• ERX examines login for realm or domain name
“@isp1.com”
• ERX searches the Domain Map for user’s
domain name

During authentication, the user will send his login, Tyler@isp1.com. On the ERX, the AAA server or
process handles all of the Authentication, Authorization, Accounting and Address Assignment.
The AAA process on the ERX will parse this login for the user’s realm or domain name. The ERX will
use the string after the @ sign as the domain name. This process receives the request, searches the
Domain Map, determines which virtual router the user will authenticate through, and forwards the
request to the appropriate virtual router
The Domain Map is manually configured on the ERX. This global or box-wide table simply lists the
valid domains and which virtual router they are associated with. This table is used initially to
determine which Authentication server to use.
Based on a match, the ERX will use the RADIUS Authentication server configured in this virtual router.
In this example, the ERX searches the Domain Map for isp1.com. The ERX determines that isp1.com
uses the RADIUS server configured in the default virtual router.
If no entries were in the Domain Map, all requests would be sent to the RADIUS Authentication server
configured in the default virtual router.
If there is no match in the Domain Map, the request is sent to the RADIUS Authentication server listed
in the default virtual router. For example, Diane@isp3.com tries to login using this configuration.
What would happen? Since there is no match in the Domain Map , the request is sent to the RADIUS
server listed in the default virtual router. One can override this behavior using a domain name of
“default” in the Domain Map .
If there is no domain in the login, Tyler, without a domain name, the ERX will also use the RADIUS
server listed in the default virtual router. One can override this behavior using a domain name of
“NONE” in the Domain Map .

PPP over ATM Rev. 3.2 Page: 4-10

 RADIUS Authentication and Authorization
GLOBAL
DOMAIN MAP DOMAIN VR
aaa domain-map isp1.com default
aaa domain-map isp2.com VR2
DSL RADIUS
Modem default 1.1.1.1
Tyler@isp1.com Tyler@isp1.com
RADIUS=1.1.1.1
UDP=1645 ISP1
key=training

Tyler@isp1.com
VR2
IP=192.168.1.10
RADIUS=2.2.2.1
UDP=1645
DSLAM key=training
DSL RADIUS
Modem
ISP2 2.2.2.1
Paul@isp2.com
ERX

• Based on the virtual router, authentication request

forwarded to appropriate RADIUS server
• Configure RADIUS Server IP Address, UDP Port, Key
• RADIUS server returns a deny or grant, including
user/session attributes

The ERX looks at the default router configuration and determines the IP address of the RADIUS
server used for authentication and authorization. Note that the RADIUS server configuration is
per virtual router, whereas the domain map information is global or “box-wide” and not tied to a
virtual router.
By default, the ERX uses UDP port 1812 for the RADIUS authentication server per the RFC. If
your RADIUS server is using a different UDP port, explicitly configure the ERX to use that port,
i.e. UDP port 1645.
It will be necessary to configure the radius key to match the RADIUS server configuration. This
is used to encrypt the password sent from the ERX to the RADIUS server.
The ERX is a RADIUS client and forwards the authentication request or Access-Request to the
RADIUS server, 1.1.1.1. This access-request may include checklist attributes: user name, PAP
user password or CHAP Password / Challenge, framed protocol, and the ERX IP Address.
The RADIUS server will issue a deny or Access-Reject if Tyler@isp1.com is not found on the
server or the passwords are incorrect, respectively.
The RADIUS server will issue a grant or Access-Accept if Tyler@isp1.com is found on the server
and the password or challenge response is correct, respectively.
In addition, the grant may include return list attributes which the ERX will apply to the user’s
session. These attributes may include the IP address, subnet mask, IP routes for security
purposes, session timeout, and idle timeout. In the above diagram, the RADIUS server has
returned an IP address from a pool configured on the server.
The RADIUS server can also be configured with Unisphere Networks Vendor Specific Attributes.
We will expand on these attributes and how they are used later in the unit.

PPP over ATM Rev. 3.2 Page: 4-11

 Additional RADIUS Parameters

DSL RADIUS
Modem default 1.1.1.1
Tyler@isp1.com
Tyler@isp1.com
RADIUS=1.1.1.1 ISP1
UDP=1645
key=training
Tyler@isp1.com
VR2 IP=192.168.1.10

RADIUS=2.2.2.1
UDP=1645
DSLAM key=training
DSL RADIUS
Modem
ISP2 2.2.2.1
Paul@isp2.com
ERX

• Retransmit Value
• Timeout Value
• Deadtime
• Max-sessions

By default, unacknowledged RADIUS requests will be retransmitted to the RADIUS server

every 3 seconds. This time interval can be adjusted on the ERX using the Retransmit
parameter.
By default, the ERX will retransmit unacknowledged RADIUS Requests 3 times. This
value can be changed using the Timeout parameter.
If the RADIUS server does not respond after 12 seconds (retransmit * timeout), by default
the ERX will stop sending requests to this RADIUS server for 5 minutes. The RADIUS
server is actually taken off the active RADIUS server list. This period of time is known as
the Deadtime, another configurable parameter.
You can use the show radius authentication server command to view RADIUS servers.
If you only have 1 RADIUS server on your network, you may want to consider setting the
Deadtime to 0 and turn off the Deadtime mechanism.
By default, the ERX can have 255 outstanding RADIUS requests, based on the 8 bit
transaction ID field. This value is known as the max-sessions. One can limit the number
of outstanding request to a specific server by lowering the max-sessions value, so as not
to overwhelm a slower RADIUS server. As of 3.x.x, this parameter now allows for 4000
concurrent RADIUS requests. This is accomplished by the ERX binding to multiple local
UDP ports for the same RADIUS server.

PPP over ATM Rev. 3.2 Page: 4-12

 RADIUS Source IP Address

1.1.1.1
DSL Access Request
Modem default DA = 1.1.1.1 RADIUS
Tyler@isp1.com Router ID= SA = 192.168.1.1
172.10.1.1
Loopback1=
192.168.1.1
RADIUS=1.1.1.1 ISP1 Access Accept
DA = 192.168.1.1
SA = 1.1.1.1
VR2
Router ID=
10.1.1.1
DSLAM Loopback 1=
DSL
172.16.1.1 2.2.2.1
Modem RADIUS=2.2.2.1
ISP2 RADIUS
Paul@isp2.com
ERX

• By default, ERX uses the Router ID as the Source IP address in

packets sent to the RADIUS server
• Control the IP address by explicitly configuring the Source IP address
used to communicate with the RADIUS server
- radius update-source-addr 192.168.1.1
- Configured per virtual router
• Verify that the RADIUS server has a route to the
configured address

By default, the ERX will use the ERX’s Router ID (ip router-id) as the source IP address
for all packets sent to the RADIUS server. Unfortunately, the RADIUS server may not
have a route to this IP address.
It is possible to control which IP address the ERX will use as the source IP address for all
packets sent to the RADIUS server. To force the ERX to use a specific IP address for all
RADIUS packets, use the radius update-source-addr a.b.c.d command, where a.b.c.d is
the source IP address the ERX should use when communicating with a specific RADIUS
server. Note that this command is per virtual router.
The RADIUS server must have a route to this IP address on the ERX in order to reply to
the requests.
Note that it is also possible to configure the ERX’s router ID using the ip router-id a.b.c.d
command, which may accomplish the same goal.

PPP over ATM Rev. 3.2 Page: 4-13

 Multiple RADIUS Servers

DSL RADIUS
Modem default 1.1.1.1
Tyler@isp1.com
RADIUS=1.1.1.1 ISP1 RADIUS
RADIUS=1.1.1.2 1.1.1.2
RADIUS=1.1.1.3

VR2
RADIUS
1.1.1.3
RADIUS=2.2.2.1
DSLAM RADIUS=2.2.2.2
DSL RADIUS
Modem
ISP2 2.2.2.1
Paul@isp2.com
ERX
RADIUS
2.2.2.2

• Direct Mode
• Round Robin

Multiple RADIUS servers can be configured on the ERX. The RADIUS servers will be
used in the order in which they are configured.
Use the show radius authentication server command to view the order being used by
the ERX at any point in time.
The RADIUS servers can be configured to use one of two server selection algorithms:
Direct (default) - This algorithm essentially implements a primary/backup scenario for
multiple RADIUS servers. Using this algorithm, requests are only sent to the first RADIUS
server listed in the configuration. If this RADIUS server does not respond to requests
(based on the timeout value and the retransmit interval), start sending requests to the
second RADIUS server listed in the configuration file. The first server will not be used for
the configured deadtime.
After the deadtime timer expires, the RADIUS server is reinstated on the active server list.
Round Robin - This algorithm will send out RADIUS requests to all active RADIUS
servers, in the order listed in the configuration file. In the above diagram, the first request
is sent to the first server, the second request to the second server, the third request is sent
to the first server, and so on. In this case, the primary server changes with each request.
This mode will effectively use all configured RADIUS servers equally, in a round robin
fashion.
The RADIUS algorithm is configured using the following configuration command:
erx2(config)#radius algorithm ?
direct Configure RADIUS client to use the list of servers in configured order
round-robin Configure RADIUS client to use the list of servers in round-robin order

PPP over ATM Rev. 3.2 Page: 4-14

 IP Address Assignment
GLOBAL
DOMAIN MAP DOMAIN VR
aaa domain-map isp1.com default
aaa domain-map isp2.com VR2
DSL RADIUS
Modem default 1.1.1.1
Tyler@isp1.com DHCP
RADIUS=1.1.1.1 ISP1 1.1.2.1
UDP=1645
key=training Access Accept
Tyler@isp1.com
192.168.1.10
VR2

RADIUS=2.2.2.1
UDP=1645
DSLAM key=training
DSL RADIUS
Modem
ISP2 2.2.2.1
Paul@isp2.com
ERX

• RADIUS Server
• Local IP Address Pool on the ERX
• DHCP Proxy Client

The user can obtain an IP address in three different ways. In the previous example, the
RADIUS server can returned Tyler’s IP address.
If the RADIUS server returns a value or 255.255.255.254, 0.0.0.0 or no address, the ERX
will obtain an IP address for the remote user using the local address pools defined on the
ERX.
As of release 1.3, the ERX can also provide DHCP proxy services for the workstation and
obtain the workstation’s IP address from a DHCP server.
In this example, the RADIUS server returned an IP address from a pool configured on the
RADIUS server. This IP address will be assigned to Tyler’s PC during the IP NCP
negotiation process.

PPP over ATM Rev. 3.2 Page: 4-15

 Local Address Pools
ip address pool local
ip local pool isp1pool
1.1.100.2-1.1.100.254
DSL RADIUS
Modem default 1.1.1.1
Tyler@isp1.com
RADIUS=1.1.1.1 ISP1
UDP=1645
key=training Access Accept
Tyler@isp1.com
255.255.255.254
VR2

RADIUS=2.2.2.1
UDP=1645
DSLAM key=training
DSL RADIUS
Modem
ISP2 2.2.2.1
Paul@isp2.com
ERX

Local Address Pools can also be configured on the ERX. Local address pools are
configured on the ERX by issuing the ip address-pool local command. Next, an IP
address range would be configured by issuing the command
ip local pool <poolname> <ip address start range> <ip address end range>.
Local Address Pools are configured per virtual router.
If the RADIUS server returns an IP address of 255.255.255.254, 0.0.0.0 or no address, as
is the case here, the ERX determines if any IP address pool information has been
configured. In this case, a local IP address pool has been configured and the ERX will
obtain an IP address for the user from the available addresses in that virtual router’s
address pool.
The ERX will associate this user with this IP address until the session is disconnected and
the address is released.
If there are no addresses available, the ERX will fail the request.
There is no concept of ‘leasing’ an address as with DHCP. The address is allocated to
that user until the user’s session disconnects.

PPP over ATM Rev. 3.2 Page: 4-16

 DHCP Proxy Client

DSL DHCP
Modem default 1.1.2.1
Tyler@isp1.com ip address-pool
dhcp ISP1
ip dhcp-server
Tyler@isp1.com
1.1.2.1
255.255.255.254

VR2

RADIUS=2.2.2.1
UDP=1645
DSLAM key=training
DSL RADIUS
Modem
ISP2 2.2.2.1
Paul@isp2.com
ERX

DHCP Proxy provides the ability to dynamically assign IP addresses to clients even
though the clients are PPP clients, not DHCP clients. The ERX acts as a DHCP client on
behalf of the PPP client and negotiates the allocation of an IP address with one or more
DHCP servers on the network. The ERX maintains the address for the client by renewing
the lease on the address until the client terminates the connection and releases the
address back to the server that provided it.
The DHCP proxy client is configured on the ERX by issuing the ip address-pool dhcp
command. Next, the IP addresses of the DHCP servers would be configured using the
command ip dhcp-server <ip address of dhcp server>.
The ERX DHCP Proxy client is configured and operates per virtual router.
If the RADIUS server returns an IP address of 0.0.0.0, no address or 255.255.255.254, as
is the case here, the ERX determines if any IP address pool information has been
configured. In this case, DHCP has been configured for the local address pool. The ERX
will obtain an IP address for the user from one of the DHCP servers configured.
In a DHCP Proxy environment, the ERX maintains the DHCP leases. For each client, the
ERX records the lease time provided by the DHCP server. When 50% of the lease time
has passed, the DHCP Proxy will attempt to renew the lease. If the server renews the
lease, the new lease time is recorded and the procedure repeats. If the server denies the
renewal, the DHCP Proxy alerts the AAA server that the address renewal failed. The AAA
server would then terminate the PPP session and issue a release of the IP address.
Up to 5 DHCP servers can be configured. The DHCP servers can be the same ones used
with Bridged 1483 or they can be completely different DHCP server. Therefore, Bridged
1483 can support 5 DHCP servers and DHCP proxy can support an additional 5 DHCP
servers. If multiple DHCP servers are configured, the address request will be sent to all
configured servers.

PPP over ATM Rev. 3.2 Page: 4-17

 Determine Virtual Router
GLOBAL
DOMAIN MAP DOMAIN VR Interface
IPConf Req 0.0.0.0 aaa domain-map isp1.com default Loopback 1
aaa domain-map isp2.com VR2 Loopback 1 RADIUS
1.1.1.1
DSL
Modem default
Tyler@isp1.com

IPConf Req ?.?.?.? Loopback 1 = ISP1

192.168.1.1/24

VR2
Loopback 1
DSLAM 172.16.1.1/16
RADIUS
2.2.2.1
DSL
Modem
ISP2
Paul@isp2.com
ERX
• Unnumbered interfaces associated with a loopback interface
• Loopbacks are IP Interfaces configured per virtual router
• Which Virtual Router should be used?
- Domain Map
- RADIUS Vendor Specific Attribute
- Profile

Once the ERX has obtained an IP address for the remote user, the next step is to perform
PPP IP NCP negotiations. Typically, the ERX will use an unnumbered interface for this
PPP session. Each unnumbered interface has an associated loopback interface. If the
ERX is using an unnumbered interface, the IP address supplied to the user during IP NCP
negotiation will be the IP address of the associated loopback interface configured on the
ERX.
This presents a challenge: Which loopback address should be used? Remember that all
layer 1 and layer 2 information is global or “box-wide” in nature and is not tied to a specific
virtual router. Layer 3 information, specifically IP interfaces, is directly tied to a specific
virtual router. Therefore, at this point in time, the ERX must determine to which virtual
router this IP interface will belong. The ERX will then use the IP address of the loopback
interface in that particular virtual router for IP NCP negotiation.
Which virtual router is this IP interface going to use? The virtual router can be determined
by three methods
•The Domain Map can specify which virtual router and which Loopback interface
to use.
•Using the Unisphere Networks RADIUS Vendor Specific Attributes (VSA), the
RADIUS server can return the user’s virtual router in the Access-accept message
and the loopback interface.
•A Profile can also specify which Virtual Router this interface is going to use.
More on Profiles later in this unit.

PPP over ATM Rev. 3.2 Page: 4-18

 IP NCP Negotiation
GLOBAL
DOMAIN MAP DOMAIN VR Interface
IPConf Req 0.0.0.0 aaa domain-map isp1.com default Loopback 1
aaa domain-map isp2.com VR2 Loopback 1
RADIUS
DSL 1.1.1.1
Modem default
Tyler@isp1.com
IPConf Nak 192.168.1.10 Loopback 1 = ISP1
IPConf Req 192.168.1.10 192.168.1.1/24

VR2
Loopback 1
172.16.1.1/16
IPConf Ack 192.168.1.10
RADIUS
2.2.2.1
IPConf Req 192.168.1.1
ISP2
IPConf Ack 192.168.1.1 ERX

Default Virtual Router’s IP Routing Table

Prefix/Length Next Hop Dist/Met Interface
192.168.1.0/24 192.168.1.1 0/1 Loopback1
192.168.1.10/32 0.0.0.0 2/1 atm 5/1.1

Now the ERX knows the IP address of the user (either from RADIUS, a local address pool
or DHCP), the virtual router this IP interface is going to use, and the appropriate IP
address to use during IPCP negotiation. The ERX and the user will now perform standard
IP NCP negotiations.
In the above diagram, isp1.com is listed in the Domain Map. Therefore, all IP interfaces
for isp1.com will be created in the router specified in the domain map. In this example,
tyler’s IP interface will be created in the default virtual router. In addition, the ERX will use
192.168.1.1, the loopback interface specified in the domain map, during IP NCP
negotiations.
If there were no entry in the domain map for isp1.com, the ERX would determine if
RADIUS returned the VSA virtual router and loopback interface information needed for IP
interface creation and negotiation. If RADIUS did not return this information, the ERX
would determine if this information was listed in the profile specified for this interface. If
the virtual router and/or loopback interface information is not specified in one of these
three places, the IP interface will not be created.
If the ip access-routes configuration command was included with the IP Interface
definition, the ERX will install the user’s IP host route into the appropriate virtual router’s
routing table. In this case, Tyler’s IP Address, 192.168.1.10, will be installed in the default
router’s IP routing table as a 32-bit host route.

PPP over ATM Rev. 3.2 Page: 4-19

 Name Servers
aaa dns primary 1.1.1.10
aaa dns secondary 1.1.1.11
aaa wins primary 1.1.1.10
aaa wins secondary 1.1.1.11
DSL RADIUS
Modem default 1.1.1.1
Tyler@isp1.com
RADIUS=1.1.1.1 ISP1 DNS/WINS
1.1.1.10

VR2
DNS/WINS
1.1.1.11
RADIUS=2.2.2.1
DSLAM
DSL RADIUS
Modem
ISP2 2.2.2.1
Paul@isp2.com
ERX

• DNS/WINS
• Obtained two different ways:
- RADIUS
- Configured on ERX per virtual router

The name server configuration operates similar to the IP address configuration. The user
can obtain the IP addresses of the name servers (DNS and WINS) two different ways.
1) RADIUS can return the IP addresses of the name servers using a Vendor Specific
Attribute or VSA.
2) The name servers can be configured on the ERX.
Name servers are configured on the ERX per virtual router.
In this example, RADIUS did not return the IP address of the name servers. The ERX will
supply the addresses of the name server based on the configuration in the default virtual
router.
Per the RFC, the ERX supports a primary and secondary name server.

PPP over ATM Rev. 3.2 Page: 4-20

 Accounting

DSL RADIUS
Modem default 1.1.1.1
Tyler@isp1.com
RADIUS=1.1.1.1 ISP1
UDP=1646
key=training

VR2

RADIUS=2.2.2.1
UDP=1646
DSLAM key=training
DSL RADIUS
Modem
ISP2 2.2.2.1
Paul@isp2.com
ERX

• RADIUS Accounting Start Record Sent

As with RADIUS authentication servers, RADIUS accounting servers are also configured
per virtual router. At this point in time, the ERX will determine the IP address of the
RADIUS Accounting server for the default virtual router and send a RADIUS accounting
start record for Tyler@isp1.com. Accounting is maintained per user.
Recall that there are two basic RADIUS accounting records: RADIUS accounting start and
RADIUS accounting stop records.
Remember that ISP1 is wholesaling services to ISP2 using this ERX. If Paul@isp2.com
logged on, a RADIUS accounting start record would normally be sent to the RADIUS
accounting server in VR2. The RADIUS accounting server for ISP2 might be located in
ISP2’s domain. However, ISP1 may want to know some of the details of ISP2’s traffic. To
accomplish this task, it is possible to configure the ERX to send duplicate accounting start
and stop messages. Messages would be sent to the RADIUS accounting server at ISP2
as well as the RADIUS accounting server at ISP1. This option is configured using the aaa
accounting duplication configuration command.
At this point, Tyler has successfully established a PPP over ATM session with the RX and
is ready to ‘surf the web!’

PPP over ATM Rev. 3.2 Page: 4-21

 PPP over ATM Interface Columns
Which Virtual Router? IP Interface IP Interface
Which IP address to cache?

PPP Interface PPP Interface

Authentication Type
1 per Client 1 per Client

Slot/Port.Subinterface ATM Subinterface ATM Subinterface

PVC 1 per Client 1 per Client

Slot/Port
Framing ATM Interface
# VC per VP (UT3 or UE3)

Clocking UT3 / UE3

Framing OC3c

The UT3/UE3 controller, ATM Interface, ATM Subinterface, and PPP interface are
statically defined on the ERX. Recall that in a PPP over ATM environment, each modem
supports just one user. Therefore, on the ERX, an ATM subinterface or PVC and PPP
interface will be statically created for each user.
In a B-RAS environment, IP Interfaces can be dynamically created and assigned to the
appropriate virtual router when the user logs on. The user could obtain a different IP
address each time he logs on to the ERX. After successful completion of IPCP
negotiation, the users IP address must be installed as a 32-bit host route in the routing
table of the appropriate virtual router. When the user logs off, the route must be deleted
and the IP Interface dynamically removed from the configuration.
To facilitate this dynamic creation and deletion of IP interfaces, the ERX uses a
mechanism called Profiles.
Recall that the IP interface configuration command ip access-routes automatically inserts
and deletes the host route in the ERX’s routing table.
If the users IP interface is NOT ALWAY going to be in the same virtual router, it is not
possible to statically configure the IP interface, assign it an address (numbered or
unnumbered) and specify the ip access-route command. Entering these commands
would lock the interface column into the virtual router the CLI was associated with when
the commands are entered. In order to dynamically create IP interfaces and bind them to
virtual routers when the customer logs in, it is necessary to use IP Profiles.
If the user’s IP Interface is always going to be assigned to the same virtual router, it is
possible to statically define the IP interface (numbered or unnumbered) in the appropriate
virtual router and specify the ip access-routes command for each interface. The ip
access-routes command instructs the ERX to automatically cache the user’s assigned
host route in the routing table and therefore bind it with the appropriate ATM subinterface.
It is also possible to use Profiles to dynamically create these IP interfaces, but not
necessary.

PPP over ATM Rev. 3.2 Page: 4-22

 Profiles
Tyler@isp1.com Paul@isp2.com
Statically Profile Dynamically
IP Interface
Created IP Interface Created

PPP Interface PPP Interface

Global ATM Subinterface ATM Subinterface

Configuration

Static
Configuration ATM Interface

UT3 / UE3
OC3c

• Placeholder or Trigger to dynamically create

an IP interface in the appropriate virtual
router using a common set of IP attributes

Remember that all layer 1 and layer 2 information (UT3/UE3/OC3c, ATM Interfaces and Subinterfaces,
PPP Interfaces) are global in nature or independent of the VR configuration. The only part of the
protocol stack or interface column that is specific to a virtual router is the IP Interface.
A Profile defines properties or behaviors of an IP interface, such as the MTU size, the option to cache
the host route in the routing table, or assigning the IP interface to specific virtual router. A Profile is
created or defined once globally on the ERX, and then applied to as many interfaces as desired.
For example, assume ISP2 wants to support 2,000 users or 2,000 IP Interfaces. The ISP wants all of
these IP interfaces to have the same behavior and characteristics, specifically that each host route will
be cached in the VR2 routing table and that each interface will have an MTU of 1500 bytes. A Profile
will be created globally in the ERX. For example:
host8(config)#profile isp2
erx5:vr2(config-profile)#ip ?
access-routes Enable the creation of host access routes on this interface.
address Configure an IP address on an interface
directed-broadcast Enable directed broadcast forwarding
ignore-df-bit Ignore DF bit
mtu Configure the maximum transmission unit for this network
policy Attach/Remove a policy to/from an interface
redirects Enable transmission of ICMP redirect messages
sa-validate Enable source address validation
unnumbered Configure IP on this interface without a specific address
virtual-router Specify a virtual router for the profile
This profile will then be assigned to all PPP interfaces configured for this ISP. The profile is also the
mechanism or trigger to dynamically create the IP interface in the appropriate virtual router.

PPP over ATM Rev. 3.2 Page: 4-23

 B-RAS Configuration Steps - Initial Setup
GLOBAL
• Configure a B-RAS License DOMAIN MAP DOMAIN VR Interface
• Configure Virtual Routers aaa domain-map isp1.com
aaa domain-map isp2.com
default Loopback 1
VR2 Loopback 1
• Configure Loopback Interfaces
- Per Virtual Router default
• Configure the Domain Map
- Global Table Loopback1=192.168.1.1

• Configure the RADIUS Authentication RADIUS=1.1.1.1

and Accounting Servers and Parameters UDP = 1645
key=training
- Per Virtual Router
• Configure Name Servers
VR2
- Per Virtual Router
Loopback1=172.16.1.1
• Configure Local IP Address Pools
- Per Virtual Router RADIUS =2.2.2.1
• If using dynamic interfaces, configure UDP = 1645
key=training
Profiles
- Specify common parameters
- Global in nature

RX-0-9-D0(config-if)#license b-ras DeMo RX-0-9-D0(config-controll)#virtual vr2

NOTICE: The Subscriber Management Feature Pack software
installed on this system is licensed to support a specific number of
simultaneous xDS users. Configuration or operational support for
more concurrent users than what has been purchased is in direct
violation of the product license agreement.
Proceed with 'license b-ras' command? [confirm]
license for 100 subscribers configured.
RX-0-9-D0(config)#interface loopback 1
RX-0-9-D0(config-if)#ip address 192.168.1.1 255.255.255.0
RX-0-9-D0(config)#aaa domain-map isp1.com default loopback 1
RX-0-9-D0(config)#radius authentication server 10.3.0.53
RX-0-9-D0(radius-server)#udp-port 1645
RX-0-9-D0(radius-server)#key training
RX-0-9-D0(radius-server)#deadtime 0
RX-0-9-D0(radius-server)#exit
RX-0-9-D0(config)#radius accounting server 10.3.0.53
RX-0-9-D0(radius-server)#udp-port 1646
RX-0-9-D0(radius-server)#key training
RX-0-9-D0(radius-server)#dead 0
RX-0-9-D0(radius-server)#exit
RX-0-9-D0(config)#profile generic
RX-0-9-D0(config-profile)#ip access-routes
RX-0-9-D0(config-profile)#exit
Proceed with new virtual-router creation? [confirm]
RX-0-9-D0:vr2(config)#interface loopback 1
RX-0-9-D0:vr2(config-if)#ip address 172.16.1.1 255.255.0.0
RX-0-9-D0:vr2(config)#aaa domain-map isp2.com vr2 loopback 1
RX-0-9-D0:vr2(config)#radius authentication server 10.3.0.53
RX-0-9-D0:vr2(radius-server)#udp-port 1645
RX-0-9-D0:vr2(radius-server)#key training
RX-0-9-D0:vr2(radius-server)#deadtime 0
RX-0-9-D0:vr2(radius-server)#exit
RX-0-9-D0:vr2(config)#radius accounting server 10.3.0.53
RX-0-9-D0:vr2(radius-server)#udp-port 1646
RX-0-9-D0:vr2(radius-server)#key training
RX-0-9-D0:vr2(radius-server)#deadtime 0
RX-0-9-D0:vr2(radius-server)#exit
NOTE: The same profile can be used for both isp1.com and isp2.com
since it is only specifying ip access routes and NOT specifying virtual
router assignment.

PPP over ATM Rev. 3.2 Page: 4-24

 PPP over ATM Configuration Steps
Tyler@isp1.com Paul@isp2.com
• Configure UT3/U3E Controller Dynamic
IP Interface IP Interface
- Clocking, Framing, Shutdown via Profile

• Configure ATM interface

PPP Interface PPP Interface
- # VCs per VP, Framing
• Configure the following per user:
- Configure ATM Subinterface ATM Subinterface ATM Subinterface

- Configure PVC, PVC encapsulation

- Configure Encapsulation PPP
- Specify PPP Authentication ATM Interface
CHAP/PAP
- Statically Configured IP Interfaces
UT3 / UE3
• Configure IP Address OC3c
• Configure ip access-routes
- Dynamically Created Interfaces
• Apply a Profile

The configuration steps for Tyler@isp1.com:
RX-0-9-D0(config)#controller t3 5/1
RX-0-9-D0(config-controll)#no shutdown
RX-0-9-D0(config)#interface atm 5/1
RX-0-9-D0(config-if)#interface atm 5/1.1
RX-0-9-D0(config-if)#atm pvc 1 0 101 aal5snap
RX-0-9-D0(config-if)#encapsulation ppp
RX-0-9-D0(config-if)#ppp authentication chap
RX-0-9-D0(config-if)#profile generic
NOTE: Profiles are required when the IP Interface
will be created dynamically. If the user may log into
different domains and therefor may be connected to
virtual routers for different logins, use a Profile.
Profiles are NOT required when the IP interface will
always be created in the same virtual router. If the IP
interface will always reside in the same virtual router,
use the following commands INSTEAD of the Profile
command:
RX-0-9-D0(config)#interface atm 5/1
RX-0-9-D0(config-if)#interface atm 5/1.1
RX-0-9-D0(config-if)#atm pvc 1 0 101 aal5snap
RX-0-9-D0(config-if)#encapsulation ppp
RX-0-9-D0(config-if)#ppp authentication chap
RX-0-9-D0(config-if)#ip unnumbered loopback 1
RX-0-9-D0(config-if)#ip access-routes
The configuration steps for Paul@isp2.com:
RX-0-9-D0:vr2(config)#interface atm 5/1.2
RX-0-9-D0:vr2(config-if)#atm pvc 2 0 102 aal5snap
RX-0-9-D0:vr2(config-if)#encapsulation ppp
RX-0-9-D0:vr2(config-if)#ppp authentication chap
RX-0-9-D0:vr2(config-if)#profile generic
RX-0-9-D0:vr2(config-if)#interface atm 5/1.3
RX-0-9-D0:vr2(config-if)#atm pvc 3 0 103 aal5snap
RX-0-9-D0:vr2(config-if)#encapsulation ppp
RX-0-9-D0:vr2(config-if)#ppp authentication chap
RX-0-9-D0:vr2(config-if)#profile generic
RX-0-9-D0:vr2(config-if)#exit
NOTE: Since Paul’s service allows him flexibility in service
provider selection, his IP interface must be dynamic. His
interface will be located in virtual router VR2 when he is using
isp2 and the default virtual router when he is using isp1. Profiles
are required to provide this flexibility.
NOTE: The same profile can be used for both isp1.com and
isp2.com since it is only specifying the ip access routes
command and NOT specifying virtual router assignment.

PPP over ATM Rev. 3.2 Page: 4-25

 How can I tell if it is working?
• show subscriber <username@domain>
erx5#show subscriber
Subscriber List
Addr Virtual
User Name IP Address Source Router
-------------------------------- --------------- ------ ------------
tyler@isp1.com 192.168.1.8 radius default
paul@isp2.com 172.16.2.2 radius vr2
trish@isp2.com 172.16.2.3 radius vr2
User Name Interface Login Time
-------------------------------- ------------------ -------------------
tyler@isp1.com atm 5/1.1 01/04/17 14:00:32
paul@isp2.com atm 5/1.2 01/04/17 14:00:33
trish@isp2.com atm 5/1.3 01/04/17 14:00:33
• show radius statistics
• show aaa domain-map
• test aaa username password
• show ip route | include atm 5/1.1
• show ppp interface | include slot/port.subinterface
• show ppp interface state up
• show ppp interface full
• show ppp interface status
• show ppp interface summary

RX-0-9-D0:vr2#show rad stat RX-0-9-D0#show ip route

RADIUS Authentication Statistics
-------------------------------- Proto: Prefix/Length: Next Hop: Dist/Met: Intf:
Statistic 10.3.0.53 Static 0.0.0.0/0 10.3.0.1 1/1 FastEthernet0/0
------------------- --------- Connect 192.168.1.0/24 192.168.1.1 0/1 loopback1
UDP Port 1645
Round Trip Time 0 Static 2.2.2.2/32 3.3.3.2 1/1 pos2/0
Access Requests 4 Connect 3.3.3.0/24 3.3.3.1 0/1 pos2/0
Retransmissions 0
Connect 10.3.0.0/24 10.3.202.1 0/1 FastEthernet0/0
Access Accepts 4
Access Rejects 0 AccIntern 192.168.1.10/32 0.0.0.0 2/1 atm5/1.1
Access Challenges 0 RX-0-9-D0#vir vr2
Malformed Responses 0
RX-0-9-D0:vr2#show ip route
Bad Authenticators 0
Requests Pending 0 Proto: Prefix/Length: Next Hop: Dist/Met: Intf:
Request Timeouts 0 Static 0.0.0.0/0 3.3.3.1 1/1 pos2/1
Unknown Responses 0
Connect 172.16.0.0/24 172.16.1.1 0/1 loopback1
Packets Dropped 0
Connect 3.3.3.0/24 3.3.3.2 0/1 pos2/1
RX-0-9-D0#show ppp int status AccIntern 172.16.2.2/32 0.0.0.0 2/1 atm 5/1.2
PPP interface 5/0.1 is Up
AccIntern 172.16.2.3/32 0.0.0.0 2/1 atm 5/1.3
PPP interface 5/0.2 is Up
PPP interface 5/0.3 is Up
PPP interface 5/1.1 is Up
PPP interface 2/0 is Up
PPP interface 2/1 is Up
PPP interface 5/1.2 is Up
PPP interface 5/1.3 is Up
8 ppp interfaces found

PPP over ATM Rev. 3.2 Page: 4-26

 ERX Logging Overview
• ERX logging must be explicitly configured
• ERX Log Messages
- Categories
• Examples include snmp, telnet, ipInterface, pppPacket,
ospfPktsSent/Rcvd, bgpConnection
- Filters
• Per interface, connection, router, slot
- Severity
• emergency 0
• alert 1
• critical 2
• error 3
• warning 4
• notice 5
• info 6
• debug 7

It is possible to configure the ERX to provide detailed log messages.

ERX log messages are broken into categories. A few category examples include snmp,
telnet, pppPacket, which is a PPP packet trace capability, ospfPktsSent and
ospfPktsRcvd, and bgpConnections. There are over 80 different categories of log
messages.
Categories can also have filters configured to limit and control the amount of logging
information. For example, some categories can have filters configured that apply to a
specific interface, such as pppPacket or ipInterface. Other categories may have filters
that apply to a specific connection, such a bgpConnections. Some categories do not
support any filters, such as snmp or telnet. By default, category filters are not enabled
and must be explicitly configured.
Within a category, ERX log messages are assigned a severity level from 0-7. The lower
the number, the higher the severity of the message. We will see that the severity level can
be configured to determine the amount and type of log messages sent to the various log
destinations.
Log messages also have 3 different verbosity levels: low, medium, and high, though this
feature has not been widely implemented. Low verbosity level will be sufficient in most
situations.
The logging process resides on the SRP. The logging facility, specifically debug logging,
is a very powerful troubleshooting tool. However, it does use CPU and memory on the
SRP. Debug logging should be used sparingly, and only for the duration of a test or while
trying to capture data in a particular scenario. Setting all logs to DEBUG should only be
done at the instruction of customer support and only on specified categories for a specified
duration.

PPP over ATM Rev. 3.2 Page: 4-27

 Where do the log messages go?
Volatile Memory
DEBUG pppPacket (interface serial 4/0:1/1):,

• Volatile Memory on SRP

tx lcp echoResp
DEBUG pppPacket (interface serial 4/0:1/1):
tx lcp echoReq
DEBUG pppPacket (interface serial 4/0:1/1):, U - Max Size = 750 entries
rx lcp echoResp,
• Flash
Flash - system.log
1-3-0.rel - 64 K maximum size
system.log - Severity Critical or higher
reboot.hty
- ASCII file
• ERX Console
- Real-time
• Telnet/SSH Session
- Real-time
• Syslog
- Multiple Hosts
- Facility (0-7) per Host
Console
Telnet Syslog

ERX log messages can be sent to a variety of locations.

By default, due to the low severity level and low verbosity level, a very limited number of
log messages are stored in volatile memory on the SRP. A sophisticated algorithm is
used by the logging process so that no one category can monopolize the logging process
and starve other categories from inserting log messages into volatile memory. As of
release 3.2 persistent logging has been implemented between system reloads. This
means that log messages in the SRP volatile memory will be retained through a system
reload unless the ERX is power cycled or the system detects any problems.
Log messages will also be stored in non-volatile memory in a file on the flash called
system.log. Only severity levels 0-2 or EMERGENCY, ALERT and CRITICAL log
messages will be stored in system.log. This ASCII file can have a maximum size of
approximately 64K. When the maximum size is reached, the file is circular in nature and
operates in a FIFO manner. The file can be copied to a PC and read by any text editor.
The log messages can also be sent to the console in real-time. The console also has a
severity level associated with it. By default, only messages that have a severity level of
WARNING or higher are sent to the console. These same messages can also be directed
to a Telnet/SSH session. By default, if NOTICE, INFO OR DEBUG log messages occur,
they are not directed to the console. This behavior is configurable.
Finally, ERX log messages can also be directed to syslog. By default, the severity level for
syslog is DEBUG. Multiple syslog hosts can be configured. For each syslog host, it is
possible to configure which facility (0-7) syslog messages are sent.

PPP over ATM Rev. 3.2 Page: 4-28

 Default ERX Logging Configuration

ERX-00-70-d0#show log config

log destination console severity WARNING
log destination nv-file severity CRITICAL
no log engineering
log fields timestamp instance no-calling-task
log here
no log severity

category severity verbosity filters notes

------------------------- -------- --------- ------- -----
NameResolverLog ERROR low
aaaAtm1483Cfg ERROR low
aaaEngineGeneral ERROR low
aaaServerGeneral ERROR low
aaaUserAccess ERROR low
addressServerGeneral ERROR low
atm ERROR low
atm1483 ERROR low
.....
ppp ERROR low
pppPacket --- low
pppStateMachine --- low
pppoe ERROR low
pppoeControlPacket --- low
profileMgr ERROR low

Use the show log configuration CLI command to view the current ERX logging
configuration. This example is the default log configuration and only shows a subset of
the categories.
Notice the three log destinations:
•console - Currently, only log messages that have severity levels 0-4 will be sent to the
console.
•nv-file - This destination refers to the the file system.log found on the flash card. Only
severity levels 0-2 or EMERGENCY, ALERT and CRITICAL log messages will be stored
in system.log. It is not possible to store ERROR, WARNING, NOTICE, INFO or DEBUG
messages in the file system.log.
•syslog - The IP address of the syslog host is configured as well as a severity level of
DEBUG.
By default, all log categories are assigned a severity of ERROR or 3 and a verbosity level
of low. An exception to this rule is the category os which has a severity of NOTICE. In
addition, no interfaces or connections have logging associated with them. One must
explicitly configure ERX logging on specific interfaces or connections.
Note: The documentation includes a complete list of categories and the messages
available at each severity level.

PPP over ATM Rev. 3.2 Page: 4-29

 Configuring DEBUG Logging on a PPP Interface

ERX1(config)#log severity debug pppPacket atm 5/1.1

ERX-00-70-d0(config)#end
ERX-00-70-d0#show log config
log destination console severity WARNING
log destination nv-file severity CRITICAL
no log engineering
log fields timestamp instance no-calling-task
log here
no log severity

category severity verbosity filters notes

------------------------- -------- --------- ------- -----
NameResolverLog ERROR low
aaaAtm1483Cfg ERROR low
.....
policyMgrPacketLog ERROR low
ppp ERROR low
pppPacket --- low 1
pppStateMachine --- low
pppoe ERROR low
pppoeControlPacket --- low

log severity DEBUG pppPacket atm 5/1.1

In this example, we are going to configure the ERX to log PPP packets on a specific PPP interface,
5/1.1. We are going to configure the pppPacket category, specify a severity of DEBUG and
specify the PPP interface, 5/1.1. All logging configuration is done in global configuration mode.
When a specific interface or connection is specified for logging, the ERX considers it a log filter.
Specific log filters are always listed at the bottom of the log configuration display. As of release 3.2
the Notes column has been added. This column will indicate a note number next to the categories
where the severity has been modified from its default value. The associated note and number will
be displayed at the end (or bottom of the screen) of the command just as the filter is.
ERX1(config)#log ?
destination Configure logging destinations
engineering Enable engineering logs
fields Select optional log fields to display
here Enable this terminal as a log console
severity Configure log severities and/or filters
verbosity Configure the verbosity level
ERX1(config)#log severity debug ?
aaaServerGeneral AAA Server General logs
addressServerGeneral Address Server General logs
atm ATM
…….
ppp Point-to-Point Protocol Layer
pppPacket PPP packet capture
pppStateMachine PPP state machine trace
pppoe Point-to-Point Over Ethernet Layer
ERX1(config)#log severity debug pppPacket ?
atm Specify an ATM PPP interface
pos Specify a POS PPP interface
serial Specify a serial PPP interface
<cr>
ERX1(config)#log severity debug pppPacket atm
INTERFACE The atm interface identifier
ERX1(config)#log severity debug pppPacket atm 5/1.1

PPP over ATM Rev. 3.2 Page: 4-30

 Viewing the ERX Log - LCP & CHAP
ERX6(config)#cont t3 5/1
ERX6(config-controll)#no shutdown
ERX6(config-controll)#end
ERX6#show log data category pppPacket severity debug
*** stored log messages ***
*** log: pppPacket
*** severity: DEBUG and higher
*** no baseline

DEBUG 11/28/2001 12:46:35 pppPacket (interface atm 5/1.1): time: 0.00, tx lcp confReq, id = 40, length = 19, mru = 9178, authentication =
chap MD5, magicNumber = 0x070c43db

DEBUG 11/28/2001 12:46:35 pppPacket (interface atm 5/1.1): time: 0.00, rx lcp confReq, id = 60, length = 14, mru = 9178, magicNumber =
0x7553a501

DEBUG 11/28/2001 12:46:35 pppPacket (interface atm 5/1.1): time: 0.00, tx lcp confAck, id = 60, length = 14, mru = 9178, magicNumber =
0x7553a501

DEBUG 11/28/2001 12:46:35 pppPacket (interface atm 5/1.1): time: 0.00, rx lcp confAck, id = 40, length = 19, mru = 9178, authentication =
chap MD5, magicNumber = 0x070c43db

DEBUG 11/28/2001 12:46:35 pppPacket (interface atm 5/1.1): time: 0.00, tx chap challenge, id = 172, length = 39, challenge length = 30,
challenge = 6e c0 41 2a 50 7a 23 60 8f 43 b5 0b 8f 9e 90 29 72 ae c0 6c cb f6 ef 2e 01 ab 99 3b c8 6d, name = 'ERX6' 45 52 58 36

DEBUG 11/28/2001 12:46:35 pppPacket (interface atm 5/1.1): time: 0.01, rx chap response, id = 172, length = 35, response length = 16,
response = 5d ed 51 8c 0b aa 4c 03 d2 69 b4 d2 4a b9 49 1e, name = 'tyler@isp1.com' 74 79 6c 65 72 40 69 73 70 31 2e 63 6f 6d

DEBUG 11/28/2001 12:46:35 pppPacket (interface atm 5/1.1): time: 0.86, tx chap
success, id = 172, length = 4

In this example, the PPP interface is ‘bounced’. By default, these pppPacket log messages will
go to volatile memory as well as syslog. They will not be directed to the console since the
console’s severity level is still set to WARNING and these messages are DEBUG.
To view the log messages stored in volatile memory, use the show log data command. There are
several options that can be used to view the log data stored in volatile memory, including severity
levels and categories.
erx1#show log data
erx1#show log data ?
category Limit the display to a specific log category
nv-file Display the nv-file log
severity Specify the minimum severity to display
| Filter output using the CLI Filtering feature
<cr>
erx1#show log data category pppPacket ?
severity Specify the minimum severity to display
| Filter output using the CLI Filtering feature
<cr>
erx1#show log data category pppPacket severity ?
<0 - 7> The minimum severity to display
alert immediate action needed (1)
critical critical conditions exist (2)
debug debug messages (7)
emergency system unusable (0)
error error conditions (3)
info informational messages (6)
notice normal but significant conditions (5)
warning warning conditions (4)
erx1#show log data category pppPacket severity debug ?
| Filter output using the CLI Filtering feature
<cr>

PPP over ATM Rev. 3.2 Page: 4-31

 Example PPP over ATM Log - IP NCP

DEBUG 11/28/2001 12:46:35 pppPacket (interface atm 5/1.1): time: 0.86, tx ipNcp
confReq, id = 244, length = 10, ipAddress = 192.168.1.1

DEBUG 11/28/2001 12:46:35 pppPacket (interface atm 5/1.1): time: 0.87, rx ipNcp
confReq, id = 96, length = 10, ipAddress = 0.0.0.0

DEBUG 11/28/2001 12:46:35 pppPacket (interface atm 5/1.1): time: 0.87, tx ipNcp
confNak, id = 96, length = 10, ipAddress = 192.168.1.2

DEBUG 11/28/2001 12:46:35 pppPacket (interface atm 5/1.1): time: 0.87, rx ipNcp
confAck, id = 244, length = 10, ipAddress = 192.168.1.1

DEBUG 11/28/2001 12:46:35 pppPacket (interface atm 5/1.1): time: 0.87, rx ipNcp
confReq, id = 97, length = 10, ipAddress = 192.168.1.2

DEBUG 11/28/2001 12:46:35 pppPacket (interface atm 5/1.1): time: 0.87, tx ipNcp
confAck, id = 97, length = 10, ipAddress = 192.168.1.2

A sample configuration file is located in the back of the PPP over ATM lab.

PPP over ATM Rev. 3.2 Page: 4-32

 Additional ERX Log Configuration
Options
• To view the log file on the flash
- erx1#show log data nv-file
• To view pppPacket DEBUG log messages real-time on the console
- erx1(config)#log destination console severity debug
• To direct log messages to a Telnet/SSH session
- erx1(config)#log here
• To quickly disable logging DEBUG messages to the console:
- erx1(config)#no log here
OR
- erx1(config)#log destination console off
OR
- erx1(config)#log destination console severity warning
• To turn off all logging filters:
- erx1(config)#no log filters
• With release 3.2 the baseline log and delta functions are available
– erx1#baseline log
– erx1#show log data category pppPacket severity debug delta

To view the pppPacket DEBUG log messages in real-time on the console, use the
configuration command log destination console severity debug. DEBUG messages
will only be sent to the console session directly attached to the ERX.
By default, log messages are not directed to Telnet/SSH sessions. Once the console is
configured to support debug messages, use the log here configuration command from the
Telnet/SSH session to direct log messages to the Telnet/SSH session. At this point,
pppPacket trace log messages will be directed to both the Telnet/SSH session as well as
the directly connected console session.
To stop directing log messages to a specific console or Telnet/SSH session, use the no
log here configuration command. In a troubleshooting situation, log messages could be
directed to a Telnet/SSH session using the log here option and the directly attached
console session could be used for other troubleshooting commands using the no log here
option.
To turn off logging to all console sessions, use the log destination console off
configuration command. This command disables logging to both Telnet/SSH and directly
attached console sessions.
To scale down the amount of log messages being sent to the console or Telnet/SSH
session, use the log destination console severity warning configuration command.
As of release 3.2 you can baseline log data using the baseline log command. Use the
optional delta keyword with the show log data command to specify that baselined
messages are not to be shown.

PPP over ATM Rev. 3.2 Page: 4-33

 Useful Logging Categories for PPP
over ATM

• pppPacket
• aaaUserAccess
• radiusAttributes
• radiusClient

PPP over ATM Rev. 3.2 Page: 4-34