E-Series B-RAS Configuration Student Guide PDF

E-Series B-RAS Configuration Basics
Student Guide
1194 North Mathilda Avenue

Sunnyvale, CA 94089
USA
408-745-2000
www.juniper.net
Juniper Networks, the Juniper Networks logo, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other
countries. JUNOS and JUNOSe are trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or registered service
marks are the property of their respective owners.
E-series B-RAS Configuration Basics Student Guide, Revision 7.b
Copyright © 2007, Juniper Networks, Inc.
All rights reserved. Printed in USA.

Revision History:
Release 4.0—August 2002

Revision 4.a—April 2003
Revision 4.b—October 2003
Revision 6.a—January 2005
Revision 6.b—February 2005
Revision 7.a—January 2007
Revision 7.b—April 2007
The information in this document is current as of the date listed above:
The information in this document has been carefully verified and is believed to be accurate for software Release 7.3.0. Juniper Networks assumes no
responsibilities for any inaccuracies that may appear in this document. In no event will Juniper Networks be liable for direct, indirect, special, exemplary,
incidental or consequential damages resulting from any defect or omission in this document, even if advised of the possibility of such damages.
Juniper Networks reserves the right to change, modify, transfer or otherwise revise this publication without notice.
YEAR 2000 NOTICE
Juniper Networks hardware and software products do not suffer from Year 2000 problems and hence are Year 2000 compliant. The JUNOS software has no
known time-related limitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036.
SOFTWARE LICENSE
The terms and conditions for using Juniper Networks software are described in the software license provided with the software, or to the extent applicable, in an
agreement executed between you and Juniper Networks, or Juniper Networks agent. By using Juniper Networks software, you indicate that you understand
and agree to be bound by its license terms and conditions. Generally speaking, the software license restricts the manner in which you are permitted to use the
Juniper Networks software, may contain prohibitions against certain uses, and may state conditions under which the license is automatically terminated. You
should consult the software license for further details.
Contents
Module 0: Course Introduction ..................................................................................... 0-1
Module 1: DSL Overview and IP over ATM ..................................................................... 1-1

B-RAS and DSL Overview .............................................................................. 1-3
IP-over-ATM Operation and Configuration .................................................. 1-13
Troubleshooting IP over ATM ..................................................................... 1-31
Lab 1: Configuring IP over ATM .................................................................. 1-35
Module 2: Bridged Ethernet and DHCP ......................................................................... 2-1

Overview of Bridged Ethernet ......................................................................... 2-3
Bridged Ethernet and DHCP Configuration and Troubleshooting ................. 2-11
Lab 2: Configuring Bridged Ethernet ........................................................... 2-19
Module 3: PPP over ATM................................................................................................. 3-1

Overview of PPP over ATM .......................................................................... 3-3
Life of a Packet PPP over ATM .................................................................... 3-10
Configuring PPP over ATM ......................................................................... 3-25
Troubleshooting PPP-over-ATM Interfaces ................................................. 3-35
Lab 3: Configuring PPP over ATM ................................................................ 3-53
Module 4: PPP over Ethernet ........................................................................................ 4-1

Overview of PPP over Ethernet ...................................................................... 4-3
PPP over Ethernet in Ethernet Access Networks ........................................ 4-11
PPP-over-Ethernet Configuration and Troubleshooting ............................... 4-17
Lab 4: Configuring PPP over Ethernet ........................................................ 4-35
Module 5: Dynamic Interfaces ....................................................................................... 5-1

Dynamic PPP-over-ATM and PPP-over-Ethernet Interfaces .......................... 5-3
Dynamic IP-over-ATM and Bridged Ethernet Interfaces ................................ 5-15
Dynamic Interface Creation Using Bulk Configuration ................................. 5-21
Dynamic Subscriber Interfaces ................................................................... 5-31
Lab 5: Configuring Dynamic Interfaces ....................................................... 5-36
Module 6: L2TP .............................................................................................................. 6-1

L2TP Overview ............................................................................................... 6-3
L2TP Operation ............................................................................................ 6-9
E-series Router L2TP Configuration ............................................................. 6-15
L2TP Tunnel Failover and Tunnel Selection ................................................ 6-26
E-series Router Requirements...................................................................... 6-34
Troubleshooting L2TP .................................................................................. 6-48
Lab 6: Configuring L2TP............................................................................... 6-56
Contents - iii
Module 7: Policy Management Overview ........................................................................ 7-1
Policy Management Overview .......................................................................... 7-3
Configuring Classifier Lists and Policy Lists.................................................. 7-11
Configuring Rate-Limit Profiles ..................................................................... 7-29
Configuring Policy Lists with Multiple Rules ................................................ 7-41
Troubleshooting Policies on the E-series Router .......................................... 7-58
Lab 7: Configuring Policy ............................................................................. 7-63
Module 8: System Administration................................................................................... 8-1

Upgrading and Downgrading Software .......................................................... 8-3
Backup Boot Configuration and Slot Configuration ...................................... 8-18
Rebuilding Flash Cards and Password Removal........................................... 8-23
Accessing the CLI ...................................................................................... 8-32
Other System Administration Tasks .............................................................. 8-40
Contents - iv
Course Overview
The E-series B-RAS Configuration Basics course is designed to provide technical network professionals with
the skills needed to successfully install, configure, and troubleshoot the E-series platform to act as a broadband
remote access server (B-RAS). The course covers the fundamentals of B-RAS, ATM, IP over ATM, bridged
Ethernet, PPP over ATM, PPP over Ethernet, VLANs, dynamic interfaces, L2TP, policy management as well as
E-series router systems administration.
Objectives
After successfully completing this course, you should be able to:
• After successfully completing this course, you should be able to:
• Configure IP-over-ATM interfaces;
• Configure bridged Ethernet interfaces;
• Configure PPP-over-ATM interfaces;
• Configure PPP-over-Ethernet interfaces;
• Configure dynamic interfaces;
• Configure L2TP;
• Troubleshoot connectivity issues;
• Configure fundamental policy management; and
• Describe E-series router system administration tasks.
Intended Audience
This course is intended for technical network professionals responsible for the integration, configuration,
and management of E-series router networks.
Course Level
This is an intermediate-level course designed to provide a strong foundation for configuring the
B-RAS application on an E-series router.
Prerequisites
The prerequisites for the E-series B-RAS Configuration Basics course are knowledge of IP in an ISP
environment and the Introduction to Juniper Networks Routers-E-series course.
Course Overview - v
Course Agenda
Day 1
Module 0: Course Introduction
Module 1: DSL Overview and IP over ATM
Module 2: Bridged Ethernet and DHCP
Day 2
Module 3: PPP over ATM
Module 4: PPP over Ethernet
Day 3
Module 5: Dynamic Interfaces
Module 6: L2TP
Day 4
Module 7: Policy Management Overview
Module 8: System Administration
Course Agenda - vi
Additional Information
Education Services Offerings

You can obtain information on the latest Education Services offerings, course dates, and class locations
from the World Wide Web by pointing your Web browser to: http://www.juniper.net/training/education/ .
About This Publication

The E-series B-RAS Configuration Basics Student Guide was developed and tested using software
version 7.3.0. Previous and later versions of software may behave differently so you should always
consult the documentation and release notes for the version of code you are running before reporting
errors.
This document is written and maintained by the Juniper Networks Education Services development
team. Please send questions and suggestions for improvement to training@juniper.net.
Technical Publications
You can print technical manuals and release notes directly from the Internet in a variety of formats:
• Go to http://www.juniper.net/techpubs/ .
• Locate the specific software or hardware release and title you need, and choose the format in
which you want to view or print the document.
Documentation sets and CDs are available through your local Juniper Networks sales office or account
representative.
Juniper Networks Support

For technical support, contact Juniper Networks at http://www.juniper.net/customers/ support/, or at
1-888-314-JTAC (within the United States) or 408-745-2121 (from outside the United States).
Additional Information - vii

Additional Information - viii
E-series B-RAS Configuration Basics
Module 0: Course Introduction

Module Objectives
 After successfully completing this module, you will be able
to:
– Get to know one another
– Identify the objectives, prerequisites, facilities, and materials used
during this course
– Identify additional Juniper Networks courses
– Describe the Juniper Networks Technical Certification Program
(JNTCP)
This Chapter Discusses:

•Objectives and course content information;
•Additional Juniper Networks courses; and
•Juniper Networks Technical Certification Program.
Module 0: Introduction and Overview 0-2

Introductions
 What is your name?
 Where do you work?
 What is your primary role in your organization?
 What kind of network experience do you have?
 What is the most important thing for you to learn in this
training session?
Introductions
This slide serves to break the ice by having you introduce yourself and state your reasons for attending
the class.

Course Contents
 DSL Overview and IP over ATM
 Bridged Ethernet and DHCP
 PPP over ATM
 PPP over Ethernet
 Dynamic Interfaces
 L2TP
 Policy Management Overview
 System Administration
Course Contents
This slide lists the topics we discuss in this course.

Prerequisites
Introduction to Juniper
Networks Routers—E-series
Familiarity with Juniper Networks system

architecture
Familiarity with the JUNOSe CLI
Understanding of IP in an ISP environment
Prerequisites
This slide lists the prerequisites for this course.

Course Administration
 Course objectives
 Sign-in sheet
 Schedule
– Class times
– Breaks
– Lunch
 Break and restroom facilities
 Communications
– Telephones
– Cellular phones and pagers
– Internet access
General Course Administration

This slide documents general aspects of classroom administration.

Education Materials
 Available in class:
– Lecture material
– Lab guide
– Lab equipment
 Available outside of class:
– Online documentation at www.juniper.net
– Juniper Networks Technical Assistance Center (JTAC)
 Available through your account representative:
– Documentation CD
– Printed documentation
Training and Study Materials

This slide describes several options for obtaining study and preparation materials.

Satisfaction Feedback
Class Feedback
 Please be sure to tell us how we did!

– Look for an e-mail asking you to complete our on-line survey
 Completed surveys:
– Help us serve you better
– Ensure that you receive a certificate of completion
Satisfaction Feedback
Juniper Networks uses an electronic survey system to collect and analyze your comments and
feedback. Depending on the class you are taking, please complete the survey at the end of the class,
or be sure to look for an e-mail about two weeks from class completion that directs you to complete an
online survey form (be sure to provide us with your current e-mail address).
Submitting your feedback entitles you to a certificate of class completion. We thank you in advance for
taking the time to help us improve our educational offerings.

M-series, T-series, and J-series Curriculum

Enterprise Track
(J-series)
Prerequisites:
Operating Juniper Networks
General knowledge of Routers—J-series
TCP/IP and routing (OJNR-J)
Prerequisites: Detailed knowledge of M-series and

Service Provider Track T-series routers from CJNR attendance or similar
(M-series and Advanced
T-series) VPNs
Advanced
Policy
Advanced
Juniper Networks
Prerequisites: Familiarity Configuring Juniper Routing (AJNR)
with JUNOS software CLI, Networks Routers
general knowledge of (CJNR)
Juniper Networks
TCP/IP, and routing Security
Solutions (JNSS)
Operation and IPSec

Prerequisites: Troubleshooting of Juniper
General knowledge Networks Routers
Class of Service
of TCP/IP and routing (OTJNR)
IPv6
Service Provider Curriculum: JUNOS Platforms

This slide displays the primary Education Services offerings that support Juniper Networks M-series
and T-series technologies in a service provider environment.

The E-series Curriculum
Prerequisites: Detailed
knowledge of E -series products
from attendance of IJNR-E class
or similar
Broadband
Remote Access
Server
Introduction to Configuration
Juniper Networks
Routers—E-series
(IJNR-E)
E-series Routing E-series MPLS

Protocols Configuration
Prerequisites: General
knowledge of TCP/IP
and routing
Prerequisites: Attendance
of E-series Routing
Protocols class
Service Provider Curriculum: JUNOSe Platforms

This slide displays the primary Education Services offerings that support Juniper Networks E-series
router technologies.

Technical Certification Programs
 Two technical certification tracks

– E-series routers track
– M-series routers track (covers T-series routers and JUNOS software)
 Both tracks consist of written and lab-based examination
Technical Certification Programs: Routing Tracks

This slide outlines the current levels of technical certification offered by Juniper Networks.

Juniper Networks Certified Internet Associate
 JNCIA
– Computer-based, written exam
– Delivered at Prometric testing centers worldwide
– 60 questions, 60 minutes
– Passing Score: 70%
– $125 USD
– Prerequisite certification: none
– Benefits provided to JNCIAs:
 Certificate
 Logo usage
 Industry recognition
– Validates candidate’s general knowledge of IP technologies,
platform operating system, and hardware
The JNCIA Certification

This slide details the JNCIA certification level.

Juniper Networks Certified Internet Specialist
 JNCIS
– Computer-based, written exam
– Delivered at Prometric testing centers worldwide
– Prerequisite for the JNCIP lab exam
– 75 questions, 90 minutes
– Passing Score: 70%
– $125 USD
– Prerequisite certification: none
– Benefits provided to JNCISs:
 Certificate
 Logo usage
 Provides ability to take JNCIP exam
 Industry recognition as an IP and routing platform specialist
– Validates candidate’s advanced knowledge of platform operating
system, hardware, and IP technologies
The JNCIS Certification

This slide details the JNCIS certification level.

Juniper Networks Certified Internet Professional
 JNCIP
– One-day, lab-based exam
– Tests candidate’s configuration and design skills for essential
technologies
– Testing centers: Sunnyvale, Amsterdam, Herndon, Westford, Remote
– Prerequisite for the JNCIE lab exam
– $1,250 USD
– Prerequisite certification: JNCIS
– Benefits provided to JNCIPs:
 Certificate
 Logo usage
 Provides ability to take JNCIE exam
 Industry recognition as an IP and routing platform professional
– Validates candidate’s practical platform configuration skills
The JNCIP Certification

This slide details the JNCIP certification level.

Juniper Networks Certified Internet Expert

 JNCIE
– One-day, lab-based exam
– Tests candidate’s advanced configuration and design skills for
essential and specialized technologies
– Testing centers: Sunnyvale, Amsterdam, Herndon, Remote
– $1,250 USD
– Prerequisite certification: JNCIP
– Currently only available in the M-series routers track
– Benefits provided to JNCIEs:
 Crystal plaque and certificate
 Logo usage
 Worldwide recognition as an Internet Expert
– The most challenging and respected exam of its type in the industry
The JNCIE Certification

This slide details the JNCIE certification level.

Certification Preparation
 Training and study resources

– JNTCP Website
 www.juniper.net/certification
– Education Services training classes
 http://www.juniper.net/training
– Juniper Networks documents and white papers
 http://www.juniper.net/techpubs/
 http://www.juniper.net/techcenter/
– Sybex JNTCP preparation guides
 JNCIA and JNCIP available February, 2003
– Juniper Networks Routers: The Complete
Reference
 Available at bookstores now
 Covers M-series and T-series platforms
 Practical exams: Lots of hands-on practice
– On-the-job experience
– Education Services training classes
– Equipment access
Prepping and Studying

This slide lists some options for those interested in prepping for Juniper Networks certification.

Questions
Any Questions?
If you have any questions or concerns about the class you are attending, we suggest that you voice
them now so that your instructor can best address your needs during class.

Copyright © 2006 Juniper Networks, Inc. Copyright © 2007, Juniper Networks, Inc. Proprietary and Confidential www.juniper.net 18

Module 1: DSL Overview and IP over ATM

Module Objectives
to:
– Compare and contrast narrowband remote access services and
broadband remote access services
– Describe the different types of DSL connections
– List and describe the equipment used in a DSL network
– List and describe four different DSL connection types
– Describe the life of a packet in an IP-over-ATM environment
– Describe basic ATM concepts and terminology
– Compare and contrast IP addressing options in an IP-over-ATM
environment
– Configure an IP-over-ATM interface on the E-series router

• The narrowband remote access services and broadband remote access services;
• Different types of digital subscriber line (DSL) connections;
• The equipment used in an DSL network;
• The different DSL connection types;
• The life of a packet in an IP-over-ATM environment;
• Basic ATM concepts and terminology;
• The different IP addressing options in an IP-over-ATM environment; and
• How to configure an IP-over-ATM interface on the E-series router.
Module 1: DSL Overview and IP over ATM 1-2

Agenda: DSL Overview and IP over ATM

 B-RAS and DSL Overview
 IP-over-ATM Operation and Configuration
 Troubleshooting IP over ATM
B-RAS and DSL Overview

The slide lists the topics we discuss in this chapter. We discuss the highlighted topic first.

Narrowband Remote Access

Modem
RADIUS
tyler@isp1.com
Routers ISP1
RAS
PPP Session
Modem
RADIUS ISP2
paul@isp2.com
 Relatively slow access rates using dedicated POTS line

 RAS responsibilities:
– PPP session termination
– Authentication, authorization, and address assignment using
RADIUS
– Routing IP packets to appropriate routers
Slow Access Rates Using POTS Lines

In a narrowband remote access environment, relatively slow-speed connections were made using
dedicated plain old telephone service (POTS) lines. These narrowband 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.
RAS Responsibilities
In this environment, the phone lines terminated in a remote access server (RAS), also referred to as a
narrowband RAS (N-RAS). The N-RAS also terminated the user's Point-to-Point Protocol (PPP)
session and handled user authentication, authorization and address assignment in conjunction with a
Remote Access Dial-In User Service (RADIUS) server. From the N-RAS, the packets were sent to the
appropriate routers.
However, times have changed and needs have changed. More often, families have more than one PC,
yet they only have one additional phone line to use for connectivity. In addition, more users are
demanding higher access rates. There must be a better solution.

Broadband Remote Access Services
Dial-up
DSL
E-Series Router
Cable
GSM/GPRS
LMDS/UMTS IP Core
Fiber
FTTx
Laptop PC Wi-Fi
Laptop PC Hotspot
PDA
PDA
Broadband Remote Access Services Overview

In today's remote access environment things are not as simple. The term broadband remote access
server (B-RAS) refers to a variety of subscriber connection methods using higher speed access lines,
with speeds ranging from 128 Kbps to 26 Mbps or higher.
The E-series system, acting as a B-RAS, is access agnostic. It can be used to support dial-up
subscribers using analog modems through a narrowband RAS, DSL modems through a DSL-capable
telephone network, cable modems through a cable modem termination server (CMTS), mobile
subscribers connecting through Global System for Mobile Communications (GSM) General Packet
Radio Service (GPRS) network (2.5G), or a Local Multipoint Distribution Service (LMDS)/Universal
Mobile Telecommunications Service (UMTS) network (3G). Additional access methods include metro-
Ethernet subscribers via fiber to the building (FTTB) or fiber to the house (FTTH) infrastructure, also
known as FTTx, and IEEE 802.11x subscribers accessing service through Wi-Fi (wireless fidelity)
hotspots.

E-series Router Supported Services

Consumer &
Business DSL
Access Network ASP/CP
PPP over ATM
DSLAM
Bridged Ethernet E-series

ATM Routers
ISP1
PPPoE
ATM
IP over ATM
Sonet/SDH
WiFi VPN
Hotspot SDX-300 RADIUS DHCP
GSM/GPRS GigEthernet
LMDS/UMTS
ISP2
Service
Access Network
Fiber
FTTx
Network Provider
E-series Supported Services

Regardless of the access network technology employed by the customer, you can configure the E-
series system to provide a wide variety of IP services. When deployed with a RADIUS server for
authentication and accounting services, the E-series system provides the PPP termination functions
traditionally seen in an N-RAS environment. In a wholesale environment, a single E-series system
services customers for multiple Internet service providers (ISPs). In virtual private networking (VPN)
applications, the E-series system provides VPN services using virtual routers, the Layer 2 Tunneling
Protocol (L2TP), RFC 2547-defined Multiprotocol Label Switching (MPLS) VPNs, and IPSec-based
VPNs.
When deployed with Juniper Networks Service Deployment System (SDX-300), the B-RAS subscriber
can choose from a menu of customized services and have its E-series interface provisioned to support
the selected service without the need for operator intervention.

DSL Overview
PC w/Ethernet
NIC
PC w/DSL
Modem
DSL
Modem
DSL DSL
Bridge Modem
Network
PC w/ATM NIC of PCs
DSL
Modem
DSL
DSLAM Concentrator
DSLAM
Customer
Network DSL ATM Internet
Router
Customer ATM
DSL Switch
Network
Router RADIUS
DHCP
 High-speed connection using existing phone lines

– Always on!
– Voice, fax, and data over the same phone line
– Speed is dependent on flavor of DSL, line quality, and distance
High-Speed Connections Using Existing Phone Lines

Broadband connections are becoming more and more prevalent. A DSL Internet connection is always
on. You do not need to dial-up your ISP. DSL speeds range from 128 Kbps to 26 Mbps or higher,
depending of the type of DSL, the line quality, and the distance from the central office. DSL is a family
of access technologies that use high transmission frequencies to convert existing phone lines into
high-speed data connections. Using DSL, you can use a single phone line for voice and data at the
same time. Voice traffic or POTS only uses the lower frequencies, specifically 0-4 kHz, leaving the
higher frequencies available for other services. DSL uses these higher, unused frequencies (25 kHz-
1.5 MHz) to provide greater bandwidth for data connections. Providers can use two different methods
in their network to allocate this higher range of frequencies. The carrier amplitude phase (CAP) system
reserves different frequencies for upstream traffic (that is, traffic coming from the PC to the network)
(25 kHz-160 kHz) and downstream traffic (that is, traffic going from the network to the PC) (240 kHz-
1.5 MHz). The second approach, discreet multitone (DMT), separates the usable frequency range into
256 frequency bands of 4.135 kHz each.

xDSL: Different Connection Types

PC w/Ethernet
NIC
PC w/DSL
Modem
DSL
Modem
DSL DSL
Bridge Modem
Network
PC w/ATM NIC of PCs
DSL
Modem
DSL
DSLAM Concentrator
DSLAM
Customer
Router
Customer ATM
DSL Switch
Network
Router RADIUS
DHCP
 DSL connection types:
– Asymmetric
– Symmetric
– Rate adaptive
– High bit rate
– Very high bit rate
DSL Connection Types

There are different types of DSL connections, where the x in xDSL indicates the type of connection:
http://broadbandguide.com.au/
• Asymmetric DSL (ADSL): Provides more bandwidth downstream (from the Internet to the
PC) than upstream (from the PC to the Internet). This is the most common type of service
because Internet requests are typically small and Internet downloads are large; therefore,
having a smaller transmit rate and a larger receive rate works well. ADSL upstream rate
ranges from 64 Kbps to 1 Mbps, and downstream speeds are 384 Kbps to 24 Mbps,
although lower rates are more common. There are several different versions of ADSL,
including ADSL, ADSL2, ADSL2-plus, and ADSL2-RE (reach extended). The different
versions provide advanced diagnostics, better performance, and higher bandwidth over
shorter distances. http://www.paradigm.com.tw/Support_FAQ-ADSL.html
• Symmetric DSL (SDSL): Provides the same bandwidth in both directions. SDSL rates range
from 128 Kbps to 2.32 Mbps in both directions. While SDSL is a vendor-proprietary version
of DSL, Symmetric High-Speed Digital Subscriber Line (SHDSL) is the first standardized
multirate symmetric DSL service providing rates from 192 Kbps to 5.7 Mbps. It is best suited
for data-only applications requiring high upstream bit rates. Unlike ADSL, SHDSL does not
carry voice.
• High bit rate DSL (HDSL): Symmetric T1/E1 line using standard copper phone wire without
the use of repeaters. HDSL is the oldest and most heavily deployed DSL service. Unlike the
other DSL types, HDSL uses two (T1) or three (El) twisted pairs of copper phone wire and
only supports data traffic. HDSL2, the second generation of HDSL, delivers a 1.5-Mbps
service over a single copper pair. HDSL4 is virtually identical to HDSL2 but can support
longer distances by using two pairs of wire.
• Very high bit rate DSL (VDSL): A shorter distance, higher speed version of ADSL supporting
rates up to 26 Mbps. The second generation of VDSL-VDSL2—specifies eight different
profiles that address a range of applications. The differences include bandwidth, distance,
and symmetric versus asymmetric transmissions. For example, one profile provides up to
100-Mbps symmetric transmission on 100-meter long loops. Another profile specifies
asymmetric operation with downstream rates in the range of 10-40 Mbps on loops of lengths
ranging from 1 km to 3 km.

DSL Customer Premise Equipment

PC w/Ethernet
NIC
PC w/DSL
Modem
DSL
Modem
DSL DSL
Bridge Modem
Network
PC w/ATM NIC of PCs
DSL
Modem
DSL
DSLAM Concentrator
DSLAM
Customer
Router
Customer ATM
DSL Switch
Network
Router RADIUS
DHCP
 How customers connect:
– Business customers connect LANs to DSL routers or bridges
– Residential customers:
 Workstation with integrated DSL modem
 Workstation with an Ethernet NIC connected to a standalone DSL bridge or
modem
DSL Customer Premise Equipment

DSL networks require new equipment to be installed at both the customer's location as well as the
providers location. A DSL modem is installed at the customer premise. It carries the data across
existing copper wires to a similar DSL modem at the provider's central office.
Business or enterprise customers often connect their LANs to DSL-capable routers or bridges. These
devices typically have an Ethernet interface and an integrated DSL modem with integrated ATM
capabilities. Another option is to connect their local area networks (LANs) to a router, which in turn
connects to an external DSL modem.
Residential or small office, home office (SOHO) users either have a workstation or a PC with an
integrated DSL modem, an Ethernet network interface card (NIC) that connects to an external DSL
modem, or, in very rare instances, an ATM NIC connected to an external DSL modem. The most
common approach is the Ethernet NIC connecting to an external DSL modem

DSL POP Equipment

PC w/Ethernet
NIC
PC w/DSL
Modem
DSL
Modem
DSL DSL
Bridge Modem
Network
PC w/ATM NIC of PCs
DSL
Modem
DSL
DSLAM Concentrator
DSLAM
Customer
Router
Customer ATM
DSL Switch
Network
Router RADIUS
DHCP
 Local POP
– One or more DSLAM
 Central office
– ATM switch
– DSL concentrator
– RADIUS, DHCP servers
– PVC established from the DSL concentrator to the CPE Device
Local POP
In an DSL environment, thousands of subscriber lines connect to a digital subscriber line access
multiplexers (DSLAMs), which are typically located in the provider's local point of presence (POP). The
DSLAM contains DSL modems, which it aggregates onto high-speed ATM, Gigabit Ethernet, or 10
Gigabit Ethernet connections.
Central Office
At the central office, an ATM or Ethernet switch potentially aggregates the connections from the
DSLAM and ultimately terminates them on a DSL concentrator. RADIUS and the Dynamic Host
Configuration Protocol (DHCP) servers might also be located at the central office. They might be used
for user authentication and IP address assignment.
For ATM-based DSLAMS, the DSL concentrator establishes a permanent virtual circuit (PVC) to the
customer premise equipment (CPE) device. One or more users can use this PVC, depending on the
configuration. For Ethernet-based DSLAMs, the DSL concentrator might establish a VLAN to each
CPE device.

To Authenticate or Not... (1 of 2)
PC w/Ethernet
NIC
Bridged Ethernet PC w/DSL
Modem
DSL
Modem
DSL
DSL
Bridge Modem
Network
of PCs
DSL
Modem
PC w/ATM NIC
IP over ATM DSLAM

DSLAM DSL
Concentrator
Customer
Network DSL ATM
Router Internet
ATM
DSL
Switch
Customer Router RADIUS
Network
DHCP
 Always on, no user authentication

– Bridged Ethernet
– IP over ATM
Always On, No Authentication

Four basic types of DSL connections exist:
Bridged Ethernet;
• IP over ATM;
• PPP over ATM; and
• PPP over Ethernet.
These connection types fall into two different categories:
• No centralized user authentication and authorization; and
• Centralized user authentication and authorization.
With the first two types—bridged Ethernet and IP over ATM—the DSL users are always on and no
user authentication takes place. It is the simplest configuration. Using IP over ATM, the user's IP
address is statically configured. With bridged Ethernet connections, the users' IP address is typically
obtained using DHCP. The user's IP address could also be statically configured. Typically, users incur
a monthly, flat-rate fee based on bandwidth.

To Authenticate or Not... (2 of 2)
PC w/Ethernet
PPP over NIC
ATM PC w/DSL
Modem
DSL
Modem
DSL DSL
Bridge
Modem
PPP over
PC w/ATM NIC
DSL
Network Ethernet
Modem of PCs
DSLAM DSL
DSLAM Concentrator
Customer
DSL
Internet
Network ATM
Router
ATM
DSL Switch
PPP over
Network
ATM
 To maintain current dial-up model, complete with RADIUS

authentication and accounting services, use:
– PPP over ATM
– PPP over Ethernet
Maintains the Dial-up Model

The last two types of DSL connections attempt to maintain the traditional dial-up model, complete with
centralized user authentication, authorization, and accounting. The DSL connections are still always
on, but initially the users must authenticate through a RADIUS server prior to establishing an IP
connection. They typically obtain their IP address from RADIUS. We often refer to this approach 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.


 B-RAS and DSL Overview
 IP-over-ATM Operation and Configuration
 Troubleshooting IP over ATM
IP-over-ATM Operation and Configuration

The slide highlights the topic we discuss next.

IP over ATM: Life of a Packet

IP=1.1.1.2 IP Connection Terminated IP=2.2.2.2
MAC=A on the E-series Router MAC=F
MAC=B
VPI/VCI 0/33 MAC=E
DSL MAC=C
Router
MAC=D
DA IP=2.2.2.2
SA IP=1.1.1.2
DA IP=2.2.2.2 DA IP=2.2.2.2 DA IP=2.2.2.2
Layer 3 SA IP=1.1.1.2 SA IP=1.1.1.2
SA IP=1.1.1.2 RFC 2684
EtherType=0x0800
EtherType=0x0800 OUI=0x00-00-00 EtherType=0x0800 EtherType=0x0800
Layer 2 DA MAC=B LLC=0xAA-AA-03 DA MAC=D DA MAC=F
SA MAC=A SA MAC=C SA MAC=E
ATM VPI/VCI=0/33
Layer 1 Physical Physical Physical Physical
Life of a Packet
In the IP-over-ATM environment, a DSL-capable router or a router and a DSL modem are installed at
the customer's location. This router provides connectivity to the Internet for one or more networks at
the customer's location. The router or modem is connected over a phone line to a DSLAM, which is in
turn connected via ATM to the E-series router. A single ATM PVC is provisioned from the router to the
customer's CPE device.
If a user at the customer's location wants access to the Internet, the basic packet flow is as follows (for
this example, the customer uses Ethernet for the Layer 2 transport mechanism):
• The user's PC generates an IP packet, encapsulates it in an Ethernet frame, and addresses
it to a DSL router.
• The DSL router receives the Ethernet frame, sees that it is addressed to the router, and
strips off the Ethernet frame.
• The DSL router looks at the destination IP address, consults its routing table, and
determines that the next hop is the DSL interface.
• The DSL router adds an RFC 2684-defined ATM Layer 2 header (previously known as RFC
1483), indicating that the frame contains an IP datagram, and then segments the IP
datagram into 53-byte cells.
• The DSL router sends the cells across the PVC to the E-series router.
• The E-series router receives and reassembles the cells, strips off the RFC 2684 header,
looks at the destination IP address, and determines the next-hop interface.
• The E-series router encapsulates the IP datagram in the appropriate Layer 2 frame and
transmits the data into the Internet, repeating this process each step along the way to the
destination IP address.

Note that if a router receives a Layer 2 frame addressed to itself, it strips off the Layer 2 encapsulation,
determines the next-hop address based on the destination IP address, and encapsulates the IP
datagram in a new Layer 2 frame for the next leg of its journey. We will see that this behavior is very
different in a bridged Ethernet environment.

ATM Basics
DSL
Bridge
DSLAM VPI 0
Customer VCI 33
Network DSL
Router VCI 34
VCI 35
DSL
Customer Router
Network
 1 physical interface, multiple logical connections

– E-series router supports PVCs
 PVC identified by VPI, VCI, VCD
– VPI/VCI identifies connection on physical interface
– VCD is a configuration parameter specific to the E-series router
 A unique number (per interface) that identifies a virtual circuit
One Physical Interface with Multiple Logical Connections

In an ATM environment, one physical connection can support multiple logical interfaces. These logical
connections are known as PVCs. They are statically configured and are always available. No call setup
occurs to establish connectivity. In a typical DSL environment, one PVC is configured for each DSL
CPE device. Therefore, one physical port on the E-series router can support thousands of DSL users.
Identifying PVCs
A virtual path identifier (VPI) and a virtual circuit identifier (VCI) identify a PVC. A virtual path (VP) can
contain many virtual circuits (VCs). There can also be multiple virtual paths on a single physical
interface. In the example on the slide, VP 0 contains three VCs: VCI 33, VCI 34, and VCI 35. The
combination of VPI/VCI uniquely identifies a connection on a physical interface. In the example, the
logical connections are identified by VPI/VCI: 0/33, 0/34, and 0/35.
The E-series router also adds an extra identifier to each VC, known as the virtual circuit descriptor
(VCD). The VCD must be unique on an interface. You can view the . VCD as a label. You use this
label to obtain statistics about a particular VPI/VCI on the E-series router.

IP-over-ATM Interface Columns

DSL
Bridge DSLAM VPI 0
VCI 33
Customer VCI 34
Network DSL
Router VCI 35
DSL
Customer Router
Network
IP Address
Network IP Interface IP Interface Subnet Mask
Layer IP Description
VCD VPI/VCI
ATM PVC ATM PVC Encapsulation Type
ATM Subinterface ATM Subinterface Service Category
Data Link F5 OAM
Layer
ATM # VCs per Virtual Path
Major Interface F4 OAM
Slot/Port or Slot/Adapter/Port
Physical SONET/SDH Clock Source

Layer Shutdown
OCx/STMx SDH
Slot/Port or Slot/Adapter/Port
IP-over-ATM Configuration Aspects

This slide shows the components for configuring IP-over-ATM interface columns. First, you configure
the physical layer referencing the slot and port or slot, adapter, and port of the OCx/STMx controller.
You can turn off and on or toggle the physical port using the shutdown and no shutdown command. By
default, OCx/STMx ports operate as SONET controllers. Use the sdh command to change the port to
operate as an SDH controller. By default, controllers on the E-series router derive the transmit clock
source based on the line's receive data stream. If you test routers in a back-to-back environment, you
must configure one end of the line using the command clock source internal and the other end with the
command clock source line.
You next configure ATM major interface parameters such as the number of virtual circuits for each
virtual path. The VPI/VCI address ranges allowed on ATM interfaces are module dependent. Certain
modules on ERX-7xx, ERX-14xx, and ERX-310 routers have a fixed allocation scheme whereas others
have a configurable allocation scheme. In the configurable allocation scheme, a bit range is shared
across the VPI and VCI fields. For these modules you use the atm vc-per-vp command to configure the
number of bits allocated to the VCI field. Using the OCx/STMx line module, you can allocate 20 bits
across the VPI/VCI fields. The range of VPI/VCI addresses is equal to 0 - (2n - 1), where n is the
number of allocated bits. If you allocate 7 bits to the VPI field and 13 bits to the VCI field, the VPI can
range from 0-127 and the VCI can range from 0-8191. To configure this example, you use the atm vc-
per-vp 8192 command. The number you configure must be a power of 2. The minimum number of VCs
per VP is 4096 on an OCx/STMx line module.
All ATM interfaces on the E320 router support the full VPI/VCI address range. No additional
configuration is necessary.
Continued on next page.

ATM interfaces support the operations, administration, and management (OAM) standards. The E-
series router supports F4 and F5 OAM fault management, loopback, and continuity check cells. These
cells perform fault detection and notification, loopback testing, and link integrity. F4 cell flows, used to
monitor VPs, are configured at the ATM major interface level. You can configure F4 flows for a specific
VP or for all possible VPs on an interface.
For each logical connection, you configure an ATM subinterface and build the PVC at the subinterface
level. You can configure and manage ATM major interfaces, subinterfaces, and PVCs from any virtual
router context. You can configure F5 OAM flows on ATM PVCs. You can also configure a description
for the ATM subinterface.
Finally, you create an IP interface on top of the ATM subinterface. The IP interface must be created in
the appropriate virtual router. This IP interface can be a numbered or unnumbered IP interface. For
numbered interfaces, you must also configure a subnet mask. For unnumbered IP interfaces, a mask
is not specified. Instead, the unnumbered IP interface must reference some IP interface on the router,
typically a loopback interface. You can also configure an IP description.

Configuring IP over ATM (1 of 2)

 IP-Over-ATM interface configuration for Customer ABC
erx1(config)#controller sonet 6/2
erx1(config-controll)#clock source int chassis
erx1(config-controll)#sdh
erx1(config-controll)#exit
erx1(config)#interface atm 6/2
erx1(config-if)#atm vc-per-vp 8192
erx1(config-if)#interface atm 6/2.33
erx1(config-subif)#atm pvc 33 0 33 aal5snap
erx1(config-subif)#ip address 172.10.1.1 255.255.255.252
erx1(config-subif)#ip description CustomerABC
IP-over-ATM Interface Configuration Steps for Customer ABC

The slide shows the configuration steps for a numbered IP-over-ATM interface on a 4-port 0C3/STM1
line module. First, you configure the SONET controller, specifying the clock source and, if necessary,
the framing. Next, you configure the ATM major interface parameters. For each logical connection, you
create an ATM subinterface and PVC. This examples uses the atm pvc command. Administrators
often use the same number for ATM subinterface, VCD, and VCI, as is the case with the example on
the slide. The ATM major interface, subinterface, and PVC can be configured within any virtual router
context. This example shows all ATM interface configuration taking place within the default virtual
router context.
Finally, you configure the numbered IP interface and, optionally, an IP description

Configuring IP over ATM (2 of 2)

 IP-Over-ATM interface configuration for Customer XYZ
erx1(config-subif)#pvc 34 0/34
erx1(config-subif)#ip description Customer XYZ
IP-over-ATM Interface Configuration Steps for Customer XYZ

The slide shows the configuration steps for a numbered IP-over-ATM interface on the same ATM
major interface. This configuration example uses the pvc command instead of the atm pvc command.
This newer command allows you to easily configure and modify PVC attributes one at a time. These
PVC attributes include the encapsulation method, service category, F5 OAM, and Inverse ARP. If a
PVC attribute is not specifically configured, default values are assigned.

ATM Traffic Management

DSL
Bridge
Outbound Traffic
DSLAM VPI 0
Customer VCI 33
Network DSL
Router VCI 34
VCI 35
Customer
DSL
Network
Router
 Traffic shaping capabilities:

– Outbound traffic shaping done on an individual VC
– UBR
– UBR with peak cell rate (PCR)
– Nonreal-time (nrt) variable bit rate (VBR)
– Real-time (rt) variable bit rate (VBR) (OCx/STMx only)
– Constant bit rate (CBR) (OCx/STMx only)
ATM Traffic Management

The E-series router supports ATM traffic management capabilities, otherwise known as traffic shaping.
Traffic shaping is only relevant to outbound traffic.
The router supports specific ATM service categories. Each line module supports unspecified bit rate
(UBR), UBR with peak cell rate (PCR), non-real-time (nrt), variable bit rate (VBR), real-time (rt) VBR,
and constant bit rate (CBR). See the Link Layer Configuration Guide for more specific details.
Using UBR with PCR, you only configure the peak cell rate for VC.
With nrt VBR and rt VBR, you configure the following parameters: PCR, average (sustained) cell rate,
and burst size. The average cell rate is the sustained rate to which the VC is restricted. The PCR
identifies the peak rate at which the VC is allowed to burst for the configured burst size, which is in
terms of a number of cells. After one burst, the rate must fall below the average cell rate before a
subsequent burst is permitted.
With CBR, you only configure a constant bit rate per PVC.

ATM Traffic Management Configuration

 Traffic management configuration examples:
– UBR
– UBR with PCR: peak cell rate = 512 Kbps
erx1(config-subif)#atm pvc 34 0 34 aal5snap 512
– nrt VBR: peak cell rate = 256 Kbps, average cell rate = 128 Kbps,
burst = 1000 cells
erx1(config-subif)#atm pvc 35 0 35 aal5snap 256 128
1000
– rt VBR: peak cell rate = 256 Kbps, average rate = 128 Kbps,
burst = 1000 cells
erx1(config-subif)#atm pvc 36 0 36 aal5snap 256 128
1000 rt
– Constant bit rate = 1 Mbps
erx1(config-subif)#atm pvc 37 0 37 aal5snap cbr 1000
ATM Service Category Configuration

This slide shows how you configure PVCs using the different traffic management capabilities. The first
few examples show the configuration using the atm pvc command. The last example shows the
configuration using the pvc command.

ATM VC Classes
 ATM VC classes:
– Group or classify ATM circuits based on common attributes Easier to
create or modify large numbers of ATM PVCs
– - Template containing common ATM configuration parameters
 Encapsulation method. service category. F5 OAM options. and Inverse ARP
erxl(config)#vc-class atm biz-user
erxl(config-vc-class)#encapsulation aal5snap
erxl(config-vc-class)#cbr 1000
erxl(config-vc-class)#exit
erxl(config)#vc-class atm res-user
erxl(config-vc-class)#encapsulation aal5snap
erx1(config-vc-class)#ubr 512
ATM VC Classes
What if you configured 1000 CBR ATM PVCs with a rate of 1 Mbps and now you want to change the
PCR to 1.5 Mbps. How would you do that? You would have to modify all 1000 PVCs individually,
changing the rate to 1.5 Mbps.
ATM VC classes provide a way to group or classify ATM circuits based on common attributes, such as
service category. An ATM VC class is a template that contains common ATM attributes, such as
encapsulation method, service category, F5 OAM options, and Inverse ARP.
For example, a service provider might have two types of customers. Its business users require 1-Mbps
CBR connections, and its residential users require UBR connections with a peak cell rate of 512 Kbps.
The slide shows the configuration of two ATM VC classes, one for the business users and one for
residential users. The ATM VC class contains the common ATM PVC attributes for each type of user.
The ATM VC class is then applied to each type of connection. If the service provider decides to
upgrade the business user's rate from 1 Mbps to 1.5 Mbps, a single change is made to the ATM VC
class. All PVCs using this ATM VC class are automatically changed.

Assigning ATM VC Classes

 Assigning ATM VC classes:
– Assign ATM VC class to a PVC, an ATM subinterface, or an ATM
major interface
– ATM VC class precedence level rules
– ATM PVC must be created using the pvc command
erx1(config)#int atm 6/2
erx1(config-if)#class-int res-user
erx1(config-if)#int atm 6/2.100
erx1(config-subif-atm-vc)#class-vc biz-user
erx1(config-subif-atm-vc)#exit
erx1(config-subif)#ip add 100.1.1.1/30
erx1(config-subif)#int atm 6/2.101
erx1(config-subif-atm-vc)#exit
erx1(config-subif)#ip add 100.1.1.5/30
Assigning ATM VC Classes

You can assign ATM VC classes to the ATM major interface, the ATM subinterface, or an individual
ATM PVC. ATM VC class assignments only work on ATM PVCs created using the pvc command.
ATM VC classes have no affect on PVCs configured using the atm pvc command.
Because you can assign ATM VC classes at different levels of the interface column, specific
precedence level rules exist as to which VC class is assigned to a PVC. Any PVC configured with
explicit ATM PVC attributes always takes precedence. If a PVC attribute is not explicitly configured, the
router first determines if a VC class is associated with the individual PVC and uses those attributes. If
no VC class is assigned to the ATM PVC, the router determines if a VC class is assigned to the ATM
subinterface. Next, the router determines if a VC class is assigned to the ATM major interface. Finally,
if no PVC attributes are explicitly configured or contained in a VC class, the router uses the default
system values. Remember that VC classes only affect PVCs configured using the pvc command, not
the atm pvc command.
Let's examine the configuration on the slide to further explain this point. The res-user ATM VC class is
assigned to the ATM major interface. The ATM PVC 0/100 is configured first, specifying the biz-user
ATM VC class. The router uses the ATM attributes in the biz-user to configure this PVC. Next, the PVC
0/101 is configured without explicitly configuring PVC attributes. No VC class is specified for the
individual PVC or for the ATM subinterface, 6/2.101. However, the ATM major interface has an
assigned VC class. Therefore, the router uses the ATM VC class assigned to the ATM major interface,
res-user, to configure this PVC.

Numbered IP Interfaces
40.40.0.0
DSL .2 172.10.1.0/30
Router .1
Internet
.6 172.10.1.4/30 .5
DSL
Router
20.20.0.0
30.30.0.0
 View each ATM PVC as a unique point-to-point network

– Assign a single subnet to each ATM PVC
– Configure numbered IP interfaces on each end of the ATM PVC
– Easy to configure and manage
– Uses up IP addresses
IP Addressing: Option 1
In an IP-over-ATM environment, you can approach IP addressing two ways. The first way is to view
each ATM PVC as a unique, point-to-point network. With this approach, you assign each PVC a
unique subnet and assign a specific numbered IP address to each end of the ATM PVC. This approach
is very straightforward and easy to manage as there are no static routes to configure. It does, however,
use up IP addresses quickly. Many business DSL environments implement this addressing approach.

Unnumbered IP Interfaces
50.50.0.0
loopback 0
172.10.2.1/32
DSL 172.10.2.2/32
Router
unnumbered IP
loopback 0
Internet
NAT
172.10.2.3/32 unnumbered IP
DSL loopback 0
Router
10.0.0.0
 View each DSL router as an individual host

– Configure numbered IP interfaces on the DSL routers
– Configure unnumbered IP interfaces on the E-series router’s
PVCs
– Reference a loopback interface on the E-series router
– Conserves IP addresses
– More difficult to configure and manage
IP Addressing: Option 2
With the second approach to IP address assignment in an IP-over-ATM environment, you view each
DSL router as an individual host instead of viewing the ATM PVC as a point-to-point link. Each CPE
DSL router is assigned a numbered IP address. On the E-series router, a loopback interface is created
and assigned an IP address. The ATM PVCs on the E-series router are not assigned numbered IP
addresses. Instead, the PVCs are configured as unnumbered IP interfaces referencing the loopback
interface. While this approach conserves valuable IP address space, it is a bit more difficult to
configure and manage.

Routing Configuration: CPE
40.40.0.0
0.0.0.0
DSL
172.10.1.2/30 172.10.1.1/30
Router
int atm 6/2.33 Internet
unnumbered IP
loopback 0
DSL 172.10.2.2/32
Router int atm 6/2.34
0.0.0.0
50.50.0.0
 CPE DSL router:

– Default route directing traffic to the E-series router
– Next-hop address is CPE router’s interface
Routing Configuration: CPE

The routing configuration of IP over ATM is fairly straightforward. In the example on the slide, the CPE
DSL router must have a default route (0.0.0.0) configured, referencing its own interface as the next-
hop address. Any traffic not destined for local networks is forwarded to the router.

Routing Configuration: Router

Network Statement or Route Redistribution
172.10.1.0/24
172.10.2.0/24
40.40.0.0 40.40.0.0/16
0.0.0.0 50.50.0.0/16
DSL 172.10.1.2/30 172.10.1.1/30

Router
int atm 6/2.33 Internet
unnumbered IP
loopback 0
DSL 172.10.2.2
Router int atm 6/2.34
0.0.0.0 Prefix/Length Type Next Hop Dst/Met Intf
40.40.0.0/16 Static 172.10.1.1 1/0 ATM6/2.33
50.50.0.0 50.50.0.0/16 Static 0.0.0.0 1/0 ATM6/2.34
172.10.1.0/30 Connect 172.10.1.1 1/0 ATM6/2.33
 On the E-series router: 172.10.2.1/32
172.10.2.2/32
Connect
Static
172.16.2.1
0.0.0.0
0/0
1/0
loopback0
ATM6/2.34
– Create static routes for each remote customer network
– Unnumbered interfaces
 Create a static host route for each DSL router
 Next-hop interface must be the appropriate ATM subinterface
– Advertise appropriate customer networks
 Route maps
 Network statements or route redistribution
Routing Configuration: Router

The E-series router needs a static route configured for each remote customer network. In the example
on the slide, the following networks must be reachable from the Internet: 40.40.0.0 and 50.50.0.0.
Static routes are configured for each network, with the appropriate ATM subinterface configured as the
next-hop interface. For unnumbered interfaces, static host routes must be configured on the router for
each of the DSL router interfaces, again specifying the appropriate ATM subinterface for the next hop.
To advertise these networks onto the Internet, use network statements or route redistribution with route
maps, depending on the routing protocol in use.

IP-over-ATM Configuration Steps

erx1(config)#interface loopback 0
IP Interface IP Interface
erx1(config-if)#ip address 172.10.2.1/32
erx1(config-if)#interface atm 6/2
ATM ATM
erx1(config-if)#interface atm 6/2.33 Subinterface Subinterface
erx1(config-subif)#ip address 172.10.1.1/30
ATM Major
erx1(config-subif)#ip description CustomerABC Interface
erx1(config-subif)#interface atm 6/2.34
OCx/STMx
erx1(config-subif)#atm pvc 34 0 34 aal5snap T3A/U3A
erx1(config-subif)#ip unnumbered loopback 0
erx1(config-subif)#ip description CustomerDEF
erx1(config-subif)#exit
erx1(config)#ip route 40.40.0.0 255.255.0.0 atm 6/2.33
erx1(config)#ip route 172.10.2.2 255.255.255.255 atm
6/2.34
erx1(config)#ip route 50.50.0.0 255.255.0.0 atm 6/2.34
IP-over-ATM Configuration
This slide shows the configuration for the two routers on the previous page. To configure IP-over-ATM
interfaces, first configure the clocking for the SONET controller, which was shown on a previous page.
If you use unnumbered interfaces, configure a loopback interface, which will be used as a reference.
Next, create an ATM major interface specifying the number of VCs per VP if necessary. For each CPE,
configure an ATM subinterface and an ATM PVC. Configure a numbered or unnumbered IP interface
and an IP description to aid in troubleshooting. Finally, create the appropriate static routes. Notice that
the numbered IP interface does not require a host route.

Examining IP-over-ATM Configuration

 Use Show command to verify the configuration
erx1# show config interface atm 6/2
erx1# show config category interface
erx1# show atm vc-class biz-user include-defaults
Verify the Configuration

This slide shows several commands to examine the new configuration.


 B-RAS and DSL Overview
 IP-over-ATM Operation and Configuration
 Troubleshooting IP over ATM
Troubleshooting IP over ATM

The slide highlights the topic we will discuss next.

Verify IP-over-ATM Configuration in Layers

Layer Command Result
IP ping 172.10.1.2 Verifies network reachability

show ip interface atm 6/2.33 IP configuration and statistics
show ip route | include 172.10.1 Routes for 172.10.1*.*
traceroute Determines network path
ATM Sub- show atm subinterface atm 6/2/0/33 Subinterface configuration

interface show atm subinterface atm 6/2.33 and statistics
show atm vc atm 6/2 33 Detailed VC statistics by VCD
show atm subinterface atm 6/2 Lists all ATM subinterfaces on

a slot/port
ATM show atm interface atm 6/2 ATM major interface status
Major and statistics
Physical show controller sonet 6/2 Specific controller

configuration and status
show controller sonet Status of all controllers
Think in Layers!
When you troubleshoot any new configuration on the router, you must think in layers. First try to ping
the newly configured interface. If that does not work, start examining the configuration at the physical
layer and work your way up the interface column. Ask yourself the following questions when initially
troubleshooting an IP-over-ATM configuration:
• What is the state of the SONET controller?
• Am I transmitting and receiving frames on the entire ATM interface?
• Am I receiving errors on the ATM interface?
• Am I transmitting and receiving frames on the specific ATM PVC?
• Am I receiving errors on the ATM PVC? Verify the encapsulation method being used. Is it
the same at each end of the PVC?
• Am I transmitting and receiving frames at the IP layer?
• Am I dropping packets?
• Do I have a route to the CPE DSL router?
• Do I have a route to the networks beyond the CPE router?
• Does the CPE router have a default route to the E-series?

Additional Troubleshooting Commands

 Establish a statistics baseline
– Router reads and stores statistics at the time baseline set
– When baseline-relative statistics requested, router subtracts the
baseline statistics
– By default, must use key word delta to obtain baseline-relative
statistics
– To always obtain baseline relative statistics, enable
baseline show-delta-counts
 Examples:
erx1#baseline interface atm slot/port vcd
erx1#baseline interface atm 6/2 33
erx1#baseline ip interface atm 6/2.33
erx1#ping 172.10.1.2
erx1#show ip interface atm 6/2.33 delta
erx1#show atm vc atm 6/2 33 delta
Establish a Statistics Baseline

On the E-series router, you can set a statistics baseline to aid in troubleshooting new configurations.
You can establish baselines for Layer 2 interfaces such as ATM or PPP, IP interfaces as well as other
processes running on the router. The baseline command forces the router to read and store the
statistics of the interface or process at the time the command is entered. When you request baseline-
relative statistics using the delta keyword, the router subtracts the baseline statistics. By default, you
must include the delta keyword in any show command to obtain baseline-relative statistics. You can
have the router always provide this type of information by enabling baseline show-delta-counts.
Example
The slide shows an example of how one might use the baseline capability to troubleshoot a new
interface configuration. First establish a baseline for the ATM PVC and IP interface. Next, send
packets across the interface using the ping command. Then examine the ATM and IP interface
statistics using the delta keyword.

Review Questions
1. What are two types of DSL connections that maintain the
traditional dial-up remote access method?
2. What are four types of DSL connections, and how are they
different from one another?
3. On an E-series router, what identifies a PVC?
4. What is VP traffic shaping?
5. How can you use statistics baselines to aid in
troubleshooting a new configuration?
This Chapter Discussed:

• The narrowband remote access services and broadband remote access services;
• Different types of DSL connections;
• The equipment used in an DSL network;
• The life of a packet in an IP-over-ATM environment;
• Basic ATM concepts and terminology;
• The different IP addressing options in an IP-over-ATM environment; and
• How to configure an IP-over-ATM interface on the E-series router.

Lab 1: Configuring IP over ATM
Lab Objectives:
Configure and troubleshoot IP-over-ATM interfaces.
Lab 1: Configuring IP over ATM

The slide shows the objectives for this lab.


Module 2: Bridged Ethernet and DHCP

E-series B-RAS Configuration
Module Objectives
to:
– Describe the life of a packet in a bridged Ethernet environment
– Describe IP addressing options in a bridged Ethernet
environment
– Compare and contrast E-series routing configuration options in a
bridged Ethernet environment
– Configure the DHCP relay agent and DHCP relay proxy
– Configure a bridged Ethernet ATM PVC

• The life of a packet in a bridged Ethernet environment;
• The IP addressing options in a bridged Ethernet environment;
• The routing configuration options in a bridged Ethernet environment;
• How to configure the DHCP relay agent and DHCP relay proxy components; and
• How to configure a bridged Ethernet ATM PVC.
Module 2: Bridged Ethernet and DHCP 2-2

Agenda: Bridged Ethernet and DHCP

 Overview of Bridged Ethernet
 Bridged Ethernet and DHCP Configuration and
Troubleshooting
Overview of Bridged Ethernet


Bridged Ethernet Services

PC w/Ethernet
NIC PC w/xDSL
Bridged Ethernet
Modem
DSL
Modem
DSL DSL
Modem
Bridge
Network
of PCs
DSL
PC w/ATM NIC Modem
xDSL
IP over ATM Concentrator
DSLAM
DSLAM
Customer
Network DSL ATM
Router Internet
ATM
DSL Switch DHCP
Customer Router
Network Server
 Small number of users requiring network connectivity

– Home with a single PC
– Small office with 3 or 4 PCs
– Public Wi-Fi hotspot
– No additional IP networks
Always On, No Authentication

Recall that there are many different types of B-RAS connections. In this class, we focus on bridged
Ethernet, IP over ATM, PPP over ATM, and PPP over Ethernet. These connection types fall into two
different categories:
• No centralized user authentication and authorization; and
• Centralized user authentication and authorization.
We just discussed the IP-over-ATM approach. With this approach, a DSL-capable router is installed at
the customer's location. Several separate IP networks might require access to the Internet. Using
bridged Ethernet, a DSL-capable bridge or bridging modem is located at the customer's location. The
users at this location are also always on with no user authentication taking place. Typically, a bridged
Ethernet connection supports a small number of users. For example, a home might have a single PC
requiring network connectivity or a small office might require connectivity for 3 or 4 workstations. In the
wireless environment, a public Wi-Fi access point, sometimes known as a hot spot, might have several
users requiring Internet access. Unlike IP over ATM, bridged Ethernet environments do not have
separate IP networks requiring access to the Internet.

Bridged Ethernet—Life of a Packet

IP=1.1.1.2 IP Connection Terminated IP=2.2.2.2
MAC=A on the E-series Router MAC=F
MAC=E
VPI/VCI 0/33
DSL MAC=C
MAC=B
Bridge
MAC=D
DA IP=2.2.2.2
SA IP=1.1.1.2
EtherType=0x0800
DA MAC=B
SA MAC=A
DA IP=2.2.2.2 DA IP=2.2.2.2 DA IP=2.2.2.2
Layer 3 SA IP=1.1.1.2 SA IP=1.1.1.2
SA IP=1.1.1.2 RFC 2684
PID=0x000-07
EtherType=0x0800 OUI=0x00-80-C2 EtherType=0x0800 EtherType=0x0800
Layer 2 DA MAC=B LLC=0xAA-AA-03 DA MAC=D DA MAC=F
ATM VPI/VCI=0/33
Life of a Packet
In the bridged Ethernet environment, a DSL-capable bridge or modem is installed at the customer's
location. This bridge provides connectivity to the Internet for the customer's networks. The bridge is
connected over a phone line to a digital subscriber line access multiplexer (DSLAM), which is in turn
connected via ATM to the E-series router. An ATM PVC is provisioned from the E-series router to the
customer's CPE device.
If a user at the customer's location wants access to the Internet, the basic packet flow is as follows. For
this example, the customer uses Ethernet for its Layer 2 transport mechanism.
• The user's PC generates an IP packet, encapsulates it in an Ethernet frame, and addresses
it to the E-series router.
• The DSL bridge receives the Ethernet frame and adds an RFC 2684 header, indicating that
the cell contains a bridged Ethernet frame.
• The DSL bridge then separates the entire frame into ATM cells and transmits them across
the PVC to the E-series router.
• The E-series router receives the cell, strips off the bridged RFC 2684 header, strips off the
Ethernet frame, looks at the destination IP address, and determines the next-hop interface.
• The router encapsulates the IP datagram in the appropriate Layer 2 frame and transmits the
data onto the Internet.
Notice that in a bridged Ethernet environment, the router examines the IP header, makes a routing
decision, and forwards the packet to the next router.

Bridged Ethernet IP Addressing Options

Static Addresses
loopback 0
182.10.1.1/32
unnumbered IP
DSL
182.10.1.2 loopback 0
Bridge
Internet
DSL 182.10.2.33/27
182.10.2.34
Bridge
182.10.2.35
 Client workstation IP addressing options:
– Statically assigned
 1 static address per customer
 Small number of addresses per customer
– Dynamically obtained using DHCP
 Router IP addressing options:
– Unnumbered interfaces
– Numbered interfaces
Client IP Addressing Options

In a bridged Ethernet environment, the IP addresses on the client's workstation can either be statically
assigned or dynamically obtained using DHCP. In this example, the provider is offering customers a
choice of two different static IP services. The first service provides the customer with one public, static
IP address. The second service offering provides the customer 29 public IP addresses. With this
approach, the client workstations do not require any additional software, and their IP addresses never
change.
Route IP Addressing Options
In this environment, the router's interfaces are configured for bridged Ethernet using either
unnumbered or numbered IP interfaces. If the interface is unnumbered, it must reference some stable
interface on the router like a loopback interface.

Client Workstation Routing Configuration
loopback 0
182.10.1.1/32
DSL unnumbered IP
182.10.1.2 Bridge
0.0.0.0 int atm 6/2.36
Internet
182.10.2.33/27
DSL
182.10.2.34 Bridge int atm 6/2.37
0.0.0.0
182.10.2.35
0.0.0.0
 Client workstation configuration using static addressing

– Configure default route pointing to the E-series router
Client Workstation Configuration Using Static Addressing

The routing configuration in a bridged Ethernet environment is fairly straightforward. The client
workstations must have a default route (0.0.0.0) configured directing traffic to the E-series router. This
way the workstations forward any traffic not destined for local networks to the E-series router.

Router Configuration
Network Statements or
loopback 0 Route Redistribution
182.10.1.1/32 182.10.1.0/24
DSL unnumbered IP 182.10.2.0/24
182.10.1.2 Bridge
0.0.0.0 int atm 6/2.36
182.10.1.33/27 Internet
DSL
182.10.1.34 Bridge int atm 6/2.37
0.0.0.0
Prefix/Length Type Next Hop Dst/Met Intf
0.0.0.0 Static 182.10.100.1 1/0 GE5/0
182.10.1.0/24 Static 255.255.255.255 1/0 null0
182.10.1.35 182.10.2.32/27 Connect 182.10.2.33 0/0 ATM6/2.37
0.0.0.0 182.10.1.1/32 Connect 182.10.1.1 0/0 loopback0
182.10.1.2/32 Static 0.0.0.0 1/0 ATM6/2.36
 Router configuration using static addressing:
– Create static routes to each client workstation or group of
workstations
– Next-hop interface must be the appropriate ATM subinterface
– For localized IP address ranges, consider creating a static route
for the range using null0 as the next-hop address
– Advertise appropriate networks using route maps and network
statements or route redistribution
Routing Configuration Using Static Addressing

When the client workstations use static addresses, on the router, configure either a static host route for
each of the individual workstations or a static route for the small groups of workstations, specifying the
appropriate ATM subinterface for the next hop.
For localized IP address ranges, consider creating a static route for the entire address range using
null° as the next-hop address. This type of route is also known as a black-hole route. The null0
interface is a pseudo-interface, which is always up and can never forward or receive traffic. The E-
series router automatically creates the null° interface in every virtual router. If the entire address range
always resides on one router, black-hole routing can save overhead on the router and limit traffic sent
upstream for further processing as this route directs undesired network traffic to the null° interface.
On the slide, the address range 182.10.2.0/24 only resides on this router. In addition, the router has a
default route directing traffic upstream. Assume the workstation with IP address 182.10.1.2 tries to ping
182.10.2.34. If no ICMP filtering occurs, the ping should succeed because that device is on the
network and there is a route for it in the router's routing table. If the same workstation tries to ping
182.10.1.128, the router forwards this packet to null° because there is no specific route for it in the
routing table.
If the black-hole route were not configured, the router would forward this packet out the Gigabit
Ethernet interface for further processing. Because this entire address range is local to this one router,
the packet will ultimately get dropped somewhere farther onto the Internet. Again, this approach only
works if the entire address range is localized to one router. Black-hole routing is not limited to static
addressing in a bridged Ethernet environment.
To advertise these networks onto the Internet, use network statements or route redistribution,
depending on the routing protocol in use.

Dynamic IP Address Assignment

Dynamic Addresses
via DHCP DHCP
loopback 1
Server
182.10.3.1/32
DSL unnumbered IP
182.10.3.2 Bridge
loopback 1
Internet
unnumbered IP DHCP
DSL Server
182.10.3.4 Bridge loopback 1
182.10.3.5
 Dynamic IP address assignment:

– Workstation configured for DHCP
– Bridged Ethernet and unnumbered IP interfaces on the router
 DHCP server options:
– Remote DHCP server, router acts as DHCP relay agent
– Router acts as a local DHCP server
Dynamic IP Address Assignment

The second IP address assignment option allows the PC to obtain its IP address dynamically by using
DHCP. In this environment, the client's workstation has DHCP configured for its IP address
assignment and expects to receive its IP address from a DHCP server. The router is configured for
bridged Ethernet using unnumbered IP interfaces.
DHCP Server Options
The client workstation expects to receive an address offer from a DHCP server. The DHCP server
might be located at a remote location. In this case, the router can be configured to act as a DHCP relay
agent. When the router receives the PC's DHCP discover message, it forwards it to the appropriate
DHCP server to obtain an IP address. The router can also act as a standalone DHCP server.

Routing Configuration—DHCP
loopback 1 Route Redistribution
182.10.3.1/32 182.10.1.0/24 DHCP
DSL 182.10.2.0/24 Server
182.10.3.2 unnumbered IP
Bridge
0.0.0.0 int atm 6/2.38
Internet
unnumbered IP
DSL
182.10.3.3 int atm 6/2.39
Bridge
0.0.0.0
Prefix/Length Type Next Hop Dst/Met Intf
182.10.3.1/32 Connect 182.10.3.1 0/0 loopback0
182.10.3.2/32 AccIntern 0.0.0.0 2/0 ATM6/2.38
182.10.3.4
0.0.0.0 182.10.3.3/32 AccIntern 0.0.0.0 2/0 ATM6/2.39
182.10.3.4/32 AccIntern 0.0.0.0 2/0 ATM6/2.39
 Client workstation configuration using DHCP:

– Default route automatically created
 Router configuration using DHCP:
– Static routes not necessary as router automatically inserts host route
into routing table based on DHCP acknowledgement from server
– Advertise appropriate networks using network statements or route
redistribution
– Consider black-hole route for localized IP address ranges
Client Workstation Using DHCP

Using DHCP eases configuration on both the client workstation and the router. When the client
workstation obtains an IP address from the DHCP server, it automatically installs a default route. No
manual configuration is necessary.
Router Configuration Using DHCP
The router automatically examines the DHCP server response for the IP address assigned to the client
and updates the routing tables with the appropriate host route. In addition, if an IP address is released
and subsequently assigned to a different workstation, the router updates its routing table appropriately.
By default, the E-series router only updates the routing table if an address is assigned to a different
workstation and does not maintain any lease information. Access-internal routes installed by the DHCP
relay agent are maintained in nonvolatile storage. If a router reboots, these access-internal routes are
reinstalled in the routing table and DHCP clients have connectivity after the router is operational. To
advertise these networks onto the Internet, use network statements or route redistribution, depending
on the routing protocol in use. For localized IP address ranges, consider creating a static route for the
entire address range using null0 as the next-hop address. In this example, however, black-hole routing
might not be a viable option. If the DHCP server offers addresses from the same address range to
workstations off multiple routers, the single, contiguous IP address range could be scattered across
many devices. The black-hole approach requires that the address range be contiguous so as not to
cause routing problems.

Agenda: Bridged Ethernet and DHCP

 Overview of Bridged Ethernet
 Bridged Ethernet and DHCP Configuration and
Troubleshooting
Bridged Ethernet and DHCP Configuration and Troubleshooting


Bridged Ethernet Interface Columns

loopback 1
182.10.3.1/32
unnumbered IP
DSL loopback 1
182.10.3.2 Bridge
Internet
DSL 182.10.2.33/27
182.10.2.34 Bridge
Network Numbered or
Layer IP Interface IP Interface Unnumbered
IP Interface
182.10.2.35
Bridged Ethernet Bridged Ethernet
Encapsulation Method
Data Link ATM PVC VCD VPI/VCI
ATM PVC
Layer ATM Subinterface ATM Subinterface Traffic Management
ATM Major Slot/Port

Interface # VCs per Virtual Path
Physical OCx/STMx Slot/Port

Clocking
Layer T3A/E3A
Shutdown
 Think layers!
– Encapsulation, encapsulation, encapsulation!
Think in Layers
When you configure the E-series router, remember to think in layers! Configure interface columns on
the E-series router from the bottom up:
• Configure physical layer parameters first. In an ATM environment, physical parameters
include slot/port or slot/adapter/port, clock source, and framing (SONET or SDH).
• Data link layer parameters include ATM PVC information, encapsulation method, and ATM
framing. Note that you must configure the E-series router to expect a different type of
encapsulation on a PVC connected to a bridge. By default, the E-series router expects to
see an ATM header followed by an IP-over-ATM header, followed by an IP datagram. In a
bridged Ethernet environment, you must configure the E-series router to expect an ATM
header, a bridged Ethernet header, an Ethernet frame, and then the IP datagram. This
encapsulation method is known as bridged Ethernet, although the actual CLI configuration
command is encapsulation bridge1483, referring to the first RFC describing this
environment.
• Network layer parameters include IP addresses, subnet masks, and routing protocols or
static routes.
Note that each layer is dependant on the others.

Configuring Bridged Ethernet

erx1(config-if)#ip address 182.10.3.1 255.255.255.255
erx1(config-if)#exit
erx1(config-subif)#encapsulation bridge1483
erx1(config-subif)#ip unnumbered loopback 1
erx1(config-subif)#exit
erx1(config)#interface atm 6/2.37
erx1(config-subif)#encapsulation bridge1483
erx1(config-subif)#ip description to-small-business
Bridged Ethernet Configuration Steps

The slide shows the configuration steps for unnumbered and numbered bridged Ethernet interfaces.
Because the first example is using an unnumbered interface, a loopback interface is configured and
will be used as the reference point. If IP packets are sent out an unnumbered interface and are
sourced from the router, the source IP address is set to the IP address of the referenced loopback
interface. Remember to think in layers and to configure interface columns on the E-series router from
the bottom up. We discussed the physical and data link layers in the previous module. Here, we focus
on the layers specific to bridged Ethernet. Next, you configure the ATM subinterface and the PVC.
After configuring the subscriber's ATM subinterface, you must specify the bridged Ethernet
encapsulation method using the command encapsulation bridge1483. Finally, you configure an IP
interface on top of this layer. The first example is an unnumbered interface referencing the loopback
interface. The second interface is a numbered IP interface. You can optionally configure an IP
description.
Configuring the interface column from the bottom up is critical in a bridged Ethernet environment. You
must specify encapsulation bridge1483 before configuring the interface's IP address. If you configure
the IP address first, you must delete the IP address, configure the encapsulation method, and
reconfigure the IP address.
By default, proxy ARP in enabled on bridged Ethernet interfaces. The E-series router uses ARP for
every device off a bridged Ethernet interface. You can turn off proxy ARP using the no proxy-arp CLI
command. Note that each layer is dependant on the others.

DHCP Relay Agent

Dynamic Addresses
via DHCP DHCP
loopback 1 Server
182.10.3.1/32
DSL
182.10.3.2 unnumbered IP 1.1.1.1
Bridge
loopback 1
DHCP
Relay Internet DHCP
Agent Server
unnumbered IP
DSL
182.10.3.3 loopback 1
Bridge 2.2.2.2
182.10.3.4
 DHCP relay agent configuration:
– Relay agent configured per virtual router
– Up to 5 DHCP servers
– Relay agent and DHCP local server are mutually exclusive
– Router does not manage or monitor DHCP leases
– DHCP-installed host routes are preserved after reboot
erx7(config)#set dhcp relay 1.1.1.1
erx7(config)#set dhcp relay 2.2.2.2
erx7(config)#set dhcp relay agent
DHCP Relay Agent Configuration

When the router is configured to act as a DHCP relay agent, the router forwards any DHCP discover
packets that it receives on bridged Ethernet interfaces to the DHCP relay agent configured in the
subscriber's virtual router. If the router receives a discover message on an unnumbered interface, the
router passes the IP address of the associated loopback interface to the DHCP server. You can
configure up to five DHCP servers, and the router sends the request to all DHCP servers. The router
forwards any DHCP server-originated responses back to the appropriate DHCP client. Because the
client could receive multiple offers, the router waits for an acknowledgement from the DHCP server
before updating the routing table with the assigned IP address. With this model, the DHCP client is
responsible for choosing which address to use. The DHCP clients communicate directly with the
DHCP server to renew and release addresses, and the DHCP relay agent component never sees this
communication.
By default, the E-series router does not monitor or maintain any DHCP lease information, nor does the
router manage host route information. If the router reboots, DHCP host routes are preserved and
reinstalled into the routing table.
To configure the router as a DHCP relay agent, first configure the DHCP servers using the set dhcp
relay command. Next, enable the DHCP relay agent using the set dhcp relay agent command.

DHCP Relay Proxy

Dynamic Addresses
via DHCP DHCP
DHCP Proxy Relay Server
DSL
182.10.1.12 1.1.1.1
Bridge
DHCP
DHCP Relay
Server Agent Internet DHCP
DSL
182.10.1.13 Server
Bridge
Router 2.2.2.2
DSL
Bridge
182.10.1.14
 DHCP relay proxy:

– Allows router to monitor leases and manage host routes
– DHCP client views the router as the DHCP server
– DHCP servers view the router as the DHCP relay agent
 DHCP relay proxy communicates directly with the DHCP client
and DHCP server
– Receives offers, picks and offers a single address, manages
address renewals and releases, removes stale host routes
DHCP Relay Proxy

By default, when the E-series router is configured as a DHCP relay agent, it does not monitor leases or
manage host routes. If a user turns off the PC, the router has no way of knowing this and keeps the
workstation's host route in its routing table. Even if the lease expires, the router still has no way of
knowing. The router only updates the routing table when the DHCP server offers the same address to
a different DHCP client. With this approach, the router could maintain invalid host route information
and packet forwarding could be compromised.
When the E-series router is configured as a DHCP relay proxy, the router manages all DHCP
communications between the client and the server. In this configuration, the DHCP client views the
router as the DHCP server, while the external DHCP server still views the router as a DHCP relay
agent.
DHCP Relay Proxy Communication
When the client requests an address, the DHCP relay proxy receives the request and forwards it to the
external DHCP servers. As with the DHCP relay agent, you can configure up to five DHCP servers per
virtual router. The DHCP servers respond with offers. With DHCP relay proxy, the router, not the
DHCP client, determines which offer to accept. The router chooses either the specific IP address the
client requested, the offer that contains an IP address on the same subnet as the requested address,
or the offer with the longest lease time. The router then presents a single offer to the client as if it were
the one DHCP server in the network.
Once the DHCP client is configured, address renewals or releases come directly to the router. The
router maintains a table that maps the client ID or MAC address to the real DHCP server's address as
well as the lease time. Based on this information, the router fo rwards any renews to the appropriate
DHCP server and waits for an
acknowledgement, which is then sent back to the client. The router also forwards releases to the
appropriate server and deletes the associated host route from the routing table. The router also
periodically reviews this table to determine if any leases have expired, and it takes the appropriate
action.

DHCP Relay Proxy Configuration

Dynamic Addresses
via DHCP DHCP
DHCP Proxy Relay Server
DSL
182.10.1.12 1.1.1.1
Bridge
DHCP
DHCP
Server Relay Internet DHCP
DSL
182.10.1.13 Agent Server
Bridge
Router 2.2.2.2
DSL
Bridge
182.10.1.14
 DHCP relay proxy configuration:

– Router must be first hop from the DHCP client
– First DHCP server configured enables proxy mode for all
erx8:provider(config)#set dhcp relay 1.1.1.1 proxy
erx8:provider(config)#set dhcp relay 2.2.2.2
erx8:provider(config)#set dhcp relay agent
DHCP Relay Proxy Configuration

If the router is configured as a DHCP relay proxy, it must be the first hop from the DHCP client. If it is
not the first hop, the E-series router operates as a standard DHCP relay agent. Use the set dhcp relay
command to configure the DHCP server addresses and the mode of operation. If you do not specify a
mode for the first DHCP server configured, the router only acts as a DHCP relay agent. If you want to
enable the DHCP relay agent and relay proxy functionality, you must use the proxy keyword for the
first DHCP server configured. If you do not specify the proxy keyword for the first DHCP server, you
cannot change it later. Instead, you must delete all DHCP servers configured and re-add them, using
the proxy keyword for the first server configured.
Access-internal routes installed by the DHCP relay proxy are also maintained in nonvolatile storage. If
a router reboots, these access-internal routes are reinstalled in the routing table, and DHCP clients
have connectivity after the router is operational.

Verifying Bridged Ethernet

Configuration in Layers

ATM Sub- show atm subinterface atm 6/2/0/33 Subinterface configuration

interface show atm subinterface atm 6/2.33 and statistics
show atm subinterface atm 6/2 Lists all ATM subinterfaces on

a slot/port
ATM show atm interface atm 6/2 ATM major interface status
Major and statistics
Physical show controller sonet 6/2 Specific controller

configuration and status
Verifying Bridged Ethernet Connections

When you are troubleshooting any new configuration on the router, you must think in layers. First try to
ping the newly configured interface. If that does not work, start examining the configuration at the
physical layer and work your way up the interface column. Ask yourself the following questions when
initially troubleshooting bridged Ethernet configuration:
• What is the state of the SONET controller?
• Am I transmitting and receiving frames on the entire ATM interface?
• Am I receiving errors on the ATM interface?
• Am I transmitting and receiving frames on the specific ATM PVC?
• Am I receiving errors on the ATM PVC? Verify the encapsulation method being used. Is it
the same at each end of the PVC?
• Am I transmitting and receiving frames at the IP layer?
• Am I dropping packets?
• Do I have a route to the CPE DSL router?
• Do I have a route to the networks beyond the CPE router?
• Does the CPE router have a default route to the E-series?

Review Questions
1. How does a bridged Ethernet environment differ from an IP-
over-ATM environment?
2. How would you describe the basic packet flow from PC to
Internet in a bridged Ethernet environment?
3. Compare and contrast static IP address assignment and
dynamic IP address assignment using DHCP?
4. What are some of the E-series routing configuration options
in a bridged Ethernet environment?
5. What is the difference between DHCP relay agent and DHCP
relay proxy?

• The life of a packet in a bridged Ethernet environment;
• The IP addressing options in a bridged Ethernet environment;
• The routing configuration options in a bridged Ethernet environment;
• How to configure the DHCP relay agent and DHCP relay proxy components; and
• How to configure a bridged Ethernet ATM PVC.

Lab 2: Configuring Bridged Ethernet
Lab Objectives:
Configure a bridged Ethernet interface
and static routes.
Lab 2: Configuring Bridged Ethernet



Module 3: PPP over ATM

Module Objectives

to:
– List the benefits of using PPP over ATM
– Describe the basic life of a packet in a PPP-over-ATM
environment
– List and describe the three different ways a PC can obtain its IP
address dynamically in a PPP-over-ATM environment
– Explain the purpose of the domain map
– Explain the function and use of profiles
– Configure the E-series router for PPP over ATM
– Describe the E-series router’s logging capabilities
– Verify PPP-over-ATM operation using show commands and
setting statistics baselines

• The benefits of PPP over ATM;
• The life of a packet in a PPP-over-ATM environment;
• Three ways a PC can dynamically obtain an IP address in a PPP-over-ATM environment;
• The purpose of a domain map;
• The functions and use of profiles;
• Configuring the E-series router for PPP over ATM;
• The E-series router's logging capabilities; and
• Using show commands and logging to verify PPP-over-ATM operation.
Module 3: PPP over ATM 3-2

Agenda: PPP over ATM

 Overview of PPP over ATM
 Life of a Packet: PPP over ATM
 Configuring PPP over ATM
 Troubleshooting PPP-over-ATM Interfaces
Overview of PPP over ATM


Modem
RADIUS
tyler@isp1.com
Routers ISP1
RAS
PPP Session
Modem
RADIUS ISP2
paul@isp2.com
 History of remote access:

– 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
Traditional Remote Access

In the remote access world of yesterday, relatively slow-speed connections were made using a
dedicated plain old telephone service (POTS) line. These connections, with speeds from 28.8 kbps to
56 kbps, were one to one in nature. 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 to the appropriate routers.
However, times have changed and needs have changed. More and more often, families have more
than one PC, yet they only have one additional phone line to use for connectivity. In addition, more
users are demanding higher access rates. There must be a better solution.

Authentication in a DSL Environment

PC w/Ethernet NIC
PC w/DSL Modem PPP over Ethernet
Bridged Ethernet PPP over ATM
DSL
Modem
DSL
DSL
Bridge Modem
Network
PC w/ATM NIC of PCs
DSL
Modem
IP over ATM
DSLAM DSL
DSLAM Concentrator
Customer
Network DSL
Router ATM
Internet
PPP over ATM
ATM
DSL
Switch
Network
DHCP
 Two methods of maintaining current dial-up model, complete

with RADIUS authentication and accounting services:
– PPP over ATM
– PPP over Ethernet
Authentication and Accounting in a DSL Environment

The previous modules discussed two types of B-RAS connections, specifically IP over ATM and
bridged Ethernet. These connection types are always on and do not provide any centralized user
authentication or authorization.
Another 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. Then they obtain an IP address either from
RADIUS or from a local address pool on the router. We often refer to this approach 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―Single User per ATM PVC

DSL PPP Sessions
Modem
tyler@isp1.com
PPP client
ATM NIC
ISP1 RADIUS
Private DSL
Network Router
home1@isp1.com
Router with
PPPoA Support ISP2 RADIUS
DSL
Modem
paul@isp2.com External DSL modem

PPP client with PPPoA support
 PPP over ATM:

– Single, high-speed interface supporting thousands of ATM
PVCs
– One ATM PVC or subinterface per modem or router supporting a
single PPP session and a single IP interface
– E-series router terminates the PPP session
 PPP over ATM connection methods
Single User per ATM PVC

With PPP over ATM, the E-series router supports a single client or IP interface on a single ATM
subinterface. In other words, a one-to-one relationship is formed. An ATM permanent virtual circuit
(PVC) is configured for each user or device.
A PPP session and an IP interface are established across this PVC between the user and the router.
The router terminates this PPP session and acts as a liaison or client for the authentication,
authorization, and accounting (AAA) associated with the user's PPP client. The router maintains a
single IP interface on this ATM PVC. The customer might have many users using this single ATM
PVC, as in the case of the DSL router using Network Address Translation (NAT) services. But from the
perspective of the router, it maintains a single IP interface and does not know that many individual
users might use this PVC.
Over a single, high-speed interface, you can configure thousands of ATM PVCs to support thousands
of remote DSL users. To support this configuration, you must configure each ATM PVC with a single
PPP encapsulation supporting a single IP interface.
PPP-over ATM-Connection Methods
The slide shows the E-series router servicing two ISPs—ISP1 and ISP2. These ISPs have three types
of PPP-over-ATM customer connections. The first type of connection is a user's PC with an ATM NIC
installed, which connects to the DSL modem. In this scenario, when the PC wants to send IP data, that
data is encapsulated into a PPP frame. Although possible, this connection type is not very common.

The second connection type is a small business or residence using a DSL router with an integrated
DSL/ATM interface and an Ethernet interface. In this setup, the PPP login information is configured on
the router. This router might 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 a PPP frame. This is the most common PPP-over-ATM connection
method.
The third type is a single user or PC connecting to a DSL modem supporting PPP over ATM. This
user's workstation typically connects to the modem using either a USB or PCI interface, and the
workstation runs PPP client software. The user's IP traffic is encapsulated in a PPP frame and sent to
the DSL modem, which forwards it along to the DSLAM.
With all three methods, the user's IP datagrams are first encapsulated into a PPP frame. Next, the PPP
frame is fragmented into 53-byte ATM cells and sent over the appropriate ATM interface. These cells
are then transmitted across the POTS connection, to the DSLAM, across the ATM switch (if
necessary), and are received by the E-series router.
From the router's perspective, all approaches are equivalent in that the ATM cells received have an
RFC 2364 header indicating PPP, then the PPP frame, and finally the IP datagram. The router
reassembles the PPP frame and routes the packet out the appropriate interface.
From this point on, we focus our attention on the PPP side of the connection, remembering that this
PPP session is carried in an ATM PVC.

PPP over ATM—Life of a Packet

IP/PPP/ATM Connection
IP=192.168.1.10 Terminated on the Router
IP=1.1.1.2 IP=2.2.2.2
MAC=X
MAC=A MAC=F
VPI/VCI 0/33 MAC=E
DSL MAC=C
MAC=B
Router
IP=192.168.1.1 MAC=D
MAC=Y
DA IP=2.2.2.2
SA IP=1.1.1.2
Layer 3 DA IP=2.2.2.2 DA IP=2.2.2.2 DA IP=2.2.2.2
SA IP=192.168.1.10 PPP Header SA IP=1.1.1.2 SA IP=1.1.1.2
RFC 2364
EtherType=0x0800 NLPID=0xCF EtherType=0x0800 EtherType=0x0800
Layer 2 DA MAC=B DA MAC=D DA MAC=F
SA MAC=A ATM VPI/VCI=0/33 SA MAC=C SA MAC=E
Life of a Packet
In this PPP-over-ATM environment, a PPP-over-ATM-capable DSL router is installed at the customer's
location. This router is providing NAT services to the workstations on the LAN. The router is connected
over a phone line to a DSLAM, which is in turn connected using ATM to the router. An ATM PVC is
provisioned from the router to the customer's DSL router. The user's PCs in this network do not have
any extra software installed. If a user at the customer's location wants access to the Internet, the basic
packet flow is as follows:
• The user's PC generates an IP packet that is forwarded to the DSL router.
• The router NATs the packet and encapsulates the IP packet in a PPP frame. It then
segments the frame into ATM cells and adds an ATM RFC 2364 header indicating that the
cell contains a PPP frame.
• The cells are then transmitted across PVC to the router.
• The router receives the cells and reassembles the PPP frame. Then the router strips the
PPP frame, looks at the destination IP address, and determines the next-hop interface.

Typical IP Addressing Scheme

DSL
Modem
tyler@isp1.com Route Redistribution RADIUS
182.16.3.2 182.16.3.0/24 Server
loopback 0
DSL
Modem
192.168.100.1/32
gary@isp1.com
Internet
182.16.3.3
DSL
Modem
unnumbered IP
rich@isp1.com loopback 0
182.16.3.4
 Typical IP configuration:
– Workstation obtains IP address dynamically
– Router uses unnumbered IP interfaces
– Router dynamically installs workstation’s host routes into routing
table
– Router advertises appropriate networks using network statements
or route redistribution techniques
Typical IP Configuration Techniques

In a PPP-over-ATM environment, workstations dynamically obtain their IP addresses, either from a
RADIUS server or a local address pool configured on the router. Unnumbered interfaces are typically
configured on the router referencing some stable IP interface such as a loopback interface.
Because DSL users obtain their IP addresses dynamically, they might or might not obtain the same IP
address every time they connect to the network. In addition, this IP address must be inserted into the
router's routing table, tied to the appropriate ATM PVC. To have the router automatically insert the DSL
user's host route into the routing table, use the configuration command ip access-routes for each
unnumbered IP interface supporting a DSL user. To advertise these networks onto the Internet, use
network statements or route redistribution, depending on the routing protocol in use. For localized IP
address ranges, consider creating a static route for the entire address range using null° as the next-
hop address. In this example, however, black-hole routing might not be a viable option. If the RADIUS
server is offering addresses from the same address range to workstations off multiple routers, the
single, contiguous IP address range could be scattered across many devices. The black-hole approach
requires that the address range be contiguous so as not to cause routing problems:


 Overview of PPP over ATM
 Life of a Packet: PPP over ATM
Life of a Packet PPP over ATM


Life of a Packet—Session Initiation

1 -PPP LCP
Request
E-series Router
DSL
Modem
2 -PPP LCP default
Tyler@isp1.com Request - Chap
ISP1
AAA
Process
RADIUS
VR2
DSL
Modem ISP2
Paul@isp2.com
RADIUS
 Session initiation:
– User initiates PPP connection using LCP
– PPP client and E-series router agree on PPP authentication
protocol (CHAP or PAP)
Session Initiation
Let's take a look at the details of the configuration as well as how a user's session is established using
this configuration.
The E-series router shown on the slide is configured for two 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 using PPP Link Control Protocol (LCP)
to the E-series router. LCP negotiation occurs. Some of the LCP options that the router can negotiate
include the MRU, magic number (for loopback detection), and authentication protocol—Password
Authentication Protocol (PAP) or the Challenge-Handshake Authentication Protocol (CHAP)).

Determining the Authentication Server

AAA Domain Map
Domain Router Name Local Interface
isp1.com default loopback0
isp2.com VR2
DSL
Modem default
Tyler@isp1.com
AAA ISP1
Tyler@isp1.com Process
VR2 RADIUS
DSL
Modem
ISP2
Paul@isp2.com
RADIUS
 Determine authentication server:
– User sends login: Tyler@isp1.com
– Router examines login for domain name “@isp1.com”
– Router searches the domain map for user’s domain name
– Domain/realm. Delimiter, and parsing order configurable
Determining the Authentication Server

During authentication, Tyler sends his login, Tyler@isp1.com, to the E-series router. On the E-series
router, the AAA server or process handles all authentication, authorization, accounting, and address
assignment functions.
The router's AAA server parses this login for the user's domain name. By default, the E-series router
uses the string after the @ sign as the domain name. You can set up the router to recognize delimiters
other than the @ sign using the aaa delimiter domainName command. The AM server on the router
receives the login request, searches the domain map, determines through which virtual router the user
will authenticate, and forwards the request to the appropriate virtual router. You can also override
domain-wide behavior and steer an individual user to a specific virtual router.
You manually configure the domain map on the E-series router. This global, or box-wide, table simply
lists the valid domains and with which virtual router they are associated. This table initially determines
which authentication server to use. Based on a match, the E-series router uses the RADIUS
authentication server configured in this virtual router.
In this example, the E-series router searches the domain map for isp1.com. The router determines that
the domain isp1.corn 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 no match exists in the domain map, the request is sent to the RADIUS authentication server listed in
the default virtual router. For example, what happens if Diane@isp3.com tries to login using this
configuration? Because there is no match in the domain map, the request is sent to the RADIUS server
listed in the default virtual router. You can override this behavior by mapping a domain name called
default to a specific virtual router in the domain map.

If no domain is in Tyler's login, the router first searches the domain map for an entry mapping the
domain called none to a specific virtual router. If the router finds a match, it sends the request to the
RADIUS server in the specified virtual router. If it finds no match, the router next searches for the
domain called default. If it finds no match, the request is sent to the RADIUS server configured in the
default virtual router.
The router is able to use a delimiter other than the at (@) sign. The router is also able to use the realm
name as the domain name, use delimiters other than the forward slash (/) to designate the realm name,
and use either the domain or the realm as the domain name when the username contains both. You
can also change the direction in which the router searches for the domain name or the realm name.

RADIUS Authentication and Authorization

AAA Domain Map
isp2.com VR2
DSL RADIUS
Modem default Access Request 1.1.1.1
Tyler@isp1.com Tyler@isp1.com
RADIUS=1.1.1.1
UDP=1645 ISP1
key=training
Access Accept
VR2 Tyler@isp1.com
IP=192.168.1.10
RADIUS=2.2.2.1
UDP=1645
key=training
DSL RADIUS
Modem
ISP2 2.2.2.1
Paul@isp2.com
 RADIUS authentication and authorization:

– Based on the virtual router, the authentication request is forwarded to
appropriate RADIUS server
– Configure RADIUS server IP address, UDP port, and key
– RADIUS server returns a deny/grant, including user/session attributes
RADIUS Authentication and Authorization

After the E-series router receives Tyler's login request and examines the domain map, it 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 and not tied to a virtual router.
By default, the E-series system uses UDP port 1812 for the RADIUS authentication server per the
RFC. If your RADIUS server is using a different UDP port for authentication, such as UDP port 1645,
explicitly configure the E-series router to use this port.
You must configure the RADIUS key to match the RADIUS server configuration. This encrypts the
password sent from the E-series router to the RADIUS server.
The E-series router is a RADIUS client and forwards the authentication request or access request to
the RADIUS server, 1.1.1.1. This access request might include checklist attributes: user name, PAP
user password or CHAP password and challenge, framed protocol, and router's IP address.
The RADIUS server issues an access-reject message if Tyler@ispl.com is not found on the server or if
the passwords are incorrect. The RADIUS server issues an access-accept message if Tyler@ispl.com
is found on the server and if the password or challenge response is correct.
In addition, the grant might include return list attributes, which the router applies to the user's session.
These attributes might include the IP address, subnet mask, IP routes for security purposes, session
timeout, and idle timeout. On the slide, the RADIUS server returned an IP address from a pool
configured on the server.
You can also configure the RADIUS server with Juniper Networks vendor-specific attributes (VSAs).
Later in the module, we discuss these attributes further and how they are used.

RADIUS Timers
DSL RADIUS
RADIUS=1.1.1.1
UDP=1645 ISP1
key=training
Access Accept
Tyler@isp1.com
VR2
IP=192.168.1.10
RADIUS=2.2.2.1
UDP=1645
key=training
DSL RADIUS
Modem
ISP2 2.2.2.1
Paul@isp2.com
 Additional RADIUS parameters:

– Timeout
– Retransmit
– Deadtime
Additional RADIUS Parameters

By default, unacknowledged RADIUS requests are retransmitted to the RADIUS server every 3
seconds. You can adjust how long the router waits before resending the request using the retransmit
parameter. Also by default, the E-series router retransmits unacknowledged RADIUS requests to a
RADIUS server three times. You can change this value using the retransmit parameter.
In a multiple RADIUS server environment, you can mark an unresponsive RADIUS server unavailable
for a specific period of time and stop sending additional requests to that server. We call this period of
time the deadtime, which is another configurable parameter. By default, the deadtime is set to 0, which
is why the router continually sends authentication requests. Assume the deadtime parameter is set to 5
minutes. If the RADIUS server does not respond after 12 seconds (retransmit * timeout), the router
stops sending requests to this RADIUS server for 5 minutes. The E-series router actually removes the
RADIUS server from the active RADIUS server list.
You can use the show radius authentication server command to view RADIUS servers.
Please review the documentation for additional RADIUS configuration options.

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.100.1
172.10.1.1
loopback 0=
192.168.100.1
RADIUS=1.1.1.1 ISP1 Access Accept
DA = 192.168.100.1
VR2 SA = 1.1.1.1
Router ID=
10.1.1.1
loopback 0=
172.16.100.1
DSL RADIUS=2.2.2.1 2.2.2.1
Modem
ISP2 RADIUS
Paul@isp2.com
 Configuring the source IP address:

– Router ID as the source IP address in packets sent to the RADIUS
– Explicitly configuring the source IP address used to communicate
with the RADIUS server:
erx7(config) #radius update-source-addr 192.168.100.1
– Configured per virtual router
– Verify that the RADIUS server has a route to the configured address
Configuring the Source IP Address

By default, the E-series router uses its router ID (ip router-id) as the source IP address for all packets
sent to the RADIUS server. Unfortunately, the RADIUS server might not have a route to this IP
address or have this IP address configured as a valid RADIUS client.
You can control, however, which IP address the E-series router uses as the source IP address for all
packets sent to the RADIUS server. To force the router 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 E-series system 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 router to reply to the requests. Note
that you can also configure the router ID using the ip router-id a .b. c. d command, which can
accomplish the same goal.

Multiple RADIUS Servers
DSL RADIUS
Modem default 1.1.1.1
Tyler@isp1.com
RADIUS=1.1.1.1
RADIUS=1.1.1.2
ISP1 RADIUS
1.1.1.2
RADIUS=1.1.1.3
VR2
RADIUS
1.1.1.3
RADIUS=2.2.2.1
RADIUS=2.2.2.2
DSL RADIUS
Modem
ISP2 2.2.2.1
Paul@isp2.com
RADIUS
2.2.2.2
 Two algorithms:
– Direct mode
– Round robin
Using Multiple RADIUS Servers

You can configure multiple RADIUS servers on the E-series system. The RADIUS servers are used in
the order in which they are configured.
Use the show radius authentication server command to view the order the system is using at any point
in time.
You can configure the RADIUS servers 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, the E-series router only sends requests 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), the E-series router starts
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 E-
series router reinstates the RADIUS server on the active server list. You configure this
RADIUS algorithm using the radius algorithm direct configuration command.
• Round robin: This algorithm sends out RADIUS requests to all active RADIUS servers in the
order listed in the configuration file. On the slide, 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. With this algorithm, the primary server changes with each request. This mode effectively
uses all configured RADIUS servers equally, in a round-robin fashion. You configure this
RADIUS algorithm using the radius algorithm round-robin configuration command.

IP Address Assignment
AAA Domain Map
isp2.com VR2
DSL RADIUS
Tyler@isp1.com DHCP
RADIUS=1.1.1.1 1.1.2.1
UDP=1645
ISP1
key=training Access Accept
Tyler@isp1.com
192.168.1.10
VR2
RADIUS=2.2.2.1
UDP=1645
key=training
DSL RADIUS
Modem
ISP2 2.2.2.1
Paul@isp2.com
 Three ways for IP address assignment:

– RADIUS server
– Local IP address pool on the E-series system
– DHCP proxy client
IP Address Assignment
The user can obtain an IP address in three different ways. The RADIUS server can provide an IP
address, the router can provide an address from address pool configured on the router, or the router
can obtain an address via a DHCP server.
On the slide, 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.

Local Address Pools

Local address pool configuration for the default virtual router
Address Scheme: ip address pool local
Local Address Pools: ip local pool isp1pool 1.1.100.2 1.1.100.254
ip local pool isp1pool 1.1.101.2 1.1.101.254
DSL
Modem default RADIUS
Tyler@isp1.com 1.1.1.1
RADIUS=1.1.1.1 ISP1 Access Accept
UDP=1645 Tyler@isp1.com
key=training 255.255.255.254
VR2
RADIUS=2.2.2.1
UDP=1645
DSL key=training
Modem
RADIUS
ISP2 2.2.2.1
Paul@isp2.com
 Local address pools:

– If no address is returned, router examines IP addressing scheme
– If RADIUS access-accept message did not contain Address-Pool-
Name, router assigns an address from the first pool configured
– Router assigns addresses from pool sequentially until exhausted and
then moves to the next pool
Local Address Pools

If the RADIUS server returns an IP address of 255.255.255.254, 0.0.0.0, or no address, as is the case
shown on the slide, the E-series router determines which local addressing scheme to use. Remember
that there are two local addressing schemes for PPP users: local address pools or DHCP proxy client.
The router examines the configuration setting of ip address-pool to determine the local addressing
scheme in use. If this configuration parameter is set to ip address-pool local, the router obtains an IP
address for the user from one of the local address pool configured on the router.
Local address pools are configured per virtual router. You configure local address pools on the router
by first issuing the command ip address-pool local. Next, you configure an IP address range by issuing
the command ip local pool poolname ip address start range ip address end range. You specify
additional IP address ranges using the same pool name.
If the user's access-accept message contains a specific pool name in the Juniper Networks VSA
Address-Pool-Name, the router obtains an IP address from the specified pool. If the user's access-
accept message did not contain a VSA, the router tries to obtain an IP address from the first configured
local address pool. Addresses are allocated in sequential, cyclic manner. For example, the first user
gets the first address from the local pool, the second user gets the second address from the local pool,
and so on. The router associates the user with this IP address until the PPP session is disconnected
and the address is released. The third client gets the third address even if the first client released his
address and the first address is now available. If the end of the pool is reached, the router cycles back
to the beginning of the address range and allocates released addresses. When all addresses are
exhausted, the router moves to the next address pool until it finds a free IP address. If there are no
addresses available, the router denies the request. There is no concept of leasing an address as with
DHCP. The E-series router allocates the address to that user until the user's PPP session disconnects.

DHCP Proxy Client

Local address pool configuration for the default virtual router
Address Scheme: ip address-pool dhcp
Local Address Pools: ip dhcp-server 1.1.2.1
DSL
Access Accept
Modem default Tyler@isp1.com
RADIUS
Tyler@isp1.com 255.255.255.254
RADIUS=1.1.1.1
ISP1 1.1.1.1
UDP=1645
key=training
VR2 DHCP
1.1.2.1
RADIUS=2.2.2.1
UDP=1645
key=training
DSL
Modem
ISP2
Paul@isp2.com RADIUS
2.2.2.1
DHCP Proxy Client

The DHCP proxy provides the ability to dynamically assign IP addresses to clients even though the
clients are PPP clients, not DHCP clients. The E-series router acts as a DHCP client on behalf of the
PPP client and negotiates the allocation of an IP address with one or more DHCP server on the
network. The E-series router 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.
If the RADIUS server returns an IP address of 0.0.0.0, no address, or 255.255.255.254, as shown on
the slide, the E-series router determines which addressing scheme it will use to obtain an IP address
for the user. The router examines the configuration setting of ip address-pool. If this configuration
parameter is set to ip address-pool dhcp, the router obtains an IP address for the user from the DHCP
server configured using the DHCP proxy functionality.
In a DHCP proxy environment, the E-series router maintains the DHCP leases. For each client, the
router records the lease time provided by the DHCP server. When 50% of the lease time passes, the
DHCP proxy attempts 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—that is, if it gives a negative
acknowledgement (NAK)—the DHCP proxy alerts the AM server that the address renewal failed. The
AM server then terminates the PPP session, the subscriber is logged off, and the IP address is
released.
To use the DHCP proxy functionality, you first configure the DHCP proxy client on the router by issuing
the ip address-pool dhcp command. Next, you configure the IP addresses of the DHCP servers using
the command ip dhcp-server ip address of dhcp server. You configure the router's DHCP proxy client
and the DHCP servers per virtual router. In a DHCP proxy environment, you can configure up to five
DHCP servers using the ip dhcp-server command. The DHCP servers configured with this command
can be the same ones used in a DHCP relay environment using the set dhcp relay command or they
can be completely different DHCP servers. The DHCP relay agent and the DHCP proxy client are
separate and distinct services. Each service supports a maximum of five DHCP servers. If multiple
DHCP servers are configured, the E-series router sends the address request to all configured servers.

Which virtual router & loopback interface?

AAA Domain Map
IPConf Req 0.0.0.0
isp2.com VR2 RADIUS
default 1.1.1.1
DSL
Modem Access Request
loopback 0 =
IPConf Req ?.?.?.? 192.168.100.1/32 ISP1
VR2
loopback 0 = Access Accept
172.16.100.1/32 Tyler@isp1.com
IP=192.168.1.10
DSL
Modem
RADIUS
2.2.2.1
Paul@isp2.com ISP2
 Determining the virtual router:
– Statically configured unnumbered interfaces reference a loopback
– Loopback interfaces configured per virtual router
– Dynamically created IP interfaces built when the user logs in
– Which virtual router and loopback interface should be used?
 Domain map
 RADIUS vendor-specific attribute
 Profile
Determining the Virtual Router

Once the router obtains an IP address for the remote user, the next step is to perform PPP IP NCP
negotiations. Typically, the router uses an unnumbered interface for this PPP session. Each
unnumbered interface has an associated loopback interface. If the unnumbered IP interfaces on the
router are statically configured, the router knows exactly which loopback interface to use for IP NCP
negotiation. The router also knows to which virtual router the IP interface belongs. It is also possible to
build IP interfaces dynamically when the user logs in using information obtained from RADIUS. If IP
interfaces are dynamically built when the user logs in, which loopback address should be used during
the negotiation process, and in which virtual router will the dynamic interface be built?
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, the router must determine to which virtual router this IP interface will
belong as well as what local interface to use for IP NCP negotiation.
Which virtual router will this IP interface use? The virtual router can be determined by three methods:
• The domain map can specify which virtual router and which loopback interface to use.
• The RADIUS server can return the user's virtual router in the access-accept message and
the loopback interface using Juniper Networks VSAs.
• A profile can also specify which virtual router and which local interface this interface will use.
We discuss more on profiles later in this module.

IP NCP Negotiation
AAA Domain Map
isp2.com VR2
IPConf Req 192.168.100.1 RADIUS
DSL
Tyler@isp1.com
Tyler@isp1.com
IPConf Req 0.0.0.0 loopback 0 = ISP1
IPConf Nak 192.168.1.10 192.168.100.1/32
Access Accept
VR2
Tyler@isp1.com
IPConf Ack 192.168.100.1 loopback 0 = IP=192.168.1.10
172.16.100.1/32
IPConf Req 192.168.1.10
RADIUS
ISP2 2.2.2.1
IPConf Ack 192.168.1.10
Default Virtual Router’s IP Routing Table

Prefix/Length Type Next Hop Dst/Met Interface
192.168.1.10/32 AccIntern 0.0.0.0 2/0 atm 5/1.1
IP NCP Negotiation
Now the router knows the IP address of the user (either from RADIUS, a local address pool, or DHCP),
the virtual router this IP interface will use, and the appropriate IP address to use during IP NCP
negotiation. The router and the user now perform standard IP NCP negotiations.
On the slide, isp1.com is listed in the domain map. Therefore, all dynamic IP interfaces for isp1.com
are created in the router specified in the domain map. In this example, Tyler's IP interface is created in
the default virtual router. In addition, the router uses 192.168.100.1, which is the loopback interface
specified in the domain map, during IP NCP negotiations.
If no entry exists in the domain map for isp1.com, the router determines if the RADIUS server returned
the Juniper-Virtual-Router VSA and the Local-Interface VSA, configuration information needed for IP
interface creation and negotiation. If RADIUS did not return this information, the router determines if
this information is 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 is not created.
If the ip access-routes configuration command is included with the IP interface definition, either
statically defined or in a profile, the router installs the user's IP host route into the appropriate virtual
router's routing table. In this case, Tyler's IP address, which is 192.168.1.10, is installed in the default
router's IP routing table as a 32-bit host route.

Configuring the 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
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
RADIUS
ISP2 2.2.2.1
 During IP NCP, PPP client requests WINS and DNS

addresses
– Supplied by RADIUS using VSAs
– Configured on the router per virtual router
Configuring the Name Servers

The name server configuration operates similarly to the IP address configuration. The user can obtain
the IP addresses of the name servers (DNS and WINS) two different ways:
• RADIUS can return the IP addresses of the name servers using a VSA.
• You can configure the name servers on the E-series router. You configure name servers per
virtual router.
On the slide, RADIUS did not return the IP address of the name servers. The router supplies the
addresses of the name server based on the configuration in the default virtual router.
Per RFC 1035, Domain Name—Implementation and Specification, the E-series system supports a
primary and secondary name server.

RADIUS Accounting
default
DSL RADIUS
Modem
RADIUS=1.1.1.1 1.1.1.1
Tyler@isp1.com UDP=1646 ISP1
key=training
VR2
 User RADIUS RADIUS=2.2.2.1

UDP=1646 RADIUS
key=training 2.2.2.1
accounting messages: ISP2
– RADIUS accounting-start message is sent
– Configurable interim accounting messages
– Duplicate accounting messages are sent to a RADIUS server in a
different virtual router
– RADIUS accounting-stop message is sent when user disconnects
– RADIUS attributes included in messages are configurable
 Router RADIUS accounting messages:
– RADIUS accounting-on message
– RADIUS accounting-off message
User RADIUS Accounting Messages

Once Tyler's service is established, the router sends a RADIUS accounting start message to the
RADIUS accounting server. As with RADIUS authentication servers, you configure RADIUS
accounting servers per virtual router. Accounting is maintained per user. When Tyler disconnects, a
RADIUS accounting stop message is also sent.
You can also configure the router to send RADIUS interim accounting messages using the aaa
accounting interval minutes command. The default is 0 minutes, which means that the feature is
disabled. The minutes parameter can range from 10 minutes to 1440 minutes. You configure the
accounting interval per virtual router. You can also configure the interim accounting interval on the
RADIUS server using the acct-interim-interval attribute. This standard RADIUS attribute is configured
in seconds and must not be set lower than 60 seconds. The RADIUS RFC also suggests not to
configure the interval smaller than 600 seconds, or 10 minutes.
In this example, ISP1 is wholesaling services to ISP2. 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 might want to know
some of the details of ISP2's traffic. To accomplish this task, you can configure the router 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. You configure this option using the
aaa accounting duplication virtual router name configuration command.
It is also possible to configure which RADIUS attributes are included in the accounting start and
accounting stop messages. You can determine which fields are included using the show radius
attributes-included command.
Router RADIUS Accounting Messages
When the router boots or when you configure the first RADIUS accounting server, the router sends an
accounting-on message. When the router is shut down, a RADIUS accounting-off message is sent. An
accounting-off message is also sent if you delete the last RADIUS accounting server in a virtual router
or you delete a virtual router containing a RADIUS accounting server definition.


 Configuring PPP over ATM
Configuring PPP over ATM


B-RAS Licensing
 Each E-series router requires:
– JUNOSe software version
– Subscriber access license to use
– B-RAS subscriber license for each IP-over-ATM session
 4k, 8k, 16k, 32k, or 48k simultaneous active IP, LAC, and bridge d interfaces
 License configuration:
erx7(config)#license b-ras DeMo
NOTICE: The Subscriber Management Feature Pack
software installed on this system is licensed to
support a specific number of simultaneous DSL 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.
erx7(config)#
B-RAS Licensing
In a B-RAS configuration, each E-series router requires a JUNOSe software license as well as a
Subscriber Access software license-to-use (LTU). Each router must also have a B-RAS subscriber
license for each active IP, LAC, and bridged interface. Subscriber licenses come in chunks of 4 k, 8 k,
16 k, 32 k, 48 k (ERX-1440 or E32 platforms), 64 k (E320 platform), or 96k (E320 platform) active
subscribers. The license activation key is shipped with the router. The router provides a grace of 100
subscribers for 4 k, 8 k, and 16 k subscribers. The router does not provide a 100 subscriber grace
license for the 32 k, 48 k, 64 k, or the 96 k licenses. If a 4 k license is configured, the router generates
a warning log message, and the next 100 users are permitted to log in. In this example, the router
denies the 4101st user.
If no license is configured, the router generates a log message when the 100th subscriber logs in. The
101st active subscriber will be denied access.
In this example, a demo license is configured. The demo license allows 100 active subscribers. This
license allows 100 active subscribers plus a 100-subscriber grace. A log message is generated with
the 100th active subscriber and the 201st active subscriber will be denied.
Using the current JUNOSe software, a few cases might exist where the licensing enforcement and log
messages are not in line with the licensing scheme. Future software releases will fix these
inconsistencies.

ISP1’s Initial B-RAS Configuration

 ISP1’s initial configuration:
– Steer users to correct virtual router using AAA domain map
– RADIUS returns user’s IP address, no local pools in use
erx7(config-if)#ip address 192.168.100.1 255.255.255.255
erx7(config-if)#aaa domain-map isp1.com
erx7(config-domain-map)#router-name default
erx7(config-domain-map)#local-interface loopback0
erx7(config-domain-map)#exit
erx7(config)#radius authentication server 1.1.1.1
erx7(config-radius)#key training
erx7(config-radius)#exit
erx7(config)#radius accounting server 1.1.1.1
erx7(config)#radius update-source-addr 10.13.7.17
Initial Configuration Steps

This slide shows the initial configuration commands necessary to set up the E-series router for ISP1,
one of our sample B-RAS providers. In this environment, we steer users to the correct virtual router
using the AM domain map. For isp1.com users, their dynamic unnumbered IP interfaces are created in
the default virtual router using the default router's loopback 0 interface as a reference. For isp1.com,
this information is configured in the AAA domain map. Isp1.com's users authenticate using the
RADIUS server configured in the default virtual router. The RADIUS server returns the user's IP
address so no local pools are configured. Because this RADIUS server is using obsolete UDP ports
(port 1645 for authentication and port 1646 for accounting) they must be configured on the router. The
router is using 10.13.7.17 as the source address for all packets sent to the RADIUS server. This same
address is configured on the RADIUS server as a valid RADIUS client.

ISP2’s Initial B-RAS Configuration

 ISP2’s Initial configuration:
– Steer users to the appropriate RADIUS server in the correct virtual
router using AAA domain map
– RADIUS returns user’s IP address, no local pools in use
erx7(config)#vir VR2
Proceed with new virtual-router creation? [confirm]
erx7:VR2(config)#aaa domain-map isp2.com VR2
erx7:VR2(config)#interface loopback 0
erx7:VR2(config-if)#ip address 172.16.100.1/32
erx7:VR2(config-if)#radius authentication server 2.2.2.1
erx7:VR2(config-radius)#key training
erx7:VR2(config-radius)#exit
erx7:VR2(config)#radius accounting server 2.2.2.1
erx7:VR2(config-radius)#key training
erx7:VR2(config-radius)#exit
erx7:VR2(config)#radius update-source-addr 70.70.70.2

This slide shows the initial configuration commands necessary to set up the E-series router for ISP2. In
this environment, we steer users to the appropriate RADIUS server in the correct virtual router using
the AAA domain map. Notice that you can configure the MA domain map in any virtual router because
it is global and not virtual-router specific. For isp2.com users, their dynamic unnumbered IP interfaces
are created in the VR2 virtual router using VR2's loopback 0 interface as a reference. For isp2.com,
this information is not configured in the MA domain map. Instead, this information is configured in a
profile. Isp2.com's users authenticate using the RADIUS server configured in the VR2 virtual router.
Notice that RADIUS server information is configured per virtual router. The RADIUS server returns the
user's IP address so no local pools are configured in VR2. Because this RADIUS server is using
standard UDP ports (port 1812 for authentication and port 1813 for accounting), they do not need to be
configured on the router. The router is using 70.70.70.2 as the source address for all packets sent to
the RADIUS server. This same address is configured on the RADIUS server as a valid RADIUS client.

PPP-over-ATM Interface Columns

Statically Dynamically
Configured Created
PPP Interface PPP Interface

1 per Client 1 per Client
ATM PVC ATM PVC

ATM Subinterface ATM Subinterface
Global 1 per Client 1 per Client
Static
Configuration
ATM
Major Interface
OCx/STMx
PPP-over-ATM Interface Columns

You can configure PPP-over-ATM interface columns statically or dynamically. When you configure
static PPP-over-ATM interface columns, you must first configure the controller and ATM major
interface. Next you configure an ATM subinterface and ATM PVC, PPP interface, and IP interface per
user. When you statically define the IP interface, you assume that the user always logs into the same
ISP and that the IP interface is always assigned to the same virtual router, locking the user or IP
interface into a specific virtual router. With this approach, system resources are always consumed,
even if the user is not logged into the router. This approach is not common.
In a B-RAS environment, IP interfaces can also be dynamically created and assigned to the
appropriate virtual router when users log on. Users could log onto a different ISP each time they log
onto the E-series router. In this case, the IP interface must be created in the appropriate virtual router
upon login. After successful completion of IP NCP negotiation, a user's IP address must also 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 in potentially different virtual routers, the
router uses a mechanism called profiles.
Recall that the IP interface configuration command ip access-routes automatically inserts and deletes
the host route in the router's routing table. If the user's IP interface is not always in the same virtual
router, you cannot statically configure the IP interface, assign it an address (numbered or unnumbered),
and specify the ip access-routes command. Entering these commands locks the interface column into
the virtual router with which the CLI was associated when the commands are entered. To dynamically
create IP interfaces and bind them to virtual routers when the customer logs in, you must use profiles.

Remember that all Layer land Layer 2 information (0Cx/STMx, ATM major interfaces and subinterfaces,
and PPP interfaces) are global in nature, or independent of the virtual router 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 common configuration parameters of an IP interface, such as the
assignment of the IP interface to specific virtual router, the loopback interface to reference for
unnumbered interfaces, or the option to cache the host route in the routing table. You create a profile
once globally on the router and then you apply it to as many interfaces you want.
All examples in this module use dynamically created IP interfaces.

Dynamic IP Interface Profile Configuration

 ISP1’s profile configuration: default
erx7(config)#profile isp1
loopback0=192.168.100.1
erx7(config-profile)#ip sa-validate
erx7(config-profile)#exit RADIUS=1.1.1.1
UDP = 1645
 ISP2’s profile configuration: key=training
erx7(config)#profile isp2 VR2

erx7(config-profile)#ip sa-validate loopback0=172.16.100.1
erx7(config-profile)#ip unnumbered lo0 RADIUS =2.2.2.1

UDP = 1645
erx7(config-profile)#ip virtual-router VR2 key=training
ISP1's Dynamic IP Interface Profile Configuration

For isp1.com's users, configuration information required to build the user's IP interface, such as virtual
router and local interface reference, is configured in the AM domain map. Therefore, the profile used to
create the user's IP interface only contains the IP source address validation command. This command
enables source address validation or spoof checking on the user's interface. When a packet arrives on
an interface, a reverse route lookup is performed using the source IP address as the search key. If the
interface does not match, the packet is discarded. Notice that by default, the access route addition is
enabled. Also notice that you can configure profiles in any virtual router context.
ISP2's Dynamic IP Interface Profile Configuration
For isp2.com's users, configuration information required to build the user's IP interface, such as virtual
router and local interface reference, is configured in the profile.

Examining the Profile

 Examining ISP2’s profile configuration
erx7:VR2(config)#run show profile name isp2
Profile : isp2
Unnumbered interface : loopback 0
Router : VR2
Directed Broadcast : Disabled
ICMP Redirects : Disabled
Access Route Addition : Enabled
Network Address Translation : Disabled
Source-Address Validation : Enabled
Ignore DF Bit : Disabled
Filter Option Packets : Disabled
Administrative MTU :0
TCP MSS value :0
Inactivity Timer : Disabled
Route Map Name : Disabled
…
Examinings ISP2’s Profile Configuration

The slide shows the profile configured for ISP2 users. It also shows the router other IP parameters that
you can configure within a profile

Configuring PPP-over-ATM Interfaces

 Configuration steps:
erx7(config)#controller sonet 6/1
erx7(config-controll)#clock sour int chas
erx7(config-controll) #int atm 6/1.1 PPP Interface PPP Interface
erx7(config-if)#atm pvc 1 0 101 aal5snap

erx7(config-if)#encapsulation ppp ATM Subinterface ATM Subinterface
erx7(config-if)#ppp authentication chap

erx7(config-if)#profile ip isp1
ATM
erx7(config-if)#int atm 6/1.2 Major Interface

T3A / E3A
erx7(config-if)#encapsulation ppp OCx/STMx
erx7(config-if)#ppp authentication chap pap

erx7(config-if)#profile ip isp2
Configuring PPP-over-ATM Interfaces

To configure PPP-over-ATM interfaces, first configure the clocking for the SONET controller. Next,
create an ATM major interface, specifying the number of VCs per VP if necessary. For each user,
configure an ATM subinterface and ATM PVC. Next, create a PPP interface by specifying PPP
encapsulation. Configure any PPP parameters for the PPP interface such as the PPP authentication
method or keepalive timers. Finally, for a dynamically created IP interface, apply the appropriate
profile.
This configuration example uses the atm pvc command. You can also use the newer pvc command.

Limiting Active Subscribers

 Per virtual router:
erx7:VR2(config)#aaa subscriber limit per-vr 1000
erx7:VR2# INFO 02/11/2003 01:56:46 aaaUserAccess:
User: paul@isp2.com; id: atm 6/1.2:0.102, access
denied: virtual-router <VR2> limits exceeded
 Per port:
erx7(config)#aaa subscriber limit per-port 6/1 2000
erx7#INFO 02/11/2003 02:01:30 aaaUserAccess: User:
paul@isp2.com; id: atm 6/1.2:0.102, access denied:
interface <6/1> limits exceeded
Limiting Active Subscribers per Virtual Router

You can limit the number of active subscribers per virtual router. This capability might be useful in a
wholesaling environment where the infrastructure provider wants to limit the number of active
subscribers, retailer by retailer. On this slide, we only allow 1000 active subscribers in VR2. The
configuration command aaa subscriber limit per-vr 1000, executed in the VR2 context, sets this limit.
When the limit is exceeded, the E-series router logs an information message, such as the one shown
on the slide.
For example, assume there are no active subscriber limits currently configured for VR2. This means
that the AAA subscriber limit per virtual router is set to 0, or no limit. Assume that there are currently
2000 active subscribers logged into VR2. Through the CLI, the limit is then changed to 1000. No active
subscribers are logged off, but no additional subscribers can log onto VR2 until the number of active
subscribers drops below 1000.
Limiting Active Subscribers per Port
You can also limit the number of active subscribers per port. Here, we only allow 500 active
subscribers on port 6/1. The configuration command aaa subscriber limit per-port 500, executed within
any router context, sets this limit. When the limit is exceeded, the E-series router logs an information
message, such as the one shown on the slide.


 Troubleshooting PPP-over-ATM Interfaces
Troubleshooting PPP-over-ATM Interfaces


How Can I Tell if It Works? (1 of 2)

default
DSL
Modem
RADIUS=1.1.1.1 RADIUS
Tyler@isp1.com UDP=1645
ISP1
1.1.1.1
key=training
VR2
RADIUS=2.2.2.1
UDP=1645
key=training
ISP2 RADIUS
2.2.2.1
 Is the subscriber logged into the router?

erx7#show subscribers username username@domain
 Is the router communicating with the RADIUS server?
erx7#show radius authentication statistics
erx7#test aaa ppp username@domain password
erx7#show aaa domain-map
Is the Subscriber Logged onto the Router?

First, determine if the user logged in to the router using the show subscribers username@domain
command. If you execute this command in the default virtual router, you see all users logged into the
router, regardless of their virtual router. If you execute this command in a nondefault virtual router, you
only see the users located in that specific virtual router. If the user is not logged in, refer to the
information in the following paragraph when you troubleshoot a PPP-over-ATM interface.
Is the Router Communicating with the RADIUS Server?
Use the show radius authentication statistics command. Can the router authenticate the user
locally? Use the test aaa ppp username password command. If you use a domain map, verify that the
proper domain is mapped to the appropriate virtual router using the show aaa domain-map
command.


default
DSL
Modem
Tyler@isp1.com RADIUS=1.1.1.1
ISP1 RADIUS
UDP=1645 1.1.1.1
key=training
VR2
RADIUS=2.2.2.1
UDP=1645
 Is the link key=training
between the subscriber ISP2 RADIUS

2.2.2.1
and the router operational?
erx7#show controller sonet slot/port
erx7#show atm vc atm slot/port vcd
erx7#show ppp interface state down
erx7#show ppp interface atm slot/port.subinterface full
 Can the subscriber communicate using IP?
erx7#ping a.b.c.d
erx7#show ip interface atm slot/port.subinterface
erx7#ping a.b.c.d source address w.x.y.z
erx7#show ip route | include slot/port.subinterface
Is the Link Between the Subscriber and the Router Operational?

Once you verify that the router can authenticate the user locally, examine the link between the router
and the subscriber. Is the SONET controller active? Use the show controller sonet slot/port command.
Determine if ATM cells are being transmitted and received on the subscriber's ATM interface by using
the show atm vc atm slot/port vcd command. Determine if any PPP interfaces are in the down state by
using the show ppp interface state down command. Examine the user's PPP interface by using the
PPP commands listed on the slide.
Can the Subscriber Communicate Using IP?
Determine if the router can communicate with the subscriber across the local link using the ping
command. Verify that packets are being transmitted and received on the subscriber's IP interface using
the show ip interface atm slot/ port. subinterface command. If you can communicate with the
subscriber across the local link, determine if the subscriber can communicate beyond the local link.
You can do this by using the ping a.b.c.d source address w.x.y.z. The source address keyword allows
you to specify an alternate IP address as the source of the packet. In this case, specify an IP address
on the router in a different subnet. This command verifies proper routing. Next, verify that the
subscriber's IP interface is listed as a host route in the routing table. Remember to use CLI output
filtering, such as show ip route | include 6/1.1, to limit the number of routes displayed.

Setting a Statistics Baseline

default
DSL
Modem
RADIUS=1.1.1.1 RADIUS
Tyler@isp1.com UDP=1645
ISP1
1.1.1.1
key=training
VR2
RADIUS=2.2.2.1
UDP=1645
key=training
ISP2 RADIUS
2.2.2.1
 Setting a statistics baseline to aid in troubleshooting:

erx7#baseline [radius ip ppp interface]
erx7#baseline radius
erx7#show radius statistics delta
 Global baseline configuration option:
erx7(config)#baseline show-delta-counts
erx7#show radius statistics
Setting a Statistics Baseline to Aid in Troubleshooting

Remember to use the baseline command to help during the troubleshooting process. The baseline
command sets a statistics baseline for the requested counters, such as RADIUS statistics, IP interface
statistics, or ATM interface statistics to name a few. The router implements the baseline by reading
and storing the statistics at the time the baseline is set. Next, the router subtracts this baseline
whenever baseline statistics are requested. For example, to set a statistics baseline for RADIUS
statistics, use the baseline radius command. To view only the RADIUS statistics because setting the
baseline, use the show radius statistics delta command. For example, the key word delta in the
command show radius statistics delta requests baseline-relative statistics.
Global Baseline Configuration Option
You can also configure the router to always use the delta keyword for any show command by using the
baseline show-delta-counts configuration command. By default, this capability is disabled. When this
feature is enabled, the show radius statistics command always displays the RADIUS statistics relative
to the most recent baseline.

Verifying PPPoA configuration in Layers

PPP show ppp interface atm 5/2 Lists all PPP interfaces on slot/port
show ppp interface atm 5/2.1.11 full PPP configuration and statistics
for a single user
ATM Sub- show atm subinterface atm 6/2/0/33 Subinterface configuration and
interface show atm subinterface atm 6/2.33 statistics
show atm subinterface atm 6/2 Lists all ATM subinterfaces on a

slot/port
ATM Major show atm interface atm 6/2 ATM major interface status and
statistics
Physical show controller sonet 6/2 Specific controller configuration
and status
Think in Layers!
The slide shows a summary of the show commands used at each layer to troubleshoot a PPP-over-
ATM configuration.

Logging Overview
 Logging system events:
– System events are classified into categories
 pppPacket, aaaUserAccess, cliCommand, l2tp, radiusAttributes,
radiusSendAttriubutes, snmp
– System events have an assigned severity level
 Emergency 0
 Alert 1
 Critical 2
 Error 3
 Warning 4
 Notice 5
 Info 6
 Debug 7
– System events have different verbosity levels
 Low, medium, and high
– Use filters to limit and control the amount of logging
Logging System Events

You can configure the E-series router to log system events as an aid in troubleshooting. The router's
system events or log messages are broken into categories. A few category examples include
pppPacket, which is a PPP packet trace capability, aaaUserAccess, cliCommand, and
radiusAttributes.
Each log message is assigned a severity level from 0-7. The lower the number, the higher the severity
of the message. You can configure the severity level to determine the amount and type of log
messages sent to the various log destinations.
Log messages also have three different verbosity levels—low, medium, and high. Many system event
categories provide only low-verbosity detail regardless of the verbosity setting.
You can also configure filters for many event categories to limit and control the amount of logging
information. For example, you might configure some categories to have filters that apply to a specific
interface, such as pppPacket or ipInterface. You might configure other categories to have filters that
apply to a specific connection, such a bgpConnections. Some categories do not support filters, such as
snmp or radiusAttributes. By default, category filters are not enabled. You must explicitly configure
them.

How Do I Examine Log Messages?

Volatile Memory
NOTICE 10/20/2006 17:18:45 cliCommand (): "run show
 Log message destinations:
version", console
DEBUG 10/14/2006 14:00:38 pppPacket (interface ATM6/1.1) – Console, Telnet, or SSH
time: 0.00, tx lcp confReq
DEBUG
time:
10/14/2006 14:00:38 pppPacket (interface ATM6/1.1):
0.02, rx lcp confReq, id = 133, length = 14, mru =
session in real time
9178, magicNumber = 0x51500b1b
– Volatile memory
Non-volatile Memory  Persistent logs
erx_7-3-0.rel – Nonvolatile memory
system.log
reboot.hty  system.log
 64 K maximum size
 Severity critical or higher
 ASCII file
– Syslog
Console
Telnet Syslog
Log Message Destinations

You can direct the router's log messages to a variety of locations. You can configure the router to send
log messages to the console in real time. The console 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. You
can also direct these same messages to a Telnet or SSH session. By default, if NOTICE, INFO, or
DEBUG log messages occur, they are not directed to the console; however, you can configure this
behavior.
By default, a very limited number of log messages are stored in volatile memory on the SRP. The
logging process uses a sophisticated algorithm so that no one category can monopolize the logging
process and starve other categories from inserting log messages into volatile memory. It is possible to
allocate additional memory to a specific category using the command log unlimit eventCategory. The
router also supports persistent logging between system reloads. Thus, log messages in the SRP
volatile memory are retained through a system reload unless the router is power cycled or the system
detects any problems. Log messages are not synchronized between redundant SRPs.
Log messages are also stored in nonvolatile memory in a file on the flash called system. log. By
default, only severity levels 0-2—that is, EMERGENCY, ALERT, and CRITICAL log messages—are
stored in system. log. Log messages with a severity level of 3-7 cannot be stored in system. log. This
ASCII file can have a maximum size of approximately 64 K. When the maximum size is reached, the
file is circular in nature and operates in a first in, first out (FIFO) manner. You can copy the file to a PC,
and it can be read by any text editor.
Finally, you can also direct the router's log messages to syslog servers. We cover this configuration in
greater detail later in the chapter.

Default Logging Configuration

erx7#show log configuration
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 sever ity verbosity filters notes

---------------------- -------- --------- ------- -----
aaaAtm1483Cfg ERROR low
aaaEngineGeneral ERROR low
aaaServerGeneral ERROR low
aaaUserAccess ERROR lo w
addressServerGeneral ERROR low
cliCommand NOTICE low
controlNetworkSlave ERROR low
cops ERROR low
crldpGeneral ERROR low
ctreeLog ERROR low
dcm ERROR low
dcmEngineGeneral ERROR low
dhcpGeneral ERROR low
dhcpLocalServerGeneral ERROR low
dhcpNvGeneral ERROR low
dhcpProxyGeneral ERROR low
dhcpRelayGeneral ERROR low
…
Viewing the Logging Configuration

Use the show log configuration CLI command to view the current E-series router's logging
configuration. The example on the slide is the default log configuration and only shows a subset of the
categories.
Notice the log destinations and their associated filter levels:
• console: Currently, only log messages that have severity levels 0-4 are sent to the console.
• nv-file: This destination refers to the file system.log found on the flash card. Only severity
levels 0-2 (that is, EMERGENCY, ALERT and CRITICAL log messages) are stored in
system. log. The router cannot store ERROR, WARNING, NOTICE, INFO, or DEBUG
messages in the file system. log.
You can also configure the router to send log messages to a syslog server, although by default, this
feature is not enabled.
By default, almost all log categories are assigned a severity level of ERROR (that is, level 3), and a
verbosity level of low. A few exceptions to this rule include the categories of os and cliCommand,
which have a severity of NOTICE. In addition, no filters are configured. You must explicitly configure
filters on the router to provide logging on specific interfaces or connections. Please refer to the E-
series System Event Logging Reference Guide for a complete list of categories and the messages
available at each severity level.
By default, engineering log messages are disabled. When you contact Juniper Networks Technical
Assistance Center (JTAC), they might ask you to enable engineering logs for additional
troubleshooting information.
When a specific interface or connection is specified for logging, the system considers it a filter. The
filters column indicates the number of filters applied to a given category. Specific log filters are always
listed at the bottom of the log configuration display. The notes column indicates a note number next to
a category when the severity level has been modified from its default value. The associated note and
number are also listed at the bottom of the log configuration display.

Configuring Logging on a PPP Interface

erx7#baseline log
erx7#config t
Enter configuration commands, one per line. End with ^Z.
erx7(config)#baseline show-delta-counts
erx7(config)#log severity debug pppPacket atm 6/1.1
erx7(config)#end
erx7#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
---------------------- -------- --------- ------- -----
aaaAtm1483Cfg ERROR low
aaaEngineGeneral ERROR low
...
ppp ERROR low
pppPacket --- low 1
pppStateMachine --- low
pppoe ERROR low
pppoeControlPacket --- low
...
log severity DEBUG pppPacket ATM 6/1.1
Configuring Debug Logging on a PPP-over-ATM Interface

In the example on the slide, we want to configure the router to log PPP packets on a specific PPP-
over-ATM interface, 6/1.1. We want to configure the pppPacket category, specify a severity level of
DEBUG, and specify the PPP-over-ATM interface, 6/ 1.1. We perform all logging configuration in
Global Configuration mode. When we specify a specific interface or connection for logging, the router
considers it a log filter. Notice that the filters column now indicates that a specific log filter has been
configured. The specific log filter is listed at the bottom of the log configuration display.

Viewing the Log Messages—PPP LCP

erx7(config-subif)#shutdown
erx7(config-subif)#no shutdown
erx7(config-subif)#end
erx7#show log data category pppPacket severity debug
*** stored log messages ***
*** log: pppPacket
*** severity: DEBUG and higher
*** using baseline timestamp: THU OCT 14 2004 14:00:25 UTC
DEBUG 10/14/2004 14:00:38 pppPacket (interface ATM6/1.1): time:

0.00, tx lcp confReq, id = 24, length = 19, mru = 9178,
authentication = chap MD5, magicNumber = 0x6070fb52

0.02, rx lcp confReq, id = 133, length = 14, mru = 9178,
magicNumber = 0x51500b1b

0.02, tx lcp confAck, id = 133, length = 14, mru = 9178,
magicNumber = 0x51500b1b

0.02, rx lcp confAck, id = 24, length = 19, mru = 9178,
authentication = chap MD5, magicNumber = 0x6070fb52
Viewing the Log Messages—PPP LCP

On the slide, the user's ATM subinterface is bounced. By default, these pppPacket log messages go to
volatile memory. They are not directed to the console because 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 you can use to view the log data stored in volatile memory, including severity
levels and categories.

Viewing the Log Messages―PPP CHAP

0.02, tx chap challenge, id = 70, length = 32, challenge length
= 23, challenge = 91 c6 ab e4 25 e1 ed a2 b5 f6 5f f1 f2 98 63
a8 ca 56 36 ae 29 2a a9, name = 'erx7' 65 72 78 37

0.03, rx chap response, id = 70, length = 35, response length =
16, response = 3d 5f c5 f1 20 e6 dd b6 2a 2a f2 c9 32 9b f4 42,
name = 'tyler@isp1.com' 74 79 6c 65 72 40 69 73 70 31 2e 63 6f
6d

0.52, tx chap success, id = 70, length = 4
Viewing the Log Messages—PPP CHAP

This slide shows the PPP CHAP negotiation process between the router and the user. The router first
issues a CHAP challenge to the subscriber, including the router's hostname, erx 7. The user responds
with a CHAP challenge, including the user's login, tyler@isp1.com. Notice that the CHAP challenge
does not contain the user's password, tyler, in clear text. Finally, the router transmits a CHAP success
message indicating successful CHAP negotiation.

Viewing the Log Messages―PPP IP NCP

0.53, rx ipNcp confReq, id = 156, length = 10, ipAddress =
0.0.0.0

0.53, tx ipNcp confNak, id = 156, length = 10, ipAddress =
192.168.1.246

0.54, rx ipNcp confReq, id = 157, length = 10, ipAddress =
192.168.1.246

0.54, tx ipNcp confAck, id = 157, length = 10, ipAddress =
192.168.1.246

0.56, tx ipNcp confReq, id = 157, length = 10, ipAddress =
192.168.100.17

0.62, rx ipNcp confAck, id = 157, length = 10, ipAddress =
192.168.100.17
Viewing the E-series Router's Log—PPP IP NCP

This slide shows the PPP IP NCP negotiation process between the router and the user. The router first
receives an IP NCP configure request from the user, indicating its desired IP address, 0.0.0.0. The
router tells the user that this is not the appropriate IP address by transmitting an IP NCP configuration
NAK message. The configuration NAK message also indicates that the router wants the subscriber to
use 192.168.1.246 for its IP address. The router then receives another IP NCP configuration request
from the user. This second configuration request indicates that the subscriber now wants to use
192.168.1.246 as its IP address. The router acknowledges the user's IP address, 192.168.1.246, by
transmitting a configuration acknowledgement. Next, the router issues an IP NCP configuration request
indicating its IP address, 192.168.100.17. Finally, the user transmits a configuration acknowledgement
to the router indicating that it agrees that the router should use 192.168.100.17 for its IP address.

Managing Log Destinations

 Change console destination log filter from WARNING to DEBUG
erx7(config)#log destination console severity debug
erx7(config)#do baseline log
 Direct DEBUG log messages to a Telnet or SSH session :
erx7(config)#log destination console severity 7
erx7(config)#log here
 Turn off logging to a single console or Telnet/SSH session :
erx7#no log here
 Turn off logging to all console or Telnet/SSH sessions :
erx7(config)#log destination console off
 View log messages stored in non volatile memory :
erx7#show log data nv-file
Changing Console Destination Log Filter from WARNING to DEBUG

If we want the pppPacket log messages to appear on the console in real time, we must change the
filter level on the console log destination. The configuration command log destination console severity
debug changes the severity level on the console session from WARNING to DEBUG. Now all DEBUG,
INFO, NOTICE, WARNING, ERROR, CRITICAL, ALERT, and EMERGENCY log messages are
displayed in real time on the console session. This setting does not send log messages to any Telnet
or SSH sessions.
Directing DEBUG Log Messages to a Telnet or SSH Session
By default, the E-series router does not direct log messages to Telnet and SSH sessions. Once you
configure the console to support DEBUG messages, use the log here configuration command from the
Telnet or SSH session to direct log messages to the session. At this point, the router directs all
DEBUG log messages to the Telnet or SSH session as well as the directly connected console session.
Turning Off Logging to a Single Console or Telnet or SSH Session
The previous configuration has log messages going to both the console and a Telnet or SSH session.
To stop directing log messages to a specific console or Telnet or SSH session, use the no log here
command. In a troubleshooting situation, you can direct log messages to a Telnet or SSH session
using the log here option, and you can use the directly attached console session for other
troubleshooting commands using the no log here option. To scale down the amount of log messages
being sent to all console or Telnet or SSH sessions, use the log destination console severity warning
configuration command.
Turning Off Logging to ALL Console or Telnet and SSH Sessions
To turn off logging to all console sessions, use the log destination console off configuration command.
This command disables logging to both Telnet or SSH sessions and directly attached console sessions.
Viewing Log Messages Stored in Nonvolatile Memory
To view log files stored on the flash card, use the show log data nv-file command.

Logging to System Log Servers (syslog)

 Configuring syslog on the router:
– Send log messages to multiple syslog servers
– Each server configured individually
 Syslog configuration parameters:
– Severity level
 Emergency, Alert, Critical, Error, Warning, Notice, Info, and Debug
– Facility ID
 Range of 0–7
– Categories to include or exclude:
 Include keyword only send log messages for the specific categories
configured—all other categories are ignored
 Exclude keyword sends log messages for all categories except the specific
categories configured
– Source address
Configuring Syslog on the Router

At this point we have discussed sending log messages to the console and Telnet or SSH sessions in
real time. You can also configure the router to send log messages to multiple syslog servers. You
configure each syslog server individually.
Syslog Configuration Parameters
When you configure each syslog server, you can specify the severity level or filter level as well as a
local facility ID. This facility ID is a way of grouping log messages on the syslog server. You can
specify a number between 0-7, which translates to local0- local7 on the syslog server. You can
configure the router to send all log messages based on severity level, or you can configure the router
to include or exclude specific categories. The ability to include specific categories is very useful to limit
the amount of log messages going to a specific server. The include keyword only sends log messages
for a specific list of categories. Log messages from all other categories are ignored and not sent to the
specified server. The exclude keyword is a bit more challenging to use. The exclude keyword sends
log messages for all logging categories except the categories identified in the command. You should
use this keyword with great care as you could overwhelm a syslog server with log messages. If you
use the exclude keyword, you can further limit the amount of log messages sent by configuring a
higher severity level. You can also configure a specific source address for messages sent to the syslog
server.

Configuring Syslog
 Configuring syslog:
– Send only cliCommand log messages to syslog facility ID 2 on
syslog server 10.13.7.56:
erx7(config)#log dest syslog 10.13.7.56 facility 2
erx7(config)#log dest syslog 10.13.7.56 include
cliCommand
– Send all log messages with a severity of warning or higher to syslog
facility 6 on 10.13.7.60:
erx7(config)#log dest syslog 10.13.7.60 facili 6 sev
warning
– Send all log messages with a severity of warning or higher to syslog
facility 5 on 10.13.7.70 except ipRoutePolicy, cliGeneral, ipInterface:
erx7(config)#log dest syslog 10.13.7.70 facil 5 sev
warning
erx7(config)#log dest syslog 10.13.7.70 exclude
ipRoutePolicy cliGeneral ipInterface
Configuring Syslog
This slide shows several syslog configuration examples. The first example shows a way to steer only
cliCommand log messages to a specific syslog server. You might use this log file as an audit trail of
any CLI command executed on the router. The keyword include provides a way to limit the amount and
type of log messages sent to syslog servers.
The second example shows a way to send all WARNING, ERROR, CRITICAL, ALERT, and
EMERGENCY log messages to a specific facility on the syslog server, 10.13.7.60. This example sends
all log messages regardless of category and limits the amount based on severity level.
The last example sends all log messages with a severity of WARNING or higher to a syslog server
except for the categories ipRoutePolicy, cli General, and ip Interface. This example might send many
more log messages to this server than actually required. It might be wise to review the type and
amount of log messages sent to the syslog server. Next, you would configure a new exclude list
containing a list of all categories to exclude—even the ones that were previously excluded.

Resetting the Log Configuration
Global Configuration Command Resulting Action
Restores the default

erx7(config)#no log severity * severity level of all
categories (excluding filters)
erx7(config)#no log filters Removes all log filters

erx7(config)#no log verbosity verbosity level of all log
categories
erx7(config)#no log destination settings for log destination
severity thresholds
Resetting the Log Configuration to Factory Defaults

This slide shows the configuration commands necessary to reset the logging configuration to factory
defaults. The no log severity * command quickly changes all category severity levels back to their
default configurations. To quickly remove any logging filters configured, use the no log filters
command. Use the no log verbosity command to reset all verbosity levels to their default configuration.
The no log destination command returns all log destination severity settings to their defaults.

Useful Logging Categories for PPPoA
 Additional logging categories:

– pppPacket
– aaaUserAccess
– radiusAttributes
– radiusClient
– radiusSendAttributes
 Use DEBUG-level logging wisely
– Logging uses SRP memory and resources
– Remember to reset category log levels to default values
Additional Logging Categories

We just explored the E-series router logging capabilities using the category pppPacket as an example.
However, this is not the only useful logging category in a PPP-over-ATM environment. This slide lists
several other useful logging categories to aid in troubleshooting a PPP-over-ATM connection.
Use DEBUG-Level Logging Wisely
The logging process resides on the SRP. Although the logging facility, specifically DEBUG logging, is a
very powerful troubleshooting tool, it does use CPU and memory on the SRP. You should therefore
use DEBUG logging sparingly and only for the duration of a test or while trying to capture data in a
particular scenario. You should set all logs to DEBUG only at the instruction of customer support and
only on specified categories for a specified duration.
When you troubleshoot a problem, it is common to set a specific category filter level to DEBUG as well
as the console filter level to DEBUG so you can view the log messages in real time. When you finish
troubleshooting the problem, always remember to reset both the console and category filter levels to
their default values. The most common mistake people make is changing the console filter level back
to WARNING but keeping the category filter level at DEBUG. If a category filter level is set to DEBUG,
the responsible application is still generating DEBUG-level messages and directing them to the SRP,
and under certain conditions, SRP CPU usage could be adversely affected.

Module Review
1. What are the benefits of using PPP over ATM?
2. What are the differences between the IP addressing options
in a PPP-over-ATM environment?
3. How would you describe the basic life of a packet in a
PPP-over-ATM environment?
4. What are the three different ways a PC can obtain its IP
address dynamically in a PPP-over-ATM environment?
5. What is the purpose of the domain map?
6. How would you describe the function and use of profiles?
7. How do you configure the E-series router for PPP over
ATM?
8. How do you verify PPP-over-ATM operation using show
commands and logging?
9. What are the E-series router’s logging capabilities?

• The benefits of PPP over ATM;
• The life of a packet in a PPP-over-ATM environment;
• Three ways a PC can dynamically obtain an IP address in a PPP-over-ATM environment;
• The purpose of a domain map;
• The functions and use of profiles;
• Configuring the E-series router for PPP over ATM;
• The E-series router's logging capabilities; and
• Using show commands and logging to verify PPP-over-ATM operation.

Lab 3: Configuring PPP over ATM
Lab Objectives:
Configure and troubleshoot
PPP-over-ATM interfaces on the E-series router.
Lab 3: Configuring PPP over ATM

The slide shows the objective for this lab.


Module 4: PPP over Ethernet
.
Module Objectives
to:
– List the benefits of using PPP over Ethernet
– Describe the two stages of PPP over Ethernet
– Describe the basic life of a packet for PPP over Ethernet
– Configure the E-series router for PPP over Ethernet
– Verify PPP-over-Ethernet operation using show commands and
logging

• The benefits of using PPP over Ethernet;
• The life of a packet for PPP over Ethernet;
• Comparing and contrasting ATM access networks and Ethernet access networks;
• Configuring the E-series router for PPP over Ethernet; and
• Verifying PPP-over-Ethernet operation using show commands and logging.
Module 4: PPP over Ethernet 4-2

Agenda: PPP over Ethernet

 Overview of PPP over Ethernet
 PPP-over-Ethernet in Ethernet Access Network
 PPP-over-Ethernet Configuration and Troubleshooting
Overview of PPP over Ethernet


Modem
RADIUS
tyler@isp1.com
Routers ISP1
RAS
PPP Session
Modem
RADIUS ISP2
paul@isp2.com
 Traditional remote access:

– Relatively slow access rates using dedicated POTS line
– Point-to-point session between the PC and the RAS
– RAS terminated the PPP session
– Packets sent to appropriate routers

Recall that with narrowband remote access, a single remote user had a single phone line to establish a
point-to-point connection with a remote access server (RAS). A strict peer-to-peer—or one-to-one—
relationship was established.
When a PC initiated a PPP session, the PC sent out PPP Link Control Protocol (LCP) packets across
the link. Only one other device was on this dedicated, point-to-point connection: the RAS.
Consequently, the only device capable of receiving these packets, and thus responding to these
packets, was the RAS. Establishing a connection, authenticating the connection, and managing the
connection was a fairly straightforward process, given this point-to-point scenario.

Multiple Clients per Logical Interface

DSL
diane@isp1.com Modem PPP Session
PPP Session ISP1

tim@isp1.com
DSLAM
ATM
DSL
ralph@isp2.com Modem
ATM
ISP2
DSLAM
Switch
ken@isp2.com
 PPP over Ethernet:

pam@isp1.com
– High-speed access using shared POTS line
– Multiple users per DSL modem
– Multiple PPP sessions per logical interface
 Connection methods:
– ATM PVC or VLAN per CPE
– Multiple PPP sessions per PVC
PPP over Ethernet

In this second PPP B-RAS environment, we address a small office or home with multiple PCs on an
Ethernet network, which is connected to the DSL modem.
Unlike the traditional RAS environment, or even the PPP-over-ATM environment, no dedicated, point-
to-point connection exists in a PPP-over-Ethernet (PPPoE) environment. In the old days, if a PC
transmitted an LCP request, only one other device on the network could possibly receive it—the RAS.
Now, using a shared LAN, the PC has no way of knowing where the RAS server is. In addition, the PC
must know the specific MAC address of the RAS server because it sits on a LAN. It can no longer
indiscriminately transmit PPP LCP requests. Before PPP negotiations can occur, the PC must
determine where the B-RAS server is, what its MAC address is, and it must establish a session with it.
Only then can the PC initiate a PPP session. Additionally, we need a means to support multiple PPP
sessions across the same shared media. The solution to this problem is PPP over Ethernet.
Initially, most PPPoE installations used DSL as the connection method and, consequently, most
DSLAMs were ATM based. In this environment, the E-series router supports multiple clients on a
single ATM subinterface. In other words, a one-to-many relationship is formed—one PVC, many
clients. To support this configuration, each DSL modem or group of users uses a single ATM PVC. We
then configure PPPoE to support multiple users across this PVC. Finally, we configure a PPP interface
per user.
More networks are transitioning from ATM to Ethernet. We discuss this topic later in the chapter.

PPPoE―RFC 2516
DSL
diane@isp1.com Modem
ISP1
tim@isp1.com
MAC=A
DA IP=2.2.2.2
SA IP=1.1.1.2
PPP Header MAC=X

PPPoE Header
SessionID=0x123
EtherType=0x8864
ISP2
ISP2
DA MAC=X
SA MAC=A
 RFC 2516:
Physical
– General frame format
– PC requirements
– Two stages of PPPoE:
 Discovery stage
 PPP session stage
RFC 2516
When the user PC transmits IP data, the PC creates an IP datagram, encapsulates the IP datagram in
PPP and PPPoE, and finally inserts this data into an Ethernet frame addressed to the E-series router—
hence, the name PPP over Ethernet.
To transmit data using PPPoE, the user's PC requires special PPPoE software that installs a shim
between the existing dial-up networking PPP stack and the Ethernet driver, which enables PPP
sessions to be carried directly in standard Ethernet frames. Although the PC uses PPPoE, the actual
user experience mirrors dial-up networking—a familiar experience to most current remote access
users.
Because the PPP frames are encapsulated in Ethernet frames, multiple users can share the same
DSL line.
PPPoE has two distinct stages:
• Discovery stage: When a PC initiates a PPPoE session, it performs the discovery stage to
determine which B-RAS to use, the Ethernet MAC address of the B-RAS, and a unique
session ID. This discovery stage is a client-server relationship, where the PC is the client
and the E-series router is the PPPoE server.
PPP session stage: Once the PC determines which B-RAS to use, the B-RAS MAC address, and the
session ID, the connection transitions into a peer-to-peer relationship and initiates a standard PPP
session using LCP.

PPPoE Discovery Stage
DSL
ISP1
tim@isp1.com
MAC=A
PPPoE Active DA=FF

MAC=X
SA=A
Discovery Initiation
Type=Disc
PADI PPPoE
Services DA=A PPPoE Active ISP2
ISP2
SA=X Discovery Offer
Type=Disc
PADO
PPPoE
PPPoE Active SessionID=
Discovery Request DA=X 0000
SA=A
PADR Type=Disc PPPoE Active
PPPoE DA=A Discovery Session
SessionID=
SA=X Confirmation
0000
Type=Disc
PADS
PPPoE
SessionID=
1234
PPPE Discovery Stage

Four steps exist in the discovery stage. When this stage completes, both peers know the PPPoE
session ID and the peer's MAC address. Collectively, these attributes uniquely define the PPPoE
session. The following list outlines the four steps:
• Initially, the PC broadcasts a PPPoE active discovery initiation (PADI), searching for all B-
RAS servers that can provide the services the PC requests using the service-name tag. In
our network, only the E-series router processes the PADI.
• If the B-RAS can service the request, it responds to the discovery packet with a unicast
PPPoE active discovery offer (PADO) where the session ID is all zeros. If the B-RAS cannot
provide the requested service, it does not respond with a PADO.
• If multiple B-RAS receive the PADI, the PC might receive multiple PADOs. In this case, the
PC must choose one. In the diagram on the slide, the PC receives just one PADO from the
B-RAS. The PC responds with a unicast PPPoE active discovery request (PADR) to the
server it chooses to use. The PC now knows the MAC address of the B-RAS and needs the
unique session ID.
• Finally, the B-RAS responds with a PPPoE active discovery session-confirmation (PADS).
This packet contains the unique session ID or the PPPoE session.
At any time, either the client or the server can send a PPPoE active discovery terminate (PADT)
packet to indicate that a PPPoE session is terminated. The Ethertype field for the discovery stage is
0x8863.

PPPoE PPP Session Stage
DSL
ISP1
tim@isp1.com
MAC=A
DA=X
SA=A
PPP LCP Type=PPP
PPPoE MAC=X
SessionID=
1234
PPP LCP
DA=A ISP2
ISP2
SA=X
Type=PPP
PPPoE
SessionID=
1234
 PPP data is sent like any other PPP session
PPPoE PPP Session Stage

Once the PPPoE session is established, the PPP session stage begins. The PPP session stage is just
like any other standard PPP session, starting with LCP negotiations and IP NCP negotiations. All
Ethernet frames are unicast between the PC and the E-series router. The Ethertype field for PPP
sessions is 0x8864.

PPP over Ethernet―Life of a Packet

IP=1.1.1.2 IP/PPP/PPPoE Connection Terminated IP=2.2.2.2
MAC=A on the E-series Router
MAC=F
MAC=E
VPI/VCI 0/33
DSL MAC=C
MAC=B
Bridge
MAC=D
DA IP=2.2.2.2
SA IP=1.1.1.2
PPP Header
PPPoE Header
Layer 3 DA IP=2.2.2.2 SessionID=0x123
SA IP=1.1.1.2
EtherType=0x8864
PPP Header DA MAC=B
SA MAC=A
DA IP=2.2.2.2 DA IP=2.2.2.2
PPPoE Header SA IP=1.1.1.2 SA IP=1.1.1.2
SessionID=0x123 RFC 2684
Layer 2 PID=0x000-07
EtherType=0x8864 OUI=0x00-80-C2 EtherType=0x0800 EtherType=0x0800
DA MAC=B LLC=0xAA -AA-03 DA MAC=D DA MAC=F
ATM VPI/VCI=0/33
Life of a Packet
In the PPP-over-Ethernet environment using ATM as the Layer 2 connection method, a DSL-capable
bridge or modem is installed at the customer's location. The bridge is connected over a phone line to a
DSLAM, which is in turn connected using ATM to the E-series router. An ATM PVC is provisioned from
the E-series router to the customer's CPE device. Each PC has PPP-over-Ethernet client software
installed. If a user at the customer's location wants access to the Internet, the basic packet flow is as
follows:
• The user's PC generates an IP packet that is encapsulated in a PPP frame. A PPPoE
header is added to this frame, which is then encapsulated in an Ethernet frame addressed to
the E-series router. The Ethernet type field indicates that the upper-layer protocol is PPPoE.
• The DSL bridge receives the Ethernet frame and encapsulates the entire frame into an ATM
cell. An RFC 2684 header is added at the beginning of the cell, indicating that the cell
contains a bridged Ethernet frame.
• The cell(s) are then transmitted across PVC to the E-series router.
• The E-series router receives the cell, strips off the bridged Ethernet header, strips off the
Ethernet frame, and verifies that the type field is PPP over Ethernet. If the type field is not
PPP over Ethernet, the E-series router discards the frame. If it is PPP over Ethernet, the
router strips the PPP frame and looks at the destination IP address, and determines the
next-hop interface.

PPPoE over ATM Interface Columns

Diane@isp1.com Tim@isp1.com Ralph@isp2.com Pam@isp1.com
IP Interface IP Interface IP Interface IP Interface
PPP Interface PPP Interface PPP Interface PPP Interface

1 per User 1 per User 1 per User 1 per User
PPPoE Subinterface PPPoE Subinterface PPPoE Subinterface PPPoE Subinterface

1 per User 1 per User 1 per User 1 per User
PPPoE PPPoE
Major Interface Major Interface
1 per Modem 1 per Modem
ATM PVC ATM PVC
ATM Subinterface ATM Subinterface
1 per Modem 1 per Modem
ATM
Major Interface
OCxc/STMx
PPPoE over ATM Interface Columns

In a PPP-over-Ethernet environment, each modem can support multiple users or IP interfaces using
multiple PPP interfaces. Therefore, for each modem, you must configure an ATM subinterface and
ATM PVC. Then a new PPPoE major interface is created. Finally, for each user, a new PPPoE
subinterface is created. Each PPPoE subinterface supports a PPP interface and an IP interface.
Remember that IP interfaces can be created statically or dynamically. In this example, we statically
defined the ATM subinterfaces, the ATM PVCs, the PPPoE major interfaces, the PPPoE subinterfaces,
and the PPP interfaces. Each IP interface is dynamically created using information from RADIUS or a
profile definition.


 Overview of PPP over Ethernet
 PPP-over-Ethernet in Ethernet Access Network
 PPP-over-Ethernet Configuration and Troubleshooting
PPP over Ethernet in Ethernet Access Networks


Ethernet-Based Access Networks
 Ethernet-Based access networks :

– Broadcast TV, VoD, VoIP, and gaming require higher bit rates
and advanced QoS
– Reduce the distance between the CPE and access node
– Backhauled to Ethernet interface on E-series router
– E-series router co-located with OLT in fiber networks
Ethernet-Based Access Networks

Early DSL deployments provided a higher-speed, best-effort delivery service primarily for data traffic.
Most initial DSL networks were deployed in a pure ATM-based access network. Now more and more
DSL service providers are looking to offer additional services requiring higher user bit rates,
sophisticated quality of service (QoS), and scalable multicasting capabilities. These services include
broadcast TV and video on demand (VoD), voice over IP (VolP), and gaming. In addition to PCs,
subscribers now have IP phones and set-top boxes (STB) connected to routing gateways (RG) inside
their homes. It is very difficult to deploy these types of services in a pure ATM environment.
Many of these services require significantly higher DSL synchronization rates than typical ADSL offers.
The easiest way to increase synchronization rates is to shorten the distance between the access node
in the provider's local POP—such as a DSLAM, an Ethernet switch, or an optical line terminal (OLT) in
a fiber environment—and the RG. To shorten the distance, more and more access nodes will be
deployed closer and closer to the end user. Ethernet-based networks provide a simpler way to meet
the needs of these higher-speed networks. Ethernet-based networks provide higher-speed
connections, packet-based QoS, simpler provisioning, IP multicast support, and redundancy in an
efficient manner.
Several services, such as broadcast or IPTV, VoD, and gaming, use IP multicast as the delivery
mechanism. Multicast is a bandwidth-conserving technology. Multicast is the delivery of information to
a group of destinations simultaneously using the most efficient strategy to deliver the messages over
each link of the network only once and only create copies when the links to the destinations split. IP's
and Ethernet's inherent distribution and replication capabilities allow for video network scaleability
using multicast.

Ethernet-Based Access Networks (contd.)

Gigabit Ethernet and Gigabit Passive Optical Network (GPON) are two transport technologies that are
capable of delivering large amounts of bandwidth to a highly distributed access node network. More
and more installations use Ethernet-based DSLAMs. There are two typical installation types. The first
type implements a hybrid approach where the downstream connections still utilize standard ATM over
ADSL running on the standard copper link because those are the most widely deployed technologies
today. The upstream connection is backhauled to the B-RAS using Gigabit or 10-Gigabit Ethernet. In
this instance, the DSLAM provides an interworking function between the ATM layer on the user side
and the Ethernet layer on the network side. The second approach pushes some type of Ethernet
connection all the way to the CPE device. Ethernet in the first mile (EFM) could employ a copper
connection, such as Ethernet over VDSL, or a fiber connection such as EFM over single-mode fiber.
With either approach, the connections are backhauled to Gigabit or 10-Gigabit Ethernet interfaces on
the E-series router.
Fiber to the home / curb (FTTH/FTTC) is also growing in popularity, making use of passive optical
networks (PON). A PON consists of an OLT at the service provider's central office and a number of
optical network terminals (ONTs) near end users. A PON configuration reduces the amount of fiber
and central office equipment required compared with point-to-point architectures. In this environment,
the E-series router has 10-Gigabit or Gigabit Ethernet connection to the OLT. In this environment,
typically, another aggregation device does not exist. The OLT has a point-to-multipoint, fiber to the
premises network architecture in which unpowered optical splitters are used to enable a single optical
fiber to serve multiple premises, typically 32.

VLANs
VLAN 100 VLAN 100
S -VLAN Encap
VLAN Encap
VLAN 101 VLAN 101 S-VLAN 1

ATM
VLAN 200 VLAN 200 S-VLAN 2
VLAN 201 VLAN 201

CPE CPE VLAN Encap
 VLAN options :
– Single-tagged VLANs
– Double-tagged VLANs or stacked VLANs
 S-VLANs
– Service provider VLANs (S-VLAN) and customer VLANs (C-VLAN)
– Similar to ATM VPI/VCI
– Improve VLAN scaling
– CPE or access node adds inner tag (C-Tag)
– Access node or aggregation device adds outer tag (S-Tag)
VLAN Options
In these Ethernet-based networks, the E-series router is terminating thousands of users on some type
of Ethernet interface. Virtual local area networks (VLANs) are implemented to manage large numbers
of users coming in over a single physical interface. A VLAN enables multiplexing multiple IP and
PPPoE interfaces over a single physical port using subinterfaces. VLANs are similar to ATM PVCs
with a VLAN ID acting like the ATM PVC's VPI. The IEEE 802.1Q-tagged frames provide a 12-bit
VLAN identifier. Therefore, one physical interface can support up to 4096 unique VLANs. Each VLAN
has a single, unique VLAN ID or tag assigned to it. On the slide, the diagram on the left uses this single
tagged approach. Notice that VLAN IDs must be unique within the access network.
In some Ethernet B-RAS environments where multiple access nodes are aggregated onto a single
Gigabit Ethernet or 10-Gigabit Ethernet connection, this VLAN limit is inadequate. A stacked VLAN (S-
VLAN) or double-tagged VLAN provides a two-level VLAN tag structure, extending the VLAN ID space
to more than 16 million VLANs.
S-VLANs
Stacked VLANs were developed by the IEEE as a way to segregate the customer VLAN ID space (C-
VLAN) from the service provider VLAN space (S-VLAN) and improve scaling. It is unfortunate that the
IEEE 802.1ad standard uses the term S-VLAN to mean service provider VLAN space because the E-
series router uses the term S-VLAN to mean any doubly tagged VLAN. Stacked VLANs require two
different tags or IDs. The outer tag is called the service provider tag (S-Tag) and the inner tag is called
the customer tag (C-Tag). These two tags are similar to the ATM VPI/VCI. Depending on the
installation, the CPE device or access node adds the C-Tag and the access node or aggregation
device adds the S-Tag. The E-series router performs decapsulation twice—once to get the S-Tag and
once to get the C-Tag.
On the slide, the diagram on the right uses the double-tagged approach. In this environment, each
access node is assigned a unique S-Tag, allowing the C-Tags to be reused.

VLAN Deployment Options

VLAN 200 & 300
S-VLAN Encap
VLAN Encap
VLAN 101 S-VLAN 1 VLAN 201 & 300
VLAN 200 S-VLAN 2 VLAN 200 & 300
DSLAM
VLAN 201 VLAN 201 & 300

VLAN Encap CPE
 1:1 VLAN:
– VLAN or S-VLAN per CPE
– S-Tag or S-Tag/C-Tag must be unique across access network
 N:1 VLAN
– VLAN per type of traffic o per access node
– S-Tag shared by many users
– Video or multicast services
1:1 VLAN
Service providers might use different VLAN deployment options or models. Some providers make use
of both options in the same network. The first approach, 1:1 VLAN, a single VLAN or S-VLAN is
assigned to a single CPE device. The S-Tag or S-Tag/ C-Tag must be unique across the access
network. This approach closely mimics the ATM VPI/VCI model. On the slide, the diagram on the left
implements the 1:1 VLAN approach. Notice that each CPE device is assigned a unique S-Tag/C-Tag
within the access network.
N:1 VLAN
With the N:1 VLAN approach, traffic is single-tagged with an S-Tag throughout the access network.
There might be an S-Tag for a specific type of traffic or for each access node. With this approach,
multiple users share the same S-Tag. A video or multicast service might take advantage of this
scheme. On the slide, the diagram on the right implements the N:1 VLAN approach as well as the 1:1
VLAN deployment model. Each CPE device is a member of the 300 VLAN. This VLAN is used for a
video multicast service. In addition, each CPE device is assigned a unique VLAN ID for user data
traffic.

VLAN Interface Columns

PPPoE over VLAN PPPoE over S-VLAN IP and PPPoE over VLAN
IP IP IP IP IP IP
PPP PPP PPP PPP PPP PPP
PPPoE Sub PPPoE Sub PPPoE Sub PPPoE Sub PPPoE Sub PPPoE Sub
IP over VLAN
PPPoE PPPoE PPPoE

IP IP
Major Major Major
S-VLAN
VLAN 300 VLAN 100 VLAN 200
1 100
VLAN Sub VLAN Sub VLAN Sub
VLAN Sub
VLAN Major Int
GE
10 GE
VLAN Interface Columns

The E-series router supports several different VLAN configurations. First you must create the VLAN
major interface. Next you create VLAN subinterfaces on top of the VLAN major interface. VLAN and S-
VLAN subinterfaces can coexist over the same VLAN major interface.
IP over VLAN is the simplest configuration where one VLAN subinterface supports a single IP
interface. This VLAN could be a N:1 VLAN supporting a multicast video service.
In a PPPoE-over-VLAN configuration, each VLAN subinterface supports a single CPE device. This
VLAN could be a 1:1 VLAN supporting a group of users at a single location. A PPPoE major interface
is created for each CPE. On top of the PPPoE major interface, a PPPoE subinterface is created for
each user. Each PPPoE subinterface supports a PPP interface and an IP interface. A PPPoE-over-S-
VLAN configuration is very similar. In this configuration, you specify the S-VLAN ID instead of a single
VLAN ID.
It is also possible to configure a dual-stack VLAN interface supporting both IP over VLAN and PPPoE-
over-VLAN interfaces. User data traffic might use the PPPoE encapsulation and voice or video traffic
might use the IPoE encapsulation. In this environment, the router uses the Ethertype field to determine
which interface column to use.
Remember that IP interfaces can be created statically or dynamically. In this example, we statically
defined the VLAN or S-VLAN subinterfaces, the PPPoE major interfaces, the PPPoE subinterfaces,
and the PPP interfaces. Each IP interface is dynamically created using information from RADIUS or a
profile definition.


 Overview of PPP over Ethernet
 PPP-over-Ethernet in Ethernet Access Network
 PPP-over-Ethernet Configuration and Troubleshooting
PPP-over-Ethernet Configuration and Troubleshooting


Initial B-RAS Configuration

 Initial configuration:
– All authentication requests go to the same RADIUS server
– No AAA domain map required
– Virtual routers and loopback interfaces
already configured
erx7(config)#radius authentication server 10.13.7.55
erx7(config)#radius accounting server 10.13.7.55

The slide shows the configuration steps to take when initially setting up the router in a B-RAS
environment. In this example, all authentication requests go to the same RADIUS server. No MA
domain map is required in this environment. The virtual routers and their associated loopback
interfaces are already configured. This RADIUS server is using standard UDP ports (port 1812 for
authentication and port 1813 for accounting), which are the defaults on the E-series router.

IP Configuration
 Dynamic IP interface configuration using RADIUS VSAs:
–Virtual-Router-Name
–Local-Interface-Name
– Local-Address-Pool-Name
erx7(config)#profile generic-ip
erx7(config-profile)#ip sa-validate
erx7(config-profile)#exit
 Local address pool configuration:
– Both address pools are localized to these virtual routers
erx7(config)#ip local pool isp1pool 172.16.3.2 172.16.3.254
erx7(config)#ip route 172.16.3.0 255.255.255.0 null 0
erx7(config)#vir VR2
erx7:VR2(config)#ip local pool isp2pool 182.16.3.2 182.16.3.254
erx7:VR2(config)#ip route 182.16.3.0 255.255.255.0 null0
Dynamic IP Interface Configuration

In this example, all IP configuration information required to build the user's IP interface, such as virtual
router, local interface reference, and local IP address pool name, is being returned by RADIUS.
Therefore, the profile used to create the user's IP interface only contains the IP source address
validation command.
Address Pool Configuration
The RADIUS server returns the name of an address pool configured on the router. Because both
address pool ranges are localized to the specific virtual router, a static route for each address range is
configured pointing to the null 0 interface. Remember that address pool names are case sensitive.

PPPoE-over-ATM Configuration Steps

 Configuration steps: PPPoE over ATM
erx7(config)#int atm 6/2.12 IP IP

erx7(config-if)#encapsulation pppoe PPP PPP
erx7(config-if)#interface atm 6/2.12.1
erx7(config-if)#encapsulation ppp PPPoE Sub PPPoE Sub
erx7(config-if)#profile ip generic-ip
erx7(config-if)#interface atm 6/2.12.2 PPPoE Major
erx7(config-if)#encapsulation ppp
ATM PVC
erx7(config-if)#ppp authentication chap ATM Subinterface
ATM
Major Interface
T3A / E3A
OCxc/STM1
Configuration Steps for PPPoE over ATM

To configure PPPoE-over-Ethernet interfaces over ATM, first configure the clocking for the SONET
controller. Next, create an ATM major interface, specifying the number of VCs per VP if necessary. For
each group of users, create a PPPoE major interface. Next, create a PPPoE subinterface for each
user, specifying PPP encapsulation. Configure any PPP parameters for the PPP interface, such as the
PPP authentication method or keepalive timers. Finally, for a dynamically created IP interface, apply
the appropriate profile. This configuration example uses the atm pvc command. It is also possible to
use the pvc command.

PPPoE-over-ATM Dual-Stack Config Steps

IP and PPPoE over ATM
– Single ATM subinterface with IP & IP IP
– PPPoE terminated at the router

erx7(config)#int atm 6/2.13 PPP PPP

erx7(config-if)#encapsulation bridge1483 PPPoE Sub PPPoE Sub
erx7(config-if)#ip unnumbered loopback1
erx7(config-if)#pppoe
IP PPPoE Major
erx7(config-if)#exit
erx7(config)#interface atm 6/2.13.1
Bridged
erx7(config-if)#encapsulation ppp Ethernet

ATM PVC
erx7(config-if)#profile ip generic-ip ATM Subint
OCx/STMx
Configuration Steps for Dual-Stack PPPoE over ATM

You can also configure a bifurcated interface that supports bridged Ethernet and PPPoE over the same
ATM 1483 subinterface. To allow this dual-stack configuration, you must specify the bridged Ethernet
encapsulation before you configure the PPPoE major interface. The remaining configuration steps are
the same as other PPP-over-Ethernet interfaces. In this configuration, user data traffic might use the
PPPoE configuration, and a set-top box might use the bridged Ethernet configuration.

PPPoE over Ethernet with VLANs

 Configuration steps: PPPoE over VLAN
IP IP
erx7(config)#interface fastEthernet 3/1
erx7(config-if)#encapsulation vlan
PPP PPP
erx7(config)#interface fast 3/1.100
erx7(config-if)#vlan id 100
PPPoE Sub PPPoE Sub
erx7(config-if)#pppoe subint fast 3/1.100.1
erx7(config-if)#encapsulation ppp PPPoE
Major
erx7(config-if)#ppp auth chap
erx7(config-if)#profile ip generic-ip VLAN 100
VLAN Sub
erx7(config-if)#encapsulation ppp VLAN
Major
erx7(config-if)#ppp auth chap Interface
GE
10 GE
Configuration Steps for PPPoE over Ethernet with VLANs

To configure PPPoE-over-Ethernet interfaces (Fast Ethernet, Gigabit Ethernet, and 10-Gigabit
Ethernet) with VLANs, first configure the Ethernet interface, specifying VLAN encapsulation. For each
VLAN or group of users, create a VLAN subinterface, assign a VLAN ID, and create a PPPoE major
interface. Next, create a PPPoE subinterface for each user, specifying PPP encapsulation. Configure
any PPP parameters for the PPP interface, such as PPP authentication method or keepalive timers.
Finally, apply a profile for a dynamically created IP interfaces. In this configuration, there is a VLAN
subinterface and PPPoE major interface per group of users. In other words, one physical Ethernet
interface supports multiple VLAN subinterfaces. Each VLAN subinterface supports a single PPPoE
major interface.

PPPoE over Ethernet with S-VLANs

 Configuration steps: PPPoE over S-VLAN
IP IP
erx7(config-if)#interface fast 3/1.1100 PPP PPP
erx7(config-if)#svlan ethertype 8100
erx7(config-if)#svlan id 1 100
PPPoE Sub PPPoE Sub
PPPoE
erx7(config-if)#encapsulation ppp Major
erx7(config-if)#ppp auth chap SVLAN

1 100
erx7(config-if)#profile ip generic-ip VLAN Sub
erx7(config-if)#pppoe subint fast 3/1.1100.2 VLAN
erx7(config-if)#encapsulation ppp Major
Interface
GE
erx7(config-if)#profile ip generic-ip 10 GE
Configuration Steps for PPPoE over Ethernet with S-VLANs

To configure PPPoE-over-Ethernet interfaces (Fast Ethernet, Gigabit Ethernet, and 10-Gigabit
Ethernet) with S-VLANs, first configure the Ethernet interface, specifying VLAN encapsulation. For
each S-VLAN or group of users, create a S-VLAN subinterface, assign a S-VLAN ID. By default, the E-
series router uses the 9100 for the S-VLAN Ethertype. If the E-series router is connected to a device
that uses the IEEE Standard 802.1ad, specify svlan ethertype 88a8. If the E-series router is connected
to a device that uses 802.1 Q-in-Q tagging, specify svlan ethertype 8100. Next, create a PPPoE major
interface and then create a PPPoE subinterface for each user, specifying PPP encapsulation.
Configure any PPP parameters for the PPP interface, such as PPP authentication method or keepalive
timers. Finally, apply a profile for a dynamically created IP interfaces. In this configuration, there is a S-
VLAN subinterface and PPPoE major interface per group of users. In other words, one physical
Ethernet interface supports multiple S-VLAN subinterfaces. Each S-VLAN subinterface supports a
single PPPoE major interface. Remember that VLAN and S-VLAN subinterfaces can coexist on the
same physical interface.

IP and PPPoE over Ethernet with VLANs

IP and PPPoE over VLAN
erx7(config)#interface fastEthernet 3/1 IP IP
erx7(config)#interface fast 3/1.200 PPP PPP
erx7(config-if)#vlan id 200
erx7(config-if)#ip address 172.16.100.1/24 PPPoE Sub PPPoE Sub
erx7(config-if)#pppoe sub fast 3/1.200.1
IP PPPoE Major
erx7(config-if)#encapsulation ppp
VLAN 200
erx7(config-if)#profile ip generic-ip VLAN Sub
erx7(config-if)#pppoe sub fast 3/1.200.2
erx7(config-if)#encapsulation ppp VLAN Major

erx7(config-if)#profile ip generic-ip GE
10 GE
IP and PPPoE over Ethernet with VLANs Configuration Steps

You can also configure a bifurcated interface that supports IP over Ethernet and PPPoE over the same
VLAN subinterface. First create the VLAN subinterface and configure the VLAN ID. Next, configure the
static IP interface. Create the PPPoE major interface and the remaining configuration steps are the
same as other PPP-over-Ethernet interfaces. It is also possible to configure dual stack interfaces over
S-VLANs.


default
DSL
RADIUS=10.13.7.55
ISP1 RADIUS
UDP=1812
10.13.7.55
key=training
tim@isp1.com
VR2
 Is the user logged into the router?

erx7#show subscribers username username@domain
 Is the router communicating with the RADIUS server?
erx7#show radius statistics
erx7#test aaa ppp username@domain password
Is the User Logged into the Router?

You can use some of the same troubleshooting commands that you used in a PPP-over-ATM
environment. First, to determine if the user logged in to the router, use the show subscribers username
username@domain command. If you execute this command in the default virtual router, you will see
all users logged into the router, regardless of their virtual router. If you execute this command in a
nondefault virtual router, you only see the users located in that specific virtual router. If the user is not
logged in, refer to the following paragraph when you troubleshoot a PPP-over-Ethernet interface.
Is the Router Communicating with the RADIUS Server?
Use the show radius statistics command. Can the router authenticate the user locally? Use the test
aaa ppp username password command. If you use a domain map, verify that the proper domain is
mapped to the appropriate virtual router using the show aaa domain-map command.


default
DSL RADIUS=10.13.7.55
Modem
diane@isp1.com UDP=1812 RADIUS
key=training
ISP1
10.13.7.55
VR2
tim@isp1.com
 Is the physical link between the user and the router working?
erx7#show controller sonet slot/port
erx7#show interface gigabitEthernet slot/port brief
erx7#show atm vc atm slot/port vcd
erx7#show interface gigabitEthernet slot/port.subinterface
 Is the user successfully completing both stages of PPPoE?
erx7#show pppoe interface
erx7#show pppoe interface interface
erx7#show pppoe subinterface
erx7#show pppoe subinterface interface


default
DSL
Modem
diane@isp1.com RADIUS=10.13.7.55 RADIUS
UDP=1812
ISP1
10.13.7.55
key=training
tim@isp1.com VR2
 What is the state of the user’s PPP session?

erx7#show ppp interface state down
erx7#show ppp interface atm slot/port.subint statistics
 Can the user communicate using IP?
erx7#ping a.b.c.d
erx7#show ip interface fastethernet slot/port.subinterface
erx7#ping a.b.c.d source address w.x.y.z
erx7#show ip route | include slot/port.subinterface
 Remember to set a statistics baseline to aid in troubleshooting
What Is the State of the User's PPP Session?

Once you verify that the user successfully completes both stages of PPPoE, examine the state of the
PPP session. Determine if any PPP interfaces are in the down state using the show ppp interface state
down command. Examine the user's PPP interface using the PPP commands listed on the slide.
Can the User Communicate Using IP?
Determine if the router can communicate with the user across the local link using the ping command.
Verify that packets are being transmitted and received on the user's IP interface using the show ip
interface gig slot/port. sub. pppoeSub command. If you can communicate with the user across the
local link, determine if the user can communicate beyond the local link. You can do this by using the
ping a.b.c.d source address w. x. y. z. The source keyword allows you to specify an alternate IP
address as the source of the packet. In this case, specify an IP address on the router in a different
subnet. This command verifies proper routing. Next, verify that the user's IP interface is listed as a host
route in the routing table. Remember to use CLI output filtering, such as show ip route I include 6/1.1,
to limit the number of routes displayed.
Setting a Statistics Baseline to Aid in Troubleshooting
Remember to use the baseline command to help during the troubleshooting process. The baseline
command sets a statistics baseline for the requested counters, such as RADIUS statistics, IP interface
statistics, or ATM interface statistics, to name a few.

Command Summary: PPPoE over ATM


show ip interface atm 6/2.12.1 IP configuration and statistics
show ip route | include 172.16.3. Routes for 172.10.3.*
PPP show ppp interface atm 6/2.12.1 PPP interface statistics

statistics
PPPoE show pppoe subinterface atm 6/2.12 Status of all PPPoE

subinterfaces PPPoE statistics
show pppoe interface atm 6/2.12
ATM Sub- show atm subinterface atm 6/2/0/112 Subinterface configuration and
interface show atm subinterface atm 6/2.12 statistics
ATM Major show atm interface atm 6/2 ATM major interface status and
statistics
Physical show controller sonet 6/2 Controller status
PPPoE over ATM Command Summary

This slides lists the commands used to troubleshoot a PPPoE-over-ATM environment, layer by layer.

Command Summary: PPPoE with VLANs


show ip interface gig 3/0.101.1 IP configuration and statistics
show ip route | include 172.16.4. Routes for 172.10.4.*
PPP show ppp interface gig 3/0.101.1 PPP interface statistics

statistics
PPPoE show pppoe subinterface gig 3/0.101 Status of all PPPoE

subinterfaces
show pppoe interface gig 3/0.101 PPPoE statistics
VLAN show interface gigabit 3/0.101 VLAN status and statistics
Physical show interface gigabitEthernet 3/0 Port-level statistics
PPPoE over Ethernet with VLANs Command Summary

This slides lists the commands used to troubleshoot a PPPoE over Ethernet with environment, layer by
layer.

Useful Logging Categories

 Useful logging categories for troubleshooting
PPP-over-Ethernet interfaces:
– pppPacket
– pppoeControlPacket
– aaaUserAccess
– aaaServerGeneral
– radiusClient
– radiusSendAttributes
– radiusAttributes
Useful Logging Categories for Troubleshooting PPP-over-Ethernet Interfaces

This slide lists several useful logging categories to aid in troubleshooting PPPoE interfaces on the
router.

PPPoE Successful Log: PPPoE

DEBUG 10/05/2004 13:59:56 pppoeControlPacket
(interface ATM6/2.221): PADI rx from
0090.1a41.306a, length 12, empty service name
(interface ATM6/2.221): PADO tx to
(interface ATM6/2.221): PADR rx from
(interface ATM6/2.221): PADS tx to
0090.1a41.306a, length 40, connection made
using session id 1 on sub interface 1
Viewing a PPPoE Successful Log

This slide shows the PPPoE session establishment between a PPPoE client and the E-series router.
The PPPoE client sends out a PADI (an initiation) with a destination MAC address of all Fs, indicating
a data-link broadcast and its MAC address as the source. In this example, the client is not requesting a
specific service because the service-name tag is empty. The PPPoE subinterface's adminStatus and
operStatus must be up before the E-series router will respond to the user's initiation request. The
router responds with a PADO (an offer), containing its source MAC address as well as the same
service the PPPoE client requested. Again, notice that the service-name tag is empty. The PPPoE
client then sends out a PADR (a request) for a unique session ID. The router responds with a PADS
(session establishment), containing the unique session ID.

PPPoE Successful Log: PPP LCP & CHAP

DEBUG 10/05/2004 13:59:58 pppPacket (interface ATM6/2.221.1): ti me: 0.00,
rx lcp confReq, id = 244, length = 19, mru = 1492, authenticatio n = chap
MD5, magicNumber = 0x1a9aa44d
rx lcp confReq, id = 20, length = 14, mru = 1492, magicNumber =
0x6d56dbe7
tx lcp confAck, id = 20, length = 14, mru = 1492, magicNumber =
0x6d56dbe7
tx lcp confReq, id = 245, length = 19, mru = 1492, authenticatio n = chap
rx lcp confAck, id = 245, length = 19, mru = 1492, authenticatio n = chap
tx chap challenge, id = 200, length = 32, challenge length = 23,
challenge = 17 21 74 67 75 f4 db 07 83 9e af ec 4c 98 08 74 5f 7 9 39 a3
88 6b ab, name = 'erx8' 65 72 78 38
rx chap response, id = 200, length = 35, response length = 16, response =
97 d4 dc 75 43 f9 c6 70 1a cc df 89 80 e8 2d 2e, name = 'diane@isp1.com'
64 69 61 6e 65 40 69 73 70 31 2e 63 6f 6d
tx chap success, id = 200, length = 4
Viewing a PPP LCP and CHAP Successful Log

This slide shows the PPP LCP and CHAP negotiation process between the PPPoE client and the E-
series router. Each peer sends an LCP configuration request with its options to the other peer. The
minimum options are the MRU and the magic number. The router additionally sends out a third
option—the authentication method, which, in the example, is CHAP. For the negotiation process to
proceed, each peer must acknowledge the configuration request sent from the other peer. Once the
process is successful, the E-series router sends a CHAP challenge to the client. The PPPoE client
responds with a CHAP response containing the MD5-encrypted secret. The E-series router passes this
for authentication to the RADIUS server. The router then forwards the results of the authentication with
the RADIUS server onto the PPPoE client. The example displays a CHAP success. At this point, the
peers can proceed onto NCP negotiation.

PPPoE Successful Log: PPP IP NCP

DEBUG 10/05/2004 14:00:00 pppPacket (interface
ATM6/2.221.1): time: 3.33,rx ipNcp confReq, id = 138, length
= 10, ipAddress = 0.0.0.0
ATM6/2.221.1): time: 3.33,tx ipNcp confNak, id = 138, length
= 10, ipAddress = 172.16.3.5
ATM6/2.221.1): time: 3.34, rx ipNcp confReq, id = 139,
length = 10, ipAddress = 172.16.3.5
ATM6/2.221.1): time: 3.34, tx ipNcp confAck, id = 139,
ATM6/2.221.1): time: 3.35, tx ipNcp confReq, id = 241,
ATM6/2.221.1): time: 3.38, rx ipNcp confAck, id = 241,
Viewing a Successful PPP IP NCP Log

This slide shows the PPP IP NCP negotiation process between the E-series router and the PPPoE
client. The option used with IP NCP is the IP address of the ATM subinterface to the client. The E-
series router uses the loopback address referenced for the IP unnumbered address as its IP address.
Initially, the client sends an IP address of 0.0.0.0, indicating that it does not have an address. The
router responds to this request with an IP NCP configNak message, along with an IP address assigned
from either the RADIUS server, a local pool, or a DHCP proxy client service. Once each peer
successfully acknowledges each configuration request, PPP is considered completely initialized.

Review Questions
1. How is PPP over Ethernet different from PPP over ATM?
2. What are the two different stages of PPP over Ethernet?
3. What is the basic life of a packet for PPP over Ethernet?
4. How do you configure the E-series router for PPP over
Ethernet?
5. What steps would you take to troubleshoot a
PPP-over-Ethernet interface?

• The benefits of using PPP over Ethernet;
• The life of a packet for PPP over Ethernet;
• Comparing and contrasting ATM access networks and Ethernet access networks;
• Configuring the E-series router for PPP over Ethernet; and
• Verifying PPP-over-Ethernet operation using show commands and logging.

Lab 4: Configuring PPPoE Interface
Lab Objectives:
Configure and troubleshoot static PPP-over-Ethernet
interfaces on the E-series router.
Lab 4: Configuring PPP over Ethernet



Module 5: Dynamic Interfaces
.
Module Objectives
to:
− Explain how dynamic interfaces are built
− Configure the E-series router to support dynamic interface
detection and creation using PPP
− Compare and contrast dynamic interface creation in a bridged
Ethernet and IP-over-ATM environment versus a PPP
environment
− Configure the router to dynamically create ATM subinterfaces
− Configure the router to create dynamic subscriber interfaces

• The dynamic interface creation process;
• Configuring the E-series router to support dynamic upper-layer interface detection and
creation;
• Bridged Ethernet and IP-over-ATM dynamic upper-layer interface creation;
• Dynamic interface creation using bulk configuration; and
• Dynamic subscriber interface creation.
Module 5: Dynamic Interfaces 5-2

Agenda: Dynamic Interfaces

 Dynamic PPP-over-ATM and PPP-over-Ethernet Interfaces
 Dynamic IP-over-ATM and Bridged Ethernet Interfaces
 Dynamic Interface Creation Using Bulk Configuration
 Dynamic Subscriber Interfaces
Dynamic PPP-over-ATM and PPP-over-Ethernet Interfaces


Dynamic IP Interfaces
 How are dynamic IP interfaces IP IP IP IP
Interface Interface Interface Interface
created?
− External event triggers creation PPP PPP PPP PPP
− Router receives packets
− User is authenticated PPPoE
Subint
PPPoE
Subint
PPPoE
Subint
PPPoE
Subint
− IP interface is created using
PPPoE PPPoE
information from RADIUS or profile Major Int Major Int
− PPP-over-ATM and
VLAN ATM PVC
PPP-over-Ethernet interfaces Sub Int ATM Sub
 Can we dynamically create the VLAN ATM

Major Int Major Int
rest of the interface column?
− ATM PVC encapsulation method GE/10 GE OCx/STMx
− ATM and VLAN subinterface
− PPP-over-ATM or PPP-over-Ethernet interfaces
− Dynamic upper-layer and bulk-configured interfaces
How Are Dynamic IP Interfaces Created?

Up to this point, we discussed and configured dynamic IP interfaces and static PPP, PPPoE, and ATM
interfaces. In the PPPoE and PPPoA labs, we configured interface columns using a mechanism called
profiles. A profile is a set of common interface characteristics or parameters. A profile is created once,
stored in the configuration file, and applied to many interfaces. In the previous labs, we only configured
IP
characteristics in the profile. If you use the profile command in an interface column definition without
any additional keywords, the router tries to dynamically create an IP interface based on some external
event. External events trigger dynamic interface creation. In PPPoA and PPPoE scenarios, the router
receives PPP packets and initiates user authentication. Once the user is authenticated, the router
creates the user's IP interface based on the profile configuration and attributes received from RADIUS.
In the previous labs, we statically configured the VLAN or ATM subinterface, ATM PVC encapsulation
method as well as the PPP-over-ATM or PPP-over-Ethernet interfaces. Static interfaces consume
system resources for as long as they exist, regardless of whether they are active. Static interface
configuration is also stored in nonvolatile storage, thereby ensuring persistence between system
reboots. When using static interfaces to support a large number of interfaces, the burden is on the user
to configure every interface, even if the majority of them share the same characteristics. Also, large
numbers of static interfaces require a proportional amount of memory, even if a number of interfaces
are idle.
Dynamic Interface Column Creation
In the next section, we move the line down the stack and examine benefits of making more of the
interface column dynamic. First, we discuss how to create dynamic upper-layer interfaces on top of
static ATM and VLAN subinterfaces. Next, we discuss how to dynamically build an dynamic ATM and
VLAN subinterfaces using bulk configuration. Finally, we discuss the creation of dynamic subscriber
interfaces.

Building Dynamic Interface Columns

Ryan@ Mark@ Ralph@ Pam@
isp1.com isp2.com isp2.com isp1.com
 Building dynamic interfaces: IP IP IP IP
Interface Interface
−Automatic upper-layer protocol Interface Interface
detection and configuration PPP PPP PPP PPP

 Profiles Interface Interface Interface Interface
 RADIUS attributes PPPoE PPPoE PPPoE PPPoE

 auto-configure statements Subint Subint Subint Subint
−ATM PVC encapsulation

PPPoE PPPoE
auto-detection Major Int Major Int
 Automatically configures the PVC with
either LLC/SNAP or VC multiplexing VLAN ATM PVC
encapsulation Sub Int ATM Sub
 First packet received determines the

configuration VLAN ATM
Major Int Major Int
 aal5autoconfig keyword
GE/10 GE OCx/STMx
Building Dynamic Interfaces

In this first example, the VLAN major interface, VLAN subinterface, and PPPoE major interface are
statically configured. For ATM interfaces, the ATM major interface and subinterface are statically
configured. You can configure the router to automatically detect and configure the appropriate upper-
layer protocol, such as PPPoE or PPPoA. The router detects the correct protocol using the auto-
configure command and configures the rest of the dynamic interface column using information
contained in a profile.
With the aal5autoconfig keyword, you can configure an ATM PVC to automatically detect the
encapsulation method in use on the PVC. The router automatically configures the PVC for either
LLC/SNAP (aal5snap) or VC multiplexing (aal5 mux ip), based on the first received packet.
When the user disconnects or logs out, the dynamic upper-layer interface is destroyed, freeing up
system resources. The interface column is rebuilt when the user reconnects.
If any layer of the dynamic portion of the interface column fails to be created, the interface column is
not created and the connection is denied. All dynamic layers above the static portion are destroyed,
starting with the highest dynamic layer.

Creating Profiles
Ryan@ Mark@ Ralph@ Pam@
 Profiles contain common isp1.com isp2.com isp2.com isp1.com
configuration parameters: IP
Interface
IP IP
Interface
IP
Interface Interface
− IP
 Address, virtual router, source PPP PPP PPP PPP
address validation, policy Interface Interface Interface Interface
− PPP
PPPoE PPPoE PPPoE PPPoE
 Authentication method, MRU, Subint Subint Subint Subint
keepalive, CHAP challenge length
− PPPoE PPPoE PPPoE
 Maximum number of sessions, MTU, Major Int Major Int
duplicate protection
− Flexible configuration VLAN ATM PVC
 Profile per protocol type Sub Int ATM Sub
 Profile for type of user or connection

VLAN ATM
Major Int Major Int
GE/10 GE OCx/STMx
Common Configuration Parameters

You can extend the use of profiles to include PPP and PPPoE configuration parameters in addition to
IP interface configuration information. For PPP and PPPoE, the profiles only list the common
configuration parameters; they do not configure the interfaces. We use a new command to dynamically
configure the interfaces.
First, we must create the profiles. We create the profiles once and assign them to multiple interfaces.
In the previous chapters, we discussed the IP configuration parameters contained in the profile. For
PPP interfaces, you can configure the authentication method, MRU, keepalive interval, CHAP
challenge length, as well as other parameters in the profile. It is common practice to fix the CHAP
challenge length to 16 bytes so that it can be stored in the request-authenticator field in the access-
request message sent to the RADIUS server. If the CHAP challenge is shorter or longer, it must be
placed in the CHAP-challenge attribute. Many RADIUS servers prefer to have the CHAP challenge in
the authenticator field of the access request.
For PPPoE interfaces, you can specify the maximum number of sessions, MTU, and duplicate
protection as well as other PPPoE parameters. You can configure a separate profile per protocol or a
profile for different user types. For example, you could configure one profile used for home users and a
different profile for business DSL users.

Assigning Profiles on static ATM Subint

 Applying profiles: Ralph@
isp2.com
Pam@
isp1.com
erx7(config-if)#profile [any | ip | ppp | IP IP
bridgedEthernet | pppoe] profile-name Interface Interface
− Assigned to the highest static layer PPP PPP

− Profile identifies th configuration parameters for Interface Interface
the layer above the static ATM subinterface PPPoE PPPoE

Subint Subint
 Generic profile:
− Include all configuration PPPoE
Major Int
parameters in a single profile
− Use the key word any ATM PVC
ATM Sub
 Protocol specific profile:
− Identify the specific protocol(s) above the static ATM
Major Int
ATM subinterface
− Only include those configuration parameters in OCx/STMx
the profile
Assigning Profiles
Once the profile is created, you assign it to static subinterfaces. When the profile is assigned, it
specifies the protocol or protocols to be supported directly above the static portion of the interface
column. In this example. the profile is assigned to the static ATM subinterface, which is the highest
static layer of the interface column. When you assign a profile, you indicate the encapsulation type to
which the profile applies using the keyword ppp, pppoe, bridgedEthernet, or ip.
Generic Profile
You can configure one profile and support any interface above the static subinterface by using the key
word any when assigning the profile. This key word indicates that one profile will be used for all
encapsulation types supported above the static subinterface. The profile must contain all the
configuration parameters (IP, PPP, PPPoE), and if a PPP interface is detected, the E-series router only
uses the appropriate configuration parameters when building the interface and ignores the rest, such
as the PPPoE parameters.
Protocol Specific Profile
Within an interface definition, you can specify multiple profile commands each referencing a different
upper-layer protocol. With this method, you can configure a different profile for each type of protocol.
The profile would only include parameters specific to the protocol being configured.

Detecting and Building Dynamic Interfaces

Ralph@ Pam@
 Detect and configure upper layer isp2.com isp1.com
IP IP
erx7(config-if)#auto-configure [ip | Interface Interface
ppp | pppoe | bridgedEthernet]
PPP PPP
− On receipt of first packet automatically detects Interface Interface
and build the specified layer and above
PPPoE PPPoE
− Works hand in hand with the applied profile Subint Subint
− To limit traffic to a single protocol, use a single
auto-configure command PPPoE
Major Int
− To dynamically detect the upper-layer protocol
and configure the appropriate stack (either ATM PVC
ATM Sub
PPPoE or PPPoA), use multiple auto-configure
commands referencing the different protocols ATM
Major Int
OCx/STMx
Dynamically Building Interfaces

You use the auto-configure command to dynamically detect and build interfaces using the configuration
parameters contained in the profiles. The auto-configure command indicates at which layer to begin
dynamically building the interface. You can use multiple auto-configure commands per interface,
specifying different
protocols for the router to detect and accept.
Limiting Traffic to a Single Protocol
To limit the interface to a particular type of traffic, such as PPPoE, only use one auto-configure
command, referencing the desired traffic type, for example, auto-configure pppoe.
Dynamically Detecting Upper-Layer Protocols
To allow an interface to dynamically sense different traffic types and build the appropriate interface
columns, use multiple auto-configure commands, referencing the supported protocols. For example, to
support either PPPoE and PPPoA traffic, configure two auto-configure commands—one for PPPoE
and one for PPP. Then, based on the first packet received, the appropriate interface column is built
using the configuration parameters contained in the referenced profile as well as information received
from the RADIUS server.
The next few slides show specific examples of how to use the three configuration options—profiles,
aal5 auto conf ig, and auto-configure—to allow different types of dynamic interfaces.

Dynamic upper-layer interfaces: PPPoE

Ralph@ Pam@
 Dynamic upper-layer interface configuration : isp2.com isp1.com
– CHAP or PAP authentication IP IP

Interface Interface
– Set CHAP length to 16 bytes
PPP PPP
– Maximum of two PPPoE subinterfaces Interface Interface
erx7(config)#profile pppoe-info PPPoE PPPoE

Subint Subint
erx7(config-profile)#ip unnumbered lo0
erx7(config-profile)#ip virtual-router vr1 PPPoE
Major Int
erx7(config-profile)#ppp authentication chap pap
erx7(config-profile)#ppp chap challenge 16 16 ATM PVC
ATM Sub
erx7(config-profile)#pppoe sessions 2
erx7(config-profile)#int atm 6/1.101 ATM
Major Int
erx7(config-subif-atm-vc)#encap aal5autoconfig OCx/STMx
erx7(config-subif-atm-vc)#profile pppoe pppoe-info

erx7(config-subif)#auto-configure pppoe
Dynamic Upper-Layer Interface Configuration—Only PPPoE

This slide provides a sample configuration for building dynamic interfaces that only support PPPoE
interfaces. This sample configuration does not support PPPoA interface creation. To create dynamic
interfaces that only support PPPoE interfaces, first build a profile including all the common PPP,
PPPoE, and IP parameters the interfaces will use when they are built. Note that this profile fixes the
CHAP challenge length to 16 bytes. In the ppp chap challenge command, the first 16 indicates the
minimum length and the second indicates the maximum length of the challenge.
Next, configure the ATM subinterface and ATM PVC using the aal5autoconfig keyword to automatically
detect which encapsulation method is used on the PVC. Then, assign the profile just created using the
profile pppoe command. This command indicates the common configuration parameters that the router
should use when building the interface column. The pppoe keyword indicates that the profile contains
configuration parameters for any interface above the PPPoE major interface, specifically the PPPoE
major and subinterfaces, the PPP interface, and the IP interface.
Finally, use the auto-configure pppoe command. Because only one auto-configure command is
included in this interface definition, when specifying PPPoE, the router only looks for PPPoE-
encapsulated packets on this interface. All other packet types are dropped. Only PPPoE interfaces are
dynamically built directly above the ATM subinterface using the configuration information stored in the
pppoe-info profile. Note that you should assign the profile before specifying the auto-configure
command.

Profile Configuration Example

 Protocol-specific profile configuration:
− Steer authentication request to virtual router in profile
− CHAP for business users, PAP for residential users
− Maximum of two PPPoE subinterfaces
erx7 (config) #profile biz-user
erx7 (config-profile) #ppp authen virtual-router vr1 chap
erx7 (config-profile) #exit
erx7 (config) #profile res-user
erx7 (config-profile) #ppp authen virtual-router vr2 pap
erx7 (config-profile) #pppoe sessions 2
erx7 (config-profile) #ip unnumbered lo0
erx7 (config-profile) #ip virtual-router vr2
erx7 (config-profile) #exit
− Why doesn't one profile contain IP configuration parameters?
− What happens if RADIUS returns different IP attributes for residential
users?
Protocol-Specific Profile Configuration

In this example, two different profiles are configured based on the type of user—business versus
residential. Business user authentication requests will be steered to virtual router vr1 and will use
CHAP authentication. Business users are using PPPoA. Note that the biz-user profile does not contain
any IP configuration information.
Residential user authentication requests will be steered to virtual router vr2 and will use PAP
authentication. Residential users are using PPPoE. Each residential user can have a maximum of two
PPPoE sessions. Their IP interfaces will be built in virtual router vr2 using vr2's loopback 0 as the local
interface reference.
Why doesn't the biz-user profile contain IP configuration parameters? In this example, the business
user's IP interface configuration parameters are stored in the RADIUS database.
What happens if RADIUS returns different IP attributes for residential users? For example, what if the
RADIUS server returns the virtual router name, vrl, and the local interface, loopback 1 for a residential
user? RADIUS-returned attributes take precedence over attributes stored in a profile. In this instance,
the residential user's IP interface would be built in virtual router vr1 using loopbackl as the local
reference point

Dynamic Interfaces: PPPoA or PPPoE

 PPPoA or PPPoE dynamic upper-layer interface configuration:
Marco@ Mario@
erx7(config)#int atm 6/1.102 isp2.com isp1.com
erx7(config-subif)#pvc 102 0/102 IP IP
Interface Interface
erx7(config-subif-atm-vc)#encap aal5autocon
erx7(config-subif-atm-vc)#exit PPP PPP
CompanyXYZ Interface Interface
erx7(config-subif)#profile ppp biz-user @isp1.com
erx7(config-subif)#profile pppoe res-user IP PPPoE PPPoE

Interface Subint Subint
erx7(config-subif)#auto-configure ppp
erx7(config-subif)#auto-configure pppoe PPPoE PPPoE
Major Int Major Int
ATM PVC ATM PVC

ATM Sub ATM Sub
ATM
Major Int
OCx/STMx
PPPoA or PPPoE Using Different Profiles

Now that the profiles are configured, the next step is to configure the static portion of the interface
column. First configure the ATM subinterface and ATM PVC using the aal5autoconfig keyword to
automatically detect which encapsulation method is used on the PVC. Then, specify the biz-user
profile using the profile ppp command. Specify the res-user profile using the profile pppoe command.
Only one profile is used, based on the first type of packet detected.
Finally, specify two auto-configure commands—one for PPP interfaces and one for PPPoE interfaces.
The auto-configure ppp and auto-configure pppoe commands indicate that the E-series router looks for
PPP-over-ATM or PPP-over-Ethernet encapsulated packets on this interface. The router drops all
other packet types.

Dynamic Interfaces: PPPoE over VLAN

Ryan@ Mark@
 PPPoE dynamic upper-layer interface configuration isp1.com isp2.com
IP IP
over static VLAN and static PPPoE major interface: Interface Interface
erx7(config)#int gigabitEthernet 5/0
PPP PPP
erx7(config-if)#encap vlan Interface Interface
erx7(config-if)#int gigabitEthernet 5/0.100
PPPoE PPPoE
erx7(config-if)#vlan id 100 Subint Subint
PPPoE
erx7(config-if)#pppoe profile pppoe-info Major Int
erx7(config-if)#pppoe auto-configure VLAN
Subint
VLAN
Major Int
GE/10GE
PPPoE Dynamic Interfaces over Static VLANs

This slide provides a sample configuration for building dynamic PPPoE subinterfaces over a static
VLAN subinterface and a static PPPoE major interface. It is not possible to dynamically create PPPoE
majors over static VLAN subinterfaces like you can with static ATM subinterfaces. Note that this
configuration still uses profiles and the
auto-configure command, although in a slightly different form.

Verifying Dynamic Upper-Layer Interfaces

 Verify user information:
erx7#show subscribers username ralph@isp2.com
erx7#show subscribers slot 5
erx7#test aaa ppp ralph@isp2.com ralph
erx7#show radius authentication statistics
 Examine profile and interface configuration:
erx7#show profile name pppoe-info
erx7#show config interface atm 6/1.101
 Examine statistics and dynamic upper-layer information:
erx7#show atm sub atm 6/1.101
erx7#show pppoe int atm 6/1.101
erx7#show pppoe sub atm 6/1.101.1
erx7#show ppp int atm 6/1.101.1 statistics
Verifying User Information

You can use some of the same troubleshooting commands that you used in a PPP-over-ATM or PPP-
over-Ethernet environment. First, determine if the user logged into the router using the show
subscribers username username@domain command. If not, verify that the router can authenticate the
user locally using the test aaa ppp username password command. Examine RADIUS statistics using
the show radius authentication statistics command.
Examining Profile and Interface Configuration
If the router can authenticate the user locally, verify the profile and interface configuration. Verify that
the profile includes a PPP authentication method. Examine the interface definition and make sure it
includes both the profile command and the auto-configure command. You must have both to create the
dynamic interface, and they must reference the appropriate protocols.
Examining Statistics and Dynamic Interface Column Information
Verify that the user's subinterface is transmitting and receiving frames. Depending on the user's
access method, examine PPP or PPPoE interface statistics as well as IP interface statistics.
Remember to use ping and traceroute to verify network connectivity.

Logging and Dynamic Interfaces

 Debug profiles:
– Standard PPP and PPPoE logging require static interfaces
– Create debug profile with logging enabled
erx7(config)# profile debug-pppoe
erx7(config-profile)# ip unnumbered loopback 0
erx7(config-profile)# ip virtual-router vr1
erx7(config-profile)# ppp authentication chap pap
erx7(config-profile)# pppoe sessions 2
erx7(config-profile)# ppp log pppPacket
erx7(config-profile)# pppoe log pppoeControlPacket
 Using debug profiles:
– Set console logging filter to debug
– Shut down static interface
– Swap profile during debugging
– Restore original profile when finished debugging
Debug Profiles
It is fairly straightforward to troubleshoot statically defined PPP and PPPoE interfaces using logging
when necessary. When you enable logging on a PPP-over-ATM or PPP-over-Ethernet interface, you
must reference a static subinterface. Unfortunately, when you start using dynamically created
interfaces, you no longer have an subinterface to reference. The subinterface is dynamically created
upon the receipt of traffic. You can, however, create a special profile that can be used solely for
debugging dynamic interfaces. In this debug profile you include all the IP, PPP, and PPPoE commands
found in the production profile as well as any logging categories you might want to enable.
Using Debug Profiles
To use this special debug profile, first set the console logging filter level to debug. If you are using
Telnet, remember to direct log messages to your session using the log here command. Next, navigate
to the static portion of the interface on which you want to enable logging. Shut the interface down,
remove the production profile, add the debug profile, and enable the interface. Log messages should
appear on your console session. Once the problem is solved, remember to restore the original
production profile.
You can only perform PPP packet logging on a total of 32 static and dynamic PPP interfaces per
chassis. The first 32 PPP interfaces that come up perform PPP packet logging. The remaining PPP
interfaces will not log PPP packets.


 Dynamic PPPoA and PPPoE Dynamic Interfaces
 Dynamic IP-over-ATM and Bridged Ethernet Interfaces
Dynamic IP-over-ATM and Bridged Ethernet Interfaces


Dynamic Interfaces
 How are dynamic interfaces created?
IP IP
− Router receives a packet Interface Interface
− ATM encapsulation detected
PPP PPP
− Upper-layer protocols detected Interface Interface
− PPPoE and/or PPP interfaces built
PPPoE PPPoE
− IP interface built using information Subint Subint
from a profile and RADIUS
 Can we do the same with IP-over-ATM IP PPPoE
Interface Major Int
and bridged Ethernet interfaces?
− No direct user authentication ATM PVC
ATM Sub
ATM PVC
ATM Sub
− Statically configure user authentication
information on the router ATM
− RADIUS authenticates user Major Int
− IP interface built using information from

a profile and RADIUS OCx/STMx
Creating Dynamic Upper-Layer Interfaces

The previous slides discussed how the router builds dynamic upper-layer interfaces on top of a static
ATM or VLAN subinterface. Dynamic upper-layer interface creation is based on some external event.
In the PPP-over-ATM or PPP-over-Ethernet case, the router determines the ATM PVC encapsulation
method based on the first packet it receives. It then examines the upper-layer protocols and builds the
appropriate interface stack using information found in the profile in conjunction with the protocols
allowed by the auto-configure commands. Finally, the router authenticates the PPP user and creates
the IP interface based on information in the profile as well as information received from a RADIUS
server.
Creating Dynamic IP-over-ATM and Bridged Ethernet Interfaces
How can we create dynamic IP interfaces in an IP-over-ATM or bridged Ethernet environment when
the user does not authenticate using RADIUS like a PPP user does? You can statically configure user
authentication information on any bridged Ethernet or IP-over-ATM interface on the router. With this
configuration, you mimic a PPP environment and involve a RADIUS server to assist in the interface
configuration process. You do this by using the subscriber command on the router. The subscriber
command allows you to hard-code user or company login information, such as user name, domain,
and password, on a specific interface. When this interface initializes, the hard-coded user login
information is sent to a RADIUS server for authentication. The RADIUS server responds with RADIUS
attributes such as a specific framed IP address for the customer's WAN interface, routing configuration
or policies including rate-limit profiles or classifiers.

Dynamic Interfaces―IP over ATM

User=CompanyX@isp1.com
Password = companyx
Company X Loopback 0 Return RADIUS attributes
30.30.30.1/32 Framed IP = 30.30.30.30
RADIUS Framed Route = 40.40.40.0/24
DSL
Router
30.30.30.30
Remote Network Internet
40.40.40.0/24
 Router configuration:
erx7(config) #profile small-business-IPoA
erx7(config-profile) #ip unnumbered loopback 0
erx7(config-profile) #ip virtual-router default
erx7(config-profile) #interface atm 6/1.45
erx7(config-subif) #atm pvc 45 0 45 aal5autoconfig
erx7(config-subif) #profile ip small-business -IPoA
erx7(config-subif) #subscriber ip user CompanyX domain
isp1.com password companyx
erx7(config-subif) #auto-configure ip
Dynamic Interfaces—IP over ATM

Company X requires an IP-over-ATM connection. Company X has a DSL router with one remote
network, 40.40.40.0/24, which it wants to advertise onto the Internet. Its router has a static IP address
configured on the WAN interface, 30.30.30.30. Remember that this is an IP-over-ATM, always-on
connection. The CPE router does not have any login information configured.
To create dynamic IP-over-ATM interfaces, you first configure a profile on the router specifying only IP
characteristics. Then you configure the ATM subinterface and ATM PVC and assign the profile you just
created using the profile ip command. This command provides the configuration parameters the router
uses to build the dynamic IP interface as the layer above the ATM subinterface. Next you configure the
user information to be sent to the RADIUS server. The subscriber command is locally administered
authentication information. Using the subscriber command, you configure the subscriber or user name,
domain, and an optional password. This information is then passed to the administration, authorization,
and authentication (AM) process on the E-series router, which in turn passes it to the RADIUS server
for authentication. Keep in mind that you configure this user login information on the E-series router,
not on the user's router, bridge, or workstation. Finally, use the auto-configure ip command to allow the
router to automatically detect and configure an IP interface directly above the ATM subinterface using
information found in the profile and returned by RADIUS.

RADIUS Configuration
Prefix/Length Type Next Hop Dist/Met Interface
30.30.30.30/32 AccessInternal 0.0.0.0 2/1 atm 6/1.45
40.40.40.0/24 Access 0.0.0.0 2/1 atm 6/1.45
Company X Loopback 0
User=CompanyX@isp1.com
30.30.30.1/32 Password = companyx
RADIUS Return RADIUS attributes
DSL Framed IP = 30.30.30.30
Router Framed Route = 40.40.40.0/24
30.30.30.30
Remote Network Internet
40.40.40.0/24
 RADIUS configuration:
− Same user name and password
− Framed IP address for customer’s router interface
− Framed IP route for customer’s remote network
Keep in mind that in an IP-over-ATM environment, the customer's router's WAN interface has a static
IP address assigned and configured. An IP-over-ATM environment does not run PPP or DHCP, where
the IP address is negotiated or handed out dynamically.
You just configured the user information on the customer's interface on the router using the subscriber
command. The router will use this information to obtain the routing configuration information for this
customer from the RADIUS server and cache it in the routing table. In the example on the slide, once
RADIUS authenticates the user, the RADIUS server passes back an access grant, which might include
additional RADIUS return attributes to further configure the user's interface on the router. In this IP-
over-ATM example, the RADIUS server returns a framed IP address corresponding to the customer's
WAN interface (that is, 30.30.30.30) and a framed IP route corresponding to the customer's remote
network (that is, 40.40.40.0/24). Based on the router's configuration, these entries are inserted into the
routing table bound to the customer's ATM subinterface. The RADIUS server could pass back policy
configuration as well.

Dynamic Interfaces—Bridged Ethernet

User=user1@isp1.com
Loopback 0
Return RADIUS attributes
182.10.1.1/32 Framed IP = 182.10.1.2
RADIUS
DSL
Bridge
Static IP Address Internet

182.10.1.2
 Router configuration:
erx7(config) #profile static-ip
erx7(config-profile) #ip unnumbered loopback 0
erx7(config-profile) #ip virtual-router default
erx7(config-profile) #interface atm 6/1.46
erx7(config-subif) #atm pvc 46 0 46 aal5autoconfig
erx7(config-subif) #profile bridgedEthernet static-ip
subscriber ip user user1 domain isp1.com
erx7(config-subif) #auto-configure bridgedEthernet
Dynamic Interfaces—Bridged Ethernet

To create dynamic bridged Ethernet interfaces, you first configure a profile on the router specifying
only IP characteristics. Then you configure the ATM subinterface and ATM PVC and apply the profile
you just created using the profile bridgedEthernet command. This command indicates that the router
only configures an bridged Ethernet interface as the layer above the ATM subinterface. Next you
configure the user information to be sent to the RADIUS server. Using the subscriber command, you
configure the user name, domain, and an optional password. This information is then passed to the MA
process on the E-series router, which in turn passes it to the RADIUS server for authentication. Finally,
use the auto-configure bridgedEthernet command to allow the router to automatically detect and
configure a bridged Ethernet interface directly above the ATM subinterface using information found in
the profile and returned by RADIUS.
Using this login information, the provider maps the customer's static IP address (that is, 182.10.1.2) to
the specific ATM subinterface or PVC on the E-series router and installs this information in the routing
table. The provider has the user's name stored in its RADIUS database along with return list attributes-
182.10.1.2 as a framed IP address (that is, a host route).

Sample Log using aaaUserAccess &

radiusAttributes
erx7:cpe-router# ping 30.30.30.1
Sending 5 ICMP echos to 30.30.30.1, timeout = 2 sec.
DEBUG 10/29/2001 12:45:29 radiusAttributes: USER ATTRIBUTES: (CompanyX@isp1.com)
DEBUG 10/29/2001 12:45:29 radiusAttributes: class attr: SBR-CL DN="" AT="0"
DEBUG 10/29/2001 12 COMPANYX@isp1.COM :45:29 radiusAttributes: framed IP address
attr: 30.30.30.30
DEBUG 10/29/2001 12:45:29 radiusAttributes: framed route attr: 40.40.40.0/24
INFO 10/29/2001 12:45:29 aaaUserAccess: User: CompanyX@isp1.com, access granted
...!!
Success rate = 40% (2/5), round- trip min/avg/max = 3/3/3 ms
erx7:cpe-router#ping 30.30.30.1
!!!!!
Success rate = 100% (5/5), round-trip min/avg/max = 3/3/3 ms
Sample Log
Note that traffic must be received on the interface to trigger dynamic interface creation and cause
packets to be sent to RADIUS.


 Dynamic PPP-over-ATM and PPP-over-Ethernet Interfaces
 Dynamic Interface Creation Using Bulk Configuration
Dynamic Interface Creation Using Bulk Configuration


Dynamic Interfaces Using Bulk Config

 How are dynamic upper-layer Ryan@
isp1.com
Mark@
isp2.com
Ralph@
isp2.com
Pam@
isp1.com
interfaces created? IP IP IP IP
− Router receives a packet
− Upper-layer protocols detected PPP PPP PPP PPP
− Interface columns built using
information from a RADIUS & profile PPPoE PPPoE PPPoE PPPoE
Subint Subint Subint Subint
 Can we do the same with
PPPoE PPPoE
ATM and VLAN subnterfaces ? Major Int Major Int
− Configure profile with common VLAN ATM PVC

subinterface information Sub Int ATM Sub
− Configure ATM or VLAN major interface

VLAN ATM
 Identify PVC or VLAN ranges Major Int Major Int
 Assign profile
OCx/
 Configure autodetection of the GE/10GE
STMx
specific encapsulation type
Creating Dynamic Upper-Layer Interfaces

The previous slides discussed how the router builds dynamic upper-layer interfaces on top of a static
ATM or VLAN subinterface. Dynamic upper-layer interface creation is based on some external event.
The router detects the PVC encapsulation method based on the first packet it receives. It then
examines the upper-layer protocols and builds the appropriate interface stack using information found
in the profile in conjunction with the protocols allowed by the auto-configure commands. Finally, the
router authenticates a user based on information configured in the subscriber command or the PPP
login contents.
Creating Dynamic ATM and VLAN Subinterfaces
In the next section, we move the line further down the stack and examine benefits of making the ATM
and VLAN subinterface dynamic as well. Like dynamic PPP-over-Ethernet or PPP-over-ATM
interfaces, dynamic ATM and VLAN subinterfaces require the use of profiles. In this configuration, the
profile contains common VLAN subinterface information or common ATM subinterface and ATM PVC
information such as the encapsulation method and traffic management parameters. You must still
configure an ATM or VLAN major interface and define the range of VPIs and VCIs or VLAN IDs. Like
previous dynamic interface creation configuration, you then assign the ATM or VLAN profile and allow
automatic subinterface creation.

Dynamic ATM Subinterface Bulk Config

ATM PVC ATM PVC ATM PVC
ATM Subinterface ATM Subinterface ATM Subinterface
ATM
Major Interface
OCx/STMx
 Create ATM base profile:

erx8(config)#profile atm-pvc-info
erx8(config-profile)#atm pvc aal5snap 1000 1000 1
erx8(config-profile)#atm atm1483 description dynamic-sub
 Configure ATM major interface:
erx8(config-if)#atm bulk-config range12 vc-range 1 2 33 512
erx8(config-if)#profile atm1483 bulk-config-name range12
atm-pvc-info
erx8(config-if)#auto-configure atm1483
Creating ATM Base Profile

To dynamically create ATM subinterfaces, you must create a profile, assign the profile, and allow
dynamic subinterface creation. For ATM subinterfaces, the ATM base profile contains common ATM
subinterface and PVC parameters such as the encapsulation method, traffic management parameters,
and descriptions. ATM base profiles can also reference an ATM VC class.
Configuring ATM Major Interface
Once the ATM base profile is created, you must statically configure the ATM major interface and use
two new commands to support dynamic subinterface creation. First, you must specify the range of
valid ATM VPIs and VCIs expected on the major interface using the atm bulk-config command. You
assign a name to this range of VPI/ VCIs, which will be referenced by the profile atm1483 bulk-config
command. In this example, the bulk configuration name rangel2 refers to the ranges VPI 1VCI 33-512
and VPI 2 VCIs 33-512. It is possible to configure more than one range with this command. Next, you
assign the ATM base profile using the profile atm1483 bulk-config-name command, referencing the
VPI/VCI range name as well as the ATM base profile name. Finally, you allow automatic ATM
subinterface creation using the auto-configure atm1483 command.

Building an Entire Dynamic Interface Column

 Nested profiles for PPPoA and PPPoE: Macro@
isp2.com
− Using previously configured PPPoA and PPPoE profiles IP

Interface
erx8(config)#profile atm-PPPoX PPP

erx8(config-profile)#atm pvc aal5snap 1000 1000 1 CompanyXYZ@ Interface
isp1.com
erx8(config-profile)#atm atm1483 profile ppp biz-user
IP PPPoE
erx8(config-profile)#atm atm1483 auto-configure ppp Interface Subint
erx8(config-profile)#atm atm1483 profile pppoe res-user
erx8(config-profile)#atm atm1483 auto-configure ppppe PPP PPPoE
Interface Major Int
ATM PVC ATM PVC
ATM Sub ATM Sub
erx8(config-if)#atm bulk-conf range34 vc-range 3 4 33 1000
ATM
erx8(config-if)#profile atm1483 bulk-conf range34 atm-PPPoX Major Int
erx8(config-if)#auto-config atm1483
OCx/STMx
Nested Profiles for PPPoA and PPPoE

Using the concept of nested profiles, you can create an entire dynamic interface column. Earlier in the
chapter, we created two profiles—biz-user and res-user. These profiles contained common
configuration information for PPPoA and PPPoE users, respectively. When you create the ATM base
profile, you can use the atm atm1483 profile command to specify supported protocols and reference
the profile containing the common upper-layer protocol configuration information. You then allow the
dynamic creation of these upper-layer interfaces using the atm atm1483 auto-configure command.
This example supports PPPoA or PPPoE interfaces over the dynamically created ATM subinterface.
Notice that the nested profile configuration is in the ATM base profile. You reference this profile at the
ATM major interface level.

Dynamic S-VLAN Subinterfaces

Create VLAN base profile: Ryan@
isp1.com
Mark@
isp2.com
erx8(config)#profile vlan-info
IP IP
erx8(config-profile)#svlan ethertype 88a8 Interface Interface
erx8(config-profile)#vlan profile pppoe pppoe-info
PPP PPP
erx8(config-profile)#vlan auto-configure pppoe Interface Interface
Configure VLAN major interface: PPPoE PPPoE

erx8(config)#interface gigabitEthernet 5/0 Subint Subint
erx8(config-if)#encapsulation vlan PPPoE

erx8(config-if)#vlan bulk-config range1 svlan-range 2 3 100 Major
999 Int
erx8(config-if)#profile vlan bulk -config rangel vlan-info VLAN
erx8(config-if)#auto-configure vlan Sub Int
−Router examines received packet for a VLAN ID or a VLAN

double-tagged S-VLAN ID Major Int
−Router builds interface column using VLAN bulk GE/10GE

configuration profile information
−Dynamic VLAN subinterfaces are persistent
Creating VLAN Base Profile

To dynamically create VLAN subinterfaces, whether it be S-VLANs or VLANs, you must create a base profile, assign the
profile, and allow dynamic subinterface creation. For any VLAN subinterface, the VLAN base profile contains common VLAN
configuration parameters such as the S-VLAN Ethertype. The VLAN base profile also includes nested profile statements for
PPPoE or IPoE interfaces as well as nested auto-configure commands for the appropriate upper-layer interfaces.
Configuring VLAN Major Interface
Once the VLAN base profile is created, you must statically configure the VLAN major interface and use two new commands to
support dynamic subinterface creation. First, you must specify the range of valid VLAN IDs or double-tagged S-VLAN IDs
expected on the major interface using the vlan bulk-config command. You assign a name to this range of VLAN IDs, which will
be referenced by the profile vlan bulk-config command. In this example, the bulk configuration name ran gel refers to the
double-tagged S-VLAN IDs 2-3 with VLAN IDs 100-199. It is possible to configure more than one range with this command.
Next, you assign the VLAN base profile using the profile vlan bulk-config-name command, referencing the VLAN ID range
name as well as the VLAN base profile name. Finally, you allow automatic VLAN subinterface creation using the auto-configure
vlan command.
When the router receives a packet, it examines the packet for a VLAN ID or a double-tagged S-VLAN ID. You can also
configure the router to further examine the packet for agent-circuit-identifier information. This configuration is discussed later in
the chapter. Based on these values and the configuration data in the profiles, the router creates all dynamic layers above the
VLAN major interface, starting with the lowest dynamic layer. In this example, the router first creates the dynamic S-VLAN
subinterface, then the PPPoE major interface followed by the PPPoE subinterface, the PPP interface, and finally the IP
interface.
If any layer of the dynamic portion of the interface column fail s to be created, interface creation fails and the connection is
denied. The router destroys all dynamic layers above the VLAN subinterface, starting with the highest dynamic layer. Note that
the dynamic VLAN subinterface is not destroyed; it is persistent. Once a dynamic VLAN subinterface is dynamically created, it
cannot be destroyed unless the operational state changes to down . You can change the state of the subinterface to down
using the shutdown command. Take care when performing this function, and verify that you are destroying the proper VLAN
subinterface. If the Ethernet interface is shut down, all dynamic VLAN subinterfaces are destroyed.

Agent-circuit-identifier VLANs
 Bulk configuration of S-VLAN subinterfaces using
agent-circuit-identifier:
−Double-tagged S-VLANs uniquely identify each subscriber
−Direct Ethernet connectivity or N:1 VLAN single-tagged VLANs
might not uniquely identify each subscriber
−Identify user using agent-circuit-identifier in PPPoE or DHCP
control messages instead of double-tagged S-VLAN ID
−Identifies the subscriber's DSLAM and the DSL line on the
DSLAM
−agent-circuit-identifier dynamic S-VLANs can coexist with
double-tagged S-VLANs
−For DHCP subscribers, DHCP local or external server must be
properly configured
Bulk Configuration Using agent-circuit-identifier

More and more networks are using Ethernet-based access networks instead of ATM access networks.
In this environment, DSLAMs are bridging the ATM/DSL local loop side with the Ethernet-based
access side. With this new environment, the router has only Ethernet connectivity to the subscribers.
In these Ethernet-based access networks, the router needs a way to uniquely identify each subscriber.
Many service providers are creating an ATM-like network by implementing the equivalent of a virtual
path and a virtual circuit by using stacked VLANs. For example, the provider could use the outer VLAN
or S-Tag to create a virtual path between each DSLAM and the router. Then, the provider can use the
inner VLAN ID or C-Tag to create a virtual circuit for each DSL line. The S-Tag or C-Tag uniquely
identifies each subscriber.
Unfortunately, some service providers do not want to implement VLANs or are using N:1 single-tagged
VLANs. With these approaches, it is difficult to uniquely identify each subscriber and subsequently
dynamically create a VLAN subinterface and offer subscriber based services.

Bulk Configuration using agent-circuit-identifier (contd.)
To overcome this problem, the E-series router can use subscriber loop identification or agent-circuit-
identifier information contained in DHCP and PPPoE signaling messages to create IP interfaces
associated with the same subscriber location over a common VLAN. For example, a home might have
a PC using PPPoE for data traffic and a set-top box using DHCP for multicast traffic. In this case, a
single S-VLAN interface must support both a PPPoE and IPoE interface. The agent-circuit-identifier
information is added by a device in between the subscriber and the E-series router such as a DSLAM
or a DHCP relay agent. It is similar to the NAS-Port-ID.
The agent-circuit-identifier is carried in the option 82 field of DHCP packets or in the DSL Forum VSA
26-1 of PPPoE PADR and PADI packets. The agent-circuit-identifier information identifies the
subscriber's DSLAM and the DSL line on the DSLAM. With double-tagged S-VLANs, a subscriber
location is identified by S-Tag/C-Tag. With agent-circuit-identifier S-VLANs, it is now identified by S-
Tag/agent-circuit-identifier. When configured to operate in this mode, the router examines untagged or
single-tagged packets for agent-circuit-identifier information. If it is found, the router then determines if
a VLAN subinterface exists using this information. If it does not, the router will dynamically build a S-
VLAN subinterface using the S-VLAN ID you identify and insert the agent-circuit-identifier information
for the VLAN ID. The agent-circuit-identifier might or might not be made up of printable characters. The
following capture shows an example of S-VLANs created using agent-circuit-identifier information.
erx8#show vlan subinterface
Ether Interface
Interface Status MTU Svlan Id Vlan Id Type Type
---------------------- -------- ---- -------- ------- ----- -------
FastEthernet 0/0.1 Up 1522 ---- 1 ---- Static
FastEthernet 4/0.1 Up 1522 2 ---- ---- Dynamic *
FastEthernet 4/0.2 Up 1522 2 ---- ---- Dynamic *
3 vlan subinterfaces found
* Created via agent circuit identifier
erx8#show vlan subinterface agent-circuit-identifier

Interface Svlan Id Agent-Circuit-Identifier
---------------------- ---------- -------------------------
FastEthernet 4/0.1 2 ---
FastEthernet 4/0.2 2 0200D0CB2729E5
The ability to dynamically create S-VLANs using agent-circuit-identifier information only affects
untagged or single-tagged packets containing the identifier. All double-tagged or untagged and single-
tagged packets that do not contain the identifier are unaffected. Therefore, double-tagged S-VLANs
and S-VLANs based on agent-circuit-identifier can coexist on the same interface.
In the case of DHCP, the E-series router must be configured as a DHCP local server or a DHCP
external server so that it can monitor the DHCP discover and address request messages. The DHCP
local or external server must be configured to dynamically create subscriber interfaces based on the
agent-circuit-identifier contain in the option 82 field of DHCP discover packets. We discuss dynamic
subscriber interfaces later in the chapter.

Agent-circuit-identifier VLAN Config

 Create VLAN base profile for PPPoE:
erx8(confiq)#profile aci-vlan
erx8(config-profile)#vlan profile pppoe pppoe-info
erx8(coxfig-profile)#vlan auto-configure pppoe
erx8(config-profile)#vlan auto-configure agent-circuit-
identifier
 Configure VLAN major interface:
erx8(confiq-if)#vlan bulk-config aciRange svlan-range 2 3
agent-circuit-identifier
erx8(config-if)#profile vlan bulk-config aciRange aci-vlan
erx8(config-if)#auto-configure vlan
Creating VLAN Base Profile for PPPoE

agent-circuit-identifier S-VLAN configuration is very similar to the previous bulk configuration example.
First create a profile containing characteristics for the dynamic upper-layer interface encapsulation
types to be created over the dynamic S-VLAN subinterfaces. In this example, we use a previously
created profile, pppoe- info. Create the VLAN base profile including auto-configure statements for the
upper-layer interface encapsulation types. Include the vlan auto-configure agent-circuit-identifier
command to enable autocreation of S-VLANs based on agent-circuit-identifier information. This
example only supports PPPoE interfaces. It is also possible to include IPoE configuration information
for DHCP subscribers.
Configuring VLAN Major Interface
Once the VLAN base profile is created, you must statically configure the VLAN major interface. In the
vlan bulk-config command, you only specify the S-VLAN ID range. Instead of the VLAN ID range, you
specify the keyword agent-circuit-identifier. Next, assign the VLAN base profile using the profile vlan
bulk-config-name command, referencing the VLAN ID range name as well as the VLAN base profile
name. Finally, you allow automatic VLAN subinterface creation using the auto-configure vlan
command.

Verifying Dynamic Subinterfaces

 Examine profile and interface configuration:
erx8#show [atm vlan] bulk-config
erx8#show profile name vlan-info
erx8#show profile name pppoe-info
erx8#show config interface gigabit 5/0
 Examine statistics and dynamic interface column information:
erx8#show atm subinterface atm 6/2/1/33
erx8#show pppoe interface atm 6/2/1/33
erx8#show ppp int atm 6/2.12.1 statistics
erx8#show ip interface atm 6/2.12.1
Examining Profile and Interface Configuration

To verify the bulk configuration, determine if the correct VPI/VCI or VLAN ID address ranges are
reserved. For ATM configurations, verify that the ATM base profile includes the appropriate
encapsulation method and any required traffic management parameters. If the profile includes nested
profile commands, examine the referenced profiles and verify that a PPP authentication method is
specified. Examine the ATM or VLAN major interface definition and make sure it includes the
appropriate
bulk-config, profile bulk-config-name, and auto-configure commands. Verify that the bulk configuration
name matches and that the appropriate ATM or VLAN base profile is referenced.
Examining Statistics and Dynamic Interface Column Information
Verify that the user's ATM or VLAN subinterface is transmitting and receiving frames. Depending on
the user's access method, examine PPP or PPPoE interface statistics as well as IP interface statistics.
Remember to use ping and traceroute to verify network connectivity.

Additional Bulk Configuration Information

 Additional bulk configuration information:
− Smaller configuration files
− Subinterface and VCD numbers automatically generated and usually
not the same
− Once created, bulk-configured ATM and VLAN subinterfaces remain
intact even if a user disconnects
− Interfaces support a mixture of static and bulk-configured
subinterfaces
− Add, modify. and remove bulk configuration subranges
− Assign an overriding profile to an ATM PVC or VLAN to assist in
troubleshooting
Additional Bulk Configuration Information

Dynamic ATM or VLAN bulk configuration results in smaller configuration files. When the ATM
subinterfaces are created, the router automatically generates the subinterface and VCD numbers.
These numbers are usually not the same. Once created, the ATM or VLAN subinterface remains intact
even if the user disconnects. In this case, the user's upper-layer interfaces are destroyed, but the ATM
or VLAN subinterface remains. The system assumes that this user will reconnect at some point in the
future. If the interface is oversubscribed, the ATM subinterface will be destroyed if another subinterface
requires the resources.
It is possible to mix static and bulk-configured ATM or VLAN subinterfaces on the interface. The static
subinterfaces can even have VPI/VCI or VLAN IDs that fall inside the bulk-configured ranges.
You can also add, remove, modify, disable, and enable VC and VLAN subranges within an existing
bulk-configured range.
If you have a specific ATM PVC or VLAN that is not operating properly, you can assign an overriding
profile to assist in troubleshooting. The overriding profile includes additional debugging attributes such
as PPPoE and PPP logging information. Once the problem is identified and fixed, remove the
overriding profile and shut down the specific subinterface to disable and delete the dynamic
subinterface. Once packets flow over the ATM or VLAN again, the subinterface will be recreated using
information from the original base profile.
For more information about the maximum number of VCs or VLANs that you can configure with the
bulk configuration commands per line module and per chassis, please review the JUNOSe Re/ease
Notes, Appendix A, System Maximums.


 Dynamic PPP-over-ATM and PPP-over-Ethernet Interfaces
 Dynamic Subscriber Interfaces
Dynamic Subscriber Interfaces


Dynamic Subscriber Interfaces

 Dynamic interface columns:
Subscriber Interface Subscriber Interface
− Typically PPP connections IP1 IP2
− Some type of RADIUS involvement
− Subdivide one interface into multiple Primary IP
Interface
subinterfaces
 Can we do the same with GE / FE
shared media connections?
− Dynamic subscriber interfaces (DSI)
− Subdivide a shared media connection into multiple
subinterfaces without using PPPoE
 Gigabit or Fast Ethernet
 Bridged Ethernet over ATM
− Triggered by external event
 IP address assignment using DHCP local server or DHCP external s erver
application
 Receipt of packet from access network without using DHCP or PPP
Dynamic Interface Columns

The previous slides discussed how the router builds dynamic interfaces on top of ATM and VLAN major
interfaces. These interfaces were built based on some external event. The previous discussion focused on PPP
or RADIUS traffic as the trigger for dynamic interface creation. We also saw that PPP over Ethernet provided a
way to further subdivide logical interfaces, such as ATM PVCs or VLANs, providing better scaling.
Creating Dynamic Interfaces Without RADIUS Involvement
In the next section, we discuss how to create dynamic interfaces in a shared media environment or an
environment that does not use PPP or RADIUS. We will see how we can take one shared media interface and
further subdivide it into multiple subinterfaces without the use of PPP over Ethernet. For example, one Gigabit
Ethernet interface might provide network connectivity for thousands of users. Unfortunately, this configuration will
not scale well if you try to configure policies for each user. Dividing the Ethernet interface into multiple logical
interfaces, otherwise known as dynamic subscriber interfaces (DSIs), provides a way to scale this type of
configuration. A bridged Ethernet-over-ATM interface is another shared media connection that could use DSIs.
Dynamic subscriber interface creation is also triggered by an external event.
In a DHCP environment, DHCP clients typically use some type of shared media interface, such as Gigabit
Ethernet or an ATM PVC running bridged Ethernet. When a DHCP client accepts an offer from a DHCP server, a
dynamic subscriber interface is created for that one client. To support dynamic subscriber interface creation, the
E-series router must be running either the DHCP local server or the DHCP external server application.
The router can also be configured to build a DSI on the receipt of a packet from the access network without using
DHCP or PPP. Packet detection DSI creation is the only way to build DSIs on GRE tunnel interfaces. You cannot
use the DHCP local or external server application. Packet detection DSI creation could also be used for a
workstation that has a statically configured IP address or obtained an IP address from a different DHCP server,
although this is not as common.

Creating Dynamic Subscriber Interfaces

erx7#show ip demux int fast 3/0 Subscriber Interface
Subscriber Interface
Prefix/Length SA/DA Subsriber -Intf VR/VRF Descr
ip192.168.100.9 ip192.168.100.910
192.168.100.9/32 SA ip192.168.100.9 default *
192.168.100.10/32 SA ip192.168.100.10 default *
Note: Entries with * are dynamic (dhcp) entries
Primary IP
Interface
 DSI creation process using DHCP:
− Client’s DHCP discover received on
GE / FE
primary IP interface
− DHCP server offers IP address to client
− DHCP client accepts offer and sends DHCP request
− Dynamic subscriber interface created, host route installed, and
entry added to source address demux table
− Traffic to and from client uses new DSI
 DSI creation process using trigger packet:
− Packet received on primary IP interface
− Examine interface source address demux table using packet’s IP
source address
− If no match, create DSI, install host route, and add entry to source
address demux table
DSI Creation Process Using DHCP

In this example, DHCP clients reside off an Ethernet interface on the router. DHCP clients initially send
DHCP discover packets, which the router receives on the primary IP interface. The DHCP server offers
an IP address to the client. The DHCP ciient accepts an offer and responds with a DHCP request.
Once the DHCP request is received, the router creates the user's DSI, installs a host route, and adds
an entry to primary IP interface's source address demux table. This table maps a specific IP address to
a specific subscriber interface on that primary interface. This DSI creation process requires that the E-
series router either operate as a local DHCP server or run the DHCP external server application.
DSI Creation Process Using a Trigger Packet
In this environment, client workstations either do not run DHCP or have already obtained an IP
address from a DHCP server not associated with the E-series router. When a packet is received on a
primary IP interface, the router first examines the source address demux table. If there is no match in
the table, the router creates a DSI, installs the host route, and adds an entry to source address demux
table.

Configuring Dynamic Subscriber Interfaces

 Simple DSI configuration using DHCP:
−DHCP local server already configured
erx7(config)#inteface gigabitEthernet 5/0
erx7(config-profile)#ip unnumbered loopback 100
erx7(config-profile)#ip auto-configure ip-subscriber
 Simple DSI configuration using trigger packet:
erx7(config)#inteface gigabitEthernet 5/0
erx7(config-profile)#ip unnumbered loopback 0
erx7(config-profile)#ip auto-configure ip-subscriber
erx7(config-profile)#ip auto-detect ip-subscriber
 Managing dynamic subscriber interfaces:
erx7#show ip demux interface gigabit 5/0
erx7#show ip interface ip 192.168.100.10
erx7#show ip dhcp-local binding interface gigabit 5/0
Simple DSI Configuration Using DHCP

Both examples on this slides show a very simple dynamic subscriber interface configuration. The first example
assumes the DHCP local server application is already configured. For the interfaces with DHCP clients, first
configure the primary IP interface. Next, use the command ip auto-configure ip-subscriber. This command tells
the router to automatically configure DSIs whenever an IP address is requested or accepted by the DHCP client.
If you are using the local DHCP server in standalone mode, the dynamic subscriber interfaces will be created in
the virtual router where the primary IP interface resides. If you are using the local DHCP server in equal-access
mode, the SDX system can pass back specific virtual router configuration information.
Simple DSI Configuration Using a Trigger Packet
The second simple example assumes the client workstation obtained its IP address from a different source. There
is no DHCP involvement on the router. For these interfaces, first configure the primary IP interface. Next, use the
commands ip auto-configure ip-subscriber and ip auto-detect ip-subscriber.
These commands tell the router to automatically configure DSIs whenever there is a miss on the primary IP
interface's source address demux table. When the router boots, the primary IP address's source address demux
table will be empty. As packets arrive on the primary interface, entries are added and DSIs are created.
These are two simple DSI configurations. It is also possible to create more complex configurations, such as only
creating DSIs for specific IP address ranges, applying rate limits to the DSIs, or performing additional RADIUS
authorization to obtain additional configuration information. These complex scenarios are beyond the scope of
this class.
Managing Dynamic Subscriber Interfaces
The commands listed on the slide display the contents of the demux table, dynamic subscriber interface IP
statistics, and the DHCP local server address bindings table.

Review Questions
1. How is a dynamic interface created?
2. What is the purpose of a profile?
3. When would you specify multiple auto-configure
commands?
4. What command facilitates dynamic interface creation in a IP-
over-ATM or bridged Ethernet environment?
5. How do you configure the router to create dynamic ATM
subinterfaces?
6. What triggers the creation of a dynamic subscriber
interface?

• The dynamic interface creation process;
• Configuring the E-series router to support dynamic interface detection and creation;
• Bridged Ethernet and IP-over-ATM dynamic interface creation;
• Dynamic ATM subinterface creation; and
• Dynamic subscriber interface creation.

Lab 5: Configuring PPP over Ethernet and

Dynamic Interfaces
Lab Objectives:
Configure and troubleshoot dynamic interfaces.
Lab 5: Configuring Dynamic Interfaces


Questions


Module 6: L2TP

Module Objectives
to:
– Describe the two common L2TP applications
– Explain the basic life of a packet in an L2TP environment
– Configure the E-series router as a LAC and an LNS
– Compare and contrast different tunnel failover and tunnel
selection methods
– Verify L2TP operation using show commands and logging

• Two common L2TP applications;
• The life of a packet in a Layer 2 Tunneling Protocol (L2TP) environment;
• The E-series router configuration for a LAC and an LNS;
• The different tunnel failover and selection methods; and
• Verifying L2TP operation using show commands and logging.
Module 6: L2TP 6-2

Agenda: L2TP
 L2TP Overview
 L2TP Operation
 E-series Router L2TP Configuration
 L2TP Tunnel Failover and Tunnel Selection
 E-series Router Requirements
 Troubleshooting L2TP
L2TP Overview
Module 6: L2TP 6-3

PPP-over-X Termination Points

RADIUS
Modem IP
tyler default
ISP1
@isp1.com PPP
DSL IP
IP Core
Router
isp2
home1 PPP ISP2
@isp2.com RADIUS
 Termination points:
– Layer 2 connection between user and B-RAS
– PPP session terminated on the B-RAS
– Local or remote RADIUS server provides authentication
– User’s IP interface created on the B-RAS
– User’s IP packets routed into the core
Termination Points
With a traditional remote access connection, a user establishes a connection to a network access
server, such as the E-series router, using some type of Layer 2 access method such as ATM or
Ethernet. Over this Layer 2 connection, the user runs PPP, is authenticated using either a local or
remote RADIUS server, and establishes IP connectivity into the network. In this environment, the Layer
2 connection and the PPP session terminate on the same device, the E-series router. This edge router
manages the user's associated IP interface and routes the user's traffic into the core network.
Module 6: L2TP 6-4

L2TP Termination Points

RADIUS
Modem IP
tyler ISP1
@isp1.com PPP RADIUS
IP Core
DSL IP
Router
home1 PPP ISP2

@isp2.com RADIUS
 L2TP is a client/server protocol that allows PPP to be

tunneled across a network
– Layer 2 connection between user and B-RAS
– PPP session terminated at remote location
– Local or remote RADIUS server provides authentication
– User’s IP interface terminated at remote location
– IP core routes L2TP-encapsulated packets
Using L2TP
L2TP extends the traditional PPP model by allowing the physical or Layer 2 termination point and the
PPP termination point to occur on different devices. L2TP is a client/server protocol that allows PPP to
be tunneled across a network. RFC 2661 describes and defines L2TP. With L2TP, a user still has a
Layer 2 connection to the access concentrator. The PPP connection, however, is now terminated at a
remote location. A local or remote RADIUS server provides authentication and accounting services. In
this environment, the remote device manages the user's associated IP interface and routes the user's
IP traffic to the appropriate network. The edge device or access concentrator only processes PPP
frames from the user; it has no visibility into the IP portion of the user's packets. From a user's
perspective, there is no functional difference between having the PPP session terminate on the edge
device or at a remote location using L2TP.
Module 6: L2TP 6-5

L2TP Components
RADIUS
Modem IP
tyler LNS ISP1
LAC L2TP Tunnels
DSL IP
LNS ISP2
Router
home1 PPP
@isp2.com RADIUS
 LAC:
– Physical or Layer 2 link termination
– Located at the ISP’s point of presence
– Initiates L2TP tunnel and session
 LNS:
– Located at the tunnel termination point
– Same provider, different provider, or customer site
– Terminates the PPP session
– Manages the user’s IP interface
L2TP Access Concentrator

With L2TP, a tunnel is created between an L2TP access concentrator (LAC) and an L2TP network
server (LNS). The LAC is an access or concentrator device (in this case, the E-series router) located
within the access provider's network. It terminates the physical and Layer 2 connection and initially
processes the user's PPP frames to determine if the PPP session will be terminated or tunneled using
L2TP. If the session is to be tunneled, the LAC initiates the tunnel, if necessary, and initiates the L2TP
session on behalf of the user. The E-series router can act a LAC without requiring additional hardware.
L2TP Network Server
The L2TP network server (LNS) is a router or similar edge device that terminates the L2TP tunnel. It
can be located within the provider's network or in the customer's network. The LNS terminates the PPP
session and can also manage the user's associated IP interface. Within a single L2TP tunnel,
individual user sessions are multiplexed. Multiple tunnels can exist between the LAC and the LNS.
Module 6: L2TP 6-6

L2TP Applications: Wholesaling

RADIUS
Modem IP
tyler LNS ISP1
LAC L2TP Tunnels
DSL IP
LNS ISP2
Router
home1 PPP
@isp2.com RADIUS
 B-RAS wholesaling model:

– Access service provider owns last mile
– Hands off PPP session to different ISPs
B-RAS Wholesaling Model

One of L2TP's typical applications is in the wholesaling environment. In this environment, an
incumbent local-exchange carrier (ILEC) or access service provider (ASP) has built out a dial, xDSL,
or metro-Ethernet infrastructure in the local area and has excess capacity. This last-mile provider
might want to sell off a portion of its capacity to a nationwide Internet service provider (ISP). The
advantage to the ISP is that it does not have to build out new infrastructure to service limited user
requirements nor does it have to share its subscriber data. The advantage to the ASP is that it
generates revenue on what would normally be idle equipment. Using L2TP, the ASP's LAC initiates an
L2TP tunnel to the ISP's LNS and hands off the user's PPP session to the appropriate ISP.
Module 6: L2TP 6-7

L2TP Applications: Virtual Private Networks

RADIUS RADIUS
Company A
jen@CompanyA.com IP Core Headquarters
LNS
dave@CompanyA.com
LAC
LNS
Company B
Remote Offices RADIUS
Company B Headquarters
 Virtual private network characteristics:

– Private network consisting of two or more sites connected via a
public network
– Traditional remote access backhaul
– Remote network outsourcing
Virtual Private Networks

A virtual private network (VPN) is a private network consisting of two or more sites connected via a
public network. Applications for VPNs vary widely in their network requirements; networks require a
network device, such as the E-series router, that is flexible enough to serve very different VPN
environments. Some examples of possible VPN applications include:
• Large corporate network outsourcing: A VPN can connect large or global corporations with
thousands of branch offices. VPNs of this scale are likely to have thousands of routes and
require redundant links and fast convergence times to prevent network down time.
• Small corporate network outsourcing: A VPN can connect as few as two sites. VPNs of this
scale are likely to have few routes. These VPNs must be designed to meet the customer's
needs with minimal resource usage.
• Traditional remote access backhaul: Some VPNs are implemented by remote sites that
tunnel back to a central site.
You can use L2TP to address some of the challenges of providing corporate network access to remote
users. Instead of dialing into a RAS located on the customer premises, the remote user dials into an
ISP's local POP. The ISP then provides connectivity across the Internet to the customer premises
using L2TP. To end users, the tunnel setup is transparent; what they see is the same as if they had
dialed into a remote access server connected directly to the enterprise network. User data is
encapsulated in L2TP headers and routed across the Internet using standard IP routing.
Module 6: L2TP 6-8

Agenda: L2TP
 L2TP Overview
 L2TP Operation
L2TP Operation
Module 6: L2TP 6-9

L2TP Life of a Packet

RADIUS
jen@isp2.com IP Core RADIUS

ISP2
LNS
dave@isp2.com
1.1.1.2
LAC
2.2.2.2
Server
DA IP=2.2.2.2 DA IP=2.2.2.2 DA IP=2.2.2.2

SA IP=1.1.1.2 SA IP=1.1.1.2 SA IP=1.1.1.2
PPP Header PPP Header Data Link
Encapsulation
ATM Header L2TP Header
RFC 2684 Tunnel ID Physical
VPI/VCI Session ID
Physical UDP
DA IP LNS
SA IP LAC
Data Link
Encapsulation
Physical
Life of a Packet
On this slide, the user is using PPP over ATM to establish the connection. The user's IP datagrams are
first encapsulated into a PPP frame. Next, the PPP frame is fragmented into 53-byte ATM cells and
sent over the appropriate ATM interface using RFC 2364 encapsulation. These cells are then
transmitted across the POTS connection, to the DSLAM, across the ATM switch (if necessary), and
are received by the LAC. In this case, the LAC is an E-series router.
During the authentication process, the LAC determines that the PPP session will to be tunneled using
L2TP. The LAC establishes a new tunnel (if necessary) and a new session to the appropriate LNS.
The LAC encapsulates the user's IP-over-PPP frames using L2TP and adds a new IP header to the
packet. In this new header, the destination IP address is the LNS and the source IP address is the
LAC. Based on the new destination IP address, the LAC routes the packet into the core using the
appropriate data link layer encapsulation. Note that the LAC never examined the user's IP datagram.
When the LNS receives the packet, it strips off the new IP header and the L2TP header, and
terminates the PPP session. It then examines the destination IP address of the user's datagram and
routes it to the appropriate location. In this example, only the LNS examined the user's IP datagram,
not the LAC.
Module 6: L2TP 6-10

PPP Session Initiation

RADIUS
RADIUS
LNS
LNS ISP2
erx1
dave@isp2.com LAC
LAC lo0=33.33.33.1
LCP ConfReq erx3
erx3
lo0=3.3.3.1
LCP ConfReq
LCP ConfAck
LCP ConfAck
Initial Authentication
 User initiates PPP connection to LAC

– LAC performs initial authentication and determines whether to:
 Terminate PPP session locally
 Tunnel PPP session to an LNS
– Tunnel attributes obtained:
 AAA domain map
 RADIUS
Session Initiation
The user initiates a PPP connection to the LAC. In the example on the slide, dave@isp2.com initiates
a PPP session to the LAC, which is an E-series router. The router performs the initial authentication
and determines whether to terminate the PPP session or tunnel the PPP session using L2TP. If the
session is to be tunneled, the router must determine several L2TP tunnel attributes, such as the IP
address of the LNS and the tunnel password, to initiate and build the L2TP tunnel and session.
The E-series router parses the user's login for the realm or domain name. In this example, the domain
name is isp2.com. The router looks for an entry of isp2.com in the configured domain map, which can
also include L2TP tunnel attributes. If the domain map includes L2TP tunnel attributes, the router
knows that all PPP sessions for this domain, that is, isp2.com, must be tunneled using L2TP.
If the domain map contains an entry for the domain in question but does not contain L2TP tunnel
attributes, the E-series router sends the authentication request to the appropriate virtual router's
RADIUS server. If the domain map does not contain an entry for the domain, the router sends the
authentication request to the RADIUS server configured in the default virtual router. You can also
configure the RADIUS server to return L2TP tunnel attributes for a particular realm or domain name.
Module 6: L2TP 6-11

L2TP Tunnel Establishment

RADIUS
L2TP Tunnel RADIUS

LNS ISP2
erx1
dave@isp2.com LAC lo0=33.33.33.1
erx3 Control Connection
lo0=3.3.3.1
Start Control Connection Request (SCCRQ)
Start Control Connection Reply (SCCRP)
Start Control Connection Connected (SCCCN)
Zero -Length Body (ZLB ACK)
Hello
Hello
The Control Connection

In the example on the slide, when the first session is initiated (dave@isp2.com), the tunnel is
established between the LAC and the LNS by creating the control connection. This control connection
is used to identify the peer and the peer's version number, and to assign tunnel IDs.
To establish the tunnel, the LAC sends a start control connection request (SCCRQ) to the LNS. The
SCCRQ contains the L2TP version, host name, and assigned tunnel ID. If a tunnel password is
configured, a CHAP challenge attribute value pair (AVP) field is also included.
The normal response by the LNS is the sending of a start control connection reply (SCCRP) message.
This message contains the L2TP version of the LNS, host name, and assigned tunnel ID on the LNS.
The tunnel IDs are locally significant and are communicated by LAC and LNS for mapping all
communications to each other over the control connection as well as the data sessions. If a tunnel
password is configured, a CHAP response AVP field is also included.
Assuming all is normal, the LAC responds with a start control connection connected (SCCCN)
message to the LNS as a positive acknowledgement, and the LNS responds with a zero-length body
message acknowledgement back to the LAC. At this point, the control connection and tunnel are
established.
To maintain the tunnel and control connection, the LAC and LNS send hello messages to each other. If
problems exist during the control connection setup sequence, either party can send a stop control
connection notification (StopCCN) message.
Module 6: L2TP 6-12

L2TP Session Establishment

RADIUS
L2TP Tunnel RADIUS

Session (dave@isp2.com) LNS
LNS ISP2
erx1
dave@isp2.com LAC
LAC lo0=33.33.33.1
1.1.1.2 erx3
lo0=3.3.3.1
lo0=3.3.3.1
Incoming Call Request (ICRQ)
Incoming Call Reply (ICRP)
Incoming Call Connected (ICCN)
Zero-Length Body ACK (ZLB)
User Authentication Completes
NCP IPCP Completes
Session Establishment
Once the tunnel is established, the data session for the remote user is created. The LAC accomplishes
this by sending an incoming call request (ICRQ) message to the LNS. The ICRQ message contains
the assigned session ID and call serial number for the proposed session. The LNS responds with an
incoming call reply (ICRP) containing its assigned session ID, which indicates success with the ICRQ
sent.
The LAC responds with an incoming call connected (ICCN) message to indicate acceptance of the
ICRP message sent by the LNS. Additionally, the LAC uses ICCN messages to convey authentication
information if proxy authentication is implemented. For example, this message might contain the CHAP
challenge, response, and success information. The user's authentication process completes, and the
user obtains an IP address using PPP's Network Control Protocol (NCP).
When a session terminates, the LAC sends a call disconnect notify (CDN) message. Either the LAC or
the LNS can use this message type to terminate a session.
Module 6: L2TP 6-13

Establishing Additional L2TP Sessions

RADIUS
jen@isp2.com
L2TP Tunnel RADIUS
Session (jen@isp2.com) LNS
LNS ISP2
erx1
dave@isp2.com
LCP ConfReq LAC
LAC lo0=33.33.33.1
1.1.1.2 erx3
LCP ConfReq lo0=3.3.3.1
lo0=3.3.3.1
LCP ConfAck
LCP ConfAck
Initial Authentication Incoming Call Request (ICRQ)
Incoming Call Reply (ICRP)
Incoming Call Connected (ICCN)

Zero-Length Body ACK (ZLB)
User Authentication Completes
NCP IPCP Completes
Open tunnel already exists―establish additional L2TP

sessions
Establishing Additional L2TP Sessions

Multiple sessions can exist within a tunnel. As shown on the slide, when Jen@isp2.com initiates a PPP
session with the E-series router, a tunnel is already open for that domain. The router simply
establishes an additional L2TP session with the LNS over the existing tunnel.
Module 6: L2TP 6-14

Agenda: L2TP
 L2TP Overview
 L2TP Operation
 E-series Router L2TP Configuration
E-series Router L2TP Configuration

Module 6: L2TP 6-15

LAC Configuration: User Interfaces

RADIUS
RADIUS
LNS
LNS ISP2
erx1
dave@isp2.com LAC
LAC lo0=33.33.33.1
1.1.1.2 erx3
erx3
lo0=3.3.3.1
 Configure static or dynamic PPP interfaces:

erx3(config)#profile pppinfo
erx3(config-profile)#ppp authentication chap
erx3(config-subif)#atm pvc 1 0 101 aal5autoconfig
erx3(config-subif)#profile ppp pppinfo
erx3(config-subif)#auto-configure ppp
 Why aren’t IP characteristics configured in the profile?
Configuring Static or Dynamic PPP-over-X Interfaces

In an L2TP environment, users initiate a PPP session to the LAC. On the E-series router, you must
configure static or dynamic PPP interfaces for these users. The example on the slide shows the
configuration for dynamic PPP-over-ATM interfaces.
Why Aren't IP Characteristics Configured in the Profile?
Remember that the LAC only manages the user's PPP interface. The LAC initiates user authentication
during PPP LCP negotiation. Once the LAC determines to tunnel the user's session, the LAC hands
the PPP session off to the LNS. The LNS completes the PPP session negotiation and most likely
manages the user's IP session. Because the user's IP interface will not be created on the LAC, the
profile definition only contains Layer 2 information.
Module 6: L2TP 6-16

LAC Configuration: Domain Map

RADIUS
RADIUS
LNS
LNS ISP2
erx1
dave@isp2.com LAC
LAC lo0=33.33.33.1
1.1.1.2 erx3
erx3
lo0=3.3.3.1
 Domain map:
erx3(config)#aaa domain-map isp2.com
erx3(config-domain-map)#tunnel 1
erx3(config-domain-map-tunnel)#address 33.33.33.1
erx3(config-domain-map-tunnel)#source-address 3.3.3.1
erx3(config-domain-map-tunnel)#client-name erx3
erx3(config-domain-map-tunnel)#server-name erx1
erx3(config-domain-map-tunnel)#identif erx3-primary-tunnel
erx3(config-domain-map-tunnel)#password training
Domain Map Configuration

One way the E-series router determines it should tunnel a PPP session is by examining the domain map. The
example on the slide shows a domain map configuration for ISP2. The LAC uses the following L2TP configuration
parameters specified in the domain map to establish the tunnel and control connection:
• Tunnel tag: On the E-series router, the tunnel tag is a mechanism that uniquely identifies a set of
tunnel attributes within the domain map. Each domain name supports up to 31 destinations or tunnel
tags, allowing for such things as rolling over to alternate servers.
• Address: The address parameter indicates the IP address of the LNS. In the example on the slide, the
IP address of the LNS is 33.33.33.1. We also refer to this attribute as the tunnel server endpoint, or
tunnel endpoint. Typically this IP address is a loopback address that is also configured as the LNS's
router ID.
• Source address: In the example on the slide, the IP address of the LAC is 3.3.3.1. We also refer to
this attribute as the tunnel source address or the tunnel client endpoint. Typically, this IP address is a
loopback address that is also configured as the LAC's router ID.
• Client name: This optional L2TP attribute identifies the name the LAC sends to the LNS to establish a
tunnel. Note that the client name and the LAC's hostname do not need to match. The client name
configured on the LAC must match the remote host name configured on the LNS. Some vendors'
LNSs use the LAC's hostname to identify multiple tunnels on a single LNS from different LACs.
• Server name: This optional L2TP tunnel attribute identifies the LNS's server name. Some vendors'
LAC's use the LNS hostname to identify multiple tunnels on a single LAC going to different LNSs. If
this parameter is configured, it must match the local host name configured on the LNS.
• Identification: On the LAC, the tunnel identification or tunnel assignment ID uniquely identifies an
L2TP tunnel between the LAC and the LNS. You can have multiple tunnels between a LAC and an
LNS. The tunnel ID distinguishes between these tunnels. You can also have different domains share a
tunnel, if you want. To have multiple domains use the same tunnel, configure the same tunnel ID for
both domains. The tunnel identification is locally significant to the LAC.
• Password: This password is a shared secret used for optional tunnel authentication and AVP hiding.
AVPs encode operational parameters, such as tunnel ID, over the L2TP control channel. The
authentication mechanism is CHAP-like and use the MD5 algorithm.
The E-series router only supports L2TP as the tunnel type and IPv4 as the tunnel media.
Module 6: L2TP 6-17

Tunnel Definitions Using RADIUS

RADIUS
RADIUS
LNS
LNS ISP2
erx1
dave@isp2.com LAC
LAC lo0=33.33.33.1
1.1.1.2 erx3
erx3
lo0=3.3.3.1
 RADIUS:
dave@isp2.com Password = “dave”
Framed-Protocol = PPP,
Service-Type = Framed-User,
Tunnel-Type=1:L2TP,
Tunnel-Medium-Type=1:IP,
Tunnel-Client-Endpoint=1:3.3.3.1,
Tunnel-Server-Endpoint=1:33.33.33.1,
Tunnel-Client-Auth-ID=1:erx3,
Tunnel-Assignment-ID=1:erx3-primary-tunnel
Tunnel-Password=1:training
The second and more common way the E-series router determines it should tunnel a PPP session is by obtaining
L2TP tunnel attributes from a centralized RADIUS server. The LAC uses the following L2TP configuration
parameters and standard RADIUS attributes to establish the tunnel and control connection. The "1:" notation on
the slide indicates a tagged RADIUS attribute.
• Framed Protocol: The framed protocol indicates that the user is using PPP as the Layer 2 protocol.
• Service type: This attribute indicates the service the B-RAS should provide to the user. In this case,
the B-RAS will provide a framed-user service, such as PPP.
• Tunnel type: Currently, the E-series router only supports L2TP as the tunnel type.
• Tunnel medium type: Currently, the E-series router only supports IPv4 as the tunnel medium.
• Tunnel client endpoint: In the example on the slide, the IP address of the LAC is 3.3.3.1. We also refer
to this attribute as the tunnel endpoint or tunnel source address. Typically, this IP address is a
loopback address that is also configured as the LAC's router ID.
• Tunnel server endpoint: In the example on the slide, the IP address of the LNS is 33.33.33.1. We also
refer to this attribute as the tunnel endpoint or tunnel destination address. Typically, this IP address is
a loopback address that is also configured as the LNS's router ID.
• Tunnel client auth ID: This optional L2TP attribute identifies the client name configured on the LAC. To
establish a tunnel, these two parameters must match. Some vendors' LNSs use the LACs hostname
to identify multiple tunnels on a single LNS from different LACs.
• Tunnel assignment ID: On the LAC, the tunnel identification or tunnel assignment ID uniquely
identifies an L2TP tunnel between the LAC and the LNS. You can have multiple tunnels between a
LAC and an LNS. The tunnel ID distinguishes between these tunnels. You can also have different
domains share a tunnel, if you want. To have multiple domains use the same tunnel, configure the
same tunnel ID for both domains. The tunnel identification is locally significant to the LAC.
• Tunnel password: This password is a shared secret used for optional tunnel authentication and AVP
hiding. AVPs encode operational parameters, such as tunnel ID, over the L2TP control channel. The
authentication mechanism is CHAP-like and use the MD5 algorithm.
Module 6: L2TP 6-18

LNS Configuration: Profiles

RADIUS
L2TP Tunnel RADIUS

LNS
LNS ISP2
erx1
dave@isp2.com LAC
LAC lo0=33.33.33.1
1.1.1.2 erx3
lo0=3.3.3.1 vr2
 Create a profile to support dynamic IP interface creation:

erx1(config)#profile isp2-info
erx1(config-profile)#ip virtual-router vr2
erx1(config-profile)#ip unnumbered loopback0
LNS Configuration: Profiles

The remote users' IP interfaces are built on and terminated at the LNS. To facilitate the dynamic
creation of these interfaces when an L2TP session is established, we must use a profile to define the
characteristics of the IP interface. This slide shows an example of the parameters and configuration
commands to build a profile for ISP2 interfaces. ISP2 user will use CHAP as the PPP authentication
method. The user's unnumbered IP interfaces will be created in the virtual router vr2 using vr2's
loopback 0 as a reference point.
Module 6: L2TP 6-19

LNS Configuration: Destination Profile

RADIUS
L2TP Tunnel
LNS
LNS RADIUS
erx1 ISP2
dave@isp2.com LAC
LAC lo0=33.33.33.1
1.1.1.2 erx3
lo0=3.3.3.1 vr2
 Create a specific L2TP destination profile:

erx1(config)#l2tp destination profile to-erx3-lac virtual-
router vr2 ip address 3.3.3.1
 Define a specific L2TP host profile:
erx1(config-l2tp-dest-profile)#remote host erx3
erx1(config-l2tp-dest-profile-host)#local ip address 33.33.33.1
erx1(config-l2tp-dest-profile-host)#local host erx1
erx1(config-l2tp-dest-profile-host)#profile isp2-info
erx1(config-l2tp-dest-profile-host)#tunnel password training
Creating an L2TP Destination Profile

Next, we must create an L2TP destination profile that identifies the location of the LAC. The destination
profile defines which LACs can communicate with the LNS based on the LAC's IP address and
hostname. In the slide, a LAC with the source address of 3.3.3.1 and hostname of erx3 can establish
an L2TP tunnel, and all tunnel traffic will occur in the virtual router, vr2.
Defining a Specific L2TP Host Profile
Within the destination profile, we define a L2TP host profile that identifies the attributes used by the
LNS when communicating with a LAC. The remote host name must match the client name the LAC
uses in its start control connection request message. The remote host defines the connection
parameters specific to LAC and LNS, specifically the tunnel password, the interface profile to be used
during dynamic interface creation, and the LNS's IP address. The configuration example on this slide
shows a very specific L2TP destination profile that can only be used with one specific LAC identified by
the LAC's IP address and hostname. It is also possible to configure more generic L2TP destination
profiles that can be used by multiple LACs.
Module 6: L2TP 6-20

What Parameters Must Match?

 LAC domain map or RADIUS definition:
Domain: erx3.com; router-name: default; ipv6- router-name: default
Tunnel Tunnel Tunnel Tunnel Tunnel Tunnel
Tag Peer Source Type Medium Password
------ ---------- ------- ------ ------ --------
1 33.33.33.1 3.3.3.1 l2tp ipv4 training
Tunnel Tunnel Tunnel
Tunnel Client Server Tunnel Max
Tag Tunnel Id Name Name Preference Sessions Tunnel RWS
------ ------------------- ------ ------ ---------- -------- -------------
1 erx3-primary- tunnel erx3 erx1 2000 0 system chooses
 LNS destination profile:

erx1#show l2tp destination profile to-erx3-lac
L2TP destination profile to-erx3-lac
Configuration
Destination address
Transport ipUdp
Virtual router erx3-lns
Peer address 3.3.3.1
Statistics
Destination profile current session count is 0
Host profile attributes
Remote host is erx3
Configuration
Tunnel password is training
Interface profile is erx3-pppip-info
Local host name is erx1
Local ip address is 33.33.33.1
Statistics
Current session count is 0
1 L2TP host profile found
LAC Domain Map Configuration

You can examine the LAC's domain map configuration using the show aaa domain CLI command.
LNS Destination Profile
You can examine the LNS's destination profile using the show 12tp destination profile profile-name CLI
command. The following LAC parameters must match the following LNS parameters:
LAC LNS
Tunnel peer Local IP address
Tunnel source Peer address
Tunnel password Tunnel password
Tunnel client name Remote host
Tunnel server name Local host name
Module 6: L2TP 6-21

Generic LNS Destination Profile

RADIUS
eural@isp2.com LAC
4.4.4.4
LNS
LNS RADIUS
erx1 ISP2
LAC
LAC lo0=33.33.33.1
dave@isp2.com
1.1.1.2
vr2
LAC
LAC
john@isp2.com
5.5.5.5
 Create generic L2TP destination profile:

erx1(config)#l2tp destination profile isp2 virtual-router vr2 ip
address 0.0.0.0
 Define generic L2TP host profile:

erx1(config-l2tp-dest-profile)#remote host default
erx1(config-l2tp-dest-profile-host)#local ip address 33.33.33.1
erx1(config-l2tp-dest-profile-host)#profile isp2-info
erx1(config-l2tp-dest-profile-host)#tunnel password training
Creating Generic L2TP Destination Profile

The configuration example on the previous slide identified each LAC by its IP address. Using this
approach, each LAC required a unique L2TP destination profile on the LNS. While this approach is
secure, it requires quite a bit of configuration. Each time a new LAC is added to the network, you must
configure a new L2TP destination profile on the LNS. A different approach is to configure a generic
L2TP destination profile. Instead of identifying an individual LAC by a specific IP address, you
configure the IP address
0.0.0.0, which means any LAC that can be reached via the specified virtual router is allowed to
communicate with the LNS.
Defining a Specific L2TP Host Profile
Within the generic destination profile, we define a generic L2TP host profile that identifies the attributes
used by the LNS when communicating with any LAC. Configure the remote host name of default
instead of specifying a specific host name.
Module 6: L2TP 6-22

User Authentication
RADIUS
Company A
jen@CompanyA.com Headquarters
LNS
LNS
LAC
LAC erx1
dave@CompanyA.com lo0=33.33.33.1
erx3
erx3
1.1.1.2 lo0=3.3.3.1
lo0=3.3.3.1
DSL
Router
LNS ISP2
home1@isp2.com
 LAC processing: RADIUS

– Initiates PPP user authentication
– Determines whether to tunnel or terminate PPP session
– Sends user authentication response to the LNS
 LNS processing:
– Receives user or proxy authentication response
– Determines if it should accept the response or restart the process
– By default, LNS does not use the proxy authentication data
– Proxy authentication allows LNS to accept the proxy data
erx1(config-l2tp-dest-profile-host)#enable proxy authenticate
LAC Processing
The LAC initiates user authentication. Once the LAC determines to tunnel the user's session, it hands
the PPP session off to the LNS. The LAC on the [-series router always sends the user authentication
response to the LNS. You cannot disable this functionality on the E-series router. This response or
proxy authentication data includes the username and password, or the username, CHAP challenge,
CHAP challenge ID, and the CHAP response.
LNS Processing
Once the LNS receives the proxy authentication response, the LNS can either accept the response
and authenticate the user, or the LNS can discard the response and restart the authentication process.
By default, the LNS on the [-series router always discards the proxy authentication response and
restarts the authentication process with the user. You can configure the LNS to accept and use the
proxy authentication data per L2TP destination remote host using the command enable proxy
authenticate.
Module 6: L2TP 6-23

Configuring Additional Tunnel Destinations

RADIUS
LNS
erx1
erx1
lo0=33.33.33.1
RADIUS
dave@isp2.com LAC
LAC ISP2
1.1.1.2 erx3
erx3
lo0=3.3.3.1 LNS
LNS
erx2
lo0=33.33.33.2
 Additional tunnel destinations:

erx3(config)#aaa domain isp2.com
erx3(config-domain-map-tunnel)#address 33.33.33.2
erx3(config-domain-map-tunnel)#source-address 3.3.3.1
erx3(config-domain-map-tunnel)#client-name erx3
erx3(config-domain-map-tunnel)#server-name erx2
erx3(config-domain-map-tunnel)#identif erx3-backup-tunnel
erx3(config-domain-map-tunnel)#password training
Additional L2TP Tunnel Destinations

If the LAC can connect to more than one LNS, you can configure additional tunnel destinations within
the domain map. Initially, we configured tunnel tag 1, identifying the tunnel going to erx1. This new
definition, tunnel tag 2, identifies a tunnel going to erx2.
Module 6: L2TP 6-24

Multiple L2TP Tunnel Destinations

Multiple tunnel tags:
Domain: isp2.com; router-name: default; ipv6-router-name: default

Tunnel Tunnel Tunnel Tunnel Tunnel Tunnel
Tag Peer Source Type Medium Password
------ ---------- ------- ------ ------ --------
1 33.33.33.1 3.3.3.1 l2tp ipv4 training
2 33.33.33.2 3.3.3.1 l2tp ipv4 training
Tunnel Tunnel Tunnel
Tunnel Client Server Tunnel Max
Tag Tunnel Id Name Name Preference Sessions
------ ---------------- ------ ------ ---------- --------
1 erx3-primary-tunnel erx3 erx1 2000 0
2 erx3-backup-tunnel erx3 erx2 2000 0
Tunnel
Tag Tunnel RWS
------ --------------
1 system chooses
2 system chooses
Multiple Tunnel Tags

The slide shows the domain map configuration of multiple tunnel destinations for isp2.com.
Module 6: L2TP 6-25

Agenda: L2TP
 L2TP Overview
 L2TP Operation
 L2TP Tunnel Failover and Tunnel Selection
L2TP Tunnel Failover and Tunnel Selection

Module 6: L2TP 6-26

L2TP Tunnel Selection at the LAC

RADIUS
LNS
erx1
erx1
ry ? lo0=33.33.33.1
prima
RADIUS
dave@isp2.com LAC
LAC ISP2
1.1.1.2 erx3
erx3
lo0=3.3.3.1 LNS
LNS
backup?
erx2
lo0=33.33.33.2
 Domain map configuration options:

– 31 tunnel destinations per domain
– Up to 8 levels of preference
– Up to 8 destinations per preference level
 Tunnel selection configuration options:
– Failover between preference levels
– Failover within a preference level
– Maximum number of sessions per tunnel
– Weighted load balancing
Domain Map Configuration

In an L2TP environment, the LAC can select a tunnel for a PPP session based on a number of
configuration parameters. In the domain map, you can configure up to 31 different tunnel destinations
or tunnel tags per domain. If you have more than one tunnel destination, you can configure up to eight
levels of preference. Preference is a number from 0-2000 and is the order in which the LAC attempts
to connect to the different tunnel endpoints configured for a domain. The lower the number, the more
likely that destination will be selected. Zero is the highest level of preference. You can configure up to
eight different destinations per preference level.
Tunnel Selection Configuration Options
Once the LAC determines that a PPP session should be tunneled, it selects a tunnel from a set of
destinations associated with either the PPP user's domain or the PPP user's tunnel attributes returned
from RADIUS. On the E-series router, there are four different configuration options available. The next
few slides discuss these four different options in greater detail.
Module 6: L2TP 6-27

Failover Between Preference Levels

Domain: isp1.com RADIUS LNS
Tunnel Server Tunnel erx1
pt
Tag Name Preference t te m LNS
1s t A pt
m erx2
1 erx1 100 t te
4t A
h
2 erx2 100 te mp t
2n At
d
3 erx1 200 LAC
4 erx2 200 erx3 LNS
LNS
5 erx4 200 3r d Att
emp t erx4
erx4
6 erx1 300
7 erx5 300 LNS
LNS
erx5
 Failover between preference levels:
– Default behavior: LAC selects one destination based on the highest
preference
 The numerically lowest value has the highest precedence
 Preference level configured in domain map or standard RADIUS attribute
– If preferences are the same, LAC randomly selects one from the group
– If connection attempt fails for that preference level:
 Destination for all preferences marked unreachable and not retried for 5 minutes
 No other destinations tried at that same preference level
 Router selects another reachable destination from the next lower preference level
 If all destinations marked unreachable, the LAC tries the destination that failed first
Failover Between Preference Levels

In an L2TP environment, the LAC can try to establish a tunnel for a PPP session based on a number of
configuration parameters. The default behavior is selecting a tunnel destination using a round-robin
tunnel selection method. With this method, the LAC selects a destination based on the highest
preference level. The numerically lowest precedence value has the highest precedence. You can
configure the preference level in the domain map or it can be returned as the standard RADIUS
attribute, Tunnel-Preference. If there are multiple destinations with the same preference level, the LAC
randomly selects one from the group. If the LAC fails to connect to the destination, that destination is
marked unreachable for 5 minutes at all preference levels as you can configure the same destination
with multiple preference levels. The LAC then moves to the next preference level and randomly selects
a reachable destination. If connection attempt fails, that destination is also marked unreachable for 5
minutes at all preference levels, and the process continues. Once the LAC makes an attempt at each
preference level, it repeats the process, selecting a destination at the highest preference level. If all
destinations at a preference level are marked unreachable, the LAC selects the destination that failed
first.
Module 6: L2TP 6-28

Failover Between Preference Levels (contd.)

In the example on the slide, the LAC randomly selects erxl as the first destination attempt. If the connection
attempt fails, the LAC marks erxl as unreachable at all preference levels and moves to the next preference level.
The LAC then randomly selects one of the remaining reachable destinations either erx2 or erx4. In this example,
the LAC attempts to connect to erx2. If this attempt fails, erx2 is marked as unreachable at all preference levels
and the LAC moves to the next preference level. At this point, preference level 300 only has one reachable
destination. The LAC attempts to connect to erx5. If this connection attempt fails, the LAC restarts the process at
the highest preference level. At preference level 100, both erxl and erx2 are marked as unreachable. At this point,
the LAC attempts to connect to erxl, the destination that first failed.
By default, when a destination becomes unavailable, L2TP locks out that destination for 5 minutes. After that time
period expires, L2TP automatically makes that destination available to the selection process even if it is still
unavailable. You can use several additional commands to manage and test the L2TP destination lockout process.
You can modify the lockout time using the 12tp destination lockout-timeout command. When the lockout timer
expires, the destination is immediately available.
You can also configure the router to automatically test the avai lability of the destination before it is unlocked by
enabling the 12tp destination lockout-test feature. For the test, L2TP must first obtain the necessary tunnel
parameters. Because a locked out destination retains any previously active tunnels until the tunnel destruct timer
expires, the tunnel contains the parameters necessary to perform the test. If no tunnels exist, L2TP must wait until
a new session requests the parameters for the locked out destination. If the test is successful, the destination is
automatically unlocked. In this case it is important to make sure the 12tp destruct-timeout value is larger than the
12tp destination lockout-timeout.
You can also manually unlock a destination by using the 12tp unlock destination command. This command
effectively ignores any time remaining in the existing lockout timeout as well as the lockout test, if configured. All
the L2TP destination lockout parameters are configured globally.
Module 6: L2TP 6-29

Failover Within a Preference Level

Tunnel Server Tunnel erx1
Tag Name Preference d t te
mpt LNS
2n A erx2
1 erx1 100
mpt
2 erx2 100 LAC 1st Atte
3 erx4 200
erx3 3rd Attempt
4 erx5 300 LNS
LNS
4 th At erx4
erx4
tempt
LNS
LNS
erx5
 Failover within a preference level:

erx3(config)#l2tp fail-over-within-preference
– LAC selects one destination based on the highest preference
– If preferences are the same, LAC randomly selects one destination
– If connection attempt fails for that destination level:
 Destination marked unreachable and not retried for 5 minutes
 LAC selects another reachable destination from the same preference level
 If all destinations at a preference level unreachable, LAC moves to the next
lower preference level and repeats the process
 If all destinations marked unreachable, LAC tries the destination that failed
first
Failover Within a Preference Level

You can configure the LAC to select a tunnel destination within a preference level. Again, this
preference level is configured in the domain map or using a standard RADIUS attribute. With this
method, the LAC selects a destination based on the highest preference level. If there are multiple
destinations with the same preference level, the LAC randomly selects one from the group. If the LAC
fails to connect to the destination, that destination is marked unreachable for 5 minutes. The LAC then
selects another destination at the same preference level. If that connection attempt fails, that
destination is also marked unreachable for 5 minutes. If all destinations at the same preference level
are unreachable, the LAC moves to the next lower preference level and repeats the process. If all
destinations are marked unreachable, the LAC attempts to connect to the destination that failed first.
In the example on the slide, the LAC randomly selects erx2 as the first destination attempt. If the
connection attempt fails, the LAC marks erx2 as unreachable and attempts to connect to erxl. If this
attempt fails, erxl is marked as unreachable and the LAC moves to the next preference level. The LAC
attempts to connect to erx4. If this attempt fails, erx4 is marked unreachable, and the LAC continues
the selection process.
Module 6: L2TP 6-30

Maximum Number of Sessions per Tunnel

Tunnel Server Tunnel Maximum erx1
s
Tag Name Preference Sessions s ion LNS
S es
1 erx1 100 100 1 00 erx2
2 erx2 100 200 ssions
LAC 200 S e
3 erx4 200 300
4 erx5 300 400 erx3 300 Sessions
LNS
LNS
400 S erx4
erx4
ession
s
LNS
LNS
erx5
 Maximum number of sessions:
erx3(config)#aaa domain isp1.com
erx3(config-domain-map-tunnel)#max-sessions 100
– Domain map or RADIUS VSA
– If selected tunnel session count < max-sessions, establish new
session
– If selected tunnel session count = max-sessions:
 LAC selects another tunnel from the same preference level
 LAC goes to the next lower preference level and repeats the process
 Maximum number of session processing independent from tunnel failover
scheme
Maximum Number of Sessions per Tunnel

At this point, the LAC might have multiple tunnels established for a given destination. You can also
configure the LAC to select a tunnel based on the number of active sessions using the maximum
number of sessions parameter. You can configure this parameter within a domain map or as a
RADIUS VSA. When a user initiates a session, the LAC randomly selects a tunnel from the highest
preference level and examines the tunnel's current session count. If the session count is less than the
configured maximum number of sessions, the LAC attempts to establish the session over the selected
tunnel. If the session count is greater than the configured maximum number of sessions, the LAC
randomly selects another tunnel within the same preference level or the next lower preference level
and repeats the process. The maximum number of session processing is independent from the tunnel
failover scheme as the tunnel is already established when sessions are initiated. The default value for
the maximum number of sessions is zero, which allows unlimited sessions in the tunnel.
Module 6: L2TP 6-31

Weighted Load Balancing

erx1
Tunnel Server Tunnel Maximum t 1
e igh LNS
Tag Name Pref Sessions Weight un ne l W erx2
T
1 erx1 100 500 1 t2
l W eigh
2 erx2 100 1000 2
LAC Tu nne
3 erx4 100 1500 3 Tunnel Weight 3
erx3 LNS
LNS
erx4
erx4
 Weighted load balancing:

erx3(config)#l2tp weighted-load-balancing
– LAC uses the maximum sessions parameter as a weight to select
among tunnels sharing the same preference level
– Tunnel with the largest maximum session value has the largest
weight
– Tunnel 3 would be selected three times as often as tunnel 1, and
tunnel 2 would be selected two times as often as tunnel 1
Weighted Load Balancing

You can also configure the LAC to select a tunnel for a PPP session using a weighted load-balancing
scheme. This scheme allows the operator to spread L2TP sessions across several tunnels based on
the respective weight applied to each tunnel. The weight of a given tunnel is proportional to its
maximum session limit and the maximum session limits of the other tunnels at the same preference
level. The tunnel with the largest maximum session value has the largest weight; the tunnel with the
next largest maximum session value has the next largest weight, down to the tunnel with the smallest
maximum session value that has the smallest weight.
The weight associated with a tunnel is used when choosing among multiple tunnels sharing the same
preference level. In the example on the slide there are three tunnels sharing the same preference level
of 100. Based on the maximum number of sessions parameter, tunnel 1 has a weight of 1, tunnel 2 has
a weight of 2 and tunnel 3 has a weight of 3. In this example, all three tunnels are considered
reachable. When trying to connect to the domain, tunnel 3 would be selected 3 times as often as tunnel
1, and tunnel 2 would be selected twice as often as tunnel 1.
In the event that a tunnel does not have a maximum session value configured, it would take on a value
equal to that of the largest defined maximum session value for a tunnel at the given preference level.
For example, if there are two tunnel definitions at the same preference level—one with a defined
maximum session value, the other without—the two tunnels would be treated as being equally
weighted. Note that the borrowed maximum session value would be used for weighting purposes only,
not to limit the number of sessions for that tunnel.
Module 6: L2TP 6-32

Tunnel Switching
RADIUS
RADIUS
ricardo@isp1.com LAC
LAC
7.7.1.2
LAC
LAC LNS LAC LNS isp1.com
peter@isp1.com
7.7.2.2
LAC
LAC
phil@isp1.com
7.7.3.2
 Tunnel switching:
erx3(config)#l2tp tunnel-switching
– Terminates tunnels from multiple LACs and forwards the sessions
through new L2TP tunnels
– Aids in L2TP tunnel scaling
Tunnel Switching
L2TP tunnel switching allows you to switch packets between one session terminating at an L2TP LNS
and another session originating at an L2TP LAC. What distinguishes a tunnel-switched LAC from a
conventional one is that there are two interface columns: one for the incoming session (LNS) and one
for the outgoing session (LAC). The router forwards traffic from the incoming session to the outgoing
session and vice versa. You can select tunnel switching on a per-chassis basis. By default, tunnel
switching is
disabled. This preserves current behavior and prevents inadvertent attempts to switch tunnels.
Module 6: L2TP 6-33

Agenda: L2TP
 L2TP Overview
 L2TP Operation
 E-series Router Requirements
E-series Router Requirements

Module 6: L2TP 6-34

LNS Hardware Requirements

 Dedicated tunnel-server port:
– Internal loopback interface
– Redirects egress packets back to ingress path
– Interface requires no explicit user configuration Tunnel services only,
no access services E320 platform: LM-4 + Service IOA
– ERX 310/7xx/14xx platforms: Service Module
 Shared tunnel-server port:
– Virtual port configured on specific access line modules
– Dedicate a portion of the line modules bandwidth to tunnel services
– E320 platform: LM-4 + several Ethernet, ATM, or POS IOAs ERX
310/1440 platforms: GE-2 and GE-HDE line modules
Dedicated Tunnel-Server Port

To act as an LNS, the E-series router requires either a dedicated tunnel-server port or a shared tunnel-server
port. A dedicated tunnel-server port contains an internal or virtual server port. This virtual port acts like an
interface that has been looped. The port redirects packets received on the egress forwarding controller back to
the ingress forwarding controller. This interface does not require any explicit user configuration. Dedicated server
ports only support tunnel services, such as LNS termination for L2TP as well as other IP tunnels such as Distance
Vector Multicast Routing Protocol (DVMRP) (otherwise known as IP-in-IP) and generic routing encapsulation
(GRE) tunnels. They do not support other access services.
The E320 router supports a dedicated tunnel-server port using a LM-4 paired with a Service 10A. The Service
10A does not have any ingress or egress ports. Instead, it allows the LM-4 to receive and transmit data to other
line modules. The Service 10A supports LNS termination for L2TP as well as DVMRP and GRE.
The Service Module (SM) provides the dedicated tunnel-server port for the ERX 310/ 7xx/14xx routers. Unlike
other line modules, Service Modules do not pair with I/O modules that contain ingress and egress ports. When
the router receives a tunneled packet, the router forwards the packet via the switch fabric to the SM. The SM
processes the packet and returns it to the switch fabric. Finally, the processed packet leaves the router via an
egress module. Like the Service 10A, the SM supports LNS termination, DVMRP, and GRE. In addition, it also
supports Network Address Translation (NAT) and firewall services, which, like GRE and DVMRP, require
separate licenses.
Shared Tunnel-Server Port
Shared tunnel-server ports are virtual ports that are always present on specific line modules that provide both
tunnel services and access services. You can configure this shared tunnel-server port to use a portion of the
module's bandwidth to provide tunnel services. Shared tunnel-server ports are well suited to environments
requiring limited tunnel-server processing needs. Like dedicated tunnel-server ports, shared tunnel-server ports
support LNS termination for L2TP, DVMRP, and GRE.
The E320 router supports shared tunnel-server ports on a LM-4 paired with specific GE-4, GE-8, 10GE,
OCx/STMx ATM and POS IOAs. See the E-series Routing Platform E320 Module Guide for more detailed
information.
The ERX 310 and 1440 routers support shared tunnel-server ports on GE-2 and GE-HDE line modules.
Module 6: L2TP 6-35

Shared Tunnel-Server Port Configuration

 Configuring shared tunnel-server ports:
E320(config)#tunnel-server 5/2/0
E320(config-tunnel-server)#max-interfaces 4000
E320(config)#do show tunnel-server config
Server Ports
--------------
Card Provisioned
Port Type MaximumInterfaces Interfaces HwPresent
---------- ------ ----------------- ---------- ---------
Port 5/2/0 shared 8000 4000 yes
Configuring Shared Tunnel-Server Ports

By default, shared tunnel-server ports do not have any tunnel service interfaces configured or
provisioned. You must manually provision tunnel service interfaces using the max-interfaces
command. On the E320 router, shared tunnel-server ports reside on a virtual adapter that is identified
in the software as adapter 2. This slide shows the configuration of a shared tunnel-server port on an
E320 router.
Module 6: L2TP 6-36

LAC Hardware Requirements

 LAC:
– No additional hardware required for standard LAC configuration
– IP reassembly requires:
 Dedicated tunnel-server port on Service Module or Service 10A
 Shared tunnel-server port on line modules providing tunnel services in addition to
access services
– See the E-series Routing Platform E320 Module Guide or E-series
Routing Platform ERX Module Guide notes for specific line module
information
LAC Hardware Requirements

The E-series router does not require any additional hardware to operate as a standard LAC. Please
review the E-series Routing Platform E320 Module Guide and the E-series Routing Platform ERX
Module Guide for LAC support on specific line modules. If the LAC is also performing IP reassembly, a
dedicated or shared tunnel-server port is required. This concept is discussed later in the chapter.
Module 6: L2TP 6-37

Typical Line Module Processing

Egress FC Ingress FC
Ingress Egress
Line Switch
Line Traffic
Traffic Fabric
Module Module
to
from Ingress FC Egress FC Destination
User
User IP User IP User IP

Layer 2 Tagged Layer 2
PPP with Frame
Frame Outgoing IF
 Typical line module packet processing:

– Layer 2 encapsulation stripped leaving the user’s IP packet
– IP route lookup using user’s destination IP address
– IP packet tagged with outgoing interface and sent across switch
fabric to egress line module
– Egress line module encapsulates IP packet with appropriate
Layer 2 framing
Typical Line Module Packet Processing

On an E-series router, line modules are responsible for packet forwarding. Every line module has an
ingress forwarding controller (FC) and an egress forwarding controller. In the E-series router
architecture, ingress FCs always transmit packets across the switch fabric, and egress FCs receive
packets from the switch fabric. When a packet arrives on an interface, the ingress processor strips the
Layer 2 encapsulation, examines the destination IP address, and determines the egress line module
and outgoing interface. It then tags the user's IP packet with this outgoing interface information and
sends it across the switch fabric to the egress FC or line module for Layer 2 encapsulation.
Module 6: L2TP 6-38

Line Module Processing on the LAC

Ingress Egress
Line Switch
Line Traffic
Traffic Fabric
Module Module
to
from Ingress FC Egress FC LNS
User
User IP/PPP User IP/PPP User IP/PPP

Layer 2 Tagged L2TP header
Frame with L2TP IP/UDP
Session ID Layer 2
 LAC processing:
– Layer 2 encapsulation stripped, leaving the user’s IP/PPP packet
– Client’s PPP interface identifies session and tunnel ID, which is
mapped to the tunnel destination IP address
– IP route lookup using tunnel destination IP address
– IP/PPP packet tagged with session ID and outgoing interface and
sent across switch fabric to egress line module
– Egress line module encapsulates packet with the tunnel’s
IP/PPP/L2TP headers and the Layer 2 encapsulation
LAC Processing
L2TP-encapsulated packets require a bit more processing due to the extra encapsulation. The next
few slides discuss the life of a packet traveling from a user through the LAC and arriving at the LNS.
When a user's IP/PPP packet arrives on the LAC's interface, the ingress processor strips the Layer 2
encapsulation, leaving the user's IP/PPP encapsulated frame. Remember that the user's interface
column on the LAC only includes PPP, not IP. The user's PPP interface on the LAC identifies the L2TP
session and tunnel ID, which is then mapped to the tunnel destination IP address. The ingress
processor does a route lookup on this destination IP address, which, in this case, is the tunnel
endpoint—not the user's destination IP address—to determine the egress line module and outgoing
interface. The ingress line module tags the user's IP/PPP packet with the session ID and outgoing
interface and sends the packet across the switch fabric to the egress line module. The egress
processor then adds the IP/UDP/L2TP headers to the user's IP/PPP packet and encapsulates this with
the appropriate Layer 2 framing.
Module 6: L2TP 6-39

Ingress Line Module Processing at the LNS

Service Module
Ing ress
Egress
Traffic Ingress Egress
from Line Switch Switch
Line
User Fabric Fabric
Module Module
via User’s
Ingress FC Egress FC Destination
LAC
User IP/PPP User IP/PPP

L2TP header L2TP/IP/UDP
L2TP IP/UDP Tagged with
Layer 2 Session ID
 L2TP-encapsulated packet processing on ingress line

module at LNS:
– Layer 2 encapsulation stripped, leaving the user’s
IP/UDP/L2TP-encapsulated IP/PPP packet
– IP route lookup using IP address in L2TP encapsulation
– Destination IP address local to LNS and UDP port = 1701
– Obtain L2TP session ID
– L2TP-encapsulated IP/PPP frame tagged with session ID and sent
across switch fabric to service module
L2TP-Encapsulated Packet Processing on Ingress Line Module at LNS

When the L2TP-encapsulated packet arrives on an interface at the LNS, the ingress processor strips
the Layer 2 encapsulation, leaving the user's IP/UDP/L2TP-encapsulated PPP packet. Then the
ingress processor performs one lookup. It examines the destination IP address, which, in this case, is
the tunnel endpoint, not the user's destination IP address. The ingress processor determines that the
destination IP address is a local IP address associated with the LNS. Because the IP address is local,
the ingress line module examines the IP packet and determines it is a UDP packet encapsulating an
L2TP frame (UDP port 1701). Once the ingress processor determines that it is an L2TP-encapsulated
packet, it obtains the L2TP session ID. It then tags the L2TP-encapsulated packet with the session ID
and sends the packet across the switch fabric to the dedicated or shared tunnel-server port for
additional processing. Note that the ingress processor never examined the user's destination IP
address and it did only one lookup.
Module 6: L2TP 6-40

Service Module Processing

Service Module
Ing ress
Egress
Traffic Ingress Egress
Line Switch Switch
from Line
Fabric Fabric
User Module Module
User’s
via Ingress FC Egress FC Destination
LAC
User IP/PPP User IP/PPP User IP/PPP User IP User IP

L2TP header L2TP/IP/UDP Tagged with Tagged Layer 2
L2TP IP/UDP Tagged with SM with Next Frame
Layer 2 Session ID Loopback Hop/Next Int.
 Service module or port processing:

– Remember that egress FCs receive packets from the switch fabric
– Egress FC tags PPP frame for SM loopback and second lookup
– Ingress FC strips the PPP frame, leaving user’s original IP packet
– IP route lookup using user’s destination IP address
– IP packet tagged and sent across switch fabric to egress line
module
Service Module Processing

Recall that with the E-series router architecture, ingress FCs always transmit packets across the
switch fabric, and egress FCs receive packets from the switch fabric. When the Service Module's
egress FC receives the L2TP-encapsulated packet, it strips the IP/UDP/L2TP encapsulation, leaving
the user's IP/PPP packet. The egress processor adds a tag to the IP/PPP packet and sends it to the
server port, which simply redirects this packet to the Service Module's ingress processor for the
second lookup. The Service Module's ingress FC strips the user's PPP frame, leaving the user's
original IP packet. The packet now follows the normal ingress packet processing path. The Service
Module's ingress FC examines the user's destination IP address and determines the egress line
module and outgoing interface. It then tags the user's IP packet with this information and sends it
across the switch fabric to the ultimate egress line module for Layer 2 encapsulation. By looping this
packet through the tunnel-server port, the ingress line module performs a single lookup and the egress
line module now receives an IP packet to process.
Each E-series router line module contains an ingress processor and an egress processor. Typically, a
packet uses one of these processors per line module—not both. The Service Module is just a line
module without a corresponding I/O module. Packets that flow through the Service Module actually use
both the egress processor and the ingress processor. The internal dedicated tunnel-server port forms
the loop between these two processors.
Module 6: L2TP 6-41

Line Modules Versus Service Modules

Service Module
Ing ress
Egress
Ingress Egress
Traffic Line Switch Switch
Line
from Fabric Fabric
Module Module
User User’s
Ingress FC Egress FC Destination
via
LAC
User IP/PPP User IP/PPP User IP/PPP User IP User IP
L2TP header L2TP/IP/UDP Tagged with Tagged Layer 2
L2TP IP/UDP Tagged with SM with Next Frame
Layer 2 Session ID Loopback Hop/Next Int.
 Why do we need a service module?

– Line modules designed to maintain wire-rate forwarding when
performing high-touch policy and QoS functions
– Ingress FCs designed to do one lookup
– Egress FCs expect to receive packets tagged with outgoing
interface
– L2TP-encapsulated packets require two lookups at LNS
 Additional service module functions:
– Packet transformation
– Centralized termination point or anchor point for tunnels
Why Do We Need a Tunnel-Server Port?

Remember that any time a packet arrives on an interface, the ingress controller expects to do one job—strip the
Layer 2 encapsulation, perform one lookup to determine the egress line module and outgoing interface, and
forward the packet along. Likewise, the egress line module expects to receive a packet tagged with the outgoing
interface, encapsulate the packet with the appropriate Layer 2 framing, and send the packet out the interface. E-
series line modules were designed to do these functions as well as any additional policy and quality-of-service
(QoS) processing required while maintaining wire-rate forwarding. Due to the extra encapsulation in an L2TP
environment, each packet arriving at the LNS requires two lookups. If a packet requires additional lookups or
processing, such as L2TP- or GRE-tunneled packets, the router requires the use of a dedicated or shared tunnel-
server port. Using this approach, nontunneled traffic is unaffected by packets requiring additional processing, like
L2TP-encapsulated packets.
Additional Service Module Functions
Tunnel-server ports, however, do more than just an additional lookup. In an L2TP environment they are
responsible for packet transformation. On flows going from the user to the ultimate destination, the tunnel-server
port terminates the user's PPP session and strips the user's PPP header to reveal the user's IP header. In the
reverse direction, the tunnel-server port adds the PPP header to the IP packet destined for the user. It also adds
the L2TP header to the IP/PPP packet before sending to the egress line module. The tunnel-server port also
provides a centralized termination or anchor point for tunnels. Because routes between destinations might
change, tunnels might move around between different physical interfaces or even different line modules on the
LNS. Tunneled packets for a particular session might not all arrive on the same line module. Because packets
transported by tunnels might be fragmented or require sequence number validation, there must be a centralized
location where these functions can take place. This centralized location is the tunnel-server port. It provides an
anchor point that does not drift to be able to perform reassembly and packet sequencing validation. While the E-
series router never initiates the use of sequence numbers in either role, it honors sequence number control from a
third party LAC or LNS. From this discussion you can see that tunnel resides on the line module. The user's
dynamically created IP/PPP interface resides on the tunnel-server port.
Module 6: L2TP 6-42

Fragmentation and IP Reassembly

RADIUS Smaller MTU
Tunnel Packets Fragmented
Blind PPP MRU
Negotiation
LNS
LNS RADIUS
L2TP Tunnel erx1 ISP2
dave@isp2.com LAC
LAC lo0=33.33.33.1
1.1.1.2 erx3
erx3
Incomplete lo0=3.3.3.1
PPP MRU vr2
Negotiation
 L2TP fragmentation issue:

– PPP MRU negotiated between user and LAC or LNS
– No knowledge of links between
– Packets encapsulated at LAC, forwarded into network and routed
– Tunneled IP packets might be fragmented
– Fragmented tunneled packets must be reassembled at endpoint
 Server modules perform IP reassembly
– Potential performance impact
– LAC requires service module
L2TP Fragmentation
While traversing several hops in an IP network, packets can become fragmented for several reasons. For
example, the maximum transmission unit (MTU) size of a link between two hops (routers) is smaller than the one
of the previous hops. Recall that in an L2TP environment, the PPP session is negotiated between the user and
the LAC or the user and the LNS. Unfortunately, this PPP session rides within a tunnel that might traverse several
networks links with different MTU sizes. If the user and LAC negotiate PPP maximum receive unit (MRU) sizes, it
does not encompass the entire path the packets will traverse. Likewise, if the user and LNS negotiate the PPP
MRU size, the LNS is blind to the MTU sizes of the intervening links. Unfortunately, either way, this negotiation
does not account for the different MTU sizes of the links along the path. When user data is sent across the tunnel,
the user's IP/PPP packet is encapsulated and tunneled, potentially making the packet quite large. If this tunneled
packet becomes too large for a specific Layer 2 link, it will be fragmented packets and routed and forwarded like
all other IP packets. The terminating end station (destination) must perform the IP reassembly of the fragmented
packets. In the case where already fragmented packets are tunneled, and the tunnel packets themselves become
fragmented, the fragmented tunnel packets must be reassembled first—before the actual packet can be
reassembled and processed. IP reassembly requires buffering and potential reordering of all fragmented packets
because the original IP packet cannot be reassembled until the last fragment is received. Fragmented packets
can arrive on any physical port of potentially different line cards so the reassembly of packets must be centralized
on a tunnel-server port.
Tunnel-Server Port Performs IP Reassembly
IP reassembly in the E-series router uses a dedicated or shared tunnel-server port. Remember that the LNS
requires a tunnel-server port and therefore can handle packet reassembly naturally. The LAC, however, does not
require a tunnel-server port and, by default, it does not perform any reassembly of IP packets. If the LAC must
perform IP reassembly, it requires a dedicated or shared tunnel-server port. Unfortunately, the dedicated tunnel-
server port can be quite expensive, and only specific line modules support shared tunnel-server ports. It can also
negatively impact performance. IP reassembly is enabled/disabled by virtual routers. It is disabled on all virtual
routers by default, and must be enabled explicitly.
Module 6: L2TP 6-43

Why Does the LAC Need a Service Module?

Traffic Traffic
to from
User Ingress Egress LNS
Line Switch
Line
Fabric
Module Module
Ingress FC Egress FC
User IP/PPP User IP/PPP User IP/PPP

Layer 2 Tagged L2TP header
Frame with L2TP IP/UDP
Outgoing IF Layer 2
 LAC processing:
– Layer 2 encapsulation stripped leaving the L2TP encapsulated IP/PPP
packet
– IP route lookup using IP address in L2TP encapsulation
– Destination IP address local to LAC and UDP port = 1701
– Terminate tunnel, remove L2TP IP/UDP and L2TP headers and obtain
session ID
– Using session ID, obtain outgoing user’s interface
– User’s IP/PPP packet tagged and sent across switch fabric to egress line
module
– Egress line module encapsulates IP/PPP packet in Layer 2 encapsulation
LAC Processing
When the LAC receives packets from the tunnel, the ingress processor strips the Layer 2
encapsulation leaving the user's IP/UDP/L2TP-encapsulated PPP packet. Then the ingress processor
performs one lookup. It examines the destination IP address, which in this case is the tunnel endpoint,
not the user's destination IP address. The ingress processor determines that the destination IP
address is a local IP address associated with the LAC. Because the IP address is local, the ingress
line module examines the IP packet and determines it is a UDP packet encapsulating an L2TP frame
(UDP port
1701).
Once the LAC's ingress processor determines it is an L2TP-encapsulated packet, it terminates the
tunnel, removes the L2TP IP/UDP headers, obtains the L2TP session ID, and removes the L2TP
header. Using the session ID, it determines the outgoing client interface. It then tags the user's IP/PPP
packet with the outgoing client interface and sends the packet across the switch fabric to the egress
line module. The egress FC receives the user's IP/PPP packets and encapsulates them in the
appropriate Layer 2 framing.
Note that the user's interface on the egress FC acts as the centralized anchor point. This interface
expects to receive complete IP/PPP-encapsulated packets. On the LAC, however, any number of
ingress FCs can receive tunneled packets destined for a single user. If tunneled packets were
fragmented along the way, different fragments could arrive on different line modules at the LAC. If this
is the case, the LAC has no way of reassembling fragmented packets before they are sent to the user's
outgoing interface. If tunneled packets are fragmented, the LAC requires additional hardware to act as
a single aggregation point for all incoming tunneled packets.
Module 6: L2TP 6-44

Avoiding Fragmentation
 L2TP fragmentation avoidance:
– Configure an MRU lower than the minimum size between LAC/LNS
– MRU = (Min MTU between LAC/LNS) – (L2TP UDP/IP) – (Max L2TP
header)
– Ethernet example:
Minimum link MTU 1500
L2TP IP header - 20
L2TP UDP header -8
L2TP header -6
PPP header -4
MRU size to specify 1462
 E-series router acting as a LAC:
– Configure the MTU on the access link
 E-series router acting as an LNS:
– Configure PPP MRU within the profile referenced in the L2TP
remote host definition
Avoiding L2TP Fragmentation

Instead of performing IP reassembly, a better approach is to avoid packet fragmentation in the first
place to avoid the negative affects on performance. One way is to control the size of the packets
traversing the tunnel by determining the smallest MTU along the path. You can then configure the LNS
or LAC to use this value when it negotiates the PPP MRU during PPP LOP. First determine the
smallest MTU size, then subtract the overhead associated with the L2TP UPD/IP encapsulation as well
as the maximum L2TP and PPP header encapsulation.
LAC Configuration
If the E-series router is acting as a LAC, the situation is a bit tricky because MRU negotiation occurs
between PPP peers—in this case the user's PC and the remote LNS. There is, however, an initial
negotiation done between the LAC and user's PC. The result of this initial negotiation is sent from the
LAC to the LNS as proxy LCP data. The E-series router can and does get involved. Regardless of the
MRU negotiated by the client PC in the initial LCP negotiation, the E-series router will set the MRU to
the MTU of the access link if it is less than the negotiated MRU. You can configure the access link's
MRU using the formula on the slide.
LNS Configuration
If the E-series router acts as an LNS, you can configure PPP MRU within the profile referenced in the
L2TP remote host definition. If this MRU is set low enough that the value plus the addition of all other
overhead (L2TP and IP) is less than the MRU in the network, no fragmentation will occur in that
direction.
Module 6: L2TP 6-45

L2TP Licensing
 What licenses are required for L2TP?
– LAC requires a B-RAS subscriber license for each PPP session
– LNS requires a B-RAS subscriber license for each IP interface
– LNS requires an L2TP session license for each tunneled session
– Tunnel switching: 2 L2TP session licenses—1 for inbound
session and 1 for outbound session
L2TP Licensing
In an L2TP environment, additional software licenses are required. If an E-series router acts as a LAC,
it requires a B-RAS subscriber license for each tunneled PPP session or PPP interface. If an E-series
router acts as a LNS, it requires a B-RAS subscriber license for each terminated IP session or IP
interface. The LNS also requires an LNS session license for each L2TP session it manages. If an E-
series router performs L2TP tunnel switching, each switched sessions counts as two session licenses.
Module 6: L2TP 6-46

L2TP Licensing Example

 Sample environment:
– Router 1:
 B-RAS and LAC
 Terminates 2000 PPP-over-Ethernet users
 Tunnels 3000 PPP sessions
– Router 2:
 B-RAS and LNS only
 Terminates 5000 L2TP sessions
 License requirements:
– Both routers require JUNOSe software + Subscriber Access
software LTU
– Router 1:
 B-RAS subscriber license for 8000 simultaneous IP, LAC, and bridged
Ethernet interfaces
– Router 2:
 B-RAS subscriber license for 8000 simultaneous IP, LAC, and bridged
Ethernet interfaces
 L2TP LNS session license for 8000 LNS sessions
L2TP Licensing Example

Router 1 acts as a B-RAS and a LAC. It terminates 2000 PPP-over-Ethernet users and it tunnels 3000
PPP sessions. Router 2 acts as a B-RAS and an LNS. It terminates 5000 L2TP sessions. Each L2TP
session supports one IP interface.
L2TP Licensing Requirements
In this simple environment, each router requires a JUNOSe software license as well as a Subscriber
Access software license to use (LTU). Because Router 1 manages 2000 IP interfaces and 3000 PPP
or LAC sessions, it requires a software license that supports at least 5000 interfaces, specifically a B-
RAS subscriber license for 8000 simultaneous IP, LAC, and bridged Ethernet interfaces. Because
Router 2 manages 5000 LNS sessions, it requires an LNS session license for 8000 LNS sessions.
Because each LNS session maps to one IP interface, it also requires a B-RAS subscriber license for
8000 simultaneous IP, LAC, and bridged Ethernet interfaces.
If these routers run additional applications such as OSPF, BGG, IPSec, stateful firewall, or NAT,
additional licenses are required.
Module 6: L2TP 6-47

Agenda: L2TP
 L2TP Overview
 L2TP Operation
 Troubleshooting L2TP
Troubleshooting L2TP
Module 6: L2TP 6-48

Verifying LAC and LNS Tunnel Configuration
 Examine the LAC’s tunnel attributes and verify that they

match the LNS destination profile configuration
– LAC domain map configuration:
– RADIUS tunnel attributes:
erx3#test aaa ppp user@domain
– LNS destination profile configuration:
erx3#show l2tp destination profile profile-name
 Test LAC tunnel initiation:
erx3#l2tp tunnel test anyone@domain
erx3#l2tp tunnel test anyone@erx3.com
 Examine log messages using the following categories:
– l2tp
– l2tpIpLowerBinding
– l2tpStateMachine
Verify the LAC and LNS Tunnel Attribute Configuration

The slide shows the various commands that you can use to examine the LAC and LNS configuration.
To obtain tunnel attributes, the test aaa ppp command does not require a password.
Test LAC Tunnel Initiation
You can use the l2tp tunnel test command on the LAC to verify that a tunnel can be established
between the LAC and the LNS. Remember that the LAC initiates the tunnel.
L2TP Logging Categories
The slide shows the various log categories that will aid you in troubleshooting L2TP
Module 6: L2TP 6-49

L2TP Tunnel Test Logging (1 of 2)

erx3#l2tp tunnel test anyone@erx3.com
erx3#DEBUG 08/11/2004 17:00:22 l2tp (): Authenticate configuration data:
tag = 1, type = 1, transport = ipUdp, routerId = Router 0x80000001,
address = 33.33.33.1, tName = lac-erx3-to-erx1, tSecret = training,
tLocalHostName = erx3, tPeerHostName = erx1, tLocalAddress = 3.3.3.1
DEBUG 08/11/2004 17:00:22 l2tp (): Adding new virtual router Router
0x80000001
NOTICE 08/11/2004 17:00:22 l2tp (interface TUNNEL l2tp:2): Changing
effective adminState from disabled to enabled
DEBUG 08/11/2004 17:00:22 l2tp (interface TUNNEL l2tp:2/lac -erx3-to-erx1):
Update IP transport config: local address = 3.3.3.1, remote address =
33.33.33.1
NOTICE 08/11/2004 17:00:22 l2tp (interface TUNNEL l2tp:2/lac -erx3-to-
erx1): Changing effective adminState from disabled to enabled
DEBUG 08/11/2004 17:00:22 l2tpStateMachine (interface TUNNEL l2tp:2/lac-
erx3-to-erx1): tunnel: state = closeDown, event = open, next state =
openDown
NOTICE 08/11/2004 17:00:22 l2tp (): No more configuration records
NOTICE 08/11/2004 17:00:22 l2tp (interface TUNNEL l2tp:2): Changing
ifOperStatus from LowerLayerDown to Up
DEBUG 08/11/2004 17:00:22 l2tp (interface TUNNEL l2tp:2/lac -erx3-to-erx1):
Update IP transport config: local address = 3.3.3.1, remote address =
33.33.33.1
erx1): Changing ifOperStatus from LowerLayerDown to Down
L2TP Logging: Part 1

The slide shows the log messages that you should see when you use the 12tp tunnel test command on
the LAC.
Module 6: L2TP 6-50

L2TP Tunnel Test Logging (2 of 2)

erx3-to-erx1): tunnel: state = openDown, event = upActive, next state =
txSccrq
erx1): Changing mibState from idle to connecting
erx3-to-erx1): tunnel: state = txSccrq, event = txComplete, next state
= waitCtlReply
INFO 08/11/2004 17:00:22 l2tp (interface TUNNEL l2tp:2/lac-erx3-to-erx1):
Processing incoming in-sequence sccrp
erx3-to-erx1): tunnel: state = waitCtlReply, event = sccrp, next state
= txScccn
erx3-to-erx1): tunnel: state = txScccn, event = txComplete, next state
= established
erx1): Changing ifOperStatus from Down to Up
erx1): Changing mibState from connecting to established
L2TP Logging: Part 2

The slide shows the log messages that you should see when you use the 12tp tunnel test command on
the LAC.
Module 6: L2TP 6-51

Examining L2TP Tunnel Information

RADIUS
pete@erx3.com
LNS erx3-
erx3 -lns erx3.com
lo0=33.33.33.1
LAC
LAC
holly@erx3.com rtr id=33.33.33.1
erx3
erx3
1.1.1.2 lo0=3.3.3.1 LNS vr2
DSL rtr id 3.3.3.1 lo0=33.33.33.2 ISP2
Router
rtr id=33.33.33.2
home1@isp2.com
RADIUS
 L2TP destinations:
erx3#show l2tp destination
L2TP destination 1 is Up with 1 active tunnel and 2 active sessions
L2TP destination 2 is Up with no active tunnels
2 L2TP destinations found
erx3#show l2tp destination detail
 L2TP tunnels:
erx3#show l2tp tunnel
L2TP tunnel 1/lac-erx3-to-erx1 is Up with no active sessions
1 L2TP tunnel found
 L2TP sessions:
erx3#show l2tp session
L2TP session 1/lac-erx3-to-erx1/1 is Up
L2TP session 1/lac-erx3-to-erx1/2 is Up
2 L2TP sessions found
L2TP Destinations
An L2TP destination corresponds to a LAC/LNS pair and is identified by the router's router ID. Keep in
mind that the E-series router supports virtual routers, and destinations are identified using the router
ID. For example, one LAC could have several destinations to the same physical router. In the example
on the slide, erx3 has two destinations: destination 1 is between 3.3.3.1, and 33.33.33.1 and
destination 2 is between 3.3.3.1 and 33.33.33.2. On the E-series routers, destination identifiers are
assigned sequentially by the system. You cannot configure a destination identifier.
L2TP Tunnels
A single L2TP destination can support multiple tunnels. On the LAC. tunnels are identified by
destination identifier and tunnel identification. You can configure the tunnel identification on the LAC to
aid in troubleshooting. On the LNS, tunnels are identified by destination identifier and tunnel ID. Tunnel
IDs are assigned sequentially by the LNS and are not configurable. The example on the slide shows
the active tunnel on the LAC.
L2TP Sessions
A single L2TP tunnel can support multiple sessions. On the LAC, tunnels are identified by destination
identifier, tunnel identification, and session ID. Session IDs are assigned sequentially by the LNS and
are not configurable. The example on the slide shows the active sessions on the LAC.
Module 6: L2TP 6-52

Verifying LAC User Information

 Verify subscriber and PPP interface information only:
– No IP interfaces or routes for users on the LAC
erx3#show subscribers
Subscriber List
---------------
User Name Type Addr|Endpt Virtual Router

------------------------ ----- ------------- ---------------
pete@erx3.com tnl 33.33.33.1/l2tp default
holly@erx3.com tnl 33.33.33.1/l2tp default
User Name Interface
------------------------ --------------------------------
pete@erx3.com atm 6/1.1:0.101
holly@erx3.com atm 6/1.2:0.102
User Name Login Time
------------------------ -------------------
pete@erx3.com 04/08/11 22:33:21
holly@erx3.com 04/08/11 22:33:21
Verifying LAC User Information

In an L2TP environment, only the user's PPP interface is created on the LAC. The user's IP interface is
created on the LNS. When you troubleshoot the LAC, you must verify that the user is logged in as a
tunnel user. The user should not have an assigned IP address. You must also verify that the user's
PPP interface is created and operational.
Module 6: L2TP 6-53

Verifying LNS User Information

 Verify subscriber, PPP interface, and IP interface
information:
erx1#show subscribers
Subscriber List
---------------
User Name Type Addr|Endpt VirtualRouter
----------------- ----- ----------------- ------------
pete@erx3.com ppp 172.3.3.4/radius erx3-lns
holly@erx3.com ppp 172.3.3.5/radius erx3-lns
User Name Interface
------------------------ --------------------------------
pete@erx3.com l2tp 1/1/1
holly@erx3.com l2tp 1/1/2
User Name Login Time
------------------------ -------------------
pete@erx3.com 04/08/11 17:40:38
holly@erx3.com 04/08/11 17:40:38
 Verify network connectivity using ping and traceroute
Verifying LNS User Information

In an L2TP environment, the user's PPP and IP interfaces are created on the LNS. When you
troubleshoot the LNS, you must verify that the user is logged in and has an assigned IP address. You
must also verify that the user's PPP interface is created and operational. The user's IP interface must
be created in the correct virtual router along with the corresponding host route in the routing table. You
can use ping and traceroute to verify network connectivity.
Module 6: L2TP 6-54

Module Review
1. What are two common applications for L2TP?
2. What are the steps for tunnel establishment?
3. How does the E-series router determine if a PPP session is
to be tunneled or terminated?
4. What L2TP parameters must you configure on the LNS?
5. What are the different L2TP tunnel failover methods, and
how do they differ?
6. What special hardware is required for the LAC? What
special hardware is required for the LNS?

• Two common L2TP applications;
• The life of a packet in an L2TP environment;
• The E-series router configuration for a LAC and an LNS;
• The different tunnel failover and selection methods; and
• Verifying L2TP operation using show commands and logging.
Module 6: L2TP 6-55

Lab 6: Configuring L2TP
Lab Objectives:
Configure and troubleshoot an E-series router as both
a LAC and an LNS.
Lab 6: Configuring L2TP

Module 6: L2TP 6-56

Questions
Any Questions?
If you have any questions or concerns about the class you are attending, we suggest that you voice them
now so that your instructor can best address your needs during class.
Module 6: L2TP 6-57

Module 6: L2TP 6-58

Module 7: Policy Management Overview

Module Objectives
to:
– Define the policy management function
– Follow the packet flow through the E-series router
– Identify the line module components that implement policy
management
– Configure classifier access control lists
– Configure policy lists
– Configure rate-limit profiles
– Use show commands and logging to troubleshoot policy
configuration

•The policy management functions in the E-series router;
•The packet flow in an E-series router;
•The line module components responsible for policy management;
•Configuring classifier access control lists (CLACLs);
•Configuring rate-limit profiles;
•Configuring policy lists; and
•The various show commands used to examine policy configuration.
Module 7: Policy Management Overview 7-2

Agenda: Policy Management Overview

 Policy Management Overview
 Configuring Classifier Lists and Policy Lists
 Rate-Limiting Overview
 Configuring Rate-Limit Profiles
 Configuring Policy Lists with Multiple Rules
 Troubleshooting Policies on the E-series Router
Policy Management Overview


What Is a Policy?
Captive Portal FTP server
192.168.254.1 10.10.10.10
www.disney.com
172.16.199.250
video.server.com
192.168.200.16
 A policy is condition and an action that is attached to an

interface to change normal packet forwarding behavior
– Condition:
 Evaluate any field in the IP header
 Frame Relay DE bit, MPLS EXP bits, others
– Action:
 Filter, rate-limit, log, forward, mark, forward next-hop, forward interface
 Policy attachment points:
– IP interfaces
– Layer 2 interfaces
– Inbound and outbound
What Is a Policy?
A policy is a condition and an action that is attached to an interface. The condition and action cause
the router to handle the packets passing through the interface in a certain way.
Policy Attachment Points
A policy can be attached to IP interfaces and certain Layer 2 interfaces such as Frame Relay, L2TP,
MPLS, and VLAN interfaces. This chapter focuses on attaching policies to IPv4 interfaces. An interface
can have one policy attached that evaluates inbound traffic and a different policy attached that
evaluates outbound traffic. The policies do not need to be the same in both directions.

When Are Policy Rules Applied to Packets?

Policies attached here 192.168.254.1 10.10.10.10
www.disney.com
172.16.199.250
video.server.com
192.168.200.16
 Policies applied to packets

– Condition evaluated before route lookup
 Input policy
– Condition evaluated after route lookup
 Secondary input policy
– Condition evaluated before packet leaves an interface
 Output policy
When Are Policies Applied to Packets?

When packets arrive on an interface, you can have a policy evaluate a condition before the normal
route lookup; this kind of policy is known as an input policy. You can also have conditions evaluated
after a route lookup; this kind of policy is known as a secondary input policy. You can use secondary
input policies to defeat denial-of-service attacks directed at a router's local interface or to protect a
router from being overwhelmed by legitimate local traffic. Likewise, you can have a policy applied to
packets before they leave an interface. This kind of policy is known as an output policy.

Policy Examples
192.168.254.1 10.10.10.10
www.disney.com
172.16.199.250
video.server.com
192.168.200.16
 Policy examples:
– Filter specific types of traffic
 Drop any Telnet traffic going to the user
 Drop any NetBIOS traffic coming from the user
– Rate-limit traffic
 Rate-limit inbound and outbound traffic to 512 Kbps
– Provide higher bandwidth to specific types of traffic
 FTP traffic rate-limited to 1 Mbps, all other traffic 512 Kbps
– Steer traffic to a specific interface or IP address
 Forward traffic destined for a content network to a captive portal
Policy Examples
In this chapter we discuss how to create several types of simple policy rules. Our first example shows
how to filter specific types of traffic. Our second example shows how to rate-limit all traffic going to and
coming from a user to a rate lower than the physical link speed. In our network, this rate limiting occurs
at the IP interface. Next, we
discuss how to differentiate different traffic flows and provide higher bandwidth to certain types of
traffic. In our simple network, we show how to give more bandwidth to FTP traffic. Finally, we discuss
the concept of policy routing. We use this concept to steer traffic destined for a specific IP address
range to a captive portal for additional processing. With policy routing, the router does not perform a
route table lookup using the packet's destination IP address. Instead, the policy identifies which IP
address to use as the next-hop address or across which interface to forward the packet by passing the
normal routing function.

Policy Management Function

Rate -Limit Profiles Classifier Control Lists
8Mbps FTP
1Mbps-hard
drop-traffic-from-user
512Kbps
E-series drop-traffic-to-user
Database
Policy Action Commands Policy Lists

filter business-user
rate-limit-
rate-limit- from-user
profile
profile
to-user
log Rule 1
Rule 2
forward
Rule 3
mark
mark |
|
color
color Rule n
traffic-
traffic -class
class
user-packet-
user-packet-
class
class
Policy Management Function

The policy manager function provides the CLI tools to build databases, which can be drawn from to
implement a policy. Each database contains traffic specifications. These databases are global in
nature. When building a policy, you specify input from one or more of these databases. You then
attach the policy to an interface. By combining the inputs from the various databases into policies, a
wide variety of services can be deployed. The primary components of the policy manager function are:
•Classifier access control lists (CLACLs): The CLACLs classify traffic into flows with common
characteristics. CLACLs specify a range of values in the IP datagram header. The fields examined can
include IP source/ destination address, TCP/UDP source/destination port, and the protocol field.
•Rate-limit profiles: This is the tool for assigning a bandwidth limit policy. The E-series router supports
two different rate-limit profile types-two-rate and one-rate rate-limit profiles. You can configure rate-limit
profiles to provide a tiered bandwidth service, set a hard limit on the bandwidth provided for a traffic
flow, or build TCP-friendly rate limits.
•Policy lists: A policy is a set of rules that define what specialized treatment should be applied to
classified traffic flows. Policy actions can include packet filtering, policy routing, bandwidth limiting,
traffic classification, and packet marking. You can attach policy lists to either an ingress or an egress
interface and reference CLACLs and rate-limit profiles to build services for customers.

High-Level Packet Flow

 Ingress packet flow:
– Ingress port hardware receives packet
– Ingress ASIC directs packet to ingress FC
– Ingress FC processes packet, makes forwarding decision
– Ingress ASIC buffers and schedules packet for transmission across
fabric
 Egress packet flow:
– Egress ASIC directs packet to egress FC
– Egress FC processes packet
– Egress ASIC buffers and schedules packet to port hardware
– Egress port hardware transmits packet
 Tunnel service module
– TSM service requires an extra hop across the fabric
High-Level Packet Flow

This slide outlines the forwarding path of IP datagrams through the E-series router. In this chapter, we
describe the tools the E-series policy management function provides. The policy management function
provides a set of tools that allows the service provider to configure services that customize the
treatment of individual packet flows received on a subscriber's interface

Ingress Software Flow

Decapsulation
Decapsulation Frame received on interface Remove datalink headers and obtain IP header
Input
Input Classification
Classification If input policy attached, do classifier lookup.
Input If classification match. take policy action' policy route. rate limit, mark, filter. log,
Input Policy
Policy
traffic class, or forward.
Input
Input Rate
Rate Limiting
Limiting If rate-limit policy match, do dual token bucket lookup, updating packet color.
Take color-specific action: mark, discard, or forward.
Route Do route lookup If source addresm validation enabled and check fails, discard.
Route Lookup
Lookup
If no route, forward to SRP.
Local
Local Classification
Classification For locally destined packets, if secondary input policy attached, do classifier
lookup.
Local
Local Policy
Policy If classification match, take policy action.
Encapsulation
Encapsulation Add route tag containing outgoing interface.
Fowarding
Fowarding Transmit packet acrcss switch fabric.
Statistics
Statistics Update statistics.
Ingress Software Flow

This slide shows a more detailed diagram of the ingress packet flow. This slide is intended as a high-
level overview. Subsequent pages in the chapter will go into a more detailed discussion.
A frame arrives on an interface. The router removes the datalink headers to obtain the IP header. If an
ingress input policy is attached to the receiving interface, the policy's classifier list is applied to the
packet's IP header. If there is a classification match, the associated policy action is taken. For
example, the router might filter, policy route,
mark, or simply forward the packet. For a rate-limit policy action, the router does a dual-token bucket
lookup, updates the packet color, and takes the appropriate action—mark, filter, or forward. A more
detailed discussion of the router's rate-limiting capabilities occurs later in the chapter. Notice that the
input classification step occurs before the route lookup on the destination IP address.
Next, the router obtains the destination IP address and performs a route lookup. If source address
validation is configured and fails, the router drops the packet. If there is no route, the router forwards
the packet to the SRP. If a secondary input policy is assigned to the receiving interface and the packet
is destined for a local interface on the router, the policy's classifier list is applied and matching actions
are taken. Remember that secondary input policies are one way to control denial-of-service attacks.
Based on the route lookup, the router determines the egress line module and outgoing interface. It then
tags the packet with this outgoing interface information and sends it across the switch fabric. If
enabled, policy statistics are updated.

Egress Software Flow

Decapsulation
Decapsulation Remove route tag and locate appropriate interface column
Multicast
Multicast If multicast elaborate frame onto multiple interfaces
Output If classification match, take policy action: rate limit, mark, filter, log, or traffic
Output Policy
Policy
class
Output
Output Rate
Rate Limiting
Limiting If rate-limit policy match, do dual token bucket lookup, updating packet color.
Take color-specific action mark, discard, or forward
Fragmentation If packet exceeds MTU and do not fragment bit set discard. otherwise.
Fragmentation
fragment packet
Encapsulation
Encapsulation Add datalink headers.
Fowarding
Fowarding Transmit packet acrcss physical interface.
Statistics
Statistics Update statistics.
Egress Software Flow

This slide shows a more detailed diagram of the egress packet flow. This slide is intended as a high-
level overview.
The egress line module receives the packet, removes the route tag, and locates the appropriate IP
interface column. If an egress output policy is attached to the interface, the policy's classifier list is
applied to the packet's IP header. If there is a classification match, the associated policy action is
taken. For example, the router might filter, mark or rate-limit the packet. Policy routing actions are not
supported in output policies because the route lookup occurs on the ingress line module. For a rate-
limit policy action, the router does a dual-token bucket lookup, updates the packet color, and takes the
appropriate action—mark, filter, or forward. A more detailed discussion of the router's rate limiting
capabilities occurs later in the chapter.
If the packet exceeds the outgoing interface's MTU and the do not fragment bit is set, the router drops
the packet. Otherwise, the router fragments the packet.
Finally, the router adds the necessary datalink header, transmits the packet out the interface, and
updates the appropriate statistics.


 Configuring Classifier Lists and Policy Lists
Configuring Classifier Lists and Policy Lists


IPv4 Packet Classification

Version IHL Type of Service Total Length
Identification Flags Fragment Offset
Time to Live Protocol Header Checksum
Source IP Address
Destination IP Address
Options Padding
Data
 Differentiated Services architecture defines two classifier

types
– Multifield
– Behavior aggregate
Differentiated Services Architecture

When referring to the policy management function on the E-series router, we consider the classifier to
be a main component. Classification is the process of taking a single data stream in and sorting it into
multiple output substreams.
In the Differentiated Services (DiffServ) architecture, two basic types of classifiers exist. The first
classifier type is a multifield (MF) classifier. The MF classifier can examine multiple fields in the IP
datagram header to determine the service class to which a packet belongs. The most common fields
for classification are IP source and destination address, TCP or UDP source and destination port
values, the protocol field, and type-of-service (ToS) byte in the IP datagram header, although other
fields can be examined.
The second type of classifier is a behavior aggregate (BA) classifier, which examines a single field in
an IP datagram header—ToS byte or DiffSery codepoint (DSCP)—and assigns the packet to a service
class based on what it finds.

Filtering Specific Traffic: Outbound

Outbound Policy Rule
Protocol Source IP Source Port Destination IP Destination Port Action
TCP any any any 23 filter
FTP server
10.10.10.10 telnet 10.1.1.2
10.1.1.2
www.disney.com
172.16.199.250
 Outbound policy:
– Drop Telnet traffic going to the user
 Quiz:
– What happens to FTP traffic?
– What happens to traffic coming from www.disney.com?
Outbound Policy
In the next few slides we discuss how to build a very simple policy that filters Telnet traffic going to the
user. From the router's perspective, this is an outbound policy as we are trying to prevent traffic from
going out an interface to a specific user.
Quiz
If this were the only policy rule configured on the router's outbound interface, what would the router do
with FTP traffic going to the user? What would the router do with HTTP traffic going to the user? Would
it be dropped? Would it be forwarded? On the E-series router, there is no implicit deny any any (any
source IP address or port, any destination IP address or port) policy rule, so both types of traffic would
be forwarded to the user at line rate.

Classifier List Configuration

erx7(config)#ip classifier-list drop- traffic-to- user ?
<0 - 255> The protocol matched by this classifier list
color Match color
destination- route- class Match route class from destination IP address lookup
icmp Configure a classifier list specific to the ICMP
protocol
igmp Configure a classifier list specific to the IGMP
protocol
ip Configure a classifier list specific to the IP
protocol
local Specify whether to match locally destined packets
not Match packets with protocols not equal to specified
protocol
source -route-class Match route class from source IP address lookup
tcp Configure a classifier list specific to the TCP
protocol
traffic -class Match traffic class
udp Configure a classifier list specific to the UDP
protocol
user-packet- class Match user packet class
erx7(config)#ip classifier -list drop- traffic-to- user tcp ?
A.B.C.D The source address to match
any Match any source address
host Identify the source address as a host (use a host wildcard)
not Match packets with a source ip address not equal to specified
address
erx7(config)#ip classifier -list drop- traffic-to- user tcp any any eq 23
Configuring IP Classifier Lists

You configure CLACLs with a name and then values to match in the IP datagram header. As shown on
the slide, the CLACL provides a number of fields in the datagram that can be examined. Here, we can
set a value to match in the protocol field, specify the ICMP or IGMP protocols, build an IP address list,
or build lists specific to the TCP or UDP transport protocols. Note that no action is included in a
CLACL; actions to take when there is a match are included in a policy list.
When there is a single match clause in a CLACL, the process is an AND function for the values or
fields listed for examination—that is, all fields listed must match the datagram header for the CLACL to
have a hit.
You can configure classifier lists for IP, VLANs, L2TP, and other Layer 2 technologies. This example
shows the configuration of an IP classifier list using the ip classifier-list name command. It is also
possible to configure IP classifier lists using the original command, classifier-list name. This chapter
shows both approaches.
Two categories of hardware classifiers are used on the E-series routers, depending on the type of line
module in use. LM-4, LM-10, 0C48/STM12, GE-2, and GE-HDE line modules support content-
addressable memory (CAM) hardware classifiers. All IP classification takes place in hardware on these
line modules. These line modules use software classifiers a limited amount of Layer 2 classification.
All other line modules support FPGA hardware classifiers and use software classifiers for a limited
amount of IP and Layer 2 classification. For example, these modules use hardware classifiers for
source/destination IP address, source/destination port, protocol, and ICMP to name a few. These
modules use software classifiers for ToS, IP and TCP flags, and source/destination route class. For a
complete list of hardware and software classifiers as well as detailed policy resource consumption
information for FPGA and CAM hardware classifiers, see the Policy Management Configuration Guide.

Examining Classifier Lists

erx7(config)#run show classifier -list
Classifier Control List Table
---------- ------- ---- -----
IP drop-traffic-to-user.1 tcp any any eq 23
erx7(config)#run show classifier -list drop -traffic-to-user detailed

---------- ------- ---- -----
IP Classifier Control List drop-traffic-to-user
Reference count: 0
Entry count: 1
Classifier-List drop-traffic-to-user Entry 1

Protocol: tcp
Not Protocol: false
Source IP Address: 0.0.0.0
Source IP WildcardMask: 255.255.255.255
Not Source Ip Address: false
Destination IP Address: 0.0.0.0
Destination IP WildcardMask:255.255.255.255
Not Destination Ip Address: false
Destination Port Operator: eq
Destination From Port: 23
Examining Classifier Lists

This slide shows the commands used to examine IP classifier list configurations either in brief or
detailed form. Notice that classifier lists make use of the wildcard mask functionality. Also notice that
the classifier list does not contain any actions. It only identifies fields in the IP header. The reference
count for this classifier list is zero because no policy lists are using it yet.

Policy List Configuration

erx7(config)#ip policy -list to-user
erx7(config-policy-list)#classifier-group ?
* The default classifier group
WORD (40 char max) The classifier list name
erx7(config-policy-list)#classifier-group drop-traffic-to-user
erx7(config-policy-list-classifier-group)#?
color Create a color policy
default Set a command to its default(s)
exit Exit from the current command mode
filter Create a filter policy
forward Create a forward policy
help Describe the interactive help system
log Configure logging settings
macro Run a CLI macro
mark Create a set TOS byte policy
next-hop Create a next-hop policy
next-interface Create a next-interface policy
no Negate a command or set its default(s)
rate-limit-profile Create a rate-limit policy
run Run an exec mode command
suspend Suspend a policy rule
traffic-class Create a traffic class policy
user-packet-class Create a user packet class policy
erx7(config-policy-list-classifier-group)#filter
erx7(config-policy-list-classifier-group)#exit
erx7(config-policy-list)#
Configuring Policy Lists

A policy list is a set of rules or classifier groups. Each classifier group identifies a specific classifier list
and the action to take if a packet matches that classification. In this example, we are creating an IP
policy list called to-user. This policy list initially contains a single rule. This rule or classifier group
references the classifier list drop-traffic-to-user. If a packet matches this classification, the associated
action is taken. In this example, packets matching the classifier list are filtered. Packets not matching
the classifier list are simply forwarded according to the routing table.
The asterisk (*) is a reserved keyword identifying any IP traffic. You can use this keyword instead of
creating a classifier list with an any any condition.
You can now configure policy lists for IP, MPLS, Frame Relay, VLANs , and other Layer 2 technologies.
The LM-10 uplink, however, only supports IP interfaces.
This example shows the configuration of an IP policy list using the ip policy-list name command. It is
also possible to configure IP policy lists using the original command, policy-list name. This chapter
shows both approaches.

Examining and Attaching Policy Lists

erx7(config)#run show policy-list to-user
Policy Table
------ -----
IP Policy to-user
Administrative state: enable
Reference count: 0
Classifier control list: drop -traffic-to-user, precedence 100
filter

erx7(config-if)#ip policy output to-user statistics enabled baseline enable
erx7(config-if)#run show policy-list to-user
Policy Table
------ -----
IP Policy to-user
Reference count: 1
filter
Referenced by interface(s):
FastEthernet3/2.71 output policy, statistics enabled, virtual-router
default
Referenced by profile(s):
No profile references
Examining and Attaching Policy Lists

This slide shows how to view a policy list. In the first show policy-list command results, the reference
count is zero because the policy list is not attached or associated with any interfaces.
Next, the policy list is attached to a user's IP interface as an output policy. Statistics were enabled for
the entire policy list as well as the ability to create a baseline for these statistics, which can be helpful
in troubleshooting new policy lists.
Finally, the policy list configuration is examined again. This time the policy is attached to an interface.
One policy list can be attached to more than one interface, allowing it to be used over and over again.

Filtering Specific Traffic: Inbound

Inbound Policy Rule
Protocol Source IP Source Port Destination IP Destination Port Action
TCP any any any 137 filter
UDP any any any 137 filter
TCP any any an y 138 filter
UDP any any any 138 filter
FTP server
10.10.10.10 telnet 10.1.1.1
www.disney.com
172.16.199.250
 Inbound policy:
– Drop NetBIOS traffic coming from the user
– Example only shows NetBIOS name and datagram service
 Quiz:
– What happens to traffic going to www.disney.com?
Inbound Policy
Now we discuss how to build a very simple policy that filters NetBIOS traffic coming from the user.
From the router's perspective, this is an inbound policy because we are trying to prevent traffic from
entering the router.
Quiz
If this were the only policy rule configured on the router's inbound interface, what would the router do
with FTP traffic coming from the user? What would the router do with HTTP traffic coming from the
user? Would it be dropped? Would it be forwarded? On the E-series router, there is no implicit deny
any any policy rule so both types of traffic would enter the router.

Classifier and Policy List Configuration

erx7(config)#classifier-list drop-traffic-from-user udp any any eq 137
erx7(config)#classifier-list drop-traffic-from-user tcp any any eq 137
erx7(config)#classifier-list drop-traffic-from-user udp any any eq 138
erx7(config)#classifier-list drop-traffic-from-user tcp any any eq 138
erx7(config)#run show classifier -list drop -traffic-from-user

---------- ------- ---- -----
IP drop-traffic-from-user.1 udp any any eq 137
IP drop-traffic-from-user.2 tcp any any eq 137
IP drop-traffic-from-user.3 udp any any eq 138
IP drop-traffic-from-user.4 tcp any any eq 138
erx7(config)#policy-list from-user
erx7(config-policy-list)#classifier-group drop-traffic-from-user
erx7(config-policy-list-classifier-group)#exit
erx7(config-policy-list)#exit
erx7(config)#interface fastEthernet 3/2.71
erx7(config-if)#ip policy input from-user
Configuring Classifier and Policy Lists

The example on the slide shows a multiple clause classifier list configuration matching a variety of TCP
and UDP ports used for NetBIOS name and datagram service.
When there is a single match clause in a CLACL, the process is an AND function for the values or
fields listed for examination—that is, all fields listed must match the datagram header for the CLACL to
have a hit.
When there are multiple clauses, as in the example, the process is an OR function—if the packet
matches all the fields specified in the first match clause OR all the fields specified in the second match
clause, the CLACL reports a hit to the router.
In this example, we are using the legacy classifier-list command, which is equivalent to the ip classifier-
list command used in the previous example. By default, the router builds IP classifier lists.
In the last step in this example the policy list is attached to the user's IP interface as an input policy.
Notice that statistics were not enabled for this policy list.

Testing Classifier and Policy Lists

erx7#telnet 70.70.70.1
erx7#show ip interface fast 3/2.71 delta
FastEthernet3/2.71 line protocol VlanSub is up, ip is up
Description: vlan-to-erx1
Network Protocols: IP
Internet address is 70.70.70.2/255.255.255.0
Out Forwarded Packets 0, Bytes 0

Unicast Packets 0, Bytes 0
Multicast Routed Packets 0, Bytes 0
Out Scheduler Dropped Packets 0, Bytes 0
Out Policed Packets 5, Bytes 300
Out Discarded Packets 0
IP policy input from-user

Statistics are disabled
IP policy output to-user

classifier-group drop-traffic-to-user entry 1
5 packets, 410 bytes
filter
queue 0: traffic class best-effort, bound to ip FastEthernet3/2.71
Queue length 0 bytes
Forwarded packets 1591, bytes 617512
Dropped committed packets 0, bytes 0
Dropped conformed packets 0, bytes 0
Dropped exceeded packets 0, bytes 0
Testing Classifier and Policy Lists

This slide shows the results of someone trying to Telnet to the user from the router. The Telnet session
is not established. Examining the IP interface statistics shows that the Telnet traffic met the drop-
traffic-to-user classifier list and the appropriate action, filter, was taken. Also notice that based on our
configuration, the router maintains statistics on the output policy list but not on the input policy list.


 Rate-Limiting Overview
Rate-Limiting Overview
The slide shows the topic we discuss next.

Policy Examples Using Rate Limiting

192.168.254.1 10.10.10.10
www.disney.com
172.16.199.250
video.server.com
192.168.200.16
 Rate-limit inbound and outbound IP traffic to 512 Kbps
– Provide higher bandwidth to specific types of IP traffic
 FTP traffic rate-limited to 1 Mbps, all other IP traffic 512 Kbps
– Steer certain IP traffic to a specific interface or IP address
 Forward IP traffic destined for a content network to a captive portal
Policy Examples
In the previous section, we discussed how to filter specific types of traffic. The next few examples show
how to rate-limit traffic going to and coming from a user to a rate lower than the physical link speed.
Rate limiting enforces data rates below the physical line rate of a port for either an IP interface, a
classified packet flow, or a Layer 2 interface. You implement rate limiting by configuring a rate-limit
profile that specifies bandwidth attributes and actions.
You can configure rate-limit profiles to provide a variety of services, including tiered bandwidth service
where traffic conforming to configured bandwidth levels is treated differently than traffic that exceeds
the configured values, and a hard-limit service where a fixed bandwidth limit is applied to a traffic flow.
Finally, you can configure rate-limit profiles to provide a TCP-friendly rate-limiting service that works in
conjunction with TCP's native flow-control functionality.
On the E-series router, you configure rate-limit profiles using one of two mechanisms —a Two
Rate/Three Color Marker (trTCM), as described in RFC 2698, or a Single Rate/ Three Color Marker
(srTCM ), described in RFC 2697.
The LM-10 uplink line module does not support rate limiting. See the Policy Management Configuration
Guide for more information.

The Concept of Rate Limiting

These boundaries
(exceeded => red => drop, transmit, or mark) are configurable
(conformed => yellow => drop, transmit, or mark)

bytes
( committed => green => drop, transmit, or mark)
 Rate limiting :
– Count number of bytes in each packet over time
– Categorize packets
– Assign action
– Internal color coding
The Concept of Rate Limiting

As packets enter an interface that has a rate-limit profile applied, three processes happen:
•Count (sample) the number of bytes (packets) over time.
•Categorize each packet as either:
•Committed: Within desired rate limit;
•Conformed: Above rate limit but tolerable (for a short period of time); and
•Exceeded: Above the rate limit and not so tolerable.
•Assign an action for each category:
•Transmit, drop, or mark (ToS byte) for committed actions;
•Transmit, drop, or mark (ToS byte) for conformed actions; and
•Transmit, drop, or mark (ToS byte) for exceeded actions.
You configure the variable for each of these steps using CLI commands.
An additional function of rate limiting is to apply a color code to packets assigned to each category—
green for committed, yellow for conformed, and red for exceeded. The system uses the color code
internally to indicate drop preference when there is congestion on an outbound interface.

Implementing Rate Limiting:

Dual Token Buckets
 Rate limiters are implemented using a dual token bucket
mechanism
– One bucket is for determining conformed (yellow) packets
– One bucket is for determining committed (green) packets
 Initially, each bucket is filled with a fixed number of
tokens (burst parameters)
– Burst parameters determine the depth of bucket
– Burst parameters configured in term of bytes
These are configurable values
Peak/excess burst Committed burst

(in bytes) (in bytes)
Bucket 1 Bucket 2
Dual Token Buckets

Rate limiters are implemented using a dual token bucket scheme. There is a token bucket for
conformed (yellow) packets and a token bucket for committed (green) packets. One token is
synonymous with one byte.
Burst Parameters
The depth of the buckets is the maximum number of tokens that can be placed in each bucket. You
configure the bucket depth with the peak burst parameter or the committed burst parameter.
The burst parameters are in bytes (not bytes per second)—you can think of this as the number of
tokens in a full bucket.


Draining the Buckets
 As packets enter the rate limiter, an equal number of
tokens are removed from each bucket (if possible)
– Packets are classified as red, yellow, or green (and action taken)
1
2
Peak Burst
Committed Burst
T T T
T TT
T
T T T
T TT T
TT TTT T
T
TT T T
TT T T
T TT T
TT T T T T
TT
TTT
TT
T T TT
TT T TT
TT
TTT
TTTT
TTTT T
T
TT T
TTT T
T T T TT
TT
T
T T TT TT
T TT TT
T
T
TT T
T
T
T T T
T T T
TT
TT
T T
TTTT T
T T TT
TT
T T TT
T TTT
TT T
T T
T
T TTT
T
T
TT
TT T
T
TT
T
T
Packet
Enough tokens? Yes Enough tokens? Yes
• Decrement token count

from both buckets
• Color packet green
• Take committed action
No No
• Do not decrement token count • Decrement token count from peak burst bucket
from either bucket • Color packet yellow
• Color packet red • Take conformed action
• Take exceeded action
Draining the Bucket

As packets pass through a rate limiter, their size is compared to the contents of both buckets, the
packet is categorized, and the rate-limiter action is taken on the packet. The algorithm for
categorizing the packet works like this:
1. Compare the number of bytes in the packet with the number of tokens in the peak bucket (bucket
1):
a) If there are not enough tokens, do not debit the peak bucket, and color the packet red
(exceeded).
b) If there are enough tokens, continue to the next step.
2. Compare the number of bytes in the packet with the number of tokens in the committed bucket
(bucket 2):
a) If there not are enough tokens, decrement the peak burst bucket with the size of the
packet, color the packet yellow, and take the conformed action.
b) If there are enough tokens, color the packet green (committed), decrement both buckets,
and continue.


Filling the Buckets
 At fixed intervals (100 milliseconds or .1 second), tokens are
added to the buckets based on the committed rate and peak
rate
– Peak and burst rate configured in bits per second
– Every interval add ( .1 second x peak rate) tokens to the peak bucket
– Every interval add ( .1 second x committed rate) tokens to
committed bucket
Fill rate tied to Fill rate tied to configured committed rate

configured peak rate T T T T T T T T T T
T T T T T T T
T
T
T
T
Peak T
Committed
T TT
TT T
TT TT
TTT
TT T
TT
TT TT
TT
Burst
TT T
TTTTT T T
T
TTTT
T
T TTT
T
Burst
T TTTT
TTT
TTTT T
T
T T TT
T
T
T T TT
T TT
T TT
T
T
TT T
T TT
TTT T
TTT
TT
TT
T
T TT
T T TTT
T T T TTTT
TT TTT
TT
T
TT
TTT
T T
TT
T
T
T
TTT
TT
TT
T
TT
TT
TT
TT
TT T
TT
TT
TT
T
T
 The token level of each bucket is determined by a

combination of fill rate, size of packets, and elapsed time
between packets
Filling the Buckets

The top part of this slide shows the meaning of two more rate-limit parameters: peak rate and
committed rate. Both are used to determine the fill rate of their respective buckets. If you set the
committed rate to 128,000 bps, tokens are added to the committed (green) bucket at a rate of 128,000
bps (16 K bytes per second), regardless of the traffic. If no traffic passes through the rate limiter, the
bucket continues to fill until it reaches the committed burst setting.
Token Drain Rate
Traffic passes through the rate limiter causing a draining of tokens. The drain rate is dependent on how
large the packets are and how much time elapses between packets. Note that at any given instant the
level of tokens in each bucket is a function of the fill rate, size of packets, and elapsed time between
packets.

Running Packets by the Buckets

Time
(Full) …….. Color as green
….. (committed)
.
Tokens (bytes)
Committed Burst
Color as yellow
(conformed) .
Token buckets
replenished in between
packets
(Empty) Peak Burst

Color as red
(exceeded)
 Graph shows token depletion and token replenishment

– Rate of token replenishment is determined by two parameters:
committed rate and peak rate in terms of bps
– Committed/conformed (color) boundaries are determined by two
parameters: committed burst and peak burst in terms of bytes
– Slope of packet lines is a function of the line speed
Changes in Token Levels

As packets are received on an interface with a rate limiter applied, the level of tokens in each bucket
dynamically changes:
•Tokens are added every 100-ms sample period; and
•Tokens are removed based on the size and rate of incoming packets.
This slide is a very simplistic example and shows two bursts of packets. With the first burst of three
packets, enough time passes between packets that the buckets are replenished, with the result that all
packets fall within the committed (green) zone. The packets are also very small.
The second burst consists of larger packets that have very little time between them. In this instance,
more tokens are removed from the buckets than added. In time, the buckets are exhausted such that
each packet falls within a different color zone and is handled based on the configured rate-limiter
action for each color. When the first large packet arrives, there are enough tokens in the committed
burst and peak burst bucket so the packet is colored green, and tokens are decremented from both
buckets. When the second large packet arrives, there are not enough tokens in the committed burst
bucket for the entire size of the packet, but there are enough tokens in the peak burst bucket. In this
case, the packet is colored yellow, and tokens are decremented from the peak burst bucket. When the
last large packet arrives, there are not enough tokens in the peak burst packet for the entire packet.
Therefore, the packet is colored red, and no tokens are decremented from either bucket. Note that an
entire packet is either colored green, yellow, or red. It is not possible to have part of a packet yellow
and the other part red.

Congestion Management
QUEUE
Yellow Red
Queue Drop
Drop
Limit Threshold
Threshold
50% 25%
Configuration: Color: Data Rate:
Committed Green Below Committed Burst

Conformed Yellow Below Peak Burst
Exceeded Red Above Peak Burst
Congestion Management
When you configure the rate-limit profile, a side effect is the internal tagging of packets with a drop
preference. The color-coded tag is added automatically when the committed and peak burst values for
an interface's rate-limit profile are exceeded. The egress forwarding controller uses this drop
preference when there is contention for outbound queuing resources within the E-series router, and it
uses it to decide which packets are dropped.
The queuing system uses drop eligibility to select packets for dropping when congestion exists on an
egress interface. This method is called dynamic color-based threshold dropping. Each packet
classified by a rate-limit profile has a 2-bit tag associated with it internally in the E-series router. The 2-
bit code assigns a color code to the packet—red, yellow, or green. Each packet queue in the system
has two color-based thresholds as well as a queue limit. When an egress queue exceeds the red drop
threshold due to congestion, packets that were marked red by the rate-limit profile are not queued.
When the yellow drop threshold is reached, packets marked yellow are not allowed into the egress
queue. Green packets are not dropped until the queue limit is reached.
Remember that this internal tagging is done automatically when a rate-limit profile is applied to an
interface and does not necessarily reflect the operation of the policy on an interface.


 Configuring Rate-Limit Profiles
Configuring Rate-Limit Profiles


Two-Rate Rate Limiter Configurable Parameters

 Configurable parameters:
Peak Bucket
– Committed rate
Conformed
 Rate tokens added to committed bucket (bps) Peak Action
Burst
– Committed burst 1
 Maximum number of tokens in committed bucket (bytes) Committed Bucket
– Peak Rate Committed
Committed Action
 Rate tokens added to peak bucket (bps) Burst 2
– Peak burst
 Maximum number of tokens in peak bucket (bytes)
– Committed action
 Action when both buckets have enough tokens
– Conformed action
 Action when only committed bucket has enough tokens
– Exceeded action
 Action when peak bucket does not have enough tokens
– Mask value
 Identify the appropriate bits in the ToS field
Two-Rate Rate Limit Configurable Parameters

There are two types of rate limiters: two-rate and one-rate rate limiters. The parameters for the two-
rate rate limiter are listed on the slide. The two-rate rate limiter allows us to build tiered rate-limit
services and specify different treatments for packets at different rates. Having a committed rate and a
peak rate allows us to configure two different fill rates for the token buckets. We can, for example,
configure the fill rate on the peak token bucket to be faster than the fill rate on the committed bucket.
This configuration allows us to accommodate bursts of traffic, but, through coloring, it allows us to
identify which packets are committed and which ones are not.

Configuring Two-Rate Rate Limiters

 Option 1: Use system defaults
– Determine desired committed rate and peak rate
– Let system calculate committed burst and peak burst based on a
100-ms burst
 Burst = (rate in bps X .1 second) / 8
– Set actions for committed, conformed, and exceeded packets
 Option 2: Configure everything for added flexibility
– Determine desired committed rate and peak rate
– Calculate committed burst:
 Start at 1–2 seconds worth of the committed rate (in bytes)
 Example: For a committed rate of 128 Kbps, bursting beyond that rate for 2
seconds = 256 Kb/8 => 32,000 bytes
 Cannot be set to less than 8 K bytes (64 Kb/8 = 8000 bytes)
– Calculate peak burst:
 Start at 1–2 seconds worth of the peak rate (in bytes)
– Set actions for committed, conformed, and exceeded packets
– Burst size should accommodate the largest packet size
Option 1: Use System Defaults

When you configure rate-limit profiles, you can use two different options. With the first option, you
determine and configure the committed rate and peak rates. With this approach, you let the system
calculate the burst size for you. The parameter is configured in bytes and determines how many tokens
the committed bucket will hold. By default, the system calculates the committed burst and peak burst
based on a 100-ms burst. For example, if you configure a committed rate of 128 Kbps, the system sets
the committed burst to be equal to (128000 * .1) / 8, or 1600 bytes. The system configures the
committed burst size to be equal to 8192 bytes because a burst size cannot be set to less than 8K,
specifically 8192 bytes.
Having configured the various bandwidth thresholds, you must still apply an action for each class of
traffic—committed, conformed, and exceeded. The default actions are to transmit traffic below the
committed rate, transmit conformed traffic (traffic above the committed burst rate but below the peak
burst), and drop exceeded traffic (traffic that exceeds the peak burst). The other action available is
mark, which sets a code in the IP datagram header ToS field.
Option 2: Configure Everything
With the second option, you can configure each parameter to provide a flexible solution. As with the
first option, you determine and configure the committed rate and peak rates. For the burst sizes, you
must determine what the amount of traffic you will accept from a customer over the committed rate.
The example uses a rate-over-time formula, setting the committed burst to equal the amount of data
received in 2 seconds at the committed rate. If the committed rate is 128 Kbps, in 2 seconds at the
committed rate, we would receive 256 Kbps of data. Because the committed burst is configured in
bytes, not bits, we divide 256,000 by 8 to arrive at the committed burst parameter of 32,000. The
minimum and default value for committed burst is 8192 bytes, or 64 Kbps. Configuring peak values
follows the same model: configure the peak rate then determine the depth of the peak token bucket by
configuring a peak burst using the rate-over-time formula. You must also configure the actions for
committed, conformed and exceeded packets.

Configuring a Two-Rate Rate-Limit Profile

1 Mb Committed
1.5 Mb Peak
DSL
Data within the

committed access
rate is given priority
erx7(config)# ip rate-limit-profile Tiered1Meg two-rate

erx7(config-rate-limit-profile)#committed-rate 1000000
erx7(config-rate-limit-profile)#committed-burst 125000
erx7(config-rate-limit-profile)#peak-rate 1500000
erx7(config-rate-limit-profile)#peak-burst 187500
erx7(config-rate-limit-profile)#mask 255
erx7(config-rate-limit-profile)#committed-action mark 40
erx7(config-rate-limit-profile)#conformed-action mark 48
erx3(config-rate-limit-profile)#exceeded-action drop
Two-Rate Rate-Limit Profile

Using a two-rate rate limiter, we can build a tiered service. By assigning both committed and peak
rates we can prioritize traffic based on bandwidth utilization.
With this configuration, the two-rate three-color marker defines the difference in IP packet handling
internally to the router while the ToS field marking identifies the relative priority of packets to upstream
routing elements.
This slide shows the configuration of an IP two-rate rate-limit profile. The example on this slide uses
the command ip rate-limit-profile TierediMeg two-rate. If you used the configuration command rate-
limit-profile TierediMeg, the result would be the same. The keywords ip and two-rate are the default
values and are not required.
Like CLACLs, rate-limit profiles are also global in nature. They are not specific to a virtual router. They
are also shareable. You can configure one rate-limit profile that many policies can use in many virtual
routers.
Use the mask value to set the appropriate bits in the ToS field of the IP packet header. The mask
settings include the following:
•IP precedence: OxEO (three most significant bits) or decimal 224;
•DS field: OxFC (six most significant bits) or decimal 252; and
•TOS (IP): OxFF (default) or decimal 255.

Configuring a Hard Rate-Limit Profile―Two Rate
1 Mb Hard Limit
D SL
Data within the

committed access
rate is given priority
 Two ways to configure hard rate-limit profiles:

– Configure the committed burst = peak burst
– Only configure a committed rate, not a peak rate
Two Ways to Configure Hard Rate-Limit Profiles

You can use a rate limiter to apply a hard limit to the bandwidth supported on an IP interface. In this
instance, we configure it as a clipping function—any traffic beyond the 1-Mb rate is simply discarded.
There are two ways we can configure this with a two-rate rate limiter: we can set both the committed
burst and the peak burst to the same value, or we can choose to not configure a peak rate. Both
approaches achieve the same result—a hard limit on the acceptable bandwidth of 1 Mbps.

Hard Two-Rate Rate Limit―Option 1

1000 bytes
Fill rate:
transmit committed
bytes
rate x (drop)
125000 bytes sample
period
transmit
Fill rate: (transmit)
125000 bytes peak rate x
sample
period sample period
drop
erx7(config)#rate -limit-profile 1Mbps-hard-1 two-rate

erx7(config-rate-limit-profile)#committed -rate 1000000
erx7(config-rate-limit-profile)#committed -burst 125000
erx7(config-rate-limit-profile)#peak -rate 1000000
erx7(config-rate-limit-profile)#peak -burst 125000
erx7(config-rate-limit-profile)#committed -action transmit
erx7(config-rate-limit-profile)#conformed -action transmit
erx7(config-rate-limit-profile)#exceeded -action drop
Hard Rate Limits: Option 1

With the first option, both the peak and committed buckets have the same depth and are refreshed at
the same rate. As packets are received, tokens are removed from both buckets for each byte in the
packet, and both buckets are drained at the same time so there is never any conformed traffic—just
committed and exceeded.

Hard Two-Rate Rate Limit―Option 2

Fill rate:
transmit committed
bytes
rate x (drop)
12800 bytes
sample
period
8192 bytes Empty - no action
Fill rate:
(default) (transmit)
0 x sample
period
drop
sample period
erx7(config)#rate -limit-profile 1Mbps-hard-2
erx7(config-rate-limit-profile)#committed -burst 125000
erx7(config-rate-limit-profile)#run show rate 1Mbps-hard -2
Rate Limit Profile Table

---- ----- ------- -----
IP Rate-Limit-Profile: 1Mbps-hard-2
Profile Type: two-rate
Reference count: 0
Committed rate: 100000
Committed burst: 125000
Peak rate: 0
Peak burst: 8192
Mask: 255
Committed rate action: transmit
Conformed rate action: transmit
Hard Rate Limits: Option 2

With the first option, the values for committed rate and burst are configured as shown on the slide, and
you can take the default values for the remaining parameters. The default peak rate is set to a value of
0, and the peak burst is set to a value of 8192. The default committed and exceeded actions are
transmit and drop respectively. When traffic is received, both token buckets are decremented a token
for each byte received. The peak bucket is emptied before the committed bucket, and, with a refresh
rate of 0, it is never replenished. Once again, the result is that there is no conformed traffic—only
committed and exceeded.
With both options, we achieve the same results—a hard limit on the acceptable bandwidth of 1 Mbps.
Note that this rate-limit profile uses the default rate-limit profile protocol (IP) and type (two-rate)
because they were not specified.

Hard Rate Limit Using System Defaults

192.168.254.1 10.10.10.10
www.disney.com
172.16.199.250
video.server.com
192.168.200.16
erx7(config)#rate -limit-profile 512Kbps

erx7(config-rate-limit-profile)#run show rate-limit-profile
Rate Limit Profile Table
---- ----- ------- -----
IP Rate-Limit-Profile: 512Kbps
Profile Type: two-rate
Reference count: 0
Committed rate: 512000
Committed burst: 8192
Peak rate: 0
Peak burst: 8192
Mask: 255
Committed rate action: transmit
Conformed rate action: transmit
Exceeded rate action: drop
Hard Rate Limits Using System Defaults

The configuration on the slide shows a hard rate-limit profile using system defaults. Only the
committed rate is configured.

TCP Connections and Two-Rate Rate Limiters

Two-Rate Rate Limiter
TCP Windows
(number of packets) 2
16
32 X (multiple packets dropped by rate limiter)

2
4 Due to a loss of so many packets, TCP cuts back to original window size.
And then gradually ratchets up again …. Overall, transfer rate

remains below committed rate.
 Two-rate rate limiters are not TCP-friendly

– Dropped action of rate limiter causes wide variations in TCP
window sizes
– Overall transfer rate ends up well below desired committed rate
TCP Connections and Two-Rate Rate Limiters

The slide shows a problem inherent in rate limiters when the traffic flows are TCP sessions. To help
manage congestion in an IP network, TCP uses a windowing utility to monitor how much traffic the
network can support. A TCP session starts by sending a single packet and waiting for an
acknowledgement. If it receives an acknowledgement message, it increases the window size to allow
two packets to be transmitted before it receives the next acknowledgement. When those messages are
acknowledged, it increases its window to four packets, then eight, then sixteen, etc. As the window
gets larger, TCP can sense congestion in the network by monitoring unacknowledged packets. If one
packet is lost (that is, not acknowledged), TCP cranks back its window size one step—for example, if
the window was at 32, and a single packet is lost, TCP shortens the window to sixteen. However, if
more than one packet is lost, TCP drops back to the start and runs this slow-start algorithm over again.
The problem with rate limiting is that it is not very supportive of this TCP windowing utility. Once the
rate limit is reached, packets start being clipped without regard to the impact on TCP. If this happens,
we might end up with a transmission graph similar to the one displayed on the slide—which is not a
very efficient transmission model.

Two-Rate Versus One-Rate Rate Limiters

 Two types of rate limiters:
– Two-rate rate limiter – One-rate rate limiter
(configurable parameters): (configurable parameters):
 Committed rate  Committed rate
Fill rate of Fill rate of
 Committed burst each bucket  Committed burst both
 Peak rate can be  Excess burst buckets is
 Peak burst different  Committed action same
 Committed action  Conformed action
 Conformed action  Exceeded action
 Exceeded action  Mask value
 Mask value
Conformed
Excess Burst Action
1
Conformed
Peak Action Committed
Committed Action
Burst
1 Burst 2
Committed
Committed Action Exceeded Action
Burst 2
Exceeded Action
Types of Rate Limiters

Recall that there are two types of rate limiters. The parameters of each are listed on the slide. The
biggest difference between the two is that the two-rate rate limiter has a peak rate and the one-rate
rate limiter does not.
The two-rate rate limiter allows us to build tiered rate-limit services and specify different treatments for
packets at different rates. Having a committed rate and a peak rate allows us to configure two different
fill rates for the token buckets. We can, for example, configure the fill rate on the peak token bucket to
be faster than the fill rate on the committed bucket. This configuration allows us to accommodate
bursts of traffic but, through coloring, it allows us to identify which packets are committed and which
ones are not.
The one-rate rate limiter still has two token buckets, but only a single fill rate—the committed rate—is
configured. One-rate rate limiters are required to provide TCP-friendly rate limiters.
We illustrate examples of two-rate rate limiters on the next slides.

A More TCP-Friendly Behavior

Single-Rate Rate Limiter
8
TCP Windows
(number of packets)
16
32 X (drop one packet but allow following

16 ones to pass …up to a limit)
17
Due to a loss of one packet, TCP cuts back to
previous window size.
19
23
Transfer will alternate between two optimized window sizes…
achieving something closer to the committed rate.
 Drop a single packet but allow subsequent packets to

pass: TCP window reduction is less severe
– A single-rate rate limiter does this (next slide)
The Single-Rate Rate Limiter

The E-series router implements a single-rate rate limiter, which you can configure to provide more
efficient service to TCP applications. With the single-rate rate limiter, when the committed rate is
exceeded, the rate limiter drops a single packet and then resumes transmission up to a configurable
burst window. The single, unacknowledged packet should cause TCP to cut its transmission rate in
half rather than falling all the way back to its initial window size.

Configuring a One-Rate, TCP-Friendly

Rate Limiter
This keyword determines type of rate limiter
desired.
erx7(config)# rate-limit-profile Police_8M_tcp_friendly one-rate

erx7(config- rate-limit- profile)# committed-rate 8000000
erx7(config- rate-limit- profile)# committed-burst 1500000 Drop first packet but let
erx7(config- rate-limit- profile)# excess-burst 3000000 following packets through, up
to excess burst.
erx7(config- rate-limit- profile)# committed-action transmit
erx7(config- rate-limit- profile)# conformed-action transmit
erx7(config- rate-limit- profile)# exceeded-action drop (drop)
1000 bytes (transmit)
bytes
Fill rate:
transmit committed
Committed Burst rate x
1500000 bytes sample
period
transmit (transmit)
Fill rate:
peak rate x
Excess Burst sample sample period
3000000 bytes period
drop
Configuring a One-Rate Rate Limiter

A sample configuration of a single-rate rate limiter is shown on the slide. Note that the name of the
profile is followed by the key word one-rate. If this is not explicitly stated, the default of two-rate is
implied.
The key behavior of this type of rate limiter is the action that is taken on conformed packets. The
configured action is to transmit all conformed (yellow) packets. However, the actual behavior of this
algorithm is to drop the first conformed packet and transmit subsequent packets (up to the excess
burst). The TCP nodes react to this small loss by ratcheting down their window size (probably half of
the existing window) but not with the same magnitude as when multiple packets are lost. Because the
subsequent packets are acknowledged, TCP tries to maintain the next lower window size, or push it up
again.
Some useful guidelines in configuring a single-rate rate limiter are that the committed burst size should
be 1.5 seconds worth of the committed rate (in bytes) and that the excess burst size should be twice
the committed burst size.


 Configuring Policy Lists with Multiple Rules
Configuring Policy Lists with Multiple Rules


Policy Lists with Multiple Rules

192.168.254.1 10.10.10.10
www.disney.com
172.16.199.250
video.server.com
192.168.200.16
 Adding policy rules or classifier groups to the outbound

policy list
– If you see Telnet traffic:
 Filter it
– If you see FTP traffic:
 Rate-limit it to 1 Mbps
– If you see any other traffic:
 Rate-limit it to 512 Kbps
 How do you control the order of the classifier groups?
– Precedence
Modifying the Outbound Policy List

In the first configuration example, we created a policy list with a single policy rule or classifier group. If
packets meet the condition, they are filtered. Otherwise, they are forwarded according the IP route
table. Now we are going to add additional policy rules or classifier group entries to this policy list. In our
simple network, we show how to give more bandwidth to FTP traffic and rate-limit all other types of
traffic to 512 Kbps.
Controlling the Order of the Classifier Groups
When you have more than one policy rule or classifier group in a policy list, which group is evaluated
first? How can you control the order in which the rules or classifier groups are evaluated? On the E-
series router, you control the order of the policy rules by configuring a precedence value for each
classifier group. The classifier group with the highest precedence value is evaluated first. Rules are
evaluated from the highest precedence value to the lowest precedence value. The lower numerical
value is the highest precedence.

Policy Rule Precedence

 Policy rule precedence:
– Policy lists can have more than one policy rule or classifier group
– Each classifier group has a configured precedence number
 0–32k
 The lower the number the higher the precedence
 Default precedence 100
 Policy manager processing:
– The router evaluates packets against the classifiers in the policy list
starting with the classifier group with the lowest precedence
– If the packet does not meet the condition, the router evaluates the
classifier group with the next higher precedence
– Once a condition is met, the router takes the action(s) associated
with the matching classifier group
– If the packet does not match any of the classifiers, it is forwarded
based on the IP route table
– Classifier groups with the same precedence are evaluated in the
order they were configured
– 512 classifier groups per policy list
Policy Rule Precedence

Because policy lists attached to IP interfaces can contain more than one policy rule, you can configure
a precedence value for each classifier group indicating the rule's priority. The lower the number you
assign to the rule, the higher the precedence that rule has. Precedence values range from 0 to 32 K. If
you do not configure a value, the default precedence is 100.
Policy Management Processing
The router checks packets against the classifiers in the policy list beginning with the classifier group
with the highest precedence which is the lowest numerical precedence value. If a packet does not
match the condition, the router performs the same process with the classifier group with the next lower
precedence or higher numerical value. When a packet matches a condition, the router takes the action
or actions associated with the classifier group and does not evaluate any other classifier groups. If the
packet does not match the conditions in any classifier, the router forwards it based on the IP routing
table. If classifier groups have the same precedence value, they are processed in the order in which
they were configured. Each policy list supports up to 512 classifier groups.

Multiple Outbound Policy Rules

Outbound Policy Rules
Protocol Source IP Source Port Destination IP Destination Port Action Precedence
IP any any any any rate-limit 512Kbps ???
TCP any 20-21 any any rate-limit 1Mbps ???
TCP any any any 23 filter 100
FTP server
10.10.10.10 telnet 10.1.1.1
www.disney.com
172.16.199.250
 Outbound policy rule precedence configuration

– What precedence should be configured for the 512 Kbps rate
limit?
– What precedence should be configured for the 1-Mbps FTP?
Outbound Policy Rule Precedence Configuration

We now add two additional policy rules to our existing outbound policy list. The first policy rule we
configured has a precedence of 100 because we did not specify it when it was initially configured.
What precedence values should be configured for the two additional policy rules? We want to rate-limit
FTP traffic to 1 Mbps and rate-limit all other traffic to 512 Kbps.

Precedence Configuration: Option 1

IP any any any any rate-limit 512Kbps 80
TCP any 20-21 any any rate-limit 1Mbps 90
FTP server
10.10.10.10 telnet 10.1.1.1
www.disney.com
172.16.199.250
 Will this configuration work?

– What happens to Telnet traffic?

If we use this policy rule precedence configuration, all traffic, including Telnet and FTP traffic, will be
rate-limited to 512 Kbps. The policy rule with the lowest precedence value (80) is evaluated first. All
packets meet this classification (any source IP address, any destination IP address), and the
associated action is taken for all packets. The two other rules are never evaluated.


FTP server
10.10.10.10 telnet 10.1.1.1
www.disney.com
172.16.199.250


If we use this policy rule precedence configuration, Telnet traffic is filtered, but all other traffic is rate-
limited to 512 Kbps. With this configuration, the Telnet classifier is evaluated first based on it having
the lowest precedence value (100). Telnet traffic meets this condition and is filtered. Packets that do
not meet this condition are evaluated against the classifier with the next higher precedence value
(110). All remaining packets meet this classification (any source IP address, any destination IP
address), and the associated action is taken. The rule with precedence value of 120 is never
evaluated.


FTP server
10.10.10.10 telnet 10.1.1.1
www.disney.com
172.16.199.250


If we use this policy rule precedence configuration, Telnet traffic is filtered based on the rule with a
precedence value of 100. All other traffic is evaluated against the classifier with the next higher
precedence value (110). This rule rate-limits FTP traffic to 1 Mbps. Traffic coming from
www.disney.com does not meet the first two rules so it is evaluated against the rule with the next
higher precedence value (120). All remaining packets meet this classification (any source IP address,
any destination IP address), and the rate-limit action is taken. This configuration works.

Configuring Multiple Classifier Groups

 Configure IP classifier list identifying FTP traffic:
erx7(config)#classifier-list ftp tcp any any range 20 21
erx7(config)#classifier-list ftp tcp any range 20 21 any
 Modify IP policy list to add FTP rate-limit policy rule:

erx7(config)#policy-list to-user
erx7(config-policy-list)#classifier-group ftp ?
precedence Specify the precedence of this classifier list
<cr>
erx7(config-policy-list)#classifier-group ftp precedence 110
erx7(config-policy-list-classifier-group)#rate-limit-prof 1Mbps-hard
 Add default classifier group to rate-limit any other traffic:

erx7(config-policy-list)#classifier-group ?
* The default classifier group
WORD (40 char max) The classifier list name
erx7(config-policy-list)#classifier-group * precedence 120
erx7(config-policy-list-classifier-group)#rate-limit-profile 512Kbps
 When does the modified policy list take effect?

– As soon as you exit out of policy list configuration mode
Configure Classifier Lists for FTP Traffic

Before we can add the additional policy rules, we must configure an extra classifier list identifying FTP
traffic. We configure one classifier that identifies FTP traffic coming from the user or going to the user.
Remember that when there are multiple clauses, the classification process is an OR function—if the
packet matches all the fields specified in the first match clause OR all the fields specified in the second
match clause, the CLACL reports a hit to the router.
Add the FTP Rate-Limit Policy Rule
The next step is to modify the existing to-user policy list and add additional classifier groups. Recall
that each classifier group identifies a specific classifier list and the action to take if a packet matches
that classification. In this example, we are adding two additional classifier groups. The first classifier
group references the classifier list ftp and has a precedence of 110. If a packet matches this
classification, the associated action is taken. In this example, packets matching the classifier list are
rate-limited using the 1Mbps-hard rate-limit profile we created earlier. Note that this policy list
configuration example used the legacy command policy-list name.
Add the Default Classifier Group to Rate-Limit All Other Traffic
The last step is to add a classifier group entry that identifies all other traffic. The asterisk (*) is a
reserved keyword identifying any IP traffic. You can use this keyword instead of creating a classifier list
with an any any condition. We configure the default classifier group with the highest precedence value
(120) so that only traffic that does not meet the first two conditions is rate-limited to 512 Kbps. Within
the classifier group, we specify the rate-limit action, referencing the 512 Kbps rate-limit profile we
created earlier.
When Does the Modified Policy Take Effect?
Remember that this policy list could be attached to many IP interfaces. When you exit out of policy list
configuration mode, the interfaces referencing this policy list are automatically updated with the new
policy list configuration.

Examining Updated Policy Lists

erx7#show policy-list to-user
Policy Table
------ -----
IP Policy to-user
Reference count: 1
filter
Classifier control list: ftp, precedence 110
rate-limit-profile 1Mbps-hard
Classifier control list: *, precedence 120
rate-limit-profile 512Kbps
Referenced by interface(s):
FastEthernet3/2.71 output policy, statistics enabled, virtual-router
default
Referenced by profile(s):
No profile references
Examining Updated Policy Lists

This slide shows the modified policy list using the show policy-list command. Notice that this command
only provides configuration information, specifically the precedence value of each classifier group.

Examining Interface Statistics

erx7#show ip interface fast 3/2.71
FastEthernet3/2.71 line protocol VlanSub is up, ip is up
Description: vlan-to-erx1
Network Protocols: IP
Internet address is 70.70.70.2/255.255.255.0
(Some statistical information deleted for brevity)
IP policy output to-user
classifier-group drop-traffic-to-user entry 1
filter
classifier-group ftp entry 1
committed: 1452 packets, 687292 bytes, action: transmit
conformed: 0 packets, 0 bytes, action: transmit
exceeded: 0 packets, 0 bytes, action: drop
classifier-group ftp entry 2
0 packets, 0 bytes
classifier-group *
rate-limit-profile 512Kbps
Examining Interface Statistics

This slide shows a partial capture of the IP interface statistics. Each classifier group entry is listed, and
statistics are maintained per classifier list clause. While the classifier groups are displayed in the order
they are processed, the precedence value is not shown in this display.

Classifier Groups with Multiple Actions

192.168.254.1 10.10.10.10
www.disney.com
172.16.199.250
video.server.com
192.168.200.16
 Modifying the outbound policy list with multiple actions per

classifier group
– If you see Telnet traffic:
 Filter it
 Log it
– If you see FTP traffic:
 Rate-limit it to 1 Mbps
 Mark the ToS field
– If you see any other traffic:
 Rate-limit it to 512 Kbps
Modifying the Outbound Policy List

In the previous configuration example, we created a policy list with multiple classifier groups. Each
classifier group had a single action associated with it. It is also possible to have multiple, nonconflicting
actions associated with a classifier group. For example, you might want to add the log action to a
classifier group to aid in troubleshooting a new configuration. This example also shows how to give
more bandwidth to FTP traffic and mark the ToS field indicating that this traffic should receive higher
priority within the network.

Configuring Policy Manager Packet Logging
 Add log action to existing classifier group entry:

erx7(config)#policy to-user
erx7(config-policy-list)#classifier-group drop-traffic-to-user prec
100
erx7(config-policy-list-classifier-group)#log
 Configure policy manager packet logging to console:
erx7(config)#log severity info policyMgrPacketLog
erx7(config)#log destination console severity info
erx7(config)#log here
 Test and verify:
erx7#telnet 70.70.70.1
INFO 11/04/2004 21:17:42 policyMgrPacketLog:
drop-traffic-to-user tcp FastEthernet3/2.71 70.70.70.2.1040
70.70.70.1.23 filtered
drop-traffic-to-user FastEthernet3/2.71 number of hits = 1
drop-traffic-to-user tcp FastEthernet3/2.71 70.70.70.2.1040
70.70.70.1.23 filtered
drop-traffic-to-user FastEthernet3/2.71 number of hits = 2
Configuring Classifier Group to Log Packets

The first step is to modify the existing to-user policy list and add an additional classifier group action.
Return to the classifier group drop-traffic-to-user, specifying the precedence value, and add the log
action. When modifying classifier group actions, always specify the configured precedence value. If
you do not specify the value, you might actually change the meaning of the policy list. If you do not
specify the precedence value, the system assumes that you want to change it to the default value of
100.
Configuring Policy Manager Packet Logging to the Console
The next step is to configure policy manager packet logging. First, set the category policyMgrPacketlog
to a filter level of info. Next, change the console log destination filter level to info as well. If you are
logging to a Telnet session, direct logging to the specific Telnet session using the log here command.
Testing and Verifying
The final step is to test the new configuration. In this example, we tried to establish a Telnet session
from the router to the user. The Telnet session was not established, and the action was logged to the
console session.
The LM-10 uplink line module does not support the log action. See the Policy Management
Configuration Guide for more information.

Steering Traffic to a Specific Interface

192.168.254.1 10.10.10.10
www.disney.com
172.16.199.250
video.server.com
192.168.200.16
 Rate-limit inbound and outbound traffic to 512 Kbps
– Provide higher bandwidth to specific types of traffic
 FTP traffic rate-limited to 1 Mbps, all other traffic 512 Kbps
– Steer traffic to a specific interface or IP address
 Forward traffic destined for a content network to a captive portal
Policy Examples
This final policy example shows the concept of policy routing. We want to steer traffic destined for a
restricted content network to a captive portal for additional processing. This is a common configuration
in an SDX-300 environment. In this environment, content networks are restricted unless you have
agreed to activate a service and pay for the use of the service. The captive portal allows you to
activate this service, and the SDX-300 then sends down a dynamic policy to the router that allows you
access to the service.

Configuring Policy Routing

 Steering traffic with policy routing:
– To identify specific ranges of IP addresses, use a wildcard mask
– Configure IP classifier list identifying content network:
erx7(config)#classifier-list content ip any 192.168.200.0
0.0.0.255
– Add classifier group to steer traffic to the captive portal:
erx7(config-policy-list)#classifier-gro content precedence 90
erx7(config-policy-list-classifier-group)#forward next-hop
192.168.254.1
– The user sends a packet to the router with the destination IP
address = 192.168.200.16
 What IP address does the router look for in the forwarding table?
 What happens if the next-hop address is not reachable?
Steering Traffic with Policy Routing

Before we can add the additional policy rule, we must configure an extra classifier list identifying any
hosts on the content network as destination IP addresses. To identify specific IP address ranges, we
use wildcard masks. Wildcard masks are often referred to as reverse subnet masks. Quite simply that
means wherever there's a 1 in a regular subnet mask, you'll use a 0 in a wildcard mask. In this
example, the source IP address can be any IP address. To identify any host on the 192.168.200.0
255.255.255.0 network, we use a wildcard mask of 0.0.0.255.
The next step is to modify the existing to-user policy list and add an additional classifier group. This
classifier group references the classifier list content and has a precedence of 90. If a packet matches
this classification, the associated action is taken. In this example, packets matching the classifier list
are forwarded to a specific next-hop IP address instead of looking in the routing table for the packet's
destination IP address. The next-hop IP address must be reachable within the virtual router context. It
cannot cross virtual routers. If the next-hop address is not reachable, the packet is dropped.

Multiple Next Hops or Interfaces

 Configuring a list of forwarding solutions within a single
classifier group:
– Interface selected only if next-hop IP address is in the route table
or if the interface state is up
– To control interface selection, configure the order keyword
– Selection starts with lowest order number (default order is 100)
– Order also used for revertive behavior:
erx7(config-policy-list)#classifier-gro content precedence 90
192.168.254.1
2.2.2.2 order 110
erx7(config-policy-list-classifier-group)#forward interface
atm 6/0.34 order 120
Multiple Next Hops or Interfaces

Use the forward next-hop or forward interface action to route packets to a specific IP address or
interface. By default, packets are sent to this interface regardless of the state of the interface. If the
interface is down, the packets are dropped. If there is no route for the next-hop IP address, the packets
are also dropped. It is also possible to configure multiple next hops or interfaces for a single classifier
group. Traffic will be forwarded to the first element in the list that is reachable.
You can control the order of the list using the keyword order. The router attempts to forward packets to
the element with the lowest order number. The default order number is 100. In this example, if
192.168.254.1 is in the routing table, packets are forwarded to it. If this route is no longer available, the
router then attempts to forward packets to 2.2.2.2 if it is reachable.
The order keyword is also used for revertive behavior. If the router is currently forwarding packets to
2.2.2.2 and 192.168.254.1 becomes reachable, the router reverts to using it because it has a lower
configured order number.
Notice that is possible to mix forward next-hop and forward interface actions for the same classifier
group.
The LM-10 uplink line module does not support the forward next-hop action. See the Policy
Management Configuration Guide for more information.

Attaching Policy Lists to Dynamic Interfaces
 Attaching policy lists to dynamic interfaces

– Profiles:
erx7(config)#profile isp2
erx7(config-profile)#ip policy input from-user statistics enabled
erx7(config-profile)#ip policy output to-user statistics enabled
– RADIUS VSAs:
 Ingress-Policy-Name
 Egress-Policy-Name
 Ingress-Policy-Statistics
 Egress-Policy-Statistics
Attaching Policy Lists to Dynamic Interfaces

Up to this point, we attached policy lists to static IP interfaces. In a B-RAS environment, however, most
interfaces are built dynamically. There are two different approaches you can use to attach policy lists to
dynamic interfaces. With the first approach, you can include a policy statement in a profile definition.
You can optionally enable statistics. Note that it is not possible to enable baseline statistics within a
profile definition. With the second approach, you configure the RADIUS server to return the desired
policy list configuration using Juniper Networks VSAs.

Things to Keep in Mind

 Things to keep in mind when configuring policy lists:
– If you configure a classifier group with mutually exclusive actions,
the last one configured wins:
erx7(config)#policy-list mutually-exclusive
erx7(config-policy-list)#classifier-group ftp
erx7(config-policy-list-classifier-group)#forward
WARNING: This rule has replaced a previously configured rule.
erx7(config-policy-list-classifier-group)#
– Classifier lists, rate-limit profiles, and policy list names are CaSe
sensitive
– When modifying classifier group actions, always remember to
specify the configured precedence number
 If you don’t, you might actually change the behavior of the entire policy list
– No implicit deny any any rule in a policy list unless you
configure it!
 Exception to the rule: Policy list with no classifier group
Things to Keep In Mind When Configuring Policy Lists

If you configure a classifier group with mutually exclusive actions, the last one configured effectively
overwrites the previous rule. Mutually exclusive actions include filter and forward, forward next hop,
and forward interface.
Classifier lists, rate-limit profiles, and policy list names are case sensitive. Take care when returning
policy list names using RADIUS VSAs.
When modifying a classifier group action, always remember to specify the configured precedence
number. If you do not reference the configured precedence, the router assumes that you are trying to
change the precedence value to the default (100). If you modify an existing classifier group without
specifying the configured precedence, and the original rule had a lower precedence number, you might
dramatically change the behavior of the entire policy list.
On the E-series router, a policy list does not have an implicit deny any any rule as the last policy rule. If
you want to only allow specific types of traffic and drop or filter everything else, you must specifically
configure the default classifier group with a filter action. This rule should have the lowest precedence
number. The exception to this rule is a policy list that does not contain any classifier groups. The
system notifies you when you configure this situation.


 Troubleshooting Policies on the E-series Router
Troubleshooting Policies on the E-series Router


Examining Policy Configuration

 Examine rate-limit profile configuration:
erx7#show rate-limit-profile
erx7#show rate-limit-profile name
 Examine classifier list configuration:
erx7#show classifier-list
erx7#show classifier-list brief
erx7#show classifier-list name detailed
 Examine policy lists configuration:
erx7#show policy-list brief
erx7#show policy-list name
 Examine policy management configuration:
erx7(config)#run show configuration category policy
How Are the Rate-Limit Profiles Configured?

To examine the rate-limit profile configuration, use the show rate-limit-profile command. This command
only provides configuration information; it does not provide statistical information or indicate which IP
interfaces or policies are currently referencing it.
How Are the Classifier Lists Configured?
Use the show classifier-list command to show a summary of all classifier lists configured on the router.
If you include the keyword brief, you will also obtain how many times this classifier is referenced as
well as the number of entries per classifier list. To examine detailed information about a specific
classifier list, use the show classifier-list name command. These commands only provide configuration
information; they do not provide statistical information or indicate which IP interfaces or policies
currently reference them.
How Are the Policy Lists Configured?
To show a list of all configured policy lists, use the show policy-list brief command. To show detailed
configuration information about a specific policy list, use the show policy-list name command. This
command displays which classifier lists or rate-limit profiles are used in the policy list. It also shows
which IP interfaces currently have the policy list attached. This command does not provide statistical
information.
Examining the Router's Policy Configuration
To examine the router's policy configuration, use the command show configuration category policy.
This command provides a subset of the router's configuration.

Obtaining Policy Statistics

 How do I examine policy statistics for a specific IP interface?
erx7(config-subif)#ip policy output to-user statistics enabled
erx7#show ip interface fast 3/2.71
 How do I set a statistical baseline for a policy attached to an
IP interface?
erx7(config-subif)#ip policy output to-user statistics enabled
baseline enabled
erx7#baseline ip interface fast 3/2.71
erx7#show ip interface fast 3/2.71 delta
Examining Policy Statistics for a Specific IP Interface

Remember that policies are global in nature until they are attached to an IP interface. Also keep in
mind that one policy can be shared by several IP interfaces. IP interface policy statistics are not
enabled by default. When a policy is attached to an IP interface, you can enable statistics using the
configuration command ip policy output name statistics enabled. To examine these statistics, use the
show ip interface interface-type slot/port. subinterface command. For dynamic IP interfaces, enable
statistics within the profile definition or by using RADIUS VSAs (Ingress-Policy-Statistics and Egress-
Policy-Statistics).
Setting a Statistical Baseline for a Policy Attached to an IP Interface
You can use the configuration command ip policy output name statistics enabled baseline enabled to
set a statistical baseline for a policy attached to an IP interface. Then use the show ip interface
interface-type slot/ port. subinterface delta command to examine the current statistics.

Useful Logging Categories
 Useful logging categories for policy management:

– policyMgrAttachment
– policyMgrGeneral
– policyMgrPacketLog
Additional Logging Categories for Policy Management

This slide lists several useful logging categories to aid in troubleshooting policies on the router.

Module Review
1. How would you define the policy management function in
the E-series router?
2. What is the flow of packets through the E-series router?
3. What type of information is configured in a classifier list?
4. A policy is a condition and an action. Where are the
actions configured?
5. How can you obtain policy statistics?
6. What is the difference between a one-rate and a two-rate
rate-limit profile?
7. How do you control the order of classifier groups in a
policy list?
8. How do you attach a policy list to a dynamic interface?

•The policy management functions in the E-series router;
•The packet flow in an E-series router;
•The line module components responsible for Policy Management;
•Configuring CLACLs;
•Configuring rate-limit profiles;
•Configuring policy lists; and
•The various show commands used to examine policy configuration.

Lab 7: Configuring Policy
Lab Objectives:
Configure and test classifier lists, rate-limit profiles,
and policy lists to control Telnet, FTP, and ICMP traffic.
Lab 7: Configuring Policy



Module 8: System Administration

Module Objectives
 After successfully completing this module, you will
be able to:
– List and describe the different reload options for the router
– Perform the process to upgrade software on the router
– List the different options to downgrade software on the
router
– Perform the process to recover from a corrupted flash
– Explain the password removal process
– List and explain the methods for accessing the CLI

• The different reload options for the router;
• The process to upgrade software;
• The various options to downgrade software;
• Recovering from a corrupted flash;
• Removing passwords;
• The methods for accessing the CLI; and
• Enabling and using FTP server functionality.
Module 8: System Administration 8-2

Agenda: System Administration

 Upgrading and Downgrading Software
 Backup Boot Configuration and Slot Configuration
 Rebuilding Flash Cards and Password Removal
 Accessing the CLI
 Other System Administration Tasks
Upgrading and Downgrading Software


Rebooting Review
 The router needs two things to boot or reload:
– Configuration file and operating system
 Stored on the flash
 To view current boot configuration:
erx7#show boot
System Release: erx_7-3-0.rel

System Configuration: running-configuration
Note: This system is not configured with backup
settings.
erx7#
What Is Needed to Boot?

The E-series router always needs two things to boot or reload:
• A configuration file: This file is known as the system configuration, and it is stored on the
flash. By default, the router boots using the current configuration or state of the system,
otherwise known as the running-configuration. The running-configuration is a hidden file
stored in a reserved area on the flash. You cannot delete or overwrite the running-
configuration. If you view a directory on the flash, you will never see a file called "running-
configuration." You can configure the router to boot using a different configuration file located
on the flash. Remember that all configuration files must end with the . cnf file extension.
• An operating system: The router's version of the operating system is known as the software
release. The software release is also stored on the flash. From this point on, the operating
system will be referred to as the software release.
Viewing the Current Boot Configuration
To determine which system configuration file and software release the E-series router will use the next
time it reloads, perform the show boot CLI command. To determine the software release currently
running, perform the show version command.

Router Reload Options

 Router reload options:
– Immediate reload including optional message :
erx7#reload Upgrade software to newer version
– Schedule reload:
erx7#reload at 13:10 nov 19
erx7#reload at 30 Reloading ERX in 30 minutes
– Verify reload configuration:
erx7#show reload
Reload scheduled for MON NOV 19 2006 13:10:00 UTC
Reload reason: Reloading ERX in 30 minutes
– Reload a specific slot:
erx7#reload slot 2
Options
You can reboot the router several different ways:
• Until now, we have used the simple reload command, which immediately reboots the router.
You can also include a text line indicating why the router is being reloaded. This text is
included in the router's reboot history file. In this example on the slide, the router will reboot
immediately with the reason, "Upgrade software to newer version."
• You can perform a scheduled reboot, specifying a specific time and date. This feature might
be useful during a software upgrade. With the first example on the slide, the router will
reboot on November 29 at 13:00 (or 1:00 in the afternoon). You can also include a reason in
the command. If the router reloads before the scheduled reload time, the scheduled reload
configuration is not affected. You can also perform a reload in a specified amount of time. In
the second example on the slide, the router will reboot in 30 minutes with the reason,
"Reloading ERX in 30 minutes". The reason is then stored in the reboot . ht y file; you can
view it using the show last command.
• To verify any type of scheduled reload configuration, use the show reload command. You
can cancel scheduled reloads using the reload cancel command.
• Finally, you can also reboot a single slot in the router.

Upgrading Software: Step 1

Router Flash
erx_7-0-0.rel !
Internet
Juniper Networks
FTP Server FTP Server
10.13.7.101
 Initial setup:
– Copy new release software to local FTP server
– Configure host entry on router for local FTP server and verify
connectivity
erx7(config)#host ftpServer 10.13.7.101 ftp erx7 mypassword
erx7(config)#run ping ftpServer
Resolving "ftpServer" ...
!!!!!
Success rate = 100% (5/5), round-trip min/avg/max = 0/0/1 ms
erx7(config)#
Initial Setup
The next few slides describe the general upgrade process on the E-series router. This example
describes the process to upgrade an ERX-7xx router or an ERX-1410 router from software release
erx7-0-0.rel to erx7 .3. 0 . rel.
If you upgrade an ERX-1440 router, the name of the software release is
erx4 0_x. y. z . rel, where x. y. z is the release number. If you upgrade an ERX-310 router, the name of
the software release is erx310 x. y. z. rel and if you upgrade an ERX-320 router, the name of the
software release is
erx320 x. y. z. rel. Before upgrading any router, review the release notes carefully. Some software
releases require different hardware or memory requirements to run.
To upgrade the router, first copy the new software release to your local FTP server. Next, on the
router, configure your FTP server as an FTP host. Verify that you can ping your FTP server from the
router. If you cannot, verify that you have a route to the FTP server.


Router Flash
erx_7-0-0.rel !
erx_7-0-0.cnf
erx_7-0-0.scr Internet
FTP Server
10.13.7.101
 Back up the current working configuration

– Save and backup current configuration :
erx7#copy running-configuration erx_7-0-0.cnf
erx7#copy erx_7-0-0.cnf ftpServer:erx_7-0-0.cnf
OR
erx7#copy running-configuration ftpServer:erx_7-0-0.cnf
– Create backup script :
erx7#show configuration > erx_7-0-0.scr
Script file on FTP server: erx_7-0-0.scr
Backing Up the Current Working Configuration

Before any upgrade, it is wise to save a copy of the current working configuration, just in case the
upgrade does not go smoothly.
When the router's software is upgraded, the router automatically upgrades the running-configuration
file to match the new image. After a configuration file is upgraded, you cannot downgrade the
configuration file. Therefore, save a copy of the current running- configuration file to the flash using a
different name.
Copy this saved, working configuration file to a workstation for backup purposes. Note that you can
copy the running-configuration to a file on a remote host.
Next, perform the show configuration command, and pipe the output to a script file located either on
the flash or on a workstation. Recall that the router's configuration file is binary. Depending on the size
of the configuration file, the ASCII output of the show configuration command might be quite large.
Ideally, copy this script to the router's flash, although in some cases there might not be enough room,
and you might need to store this script on a workstation.
You can run this script to configure the router if the upgrade does not go properly.


Router Flash
erx_7-0-0.rel !
erx_7-0-0.cnf
erx_7-0-0.scr
erx_7-3-0.rel ! Internet
Juniper Networks
FTP Server FTP Server
10.13.7.101
 Copy new software release to the router

– For systems with two SRP modules, turn off synchronization:
erx7(config)#disable-autosync
– Copy the new release from your FTP server to the router:
erx7#copy ftpServer:7-3-0/erx_7-3-0.rel erx_7-3-0.rel
– Configure the router to use the new software release:
erx7(config)#boot system erx_7-3-0.rel
WARNING: It is recommended that you copy the current running -configuration
to a file prior to running with a different release of software.
Copying New Software Release to the Router

To upgrade the software on a system that is operational and contains two SRP modules, you must first
turn off the automatic flash card synchronization process before you copy the new system release.
Note that disabling file synchronization does not disable high-availability mode.
From the router, copy the new software release from the FTP server. If there is not enough room, an
error message is displayed before the router attempts to copy the file.
Configuring Router to Use New Software Release
In the example on the slide, the router is configured to boot using the running-configuration and
software release erx 7-0-0 . rel. You can use the show boot CLI command to determine this
information. The next step is to configure the router to use the new software release, erx_7-3-0 . rel,
the next time it reloads. In Global Configuration mode, use the boot system
erx_7-3-0 . rel configuration command to change the release of software the router will use when the
next reload command is issued. Note that the boot system erx_7-3-0 . rel command does not reload
the router. When you issue the boot system command and specify a different software release, the
command takes a few moments to complete. During this time, SRP startup and boot ROMs are
updated with the new software release information. Notice that after this command is complete, the
router recommends saving a copy of the running-configuration.
If the router is running in high-availability mode, you will receive the following message after issuing
the boot system command:
WARNING: High Availability is currently active. If a different release is booted on the standby SRP,
High Availability will be disabled.
Proceed with boot command? [confirm]

Upgrading Software: Step 4a (1 of 2)

Standby SRP Flash Primary SRP Flash
erx_7-0-0.rel ! erx_7-0-0.rel
erx_7-0-0.cnf erx_7-0-0.cnf
erx_7-0-0.scr erx_7-0-0.scr
erx_7-3-0.rel ! erx_7-3-0.rel !
Standby SRP reloads

Synchronize File System
 Final steps during upgrade with two SRP modules:

– Synchronize the file systems
erx7 #synchronize
******************************************(done)
 Standby SRP automatically reboots and high-availability mode disable
 Wait for the redundant SRP to boot, initialize and return to the standby
state
– Synchronize the file systems again
erx7 #synchronize
******************************************(done)
Final Steps During Upgrade with Two SRP Modules: Part 1

Once the new software release is copied to the flash card on the primary SRP, synchronize the primary and
standby SRP file systems. This synchronization process takes several minutes.
When the file synchronization process completes, the standby SRP determines that it is running a different
release than the release configured, and it automatically reboots using the new software release. You will receive
the following messages:
WARNING 09/09/2006 13:36:39 ha: High Availability is disabled. View the srp redundancy status to determine the
cause.
WARNING 09/09/2006 13:36:39 ha: High Availability is disabled due to the standby SRP being unavailable
At this point in time, the system is still operational and routing packets using the primary SRP. High-availability
mode is automatically disabled because the standby SRP is in the process of rebooting.
Wait for the redundant SRP to boot, initialize, and return to the standby state before continuing. You can use the
show version command to monitor the state of the standby SRP. You will notice that the standby SRP now boots
with the new version of software. The state field for the redundant SRP should be standby when the redundant
SRP comes back online. You will also receive the following message:
High Availability is disabled due to an incompatible release running on the standby SRP.
At this point, the standby SRP is running the new erx 7-3-0 . rel software.
After any reboot, the file systems on the primary and redundant SRPs are no longer synchronized, so it is
necessary to synchronize the files systems again.

Upgrading Software: Step 4a (2 of 2)

Primary SRP Flash Standby SRP Flash
erx_7-0-0.rel erx_7-0-0.rel !
Line Modules Reboot
erx_7-0-0.cnf erx_7-0-0.cnf
erx_7-0-0.scr erx_7-0-0.scr
erx_7-3-0.rel ! erx_7-3-0.rel !
New Standby SRP reboots

Swicth SRPs
 Final steps during upgrade with two SRP modules:
– Switch from the primary SRP to standby SRP
erx7 #srp switch
WARNING: This command will reboot the system and boot
from the other SRP. Proceed with SRP switch? [confirm]
WARNING: High-availability state is not active. Switching
at this time will cause the system to cold restart.
Proceed with SRP switch? [confirm]
– Turn on automatic file synchronization
erx7 #no disable-autosync
Final Steps During Upgrade with Two SRP Modules: Part 2

Now that the standby SRP is running the new software and the file systems are synchronized, you can
now issue the srp switch command to switch from the primary to the standby SRP. When you issue the
srp switch command, you receive the following messages:
WARNING: This command will reboot the system and boot from the other SRP. Proceed with SRP
switch? [confirm]
WARNING: High-availability state is not active. Switching at this time will cause the system to cold
restart.
Proceed with SRP switch? [confirm]
The former standby SRP now assumes the primary role and the line modules reboot. Because the line
modules are currently booting, the system is no longer able to route traffic. Once the line modules
come online, the system is operational and can route traffic using the new primary SRP. High-
availability mode is still disabled because the new standby SRP is still booting with the new version of
software.
When the standby SRP comes back online, the system reinitializes high-availability mode. This
process takes several minutes to complete. You can monitor high-availability mode status using the
show redundancy command. This command identifies the criteria preventing high-availability mode
from being active. Once both SRPs are initialized, you can turn on the automatic file synchronization
process.
At this point, the system is fully operational. Both SRPs are running the new version of software. Notice
that the reload command was never used during this process.

Upgrading Software: Step 4b

Router Flash
erx_7-0-0.rel !
erx_7-3-0.rel !
erx_7-0-0.cnf Internet
erx_7-0-0.scr
10.1.7.100
 Final steps for upgrading systems with one SRP module:

– Verify the boot settings:
erx7#show boot
Note: This system is not configured with backup settings.
– Reload the router

– Verify and test the new software release
Final Steps When Upgrading Routers with One SRP Module

In the example on the slide, the E-series router is configured to boot using the running-configuration
and software release erx_7-3-0 . rel. You can use the show boot CLI command to determine this
information. Reload the router. Note that during an upgrade, the line module's boot code and
diagnostics are also upgraded, so the reload takes more time to complete. In addition, a router that has
a large number of interfaces configured might appear to be unresponsive for several minutes. This
behavior is normal, and you should allow the process to continue uninterrupted.
When the router has successfully rebooted, test and verify the configuration running with the new
software release.

Downgrading Software
 Option 1:
– Configure the router to use the old configuration file only once:
erx7(config)#boot config erx_7-0-0.cnf once
– Configure the router to use the old software release:
erx7#show boot
System Configuration: erx_7-0-0.cnf once
Note: This system is not configured with backup settings.
erx7#
– Reload the router:
erx7#reload
Downgrading Software: Option 1

If the new software release does not work properly, you must downgrade to the old system release and
the old configuration. In the example on the slide, the router is configured to use the erx 7-3-0 . rel
software release and the running-configuration file, which is based on the erx 7-3-0 . rel image.
To downgrade, configure the router to use the old configuration file,
erx 7-0-0 . cnf, specifying the once option. With the once option, the router uses this specific
configuration file for the next reload, and subsequent reloads will use the running-configuration file.
Next, configure the router to use the old software release, erx_7-0-0 . rel. Again, it takes a few
moments for this command to complete while the SRP ROMs are updated. Verify the boot settings,
and reload the router.
Note that the order in which the boot system and boot config commands are executed is critical. The
router must always be in a state where it can successfully reboot. As noted before, the router always
automatically upgrades a configuration file built with an older software release to match a new software
release, but the reverse is not true. For example, to downgrade the router, first configure the old
configuration file to use. If the router were to reload at this moment, it would boot using the new
software (Release7-3-0) using the old configuration file (erx_7-0-0 . cnf) and automatically upgrade the
configuration file to the new version. If you tried to configure the old software release first and the
router rebooted, it might not successfully reboot. Luckily, the router does not allow this situation to
occur and provides the following error message:
% The Release selected is incompatible with the system configuration that is configured to run.

Downgrading Software…Another Option

 Option 2:
– Use the factory default configuration settings on the router:
erx7(config)#boot config factory-defaults
– Configure the router to use the old release or system image:

erx7#show boot
– Reload the router
– Verify that all line modules are online:
erx7#show version
– Configure the router using the configuration script on the
flash:
erx7#config file erx_7-0-0.scr show-progress
Downgrading Software: Option 2

If, for some reason, the E-series router cannot boot using the old configuration file, you can use a
script file to reconfigure the router for the old environment.
Using this option, configure the router to boot using the factory-default configuration file. Then,
configure it to boot using the old software release, erx 7-0-0 . rel. Verify the boot settings, and reload
the router.
After the router reboots, verify that all line modules have come online using the show version
command. If a script file is executed and contains commands configuring line modules that are still
booting, the commands will fail. All line modules must be online before you can configure them.
Once all line modules are online, configure the router using the erx 7-0-0 . scr script file. You can
execute the configure file command using the verbose option. This option echoes each configuration
command to the console. If the script file is very large, it might take longer to execute using the
verbose option. Another approach is to use the show-progress option, which provides an indication of
the script file progress using the period (.) echoed to the console.

System Release Files
System Release Files

Recall that a system release consists of many individual files, such as diagnostic programs, field-
programmable gate array (FPGA) images, and operational programs. The entire set of files is called a
system release (or . rel) file. When you upgrade the router, you simply copy a single file, that is, the
system release file. This file references the individual files required for this release. This slide shows all
the individual files necessary for software release erx_7-2-1. rel. The combination of all these files is
the complete system release, which can be well over 160 MB in size.

Copying Partial Software Releases

 Steps:
– Only include required subsystems in software release on flash
 Speeds up copy time and saves flash space
– Configure the router to not copy specific subsystems when a
software release is copied from an FTP server:
erx7(config)#exclude-subsystem coc12
erx7(config)#exclude-subsystem oc12p
erx7(config)#exclude-subsystem oc12a
erx7(config)#exclude-subsystem oc12s
erx7(config)#exclude-subsystem ge
erx7(config)#exclude-subsystem ut3f
erx7(config)#exclude-subsystem ct1
– Verify subsystems to be included/excluded:
erx7#show configuration
 Indicates subsystems excluded
– Copy new partial release to the router:
erx7#copy ftpServer:images/7-3-0/erx_7-3-0.rel small.rel
Copying Partial Software Releases

By default, when a software release is copied from an FTP server to the router, all subsystems (ge, oc3-4a, oc3-
4p, ocl2a, ocl2p, etc.) are copied and included on the flash card, even if the router does not require these
subsystems. You can shorten the time it takes to copy a software release from the FTP server to the router as
well as reduce the amount of flash card space required to store software releases by excluding the subsystems
not required by the particular router.
As an example, let's say a customer never plans on using the following line modules on a particular router in the
network: 0C12 ATM, 0C12 POS, COC12, and GE. The customer decides to remove these subsystems from the
software release stored on the flash card to save space and reduce file copy time. The customer uses the
exclude-subsystem configuration command to exclude these subsystems the next time a software release is
copied to this particular router. This information is stored in the router's configuration file.
You can verify the exclude-subsystem configuration command using the show configuration command:
erx7(config)#run show config

! Configuration script being generated on SAT SEP 09 2006 18:52:48 UTC ! Juniper Edge Routing Switch ERX-
700
! Version: 7.3.0 [BuildId 6006] (September 7, 2006 22:33)
! Copyright (c) 1999 -2006 Juniper Networks, Inc. All rights reserved
boot config running-configuration boot system erx 7-3-0.rel
exclude -subsystem cocl2 exclude-subsystem ocl2p exclude-subsystem ocl2a exclude-subsystem ocl2s exclude-
subsystem ge
!
….
To create a partial software release on the flash card, copy the software release from the FTP server to the
router. With the exclude subsystem commands in the configuration file, the subsystems excluded in the
configuration file are not copied or included on the flash card.

Using Partial Software Releases

 Steps:
– Verify subsystems included / excluded in the software release:
erx7#show subsystem file small.rel | begin Exclude
Excluded Subsystems: 36950974 bytes
coc12
oc12p
oc12a
oc12s
ge
ct1
ut3f
– Boot the router using partial release
– Verify operation:
 show version command: Indicates partial release
 show configuration command: Indicates subsystems excluded
– Note: If a required subsystem is missing, the line module will
not boot
Using Partial Software Releases

Use the show subsystem file XXX . rel command to determine which subsystems are included and
excluded in the software release located on the flash card. You can also reference a network host with
this command. Next, reload the router using the new, partial sof tware release. To verify operation after
the router boots, use the show version command. This command should indicate that a partial software
release is in use.
Use the show configuration command to determine which subsystems are excluded in the
configuration file. Use the show subsystem command to determine which subsystems are excluded
from the software release. If a required subsystem is missing, the line module will not boot. The show
version command indicates a message such as the following:
2 disabled (image error) 0C3d enabled bad.rel

In addition, error messages are displayed on the console indicat ing the problem:
ERROR 11/24/2001 23:12:56 os: IcLoader: oc3Diag.cmp not installed ERROR 11/29/2004 23:12:57
os: IcLoader: oc3Boot.cmp not installed ERROR 11/29/2004 23:12:58 os: IcLoader: oc3Startup.exe not
installed
ERROR 11/29/2004 23:12:58 os: IcLoader: oc3Fpgas.cmp not installed ERROR 11/29/2004 23:12:59
os: IcLoader: oc3Fc.exe not installed

Updating Router Using JUNOSe Hotfix

 What is a JUNOSe hotfix?
– A subset of a full release used to provide time-critical updates to an
operational router
– Debug code used to collect data to troubleshoot software issues
– Depending on extent of change, might be activated and deactivated
dynamically or require a reload
 How can I obtain a JUNOSe hotfix?
– Only available for certain specific, critical software issues Provided
at the sole discretion of Juniper Networks
JUNOSe Hotfix
A JUNOSe hotfix is a subset of a full release used to provide time-critical updates to an operational
router. A hotfix is used to address specific, critical issues without having to load an entire software
release. You can also use a hotfix to add debugging code to collect data used for troubleshooting
software issues. Depending on the extent of the change, a hotfix might be dynamically activated or
deactivated, or it might require a reload of the router.
Obtaining a JUNOSe Hotfix
A hotfix is a special version of software that can only be created to address specific scenarios. Only
Juniper Networks determines when a hotfix is possible or necessary. Hotfixes are only created to
resolve truly critical, time -sensitive issues as determined by Juniper Networks.


 Upgrading and Downgrading Software
 Backup Boot Configuration and Slot Configuration
Backup Boot Configuration and Slot Configuration


E-series Router Backup Boot Config (1 of 3)

 Situation:
– Upgraded router to new software release
– The router resets too many times in a given time period
 Solution:
– Prior to an upgrade, configure the router with backup boot
settings
– Router switches to use backup software release and
configuration file based on information in the reboot.hty file
– Configurable boot revert tolerance
 An SRP will tolerate x reboots (count) in y seconds (time)
 If x + 1 reboots occur within y seconds, the backup boot configuration
takes effect (per SRP)
– Backup boot configuration steps:
erx7(config)#boot backup erx_5-2-1.rel erx_5-2-1.cnf
erx7(config)#boot revert-tolerance 2 300
Situation: Too Many Router Resets

The router also provides a method to automatically switch to use a different software release and
system configuration file if severe problems exist and the system resets too many times in a given time
period.
Solution: Backup Boot Configuration
Using the backup method, an SRP tolerates x reboots within y seconds. If x + 1 reboots occur within
this time period, the router reloads using the specified backup configuration. (Note that the count is per
SRP, not for the router.) If redundant SRPs are installed, each SRP must reboot x times within the time
period, and the x + 1 reboot causes the backup settings to take effect. The SRP examines the reboot .
hty file for system crashes to determine if it should reboot using the backup configuration.
To configure the E-series router to use backup boot settings, use the boot backup configuration
command and specify the software release and the local configuration file, or specify the factory—
default configuration file to use if the boot logic chooses the backup mode. Note that running—
configuration is not an option for the backup boot system configuration file; this command does not
reboot the router—it simply configures the environment with backup settings.
Next, configure the boot revert tolerance, which is a reboot count and a time value. If the SRP reboots
x + 1 times (the count) within y seconds (the time), the router reboots using the software release and
configuration file specified in the boot backup configuration. You should set the time value long enough
for the router to reload. If you set too small a time value, the backup configuration might not take effect.
If you do not specifically configure the boot revert tolerance, the router uses the default setting of three
boots in 1800 seconds.


 To view the current boot configuration:
erx7#show boot
System Release: bad.rel
Backup System Release: erx_7-0-0.rel

Backup System Configuration: erx_7-0-0.cnf
This system is currently configured to boot with its

primary (non-backup) settings.
Backup mode thresholds - count: 2 , time: 300
 To force the router to use the backup boot settings:
erx7(config)#boot force-backup
 To temporarily disable the backup boot settings:
erx7(config)#boot revert-tolerance never
Viewing the Current Configuration

Use the show boot command to verify the backup configuration settings. In the example on the slide,
an E-series router with a single SRP tolerates two reboots within 300 seconds. If three reboots occur
within this time period, the router reverts to the backup configuration settings. If the router has
redundant SRPs, the reboot count is effectively (2 * count + 1). In this example, a total of five resets
within 300 seconds causes the router to reload using the backup configuration. Specifically, the
following must occur within 300 seconds: SRP 1 reboots (reset count 1), SRP 2 reboots (reset count
1), SRP 1 reboots (reset count 2), SRP 2 reboots (reset count 2), SRP 1 reboots (count 3), reboot
using backup configuration.
Using Backup Boot Settings
You can force the router to use the backup boot configuration settings by issuing the boot force-backup
configuration command. Again, this command does not reboot the router; it simply changes the boot
configuration settings for the next time the router reboots.
Disabling the Backup Boot Setting
To temporarily disable the backup boot settings but preserve the backup configuration, use the boot
revert-tolerance never configuration command.
Recall that when the dir command is executed, the results indicate which software release and,
potentially, which configuration file is in use by means of the in-use flag (!). The in-use flag indicates
that the software release file name and configuration file name are stored in nonvolatile memory as a
boot configuration parameter. When you configure backup settings, there are actually two configuration
files (primary and backup) and two software release file names (primary and backup) stored in
nonvolatile memory. In this case, multiple . rel files and potentially multiple . cnf files are marked with
the in-use flag.


 Router booted with backup configuration:
erx7#show boot
System Release: bad.rel
Backup System Release: erx_7-0-0.rel

Backup System Configuration: erx_7-0-0.cnf
This system is currently configured to boot with

its backup settings.
Backup mode thresholds - count: 2 , time: 300
 To revert to primary boot configuration:
erx7(config)#no boot force-backup
erx7(config)#exit
erx7#rename reboot.hty oldreboot.hty
Booting With a Backup Configuration

If the router reverts to the backup boot configuration, the show boot command indicates that the
backup boot settings are in use.
Once the router boots using the backup software release and configuration, it continues to use these
files until you change the boot configuration settings. Note that if you make any configuration changes
at this point, they are saved in the running-configuration, not in the backup configuration file. If the
router reboots after these configuration changes are made, it reloads using the backup software
release and the backup configuration file. Any configuration changes are lost.
Reverting to the Primary Boot Configuration
If a new image is obtained and configured as the primary software release, you must configure the
router to discontinue using the backup boot software release and configuration file. You accomplish
this task by issuing the no boot force-backup configuration command. Note, however, that even if
you switch back to the primary boot configuration settings, the boot logic still checks the reboot . hty
file. Based on the boot revert tolerance configuration and the contents in the reboot . hty file, the router
might actually revert to the backup configuration settings. To guarantee that the router uses the new
image, you might want to rename the reboot . hty to oldreboot hty and effectively reset the backup boot
logic. On the router, a reboot . hty is created when the router reboots, if the file does not already exist.

Changing Slot Configurations

 Situation:
– Slot 1 used to have a UT3A line module installed and
configured―this card was removed, but remains in the
configuration
– Install a different type of line module
 show version indicates the slot is disabled due to a slot mismatch
 Solution:
– Remove existing slot configuration:
erx7(config)#slot erase 1
 Always deletes slot configuration, even if no board mismatch
 Easy bulk deletion
OR
erx7(config)#slot accept 1
 If the slot is empty or there is a board mismatch, deletes slot
configuration
 If there is no board mismatch, do nothing
– New line module boots and comes online
Situation: Changing Slot Configurations

In the situation shown on the slide, Slot 1 in the router had a GE line module installed and configured.
Now, this card has been removed. However, this card remains in the configuration file. If you perform
the show version command, the slot indicates that the GE line module was removed.
If you try to install a different type of line module in this empty slot, the router indicates a mismatch of
line modules. The current configuration file indicates the slot should contain a GE line module, and the
slot now contains a different type of line module.
Solution: Remove Existing Slot Configuration
Two approaches exist for deleting the current GE configuration in Slot 1 from the configuration file.
One method uses the slot erase configuration command, specifying Slot 1. Depending on the
configuration, this command might take a few moments to execute because the router must delete all
interface definitions from the current configuration file. The slot erase command always deletes the slot
configuration, whether or not there is a slot mismatch. Using this command is an easy way to do a bulk
slot deletion from a current configuration file.
Another option uses the slot accept configuration command. The slot accept command also deletes
the configuration. The slot accept command only deletes the slot's configuration if there is a board
mismatch or an empty slot. If there is no board mismatch, the configuration file is not touched. The new
line module should then boot and come online.
Before installing a different type of 10A on the E320 router, issue either the adapter erase or adapter
accept command.


 Rebuilding Flash Cards and Password Removal
Rebuilding Flash Cards and Password Removal


Halting in Boot Mode

 Situation:
– The router does not boot properly―it keeps halting at the
boot## prompt
 The router could have a corrupted flash or an invalid software
release
 Possible solutions:
– Option 1: Type reload at the boot## prompt
– Option 2: If the flash is accessible, configure the router to
boot using a system release on the flash card and the
factory-default configuration file:
:boot##boot system erx_7-3-0.rel
:boot##boot config factory-default
:boot##reload
Recovering from Problems

It is unlikely, but the router might not boot properly and might continue to halt at the boot## prompt.
Solutions 1 and 2
First, try a simple reload at the boot## prompt. If this does not work, type the dir command on the flash
card. If the flash card is accessible and multiple system releases are on the flash card, configure the
router to boot using a different system release than it is currently using. Configure the router to boot
using the factory-default configuration file. Verify the boot settings, and reload the router.

Copy New Software to the Flash Card

 Option 3:
– If the flash is accessible but the system release is not
valid, copy a valid system release and backup
configuration file to the flash card, configure the boot
settings, and reload the router:
:boot##ip address 10.1.7.11 255.255.255.0
:boot##host ftpServer 10.1.17.100 ftp
:boot##ip gateway 10.1.7.1
:boot##reload
– Verify that you can ping the router from the FTP server
– Copy a valid software release and configuration file, and
reload the router
:boot##copy ftpServer:erx_7-3-0.rel erx_7-3-0.rel
:boot##copy ftpServer:erx_7-3-0.cnf erx_7-3-0.cnf
:boot##boot config erx_7-3-0.cnf
:boot##reload
Solution 3
If the router still does not boot properly, configure the management Fast Ethernet port's IP address and
the FTP host address. If the FTP server is not on the local segment, you also must configure the IP
gateway. Because these commands are being written into the boot prom on the SRP, you must run the
reload CLI command to actually program the interface.
Verify that the management Fast Ethernet port is operational by pinging it from the FTP server. Copy a
valid software release from your FTP server and a backup configuration file, if available, to the flash
card. Next, configure the software release and configuration file boot settings and reload.

Rebuilding the Flash Card

 Option 4:
– Replace the flash card with a backup flash card, if
available
 Option 5:
– Contact JTAC, who might walk you through the following
procedure:
 Format the flash card, load the software and necessary files, and
reload the router:
:boot##flash-disk initialize
:boot##ip address 10.1.7.11 255.255.0.0
:boot##host ftpServer 10.1.17.100 ftp
:boot##ip gateway 10.1.7.1
:boot##reload
 Verify that you can ping the router from the FTP server
:boot##copy ftpServer:erx_7-3-0.rel erx_7-3-0.rel
:boot##copy ftpServer:erx_7-3-0.cnf erx_7-3-0.cnf
:boot##boot config erx_7-3-0.cnf
:boot##reload
Solution 4
If the boot process still halts at the boot ## prompt, you should replace the current flash card with a
backup flash card and reboot the router.
Solution 5
If you do not have a backup flash, you should contact the Juniper Networks Technical Assistance
Center (JTAC) as the flash might be corrupted. If it is corrupted, JTAC might walk you through
formatting the flash and rebuilding the environment. To do this, you perform the following steps from
the boot CLI:
:boot##flash-disk initialize Please wait
Now use the steps from Option 3 to load the software onto the flash card and reload the router.

Duplicating Flash Cards

 Duplicating flash cards:
– Copy the contents of the primary flash card onto a spare
flash card
– Reload the router and type mb during the countdown to
halt it at the boot## prompt
– Initiate the flash-disk duplicate command:
erx7#reload
WARNING: This command will cause the system to reboot.
Proceed with reload? [confirm] y
Reload operation commencing, please wait...
mb
:boot##flash-disk duplicate
Duplicating Flash Cards

If you must make a copy of the contents of a flash card for backup purposes or for use in another
system, you can use the flash -disk duplicate command. The flash cards must be from the same
manufacture and must be the same size. You perform this command from the boot ## prompt. To
access the boot ## prompt, first reload the router and then type mb during the boot countdown
process. At the boot## prompt, use the flash-disk duplicate command to copy the contents of the
primary flash card onto the spare flash card. This duplication process only requires one SRP, which
only has one flash card slot. The system will prompt you to insert the primary or spare flash when
appropriate. The system copies the flash contents incrementally, so you might need to exchange the
flash cards several times.

Flash Card Synchronization and Validation
 Synchronize:
– Manually forces the redundant SRP to synchronize its flash
card with the primary SRP’s flash card
 flash-disk compare:
– Detects differences between the redundant and primary flash
cards
erx7#flash-disk compare all
erx7#flash-disk compare configuration
 synch low-level-check:
– Validates files that failed the flash-disk compare
erx7#synchronize low-level-check all
erx7#synchronize low-level-check configuration
Flash Card Synchronization and Validation

When the router has redundant SRPs installed, it is important to keep the two flash cards synchronized. The
system automatically performs this operation every five minutes. If you want to manually force this process to
occur, use the synchronize CLI command. You can determine that t he two flash cards are synchronized by using
the dir CLI command and verifying that the output contains a single list of files. If you see a list of files for each
flash card, the file systems are not synchronized.
Even when the flash cards on the primary and redundant SRP modules are synchronized, differences can exist in
the content of files that reside on the primary flash card and the redundant flash card. You can use the flash-disk
compare command to detect these differences so you can validate and, if necessary, recover the file integrity of
the redundant SRP module.
The flash-disk compare command validates only those files that are synchronized between the primary and
redundant SRP modules. It does not compare files that are normally excluded from the synchronization process,
such as log files and core dump files. The command uses a simple checksum error detection algorithm to
compare the contents of a file residing on the flash card of the primary SRP module with the contents of the same
file residing on the flash card of the redundant SRP module. You should first verify that the file systems are in
sync before using this command.
The flash-disk compare all command verifies all mirrored files, including software releases, script files, and
configuration files. This process will take several minutes to complete. The flash-disk compare configuration
command only validates configuration files and takes less time to complete. You should not make configuration
changes while either command is executing.
You can use the synchronize low-level-check command to synchronize files that failed the flash disk comparison
process. To validate and synchronize all files, including software releases, script files, and configuration files, use
the all keyword at the end of the synchronize low-level-check command. This command will take several minutes
to execute. To validate and synchronize only configuration files , use the configuration keyword. You should not
make any configuration changes while these commands are executin g.

SRP Reset Buttons

 SRP has 2 reset buttons
– Top = Reset
– Bottom = NMI
 What happens if I push
the reset button on the
SRP?
– The router runs
hardware diagnostics
Board
and reloads Reset
– Power cycle Button
 What happens if I push NMI
the bottom NMI button?

– The router reloads
without running
hardware diagnostics
– Simple reload
Two Reset Buttons

The front of the SRP has two holes, or reset buttons. The top button is the reset button, and the bottom
button is the nonmaskable interrupt (NMI) button. You can push these buttons using an official reset
tool (otherwise known as a paper clip).
The Top Button
If you push the top reset button with a paper clip, the router runs hardware diagnostics and fully
reloads. The router acts as if it were power cycled.
The Bottom Button
If you insert a paper clip into the bottom button otherwise known as the NMI button, the router simply
reboots without running diagnostics. Pushing this button is analogous to performing a reload from the
CLI. In the unlikely event that the router hangs and console access (both local and Telnet) is lost, this
is one method to reset the box. Do not power cycle the router to reset the unit. Power cycling the E-
series router can potentially cause flash corruption.

Privileged Exec Mode Password Removal

 The enable password changed to an unknown value
or is forgotten
– You must have access to User Exec mode
– If you have physical access to the router:
 Console or Telnet/SSH access
erx7>enable
Password: ******
Password: *****
Password: ******
% Bad passwords
erx7>erase secrets 60
(Push bottom button on the SRP ONCE)
Please wait....
erx7>enable
erx7#
– If you do not have physical access to the router:
 service unattended-password-recovery must be enabled
 Console access only
erx7>erase secrets
erx7>enable
erx7#
Physical Access to Router

You can use two approaches to remove the enable passwords on the router without disrupting service.
With either approach, you must have access to User Exec mode.
If you have physical access to the router, you can use the erase secrets ## command to delete all
existing enable passwords. You can execute this command from the console or any Telnet or SSH
session. From User Exec mode, enter the erase secrets command, specifying a timer value between
1-60 seconds. Before the configured timer expires, insert a paper clip into the bottom button on the
SRP and push this button ONCE. If you push this button more than once, the router will reboot. At this
point, the password is removed from the router.
No Physical Access to Router
If you have do not have physical access to the router, you must first configure the router to support
unattended password recovery using the service unattended-password-recovery configuration
command. By default, this service is disabled. When this service is enabled, the behavior of the erase
secrets command changes. You no longer need to configure a timer or use a paper clip to remove the
password. You simply access User Exec mode and type the command erase secrets to delete all
existing enable passwords. When unattended password recovery is enabled, you can only execute this
command from the console.
The enable password is stored in the configuration file on the flash. If you move this flash card to a
different router, the password moves with it. Note that the erase secrets command only removes the
enable password. It does not affect any Telnet or console port passwords that might be configured.

Console Password Removal

 Console password changed to an unknown value or
is forgotten:
erx7 con0 is now available
Press RETURN to get started.
Console password: *****
Console password: ******
Console password: ******
% Bad passwords
– Will this solution work?
erx7>erase secrets 60
(Push bottom button on the SRP ONCE)
Please wait....
erx7>
– Access the boot## prompt
– Disable console authentication and reload router:
:boot##disable console authentication
:boot##reload
Console Password Changed to an Unknown Value or Forgotten

In the situation on the slide, the console password was changed to an unknown value, or the console
password was forgotten. The console password is different from the enable password. Recall that to
remove the enable password, you must have access to User Exec mode and have physical access to
the unit or have the router configured to support unattended password recovery. In this situation, we do
not have access to User Exec mode.
To remove the console password, you must gain access to the boot ## prompt, which requires a
reboot of the router. To reboot the router and gain access the boot ## prompt, press the reset button
on the SRP, perform a Ctrl-X from the login menu, or, as a last resort, power cycle the router. With any
approach, type mb during the boot countdown sequence.
Once at the boot ## prompt, execute the disable console authentication command. This command
disables all console authentication. Then, reload the router. At this point, console access is restored.


 Accessing the CLI
Accessing the CLI


CLI Access to the Router—

Console/Telnet/SSH
Enable
Console
User Password Privileged
Password
Exec Exec
Username
Username Password
Password gary miata
diane piano
RADIUS/TACACS+
Console, Telnet, and SSH Access

You can gain console, Telnet, and SSH access to User Exec mode on the router in one of two ways.
With the simple password scheme per router, all users use the same passwords, which are stored
locally in the configuration file on the router. The console port can have a password for User Exec
mode, similar to Telnet access.
With RADIUS authentication, you log in with a specific username and password and are authenticated
through RADIUS. These passwords are stored centrally in a RADIUS database and are per user. This
scheme allows centralized control to E-series router access. If an employee leaves the company, only
the centralized RADIUS database requires modification rather than each device in the network. This
scheme provides centralized control to User Exec mode. With this scheme, the Privileged Exec mode
password is stored locally in the router's configuration file.
You can configure console line parameters on the router, including a console or User Exec password,
a time-out, and data-set-ready (DSR) detection.
The E-series router also supports authentication using TACACS. TACACS is a security protocol that
provides centralized validation of users who are attempting to gain access to a router. TACACS+, a
more recent version of the original TACACS protocol, provides separate AM services. Note: Currently,
the E-series implementation of TACACS+ does not support the authorization or accounting functions.
Both RADIUS and TACACS+ protocols are client-server systems that allow effective communication of
AAA information.

Configuring RADIUS/TACACS+
Authentication for CLI Access
 Steps:
– Add the users into the RADIUS or TACACS+ database
– Configure the router for RADIUS or TACACS+
authentication:
erx7(config)# aaa new-model
– Configure the RADIUS or TACACS+ authentication server on
the router:
erx7(config)# radius authentication server 10.1.7.55
erx7(config-radius)# udp-port 1645
erx7(config-radius)# key training
or
erx7(config)#tacacs-server host 10.1.7.55 port 10 key
training
– Configure the source IP address of RADIUS or TACACS+
packets originated on the router:
erx7(config)# radius update-source-addr 10.1.7.6
or
erx7(config)#tacacs-server source-address 10.1.7.6
Configuring RADIUS or TACACS+ Authentication for CLI Access

The E-series router supports RADIUS and TACACS+ authentication for Telnet, SSH, and console
sessions. You must perform the following steps to configure the router for these authentication
methods:
• Add the users into the RADIUS or TACACS+ database.
• Configure the router to use RADIUS or TACACS+ authentication using the aaa new-model
command.
• Configure the RADIUS authentication server information on the router, including the IP
address of the RADIUS server, the UDP port if different from the default of port 1812 , and
the RADIUS key. If you are configuring a TACACS+ authentication server, you configure the
TCP port.
By default, the router uses the ip router-id as the source IP address of any packets sent to the
authentication server, regardless of the egress interface on the router. To ensure that the
authentication server can communicate with the router, explicitly configure the source IP address of
any RADIUS or TACACS+ packets originated by the router using the radius update-source-addr or
tacacs-server source-address command.

Configuring Console Access

 Steps:
– Configure the router authentication scheme used for console
sessions:
erx7(config)# aaa authentication login loginlist radius
tacacs line none
– Configure the console line to use the authentication scheme
defined above, and configure a console password:
erx7(config)# line console 0
erx7(config-line)# login authentication loginlist
erx7(config-line)# password consolepass
Configuring Console Access

The aaa authentication login command creates an authentication scheme used to authenticate CLI logins. A login list is
configured, and this list name is referenced by CLI access ports (console 0 or virtual terminal 0-19) to determine the
appropriate authentication method when users log in to the CLI. In the example shown here, RADIUS or TACACS+
authentication is used first. If this method is not successful, the next authentication method uses a line (virtual or console)
password. If these two authentication methods fail, the user gains access to the router. This access happens because the final
method configured is none, meaning that no authentication method is used if the other two methods fail.
To enable authentication on the console port, configure the console line to use the authentication scheme or login list name
defined above. Then, configure the console or User Exec password. This password is stored locally on the router.
Using this configuration, the console user is prompted for a username and password. This username and password are sent to
the RADIUS server for authentication. If the user is granted acc ess, the user has CLI access based on the information returned
from RADIUS. The following capture shows this scenario:
Username: user0
Password: *****
Logged in on console.
Copyright (c) 1999-2004 Juniper Networks, Inc. All rights reserved.
erx7>
Continuing on with this example, if the RADIUS server is unavailable, the authentication request is sent to the TACACS+
server. If this server is also unavailable, the user is prompted for a console password, which is stored locally on the router. If
the user knows the console password, the user gains access to Us er Exec mode. The following capture illustrates this
scenario:
Username: user° Password: *****
Console password: ***********
Logged in on console.
erx7>
If the user does not know the password, access is denied. However, if no console password is defined, the user simply gains
access to User Exec mode due to the last authentication method of none. If the RADIUS server is available but the username
or password is incorrect, the user is denied access, and no furt her processing will occur.

Configuring Telnet Access

 Steps:
– Configure the appropriate RADIUS components
– Configure the router authentication scheme used for
Telnet sessions (this authentication scheme could be the
same one used for the console):
erx7(config)# aaa authentication login telnetlist
radius line
– Configure the virtual or Telnet lines to use the
authentication scheme defined above, and configure a
Telnet password:
erx7(config)# line vty 0 4
erx7(config-line)# login authentication telnetlist
erx7(config-line)# password telnetpass
Configuring Telnet Access

The aaa authentication login command creates an authentication scheme used to authenticate CLI logins. In the example
shown here, RADIUS authentication is used first. If this method is not successful, the next authentication method is a line
(virtual or console) password. There is no additional option in this example.
To enable authentication for Telnet, configure the virtual lines to use the authentication scheme or login list name defined
above. Then, configure the Telnet password. The router stores th is password locally. In this case, it is only used if the RADIUS
server is unavailable.
Using this configuration, the Telnet user is prompted for a user name and password. This username and password are sent to
the RADIUS server for authentication. If the user is granted acc ess, the user has access to the CLI based on the information
returned from RADIUS. The following capture illustrates this sce nario:
Username: user0
Password: *****
Logged in via telnet.
erx7>
Continuing on with this example, if the RADIUS server is unavail able, the user is prompted for a Telnet password. If the user
knows the Telnet password, the user gains access to User Exec mo de. No other options are permitted using this scheme:
Username: user0
Password: *****
Telnet password: **********
Logged in via telnet.
erx7>
If no Telnet password is defined, the user is denied access. If the RADIUS server is available but the username or password
was incorrect, the user is denied access, and no further processing will occur.

Restricting User Access Using

Command Access Levels
Enable
Password User Password Privileged
Exec Exec
RADIUS
Username Username Password Level Level 0 1 5 10 15

Password gary miata 1
diane piano 10
 Access levels and available commands:

– Level 0: Disable, enable, exit, and help
– Level 1: Level 0 + all other User Exec commands
– Level 5: Level 1 + all Privileged Exec show commands
– Level 10: Level 5 + all other commands except support mode
– Level 15: Level 10 + support mode
Using Command Access Levels

You can assign a command access level to users authenticating through RADIUS. The command
access level is assigned using the Juniper Networks RADIUS Vendor Specific Attribute (VSA) Admin-
Ruth-Level. Currently, five access levels exist, with specific commands mapped to each access level:
• Level 0: Provides access to the disable, enable, exit, and help commands.
• Level 1: Provides all Level 0 commands and all other commands available in User Exec
mode.
• Level 5: Provides all Level 1 commands and all show commands previously restricted to
Privileged Exec mode.
• Level 10: Provides all Level 5 commands and all Privileged Exec commands except support
mode. This level is the default level for the Privileged Exec enable password.
• Level 15: Provides all Level 10 commands, show tech-support, and support commands that
Juniper Networks Technical Support might provide.

Restricting User Access Using Enable

Passwords per Level
Enable
Exec Exec
erx7>enable 10
RADIUS
Username Username Password Level 1 5 10 15

Level 0
Password gary miata 1
diane piano 10
 Enable passwords:
– Can be configured per level
– Stored locally on the E-series router
Restricting User Access Using Enable Passwords

In addition to assigning a command access level per user, you can also configure an enable password
per level. For example, you could configure the following enable passwords on the router:
• erx7(config)#enable password level 1 L1
In this example, Gary logs in to this router and, based on the configuration in the RADIUS database, is
placed in Command Access Level 1. If Gary knows the enable password for Level 10 on this router,
Gary can change access levels using the appropriate enable command:
erx7>enable 10
Password:***
erx7#
The E-series router assumes the default level of 10 if no level is specified in the enable command.
Remember that support mode is available only through Level 15.

Restricting User Access to a Virtual Router

Enable
Exec Exec
RADIUS E-series Router
Username Password Level All VR VR

Username VR1
gary miata 1 disable vr1
Password diane piano 10 enable
 Controlling virtual router access: Default

– Allow-All-VR-access (enable or disable)
– Virtual-Router
– Alt-CLI-Virtual-Router-Name
 Users restricted to a specific virtual router have a limited
command set
– Simple show commands only
– No halt, reload, configuration, etc.
Controlling Virtual Router Access using VSAs

You can also restrict users authenticating through RADIUS to a s pecific virtual router or a group of
virtual routers, or you can allow them access to all virtual routers. A user's access is determined using
the Juniper Networks RADIUS VSAs Allow-All-VR-Access (enable or disable), Virtual-Router, and Alt-
CLI-Virtual-Router-Name. In the example on the slide, Diane has access to all virtual routers, whereas
Gary only has access to vrl. Note that virtual router names are case sensitive.
Limited Command Set
Users restricted to a specific virtual router(s) only have access to a limited command set, including
simple show commands. They are not permitted to halt, reload, or configure the E-series router.


 Other System Administration Tasks
Other System Administration Tasks


Reserved Key Sequences

 Reserved key sequences during the boot countdown
sequence:
– Typing the mb key sequence interrupts the boot sequence
and enters boot mode
– Typing the @ sign saves 7 seconds
 User Exec or Privileged Exec mode c ontrol keys:
– Ctrl-S
 Suspends console display
– Ctrl-Q
 Resumes console display
– Ctrl-X
 Provides the ability to interrupt processing and reboot the router
 Only available from the console―not Telnet/SSH
 Enabled by default
 To disable, use the no service ctrl-x-reboot command
Reserved Key Sequences During the Boot Countdown Sequence

If you are connected via a terminal to the router's console port while the unit boots, you will notice a boot
countdown (7, 6, 5, etc.). Typing mb (case insensitive) during the boot countdown interrupts the boot sequence
and places you at the boot## prompt, otherwise known as boot mode. You should only use boot mode to initially
configure the E-series router boot proms or under advisement from the Juniper Networks Technical Assistance
Center (JTAC). To continue booting the router, simply type reload, and the E-series router should boot normally.
You can also speed up the boot process by typing the @ sign during the boot countdown sequence, which saves
7 seconds.
Reserved Control Keys
Several of the reserved control keys on the E-series router include the following:
• Ctrl -S: This key sequence suspends the console display.
• Ctrl -Q: This key sequence resumes the console display.
• Ctrl -X: This key sequence provides the ability to interrupt processing and to allow you to reload the
router. You enable this capability using the service ctrl -x-reboot command, and you disable it with the
no service ctrl-x-reboot command. This service is enabled by default.
You can only initiate a Ctrl-X from the console (console prompt, User Exec, or Privileged Exec modes), not from
Telnet or SSH. If Ctrl-X is initiated, you receive the following message:
erx5#
WARNING: This operation will force the system to reboot and should be performed ONLY as a last resort. If
possible, either wait for the current command to complete or telnet into the system and use the 'reload' command
instead. Force reboot (yes/no)?
If you choose the reboot option, the router reboots without runn ing hardware diagnostics.

The reboot.hty File

 Accessing the reboot.hty file:
– Primary SRP:
erx7#show reboot-history
– Standby SRP:
erx7#copy standby:reboot.hty temp.hty
erx7#show reboot-history temp.hty
*** Entry 1 ***
time of reset: TUE FEB 11 2003 22:27:51 UTC
run state: unknown
image type: diagnostics
location: slot (8)
build date: 0x3df863a7 THU DEC 12 2002 10:23:35 UTC
reset type: control bus reset
*** Entry 2 ***
time of reset: TUE FEB 11 2003 22:25:09 UTC
run state: unknown
image type: boot
location: slot (8)
Accessing the reboot .hty File

You can use the reboot-history file to display the history of system and module resets. The file contains
a timestamp for the reset, the image type and build date, location (for module resets), and the cause of
the reset.
You can display the current reboot . hty file or a saved reboot history file with the show reboot-history
command. If you have a redundant system, it can be convenient to copy the redundant module's
reboot . hty file to another filename for viewing with this command.

The E-series Router as an FTP Server

FTP Client erx1 FTP Server erx2
Lo0 10.1.1.1 Lo0 10.1.1.1
 FTP server configuration and operation:

– Enable FTP server:
erx2(config)#ftp enable
– Uses vty line authentication method
– Copy file from system space to user space:
erx2#copy startup.scr /outgoing/startup.scr
 On FTP client configuration and operation:
– Configure FTP server static host entry:
erxl(config)#host ftpServer 10.1.1.2 ftp anyone myPass
– Copy file from FTP server:
erxl#copy ftpServer:/outgoing/startup-scr startup.scr
FTP Server Configuration and Operation

The E-series router can also act as an FTP server, which allows the easy transfer of configuration, script, macro,
and software release files to multiple routers. To make the rout er an FTP server, enter the ftp-server enable
command in Global Configuration mode.
FTP sessions on the E -series router use the vty lines. The system divides its vty resources between Telnet, SSH,
and FTP services. Each FTP session requires one vty line. The FTP services use the authentication method
configured for the vty lines. FTP authentication services can also be provided through a RADIUS server. The
router in this example uses a simple password scheme for the vty lines configured, specifically
myPa s s.
For files to be pushed or pulled from the FTP server, they must be in the user space, as opposed to system
space, where the files are usually kept on the flash card. This user space consists of two subdirectories, which
include the /incoming (write-only) and /outgoing (read-only) directories. These subdirectories are automatically
created when you perform the ftp -server enable command.
The example on the slide shows the basic steps for an FTP client to retrieve a file from a router with FTP server
capability. For the FTP client to be able to access the file on the server, it must first be placed in user space,
meaning the /incoming or /outgoing subdirectories. You cannot access the system files directly using FTP
operations. You accomplish this access on the FTP server by using the copy startup. scr /outgoing/startup. scr
command. The FTP client can only access the user space on the router. It cannot access the system space.
FTP Client Configuration and Operation
On the FTP client, you must configure a static host entry for the FTP server. Because FTP sessions use the vty
line authentication method, the host entry must include the password. Next, transfer the file from the FTP server
on erx2 to the FTP client (erxl) using the copy ftpServer : /outgoing/startup. scr startup. scr command.

FTP Server-Related Functions

 Useful commands:
– View the router’s nonvolatile file system with FTP server
functionality:
server#dir
Please wait...
unshared in
file size size date (UTC) use
------------------- -------- -------- ------------------- ---
/incoming <DIR> 0 11/07/2001 16:03:36
/outgoing <DIR> 7168 11/07/2001 16:03:36
good.cnf 71894 71894 10/16/2001 14:25:22
start.cnf 77449 77449 11/27/2001 13:01:02
reboot.hty 28416 28416 11/28/2001 12:19:52
system.log 675 675 08/30/2001 10:22:20
erx_6-0-0.rel 69806959 69806959 10/31/2001 11:00:46 !
erx_5-2-1.rel 65132167 65132167 08/03/2001 08:59:50
Capacity = 220200960, Bytes Free = 45648291, Reserved = 36700160
– To delete files in user space:

server#delete /incoming/test.scr
– To view the contents of a subdirectory in user space:

server#dir /outgoing
Useful Commands
Several useful CLI commands exist that relate to FTP server functionality. One command is the dir
command, as seen in the example on the slide. You can see the subdirectories that are automatically
created (incoming and outgoing) with the ftp-server enable command.
To view files in either the incoming or outgoing directories, use the dir /outgoing or dir /incoming
commands.
To delete a file in one of these subdirectories, use the delete /incoming or del /outgoing commands, as
shown on the slide.
You can also manage files in the user space from an FTP client on the network using FTP protocol
commands. A few of these commands include PWD, LIST, and CWD.

Gathering Information for JTAC

 Provide details of problem and configuration
information
– show version, show hardware, show environment,
show configuration, or show tech-support
erx7#show tech-support
^
% Invalid input detected at '^' marker.
erx7#enable 15
erx7#show tech-support infoForJtac
Show Technical Support
---------------------------------------------------
System Name : erx7
Time : TUE NOV 30 2004 15:20:45 UTC
System up since : TUE NOV 30 2004 12:43:59 UTC
Software release: 41A4A7BD
Boot Flags : 0x26000000
Slot Number : 0
Serial Number : 4304151792
Assembly Number : 3400007251
Assembly Rev : A00
Description : infoForJtac
…
erx7#show tech-support > ftpServer:CompanyXYZ-11302004.txt
************************************************** (DONE)
erx7#
Gathering Information for the JTAC

When requesting technical support from the JTAC, be prepared to provide details relating to the
problem as well as detailed system configuration information. You can use the show commands listed
on the slide to provide the system configuration information required. You can also use the show tech-
support command to gather this information as well as other useful information such as system and
process utilization, the most recent CLI commands, and other internal status information. You must be
at Level 15 to use the show tech-support command. The output of this command is quite lengthy, so
you might want to direct the output to a file on the flash card or a remote host.

Review Questions
1. How do you upgrade the router’s software?

2. What are the two different ways to downgrade
software?
3. What are the benefits and risks of copying a partial
system release?
4. How do you rebuild a corrupted flash card?
5. What are the two ways you can remove enable
passwords?
6. How can you control access to the CLI?

• The different reload options for the router;
• The process to upgrade software;
• The various options to downgrade software;
• Recovering from a corrupted flash;
• Removing passwords;
• The methods for accessing the CLI; and
• Enabling and using FTP server functionality.

Questions
Any Questions?
If you have any questions or concerns about the class you are attending, we suggest that you voice them
now so that your instructor can best address your needs during class.


E-Series B-RAS Configuration Student Guide PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

E-Series B-RAS Configuration Student Guide PDF

Hochgeladen von

Copyright:

Verfügbare Formate

E-Series B-RAS Configuration Basics

1194 North Mathilda Avenue

E-series B-RAS Configuration Basics Student Guide, Revision 7.b

Copyright © 2007, Juniper Networks, Inc.

All rights reserved. Printed in USA.

Release 4.0—August 2002

The information in this document is current as of the date listed above:

YEAR 2000 NOTICE

Module 1: DSL Overview and IP over ATM ..................................................................... 1-1

Module 2: Bridged Ethernet and DHCP ......................................................................... 2-1

Module 3: PPP over ATM................................................................................................. 3-1

Module 4: PPP over Ethernet ........................................................................................ 4-1

Module 5: Dynamic Interfaces ....................................................................................... 5-1

Module 6: L2TP .............................................................................................................. 6-1

Module 8: System Administration................................................................................... 8-1

Education Services Offerings

About This Publication

Juniper Networks Support

Additional Information - vii

Module 0: Course Introduction

Copyright © 2007, Juniper Networks, Inc.

Copyright © 2007, Juniper Networks, Inc.

This Chapter Discusses:

Module 0: Introduction and Overview 0-2

Copyright © 2007, Juniper Networks, Inc.

Module 0: Introduction and Overview 0-3

Copyright © 2007, Juniper Networks, Inc.

Module 0: Introduction and Overview 0-4

Familiarity with Juniper Networks system

Copyright © 2007, Juniper Networks, Inc.

Module 0: Introduction and Overview 0-5

Copyright © 2007, Juniper Networks, Inc.

General Course Administration

Module 0: Introduction and Overview 0-6

Copyright © 2007, Juniper Networks, Inc.

Training and Study Materials

Module 0: Introduction and Overview 0-7

 Please be sure to tell us how we did!

Copyright © 2007, Juniper Networks, Inc.

Module 0: Introduction and Overview 0-8

M-series, T-series, and J-series Curriculum

Prerequisites: Detailed knowledge of M-series and

Operation and IPSec

Copyright © 2007, Juniper Networks, Inc.

Service Provider Curriculum: JUNOS Platforms

Module 0: Introduction and Overview 0-9

The E-series Curriculum

E-series Routing E-series MPLS

Copyright © 2007, Juniper Networks, Inc.

Service Provider Curriculum: JUNOSe Platforms

Module 0: Introduction and Overview 0-10

Technical Certification Programs

 Two technical certification tracks

Copyright © 2007, Juniper Networks, Inc.

Technical Certification Programs: Routing Tracks

Module 0: Introduction and Overview 0-11

Juniper Networks Certified Internet Associate

Copyright © 2007, Juniper Networks, Inc.

The JNCIA Certification

Module 0: Introduction and Overview 0-12

Juniper Networks Certified Internet Specialist

Copyright © 2007, Juniper Networks, Inc.

The JNCIS Certification