swconfig link
JunosE™ Software
for E Series™ Broadband
Services Routers
Link Layer Configuration Guide
Release
11.3.x
Published: 2010-10-13
Copyright © 2010, Juniper Networks, Inc.
Juniper Networks, Inc.
1194 North Mathilda Avenue
Sunnyvale, California 94089
USA
408-745-2000
www.juniper.net
Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United
States and other countries. The Juniper Networks Logo, the Junos logo, 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.
Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify,
transfer, or otherwise revise this publication without notice.
Products made or sold by Juniper Networks or components thereof might be covered by one or more of the following patents that are
owned by or licensed to Juniper Networks: U.S. Patent Nos. 5,473,599, 5,905,725, 5,909,440, 6,192,051, 6,333,650, 6,359,479, 6,406,312,
6,429,706, 6,459,579, 6,493,347, 6,538,518, 6,538,899, 6,552,918, 6,567,902, 6,578,186, and 6,590,785.
JunosE™ Software for E Series™ Broadband Services Routers Link Layer Configuration Guide
Release 11.3.x
Copyright © 2010, Juniper Networks, Inc.
All rights reserved. Printed in USA.
Writing: Krupa Chandrashekar, Subash Babu Asokan, Pallavi Madhusudhan, Diane Florio, Bruce Gillham, Justine Kangas, Sarah Lesway-Ball,
Helen Shaw, Brian Wesley Simmons, Fran Singer
Editing: Benjamin Mann
Illustration: Nathaniel Woodward
Cover Design: Edmonds Design
Revision History
October 2010—FRS JunosE 11.3.x
The information in this document is current as of the date listed in the revision history.
YEAR 2000 NOTICE
Juniper Networks hardware and software products are Year 2000 compliant. The Junos OS has no known time-related limitations through
the year 2038. However, the NTP application is known to have some difficulty in the year 2036.
ii
Copyright © 2010, Juniper Networks, Inc.
END USER LICENSE AGREEMENT
READ THIS END USER LICENSE AGREEMENT (“AGREEMENT”) BEFORE DOWNLOADING, INSTALLING, OR USING THE SOFTWARE.
BY DOWNLOADING, INSTALLING, OR USING THE SOFTWARE OR OTHERWISE EXPRESSING YOUR AGREEMENT TO THE TERMS
CONTAINED HEREIN, YOU (AS CUSTOMER OR IF YOU ARE NOT THE CUSTOMER, AS A REPRESENTATIVE/AGENT AUTHORIZED TO
BIND THE CUSTOMER) CONSENT TO BE BOUND BY THIS AGREEMENT. IF YOU DO NOT OR CANNOT AGREE TO THE TERMS CONTAINED
HEREIN, THEN (A) DO NOT DOWNLOAD, INSTALL, OR USE THE SOFTWARE, AND (B) YOU MAY CONTACT JUNIPER NETWORKS
REGARDING LICENSE TERMS.
1. The Parties. The parties to this Agreement are (i) Juniper Networks, Inc. (if the Customer’s principal office is located in the Americas) or
Juniper Networks (Cayman) Limited (if the Customer’s principal office is located outside the Americas) (such applicable entity being referred
to herein as “Juniper”), and (ii) the person or organization that originally purchased from Juniper or an authorized Juniper reseller the applicable
license(s) for use of the Software (“Customer”) (collectively, the “Parties”).
2. The Software. In this Agreement, “Software” means the program modules and features of the Juniper or Juniper-supplied software, for
which Customer has paid the applicable license or support fees to Juniper or an authorized Juniper reseller, or which was embedded by
Juniper in equipment which Customer purchased from Juniper or an authorized Juniper reseller. “Software” also includes updates, upgrades
and new releases of such software. “Embedded Software” means Software which Juniper has embedded in or loaded onto the Juniper
equipment and any updates, upgrades, additions or replacements which are subsequently embedded in or loaded onto the equipment.
3. License Grant. Subject to payment of the applicable fees and the limitations and restrictions set forth herein, Juniper grants to Customer
a non-exclusive and non-transferable license, without right to sublicense, to use the Software, in executable form only, subject to the
following use restrictions:
a. Customer shall use Embedded Software solely as embedded in, and for execution on, Juniper equipment originally purchased by
Customer from Juniper or an authorized Juniper reseller.
b. Customer shall use the Software on a single hardware chassis having a single processing unit, or as many chassis or processing units
for which Customer has paid the applicable license fees; provided, however, with respect to the Steel-Belted Radius or Odyssey Access
Client software only, Customer shall use such Software on a single computer containing a single physical random access memory space
and containing any number of processors. Use of the Steel-Belted Radius or IMS AAA software on multiple computers or virtual machines
(e.g., Solaris zones) requires multiple licenses, regardless of whether such computers or virtualizations are physically contained on a single
chassis.
c. Product purchase documents, paper or electronic user documentation, and/or the particular licenses purchased by Customer may
specify limits to Customer’s use of the Software. Such limits may restrict use to a maximum number of seats, registered endpoints, concurrent
users, sessions, calls, connections, subscribers, clusters, nodes, realms, devices, links, ports or transactions, or require the purchase of
separate licenses to use particular features, functionalities, services, applications, operations, or capabilities, or provide throughput,
performance, configuration, bandwidth, interface, processing, temporal, or geographical limits. In addition, such limits may restrict the use
of the Software to managing certain kinds of networks or require the Software to be used only in conjunction with other specific Software.
Customer’s use of the Software shall be subject to all such limitations and purchase of all applicable licenses.
d. For any trial copy of the Software, Customer’s right to use the Software expires 30 days after download, installation or use of the
Software. Customer may operate the Software after the 30-day trial period only if Customer pays for a license to do so. Customer may not
extend or create an additional trial period by re-installing the Software after the 30-day trial period.
e. The Global Enterprise Edition of the Steel-Belted Radius software may be used by Customer only to manage access to Customer’s
enterprise network. Specifically, service provider customers are expressly prohibited from using the Global Enterprise Edition of the
Steel-Belted Radius software to support any commercial network access services.
The foregoing license is not transferable or assignable by Customer. No license is granted herein to any user who did not originally purchase
the applicable license(s) for the Software from Juniper or an authorized Juniper reseller.
4. Use Prohibitions. Notwithstanding the foregoing, the license provided herein does not permit the Customer to, and Customer agrees
not to and shall not: (a) modify, unbundle, reverse engineer, or create derivative works based on the Software; (b) make unauthorized
copies of the Software (except as necessary for backup purposes); (c) rent, sell, transfer, or grant any rights in and to any copy of the
Software, in any form, to any third party; (d) remove any proprietary notices, labels, or marks on or in any copy of the Software or any product
in which the Software is embedded; (e) distribute any copy of the Software to any third party, including as may be embedded in Juniper
equipment sold in the secondhand market; (f) use any ‘locked’ or key-restricted feature, function, service, application, operation, or capability
without first purchasing the applicable license(s) and obtaining a valid key from Juniper, even if such feature, function, service, application,
operation, or capability is enabled without a key; (g) distribute any key for the Software provided by Juniper to any third party; (h) use the
Copyright © 2010, Juniper Networks, Inc.
iii
Software in any manner that extends or is broader than the uses purchased by Customer from Juniper or an authorized Juniper reseller; (i)
use Embedded Software on non-Juniper equipment; (j) use Embedded Software (or make it available for use) on Juniper equipment that
the Customer did not originally purchase from Juniper or an authorized Juniper reseller; (k) disclose the results of testing or benchmarking
of the Software to any third party without the prior written consent of Juniper; or (l) use the Software in any manner other than as expressly
provided herein.
5. Audit. Customer shall maintain accurate records as necessary to verify compliance with this Agreement. Upon request by Juniper,
Customer shall furnish such records to Juniper and certify its compliance with this Agreement.
6. Confidentiality. The Parties agree that aspects of the Software and associated documentation are the confidential property of Juniper.
As such, Customer shall exercise all reasonable commercial efforts to maintain the Software and associated documentation in confidence,
which at a minimum includes restricting access to the Software to Customer employees and contractors having a need to use the Software
for Customer’s internal business purposes.
7. Ownership. Juniper and Juniper’s licensors, respectively, retain ownership of all right, title, and interest (including copyright) in and to
the Software, associated documentation, and all copies of the Software. Nothing in this Agreement constitutes a transfer or conveyance
of any right, title, or interest in the Software or associated documentation, or a sale of the Software, associated documentation, or copies
of the Software.
8. Warranty, Limitation of Liability, Disclaimer of Warranty. The warranty applicable to the Software shall be as set forth in the warranty
statement that accompanies the Software (the “Warranty Statement”). Nothing in this Agreement shall give rise to any obligation to support
the Software. Support services may be purchased separately. Any such support shall be governed by a separate, written support services
agreement. TO THE MAXIMUM EXTENT PERMITTED BY LAW, JUNIPER SHALL NOT BE LIABLE FOR ANY LOST PROFITS, LOSS OF DATA,
OR COSTS OR PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES, OR FOR ANY SPECIAL, INDIRECT, OR CONSEQUENTIAL DAMAGES
ARISING OUT OF THIS AGREEMENT, THE SOFTWARE, OR ANY JUNIPER OR JUNIPER-SUPPLIED SOFTWARE. IN NO EVENT SHALL JUNIPER
BE LIABLE FOR DAMAGES ARISING FROM UNAUTHORIZED OR IMPROPER USE OF ANY JUNIPER OR JUNIPER-SUPPLIED SOFTWARE.
EXCEPT AS EXPRESSLY PROVIDED IN THE WARRANTY STATEMENT TO THE EXTENT PERMITTED BY LAW, JUNIPER DISCLAIMS ANY
AND ALL WARRANTIES IN AND TO THE SOFTWARE (WHETHER EXPRESS, IMPLIED, STATUTORY, OR OTHERWISE), INCLUDING ANY
IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NONINFRINGEMENT. IN NO EVENT DOES
JUNIPER WARRANT THAT THE SOFTWARE, OR ANY EQUIPMENT OR NETWORK RUNNING THE SOFTWARE, WILL OPERATE WITHOUT
ERROR OR INTERRUPTION, OR WILL BE FREE OF VULNERABILITY TO INTRUSION OR ATTACK. In no event shall Juniper’s or its suppliers’
or licensors’ liability to Customer, whether in contract, tort (including negligence), breach of warranty, or otherwise, exceed the price paid
by Customer for the Software that gave rise to the claim, or if the Software is embedded in another Juniper product, the price paid by
Customer for such other product. Customer acknowledges and agrees that Juniper has set its prices and entered into this Agreement in
reliance upon the disclaimers of warranty and the limitations of liability set forth herein, that the same reflect an allocation of risk between
the Parties (including the risk that a contract remedy may fail of its essential purpose and cause consequential loss), and that the same
form an essential basis of the bargain between the Parties.
9. Termination. Any breach of this Agreement or failure by Customer to pay any applicable fees due shall result in automatic termination
of the license granted herein. Upon such termination, Customer shall destroy or return to Juniper all copies of the Software and related
documentation in Customer’s possession or control.
10. Taxes. All license fees payable under this agreement are exclusive of tax. Customer shall be responsible for paying Taxes arising from
the purchase of the license, or importation or use of the Software. If applicable, valid exemption documentation for each taxing jurisdiction
shall be provided to Juniper prior to invoicing, and Customer shall promptly notify Juniper if their exemption is revoked or modified. All
payments made by Customer shall be net of any applicable withholding tax. Customer will provide reasonable assistance to Juniper in
connection with such withholding taxes by promptly: providing Juniper with valid tax receipts and other required documentation showing
Customer’s payment of any withholding taxes; completing appropriate applications that would reduce the amount of withholding tax to
be paid; and notifying and assisting Juniper in any audit or tax proceeding related to transactions hereunder. Customer shall comply with
all applicable tax laws and regulations, and Customer will promptly pay or reimburse Juniper for all costs and damages related to any
liability incurred by Juniper as a result of Customer’s non-compliance or delay with its responsibilities herein. Customer’s obligations under
this Section shall survive termination or expiration of this Agreement.
11. Export. Customer agrees to comply with all applicable export laws and restrictions and regulations of any United States and any
applicable foreign agency or authority, and not to export or re-export the Software or any direct product thereof in violation of any such
restrictions, laws or regulations, or without all necessary approvals. Customer shall be liable for any such violations. The version of the
Software supplied to Customer may contain encryption or other capabilities restricting Customer’s ability to export the Software without
an export license.
iv
Copyright © 2010, Juniper Networks, Inc.
12. Commercial Computer Software. The Software is “commercial computer software” and is provided with restricted rights. Use,
duplication, or disclosure by the United States government is subject to restrictions set forth in this Agreement and as provided in DFARS
227.7201 through 227.7202-4, FAR 12.212, FAR 27.405(b)(2), FAR 52.227-19, or FAR 52.227-14(ALT III) as applicable.
13. Interface Information. To the extent required by applicable law, and at Customer's written request, Juniper shall provide Customer
with the interface information needed to achieve interoperability between the Software and another independently created program, on
payment of applicable fee, if any. Customer shall observe strict obligations of confidentiality with respect to such information and shall use
such information in compliance with any applicable terms and conditions upon which Juniper makes such information available.
14. Third Party Software. Any licensor of Juniper whose software is embedded in the Software and any supplier of Juniper whose products
or technology are embedded in (or services are accessed by) the Software shall be a third party beneficiary with respect to this Agreement,
and such licensor or vendor shall have the right to enforce this Agreement in its own name as if it were Juniper. In addition, certain third party
software may be provided with the Software and is subject to the accompanying license(s), if any, of its respective owner(s). To the extent
portions of the Software are distributed under and subject to open source licenses obligating Juniper to make the source code for such
portions publicly available (such as the GNU General Public License (“GPL”) or the GNU Library General Public License (“LGPL”)), Juniper
will make such source code portions (including Juniper modifications, as appropriate) available upon request for a period of up to three
years from the date of distribution. Such request can be made in writing to Juniper Networks, Inc., 1194 N. Mathilda Ave., Sunnyvale, CA
94089, ATTN: General Counsel. You may obtain a copy of the GPL at http://www.gnu.org/licenses/gpl.html, and a copy of the LGPL
at http://www.gnu.org/licenses/lgpl.html .
15. Miscellaneous. This Agreement shall be governed by the laws of the State of California without reference to its conflicts of laws
principles. The provisions of the U.N. Convention for the International Sale of Goods shall not apply to this Agreement. For any disputes
arising under this Agreement, the Parties hereby consent to the personal and exclusive jurisdiction of, and venue in, the state and federal
courts within Santa Clara County, California. This Agreement constitutes the entire and sole agreement between Juniper and the Customer
with respect to the Software, and supersedes all prior and contemporaneous agreements relating to the Software, whether oral or written
(including any inconsistent terms contained in a purchase order), except that the terms of a separate written agreement executed by an
authorized Juniper representative and Customer shall govern to the extent such terms are inconsistent or conflict with terms contained
herein. No modification to this Agreement nor any waiver of any rights hereunder shall be effective unless expressly assented to in writing
by the party to be charged. If any portion of this Agreement is held invalid, the Parties agree that such invalidity shall not affect the validity
of the remainder of this Agreement. This Agreement and associated documentation has been written in the English language, and the
Parties agree that the English version will govern. (For Canada: Les parties aux présentés confirment leur volonté que cette convention de
même que tous les documents y compris tout avis qui s'y rattaché, soient redigés en langue anglaise. (Translation: The parties confirm that
this Agreement and all related documentation is and will be in the English language)).
Copyright © 2010, Juniper Networks, Inc.
v
vi
Copyright © 2010, Juniper Networks, Inc.
Abbreviated Table of Contents
About the Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxix
Part 1
Chapters
Chapter 1
Configuring ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Chapter 2
Configuring Frame Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Chapter 3
Configuring Multilink Frame Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Chapter 4
Configuring Upper-Layer Protocols over Static Ethernet Interfaces . . . . . . 151
Chapter 5
Configuring VLAN and S-VLAN Subinterfaces . . . . . . . . . . . . . . . . . . . . . . . . 167
Chapter 6
Configuring 802.3ad Link Aggregation and Link Redundancy . . . . . . . . . . 197
Chapter 7
Configuring IEEE 802.3ah OAM Link-Fault Management . . . . . . . . . . . . . . 223
Chapter 8
Configuring Point-to-Point Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Chapter 9
Configuring Multilink PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Chapter 10
Configuring Multiclass Multilink PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Chapter 11
Configuring Packet over SONET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Chapter 12
Configuring Point-to-Point Protocol over Ethernet . . . . . . . . . . . . . . . . . . . . 371
Chapter 13
Configuring Bridged IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
Chapter 14
Configuring Bridged Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
Chapter 15
Configuring Transparent Bridging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
Chapter 16
Configuring Cisco HDLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
Chapter 17
Configuring Dynamic Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
Chapter 18
Configuring Dynamic Interfaces Using Bulk Configuration . . . . . . . . . . . . . 619
Part 2
Index
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709
Copyright © 2010, Juniper Networks, Inc.
vii
JunosE 11.3.x Link Layer Configuration Guide
viii
Copyright © 2010, Juniper Networks, Inc.
Table of Contents
About the Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxix
E Series and JunosE Documentation and Release Notes . . . . . . . . . . . . . . . . . . . xxix
Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxix
E Series and JunosE Text and Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . xxix
Obtaining Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxi
Documentation Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxi
Requesting Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxi
Self-Help Online Tools and Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxii
Opening a Case with JTAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxxii
Part 1
Chapters
Chapter 1
Configuring ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
ATM Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
ATM Physical Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
ATM Virtual Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Virtual Channel Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Virtual Path Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
ATM SVCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
ATM Adaptation Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Local ATM Passthrough . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
VCC Cell Relay Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Traffic Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Connection Admission Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
ILMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
VPI/VCI Address Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
VP Tunneling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Module Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Interface Specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Supported Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Module Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Virtual Channel Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
ATM NBMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
ARP Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Static Map Versus Inverse ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Aging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Removing Circuits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Copyright © 2010, Juniper Networks, Inc.
ix
JunosE 11.3.x Link Layer Configuration Guide
Operations, Administration, and Management of ATM Interfaces . . . . . . . . . . . . . 14
End-to-End and Segment Endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Fault Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
How the ATM Interface Handles AIS Cells . . . . . . . . . . . . . . . . . . . . . . . . . 15
How the ATM Interface Handles RDI Cells . . . . . . . . . . . . . . . . . . . . . . . . . 15
Continuity Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Activation and Deactivation Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Activating CC Cell Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Deactivating CC Cell Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
After CC Cell Flow Is Enabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Loopback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
VC Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
F4 OAM Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
ATM Ping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
How the ATM Interface Handles Loopback Cells Received . . . . . . . . . . . 18
Automatic Disabling of F5 OAM Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Rate Limiting for F5 OAM Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Before You Configure ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Creating a Basic Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Setting Optional Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Optional Tasks on ATM 1483 Subinterfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Configuring OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Configuring F4 OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Configuring F5 OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Setting a Loopback Location ID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Enabling OAM Flush . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Running ATM Ping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Configuring an NBMA Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Creating an NBMA Static Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Assigning Descriptions to Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Sending Interface Descriptions to AAA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Assigning Descriptions to Virtual Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Exporting ATM 1483 Subinterface Descriptions . . . . . . . . . . . . . . . . . . . . . . . . 42
Configuring Individual ATM PVC Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Creating Control PVCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Creating Data PVCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Configuring the Service Category for Data PVCs . . . . . . . . . . . . . . . . . . . . . . . 46
Configuring Encapsulation for Data PVCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Configuring F5 OAM for Data PVCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Configuring Inverse ARP for Data PVCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Configuring ATM VC Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Precedence Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Precedence Levels for Static PVCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Precedence Levels for Dynamic PVCs . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Precedence Level Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Upgrade Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
x
Copyright © 2010, Juniper Networks, Inc.
Table of Contents
Configuring VC Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Assigning VC Classes to Individual PVCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Assigning VC Classes to ATM Major Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 62
Assigning VC Classes to Static ATM 1483 Subinterfaces . . . . . . . . . . . . . . . . 63
Assigning VC Classes to Base Profiles for Bulk-Configured VC Ranges . . . . . 64
Precedence Level Examples for Assigning VC Classes . . . . . . . . . . . . . . . . . . 64
Example 1: Explicitly Changing the Service Category . . . . . . . . . . . . . . . . 65
Example 2: Changing the Encapsulation Method in the VC Class . . . . . . 65
Example 3: Effect of Using the atm pvc Command . . . . . . . . . . . . . . . . . 66
Example 4: Overriding RADIUS Values . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Configuring Dynamic ATM 1483 Subinterfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Monitoring ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Setting Statistics Baselines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Displaying Interface Rate Statistics for ATM VCs and ATM VPs . . . . . . . . . . . 68
Using ATM show Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Chapter 2
Configuring Frame Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Framing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Error Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Unicast and Multicast Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
User-to-Network and Network-to-Network Interfaces . . . . . . . . . . . . . . . . . 106
Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Module Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Interface Specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Before You Configure Frame Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Configuring Frame Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
End-to-End Fragmentation and Reassembly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Frame Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Frame Reassembly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Map Class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Configuring End-to-End Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Monitoring Frame Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Chapter 3
Configuring Multilink Frame Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
T1/E1 Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
MLFR Link Integrity Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Interface Stacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Module Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Interface Specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Supported MLFR Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Unsupported MLFR Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Before You Configure MLFR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Configuration Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Configuring Frame Relay Versus MLFR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Copyright © 2010, Juniper Networks, Inc.
xi
JunosE 11.3.x Link Layer Configuration Guide
Monitoring MLFR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Chapter 4
Configuring Upper-Layer Protocols over Static Ethernet Interfaces . . . . . . 151
Upper-Layer Protocols over Static Ethernet Overview . . . . . . . . . . . . . . . . . . . . . 151
Upper-Layer Protocols over Static Ethernet Platform Considerations . . . . . . . . . 152
Module Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Interface Specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Upper-Layer Protocols over Static Ethernet References . . . . . . . . . . . . . . . . . . . . 153
Configuring IP over a Static Ethernet Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Configuring PPPoE over a Static Ethernet Interface . . . . . . . . . . . . . . . . . . . . . . . 154
Configuring IP and MPLS over a Static Ethernet Interface . . . . . . . . . . . . . . . . . . 155
Configuring IP, MPLS, and PPPoE over Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . 155
L2TP and Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Multinetting and Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Monitoring Upper-Level Protocols over Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Chapter 5
Configuring VLAN and S-VLAN Subinterfaces . . . . . . . . . . . . . . . . . . . . . . . . 167
VLAN Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
S-VLAN Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
VLAN and S-VLAN Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Module Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Interface Specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
VLAN and S-VLAN References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Creating a VLAN Subinterface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Creating a VLAN Major Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Configuring IP over VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Configuring PPPoE over VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Configuring MPLS over VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Configuring IP over VLAN and PPPoE over VLAN . . . . . . . . . . . . . . . . . . . . . . 174
Configuring an S-VLAN Subinterface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Configuring an S-VLAN Subinterface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Configuring PPPoE over an S-VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Configuring S-VLAN Tunnels for Layer 2 Services over MPLS . . . . . . . . . . . . . . . . 182
Advantages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Interface Stacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Configuration Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
S-VLAN Oversubscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Monitoring VLAN and S-VLAN Subinterfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Displaying Interface Rate Statistics for VLAN Subinterfaces . . . . . . . . . . . . 186
Using Ethernet show Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Chapter 6
Configuring 802.3ad Link Aggregation and Link Redundancy . . . . . . . . . . 197
802.3ad Link Aggregation for Ethernet Overview . . . . . . . . . . . . . . . . . . . . . . . . . 197
LACP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Higher-Level Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Load Balancing and QoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Ethernet Link Aggregation and MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
802.3ad Link Aggregation Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . 199
Module Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Interface Specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
xii
Copyright © 2010, Juniper Networks, Inc.
Table of Contents
802.3ad Link Aggregation References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Configuring 802.3ad Link Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Configuring an Ethernet Physical Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Configuring a LAG Bundle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Configuring IP for a LAG Bundle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Configuring a VLAN Subinterface for a LAG Bundle . . . . . . . . . . . . . . . . . . . 202
Configuring a PPPoE Subinterface for a LAG Bundle . . . . . . . . . . . . . . . . . . 202
Configuring MPLS for a LAG Bundle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Example: Configuring an IP Interface for a LAG Bundle . . . . . . . . . . . . . . . . . . . . 205
Example: Configuring a PPPoE Subinterface for a LAG Bundle . . . . . . . . . . . . . . 205
Example: Configuring a PPPoE Subinterface over a VLAN for a LAG Bundle . . . 206
Example: Configuring MPLS for a LAG Bundle . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Example: Configuring MPLS over a VLAN for a LAG Bundle . . . . . . . . . . . . . . . . . 207
Ethernet Link Redundancy Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Ethernet Link Redundancy Configuration Models . . . . . . . . . . . . . . . . . . . . . 208
Ethernet Link Redundancy Configuration Diagrams . . . . . . . . . . . . . . . 209
Ethernet Link Redundancy Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Link Failure and Acquisition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Protecting Against Physical Link Failure . . . . . . . . . . . . . . . . . . . . . . . . . 213
Protecting Against Virtual Link Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Reverting After a Failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
LACP Configuration and Member Link Behavior . . . . . . . . . . . . . . . . . . . . . . 214
Member Link with Non-LAG Partner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Ethernet Link Redundancy and RSTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Acquiring Initial Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Detecting Failures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Failing Over . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Configuring Ethernet Link Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Monitoring 802.3ad Link Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Chapter 7
Configuring IEEE 802.3ah OAM Link-Fault Management . . . . . . . . . . . . . . 223
Ethernet OAM Link-Fault Management Overview . . . . . . . . . . . . . . . . . . . . . . . . 224
Ethernet OAM Link-Fault Management Platform Considerations . . . . . . . . . . . . 225
Module Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Interface Specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Ethernet OAM Link-Fault Management References . . . . . . . . . . . . . . . . . . . . . . . 226
OAM Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
OAM Elements Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
OAM Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
OAM Sublayer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Control Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Multiplexer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Parser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
OAM Feature Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
OAM Discovery Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Information OAM PDU Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Transmission Settings for Information OAM PDUs . . . . . . . . . . . . . . . . . . . . . 231
Copyright © 2010, Juniper Networks, Inc.
xiii
JunosE 11.3.x Link Layer Configuration Guide
OAM Link Monitoring Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Supported Error Events for Tracking Link Faults . . . . . . . . . . . . . . . . . . . . . . 233
Actions Performed on Exceeding Threshold Values . . . . . . . . . . . . . . . . . . . 233
OAM Remote Fault Detection Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Link Fault . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Dying Gasp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Critical Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
OAM Remote and Local Loopback Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Interrelationship of OAM Link-Fault Management with Ethernet Subsystems . . 236
Guidelines for Configuring 802.3ah OAM Link-Fault Management . . . . . . . . . . . 237
Configuring 802.3ah OAM Link-Fault Management . . . . . . . . . . . . . . . . . . . . . . . 238
Example: Configuring 802.3ah OAM Link-Fault Management and Enabling
Remote Failure Monitoring on an Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Example: Enabling Remote Loopback Support on the Local Interface . . . . . . . . 245
Monitoring OAM Link-Fault Management Discovery Settings for an Interface . . 245
Monitoring OAM Link-Fault Management Statistics for an Interface . . . . . . . . . 248
Monitoring OAM Link-Fault Management Configuration for an Interface . . . . . . 250
Monitoring OAM Link-Fault Management Sessions on All Configured
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Chapter 8
Configuring Point-to-Point Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Framing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Error Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Link Control Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
LCP Negotiation Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
Validation of LCP Peer Magic Number . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
B-RAS Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Rate Limiting for PPP Control Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Extensible Authentication Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
EAP Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
EAP Packet Retransmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
EAP Behavior in an L2TP Environment . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Remote Peer Scenarios During Negotiation of PPP Options . . . . . . . . . . . . 267
IPCP Lockout and Local IP Address Pool Restoration . . . . . . . . . . . . . . . . . . 268
IPCP Negotiation with Optional Peer IP Address . . . . . . . . . . . . . . . . . . . . . 268
Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Module Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
Interface Specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
Before You Configure PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Optional Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Configuring PPP Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
PPP Accounting Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Monitoring PPP Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
xiv
Copyright © 2010, Juniper Networks, Inc.
Table of Contents
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Chapter 9
Configuring Multilink PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
MLPPP LCP Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
MLPPP Link Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
Module Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
Interface Specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
Supported MLPPP Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
Unsupported MLPPP Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Before You Configure Static MLPPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Configuring Static MLPPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Configuration Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
Contextual Command Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
Configuring Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
Configuring Other PPP Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
Configuring Dynamic MLPPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
Configuring MLPPP Fragmentation and Reassembly . . . . . . . . . . . . . . . . . . . . . 320
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
Supported Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
Module Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Link Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
Bundle Validation and Configuration Guidelines . . . . . . . . . . . . . . . . . . . 321
Bundle Validation Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
Recovering from Bundle Validation Failure . . . . . . . . . . . . . . . . . . . . . . . 322
Configuring Fragmentation and Reassembly for Static MLPPP . . . . . . . . . . 323
Static MLPPP over ATM 1483 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Configuring Fragmentation and Reassembly for Dynamic MLPPP . . . . . . . 324
Dynamic MLPPP over PPPoE Example . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Dynamic MLPPP over L2TP Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
Configuring Fragmentation and Reassembly for MLPPP Bundles . . . . . . . . 328
Configuring Multiclass MLPPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328
Monitoring MLPPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Chapter 10
Configuring Multiclass Multilink PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Multiclass MLPPP Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Multiclass MLPPP Fragmentation and Reassembly . . . . . . . . . . . . . . . . . . . 345
Multiclass MLPPP Configuration Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . 346
Multiclass MLPPP Traffic Classes Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Multiclass MLPPP LCP Extensions Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
Multiclass MLPPP Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347
Module Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Interface Specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Multiclass MLPPP References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Configuring Multiclass MLPPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Enabling Multiclass MLPPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
Copyright © 2010, Juniper Networks, Inc.
xv
JunosE 11.3.x Link Layer Configuration Guide
Configuring Traffic Classes on Multiclass MLPPP Interfaces . . . . . . . . . . . . . . . . 350
Configuring Fragmentation on Multiclass MLPPP Interfaces . . . . . . . . . . . . . . . 350
Configuring Reassembly on Multiclass MLPPP Interfaces . . . . . . . . . . . . . . . . . . 351
Example: Configuring Multiclass MLPPP on a Dynamic Interface . . . . . . . . . . . . 352
Example: Configuring Multiclass MLPPP on a Static Interface . . . . . . . . . . . . . . 353
Monitoring Multiclass MLPPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Chapter 11
Configuring Packet over SONET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
POS Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
SONET/SDH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
Module Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Interface Specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Before You Configure POS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
Monitoring POS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
Chapter 12
Configuring Point-to-Point Protocol over Ethernet . . . . . . . . . . . . . . . . . . . . 371
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
PPPoE Stages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
PPPoE Service Name Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
Table Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
Enabling the Service Name Table for Use . . . . . . . . . . . . . . . . . . . . . . . . 375
Using the PPPoE Remote Circuit ID to Identify Subscribers . . . . . . . . . . . . . 375
Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
PPPoE Remote Circuit ID Capture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
PPPoE Remote Circuit ID Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
Use by RADIUS or L2TP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
System Event Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
PPPoE MTU Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380
Module Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Interface Specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381
Access Nodes in Ethernet Aggregation Networks Overview . . . . . . . . . . . . . . . . 382
ATM-to-Ethernet Interworking Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
Before You Configure PPPoE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Configuring PPPoE over ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Processing of IWF PPPoE Sessions with Duplicate MAC Addresses . . . . . . . . . . 391
Guidelines for Configuring Duplicate Protection for IWF PPPoE Sessions . . . . . . 391
Configuration Examples for ATM-to-Ethernet Interworking Functions . . . . . . . . 392
Single DSLAM Connected to a PPPoE Access Concentrator Example . . . . . 392
Multiple DSLAMs Connected to a PPPoE Access Concentrator Example . . 393
xvi
Copyright © 2010, Juniper Networks, Inc.
Table of Contents
Configuring PPPoE for Ethernet Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
PPPoE Interface and Subinterface Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Configuring IPv4 and IPv6 over PPPoE with VLAN . . . . . . . . . . . . . . . . . . . . 395
Configuring PPPoE Without VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
Configuring PADM Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
Configuring PADN Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
Configuring PPPoE Service Name Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Creating and Populating PPPoE Service Name Tables . . . . . . . . . . . . . . . . . 405
Enabling PPPoE Service Name Tables for Use with Static Interfaces . . . . . 408
PPPoE over ATM Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
PPPoE over Ethernet Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
Enabling PPPoE Service Name Tables for Use with Dynamic Interfaces . . . . 411
Configuring PADS Packet Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Configuring PPPoE Remote Circuit ID Capture . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
Monitoring PPPoE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 419
Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435
Chapter 13
Configuring Bridged IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
Proxy ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
Module Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
Interface Specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
Before You Configure Bridged IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
Configuring Bridged IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 440
Chapter 14
Configuring Bridged Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
Bridged Ethernet Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
Assigning MAC Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
VLAN and S-VLAN Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
Module Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
Interface Specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
Configuring Bridged Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
Configuring IP with PPPoE Terminated at the Router . . . . . . . . . . . . . . . . . . 447
Alternative Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
Configuring VLANs over Bridged Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
Configuring VLAN Subinterfaces over Bridged Ethernet . . . . . . . . . . . . . . . . 453
Configuring Higher-Level Protocols over VLANs . . . . . . . . . . . . . . . . . . . . . . 453
Configuring IP over VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
Configuring PPPoE over VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
Configuring MPLS over VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454
Configuring S-VLANs over Bridged Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
Configuring S-VLAN Subinterfaces over Bridged Ethernet . . . . . . . . . . . . . . 457
Configuring Higher-Level Protocols over S-VLANs . . . . . . . . . . . . . . . . . . . . 458
Configuring the MTU Size for Bridged Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . 459
Copyright © 2010, Juniper Networks, Inc.
xvii
JunosE 11.3.x Link Layer Configuration Guide
Monitoring Bridged Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 460
Chapter 15
Configuring Transparent Bridging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
How Transparent Bridging Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
Bridge Groups and Bridge Group Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . 466
Bridge Interface Types and Supported Configurations . . . . . . . . . . . . . . . . . 467
Subscriber Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468
Concurrent Routing and Bridging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
Transparent Bridging and VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
Unsupported Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
Module Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
Interface Specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
Before You Configure Transparent Bridging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 471
Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 472
Creating Bridge Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
Configuring Optional Bridge Group Attributes . . . . . . . . . . . . . . . . . . . . . . . . 473
Configuring Bridge Group Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
Configuring Subscriber Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 478
Enabling Concurrent Routing and Bridging . . . . . . . . . . . . . . . . . . . . . . . . . . 483
Configuring Explicit Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483
Configuration Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
Example 1: Bridging with Bridged Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . 485
Example 2: Bridging with VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486
Monitoring Transparent Bridging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
Setting Statistics Baselines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
Removing Dynamic MAC Address Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
Monitoring Bridge Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
Monitoring Bridge Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
Monitoring Subscriber Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
Chapter 16
Configuring Cisco HDLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
Framing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503
Error Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504
SLARP Keepalive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504
Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504
Module Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504
Interface Specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504
Before You Configure Cisco HDLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505
Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505
Optional Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506
Configuration Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508
Monitoring Cisco HDLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508
xviii
Copyright © 2010, Juniper Networks, Inc.
Table of Contents
Chapter 17
Configuring Dynamic Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
Autodetection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512
Types of Dynamic Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512
Upper-Layer Dynamic Interface Configurations . . . . . . . . . . . . . . . . . . . . . . . 513
Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514
RADIUS Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514
ATM Oversubscription for Dynamic Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 515
How Oversubscription Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515
Static ATM 1483 Subinterfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 515
Bulk-Configured VC Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516
Combination of Static ATM 1483 Subinterfaces and Bulk-Configured
VC Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 516
Ethernet Oversubscription for Dynamic Interfaces . . . . . . . . . . . . . . . . . . . . 516
Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
Module Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
Interface Specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 517
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 518
About Configuring Dynamic Interfaces over Static ATM . . . . . . . . . . . . . . . . . . . . 518
About Configuring RADIUS for Dynamic Interfaces . . . . . . . . . . . . . . . . . . . . 519
subscriber Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
Authenticating Subscribers on Dynamic Bridged Ethernet over Static
ATM Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519
Placing Dynamic IP Routes in the Routing Table . . . . . . . . . . . . . . . . . . 520
auto-configure Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521
Encapsulation Type Lockout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 521
atm pvc Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525
Configuration Example for Encapsulation Type Lockout for IWF PPPoE
Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525
Configuring PPP and PPPoE Dynamic Interfaces over Static ATM . . . . . . . . . . . 525
Configuring a PPP or PPPoE Dynamic Interface . . . . . . . . . . . . . . . . . . . . . . 527
Terminating Stale PPPoA Subscribers and Restarting LCP Negotiations . . 530
Configuring PPPoE Dynamic Interfaces over PPPoE Static Interfaces . . . . . . . . . 531
Configuring Dynamic PPPoE over Static PPPoE with ATM Interface
Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 531
Configuring Dynamic PPPoE over Static PPPoE with Ethernet Interface
Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532
Configuring Dynamic PPPoE over Static PPPoE with Ethernet and VLAN
Interface Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533
Configuring IPv4 and IPv6 over Static and Dynamic PPPoE . . . . . . . . . . . . . 534
Configuring Dynamic PPPoE over Static PPPoE with Ethernet and S-VLAN
Interface Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539
S-VLAN Oversubscription . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 540
Configuring Encapsulation Type Lockout for PPPoE Clients . . . . . . . . . . . . 544
Differences from Lockout Configuration for PPPoE over Static ATM . . 545
Configuration Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545
Configuring and Verifying Lockout for PPPoE Clients . . . . . . . . . . . . . . 545
Clearing the Lockout Condition for a PPPoE Client . . . . . . . . . . . . . . . . 547
Copyright © 2010, Juniper Networks, Inc.
xix
JunosE 11.3.x Link Layer Configuration Guide
Configuring IPoA Dynamic Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 550
Configuring a Dynamic IPoA Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 550
Configuring Bridged Ethernet Dynamic Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 554
Configuring a Dynamic Bridged Ethernet Interface . . . . . . . . . . . . . . . . . . . . 554
Configuring Subscriber Management for IP Subscribers on Dynamic Bridged
Ethernet Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 557
Configuration Example Using subscriber Command . . . . . . . . . . . . . . . 558
Equivalent Configuration Example Using IP Subscriber
Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 558
Configuring a Dynamic Interface from a Profile . . . . . . . . . . . . . . . . . . . . . . . . . . 559
Profile Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 559
Profile Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 560
Bridged Ethernet Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 560
IP Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 560
IPv6 Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 561
L2TP Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562
MLPPP and PPP Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562
PPPoE Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563
VLAN Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564
Working with Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564
Configuring a Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565
Assigning a Profile to an Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 589
Profile Configuration Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 591
Scripts and Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 593
Monitoring Upper-Layer Dynamic Interfaces and Profiles . . . . . . . . . . . . . . . . . . 593
Troubleshooting PPP and PPPoE Dynamic Interfaces . . . . . . . . . . . . . . . . . . . . . 614
Chapter 18
Configuring Dynamic Interfaces Using Bulk Configuration . . . . . . . . . . . . . 619
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 619
Bulk Dynamic Interface Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620
Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 620
ATM Oversubscription for Bulk-Configured VC Ranges . . . . . . . . . . . . . . . . . 621
Bulk-Configured VC Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 621
Combination of Static ATM 1483 Subinterfaces and Bulk-Configured
VC Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622
Platform Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 622
Module Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623
Interface Specifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 624
Configuring ATM 1483 Dynamic Subinterfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 624
About Configuring Dynamic ATM 1483 Subinterfaces . . . . . . . . . . . . . . . . . 625
Overview and Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625
ATM 1483 Base Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626
Nested Profile Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626
Additional Profile Characteristics for Upper Interfaces . . . . . . . . . . . . . 627
Bulk Configuration of VC Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627
Bulk Configuration and VC Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 628
Bulk Configuration and CAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629
Dynamic Interface Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 629
xx
Copyright © 2010, Juniper Networks, Inc.
Table of Contents
Overriding Base Profile Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . 629
Changing VC Subranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 630
Static ATM Interfaces Within VC Subranges . . . . . . . . . . . . . . . . . . . . . 630
Terminating Stale PPPoA Subscribers and Restarting LCP
Negotiations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 631
Authenticating Subscribers on Dynamic Bridged Ethernet over Dynamic
ATM Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 632
Configuring a Dynamic ATM 1483 Subinterface . . . . . . . . . . . . . . . . . . . . . . 633
Configuring Overriding Profile Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . 641
Assigning an Overriding Profile to an ATM PVC . . . . . . . . . . . . . . . . . . . 642
Removing an Overriding Profile Assignment from an ATM PVC . . . . . . 643
Removing Overriding Profile Assignments from a VC Range or
VC Subrange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 644
Changing VC Subranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646
Adding VC Subranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 646
Removing VC Subranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647
Modifying VC Subranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 647
Merging VC Subranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648
Changing the Administrative State of VC Subranges . . . . . . . . . . . . . . 648
Configuring Static ATM Interfaces Within VC Subranges . . . . . . . . . . . . . . . 650
Creating Static ATM Interfaces Within VC Subranges . . . . . . . . . . . . . . 651
Creating VC Subranges That Include Static ATM Interfaces . . . . . . . . . . 651
Configuring VLAN Dynamic Subinterfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653
About Configuring Dynamic VLAN Subinterfaces . . . . . . . . . . . . . . . . . . . . . 654
Overview and Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654
VLAN Base Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 655
Nested Profile Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656
Additional Profile Characteristics for Upper Interfaces . . . . . . . . . . . . . 657
Bulk Configuration of VLAN Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . 657
Bulk Configuration of VLAN Ranges Using Agent-Circuit-Identifier
Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 658
Dynamic Interface Creation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 659
Overriding Base Profile Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . 660
Changing VLAN Subranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 660
Static VLAN Subinterfaces Within VLAN Subranges . . . . . . . . . . . . . . 660
Configuring a Dynamic VLAN Subinterface . . . . . . . . . . . . . . . . . . . . . . . . . . 661
Configuring Dynamic VLAN Subinterfaces Based on Agent Circuit Identifier
Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663
Configuring Overriding Profile Assignments for VLAN Major Interfaces . . . 664
Removing an Overriding Profile Assignment from a VLAN . . . . . . . . . . 665
Removing Overriding Profile Assignments from a VLAN Range or VLAN
Subrange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 666
Changing VLAN Subranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673
Adding VLAN Subranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674
Removing VLAN Subranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674
Modifying VLAN Subranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 675
Merging VLAN Subranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676
Changing the Administrative State of VLAN Subranges . . . . . . . . . . . . 676
Copyright © 2010, Juniper Networks, Inc.
xxi
JunosE 11.3.x Link Layer Configuration Guide
Configuring Static VLAN Subinterfaces Within VLAN Subranges . . . . . . . . . 679
Creating Static VLAN Subinterfaces Within VLAN Subranges . . . . . . . 679
Creating VLAN Subranges That Include Static VLAN Subinterfaces . . 680
Monitoring Dynamic Interfaces and Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 682
Part 2
Index
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 709
xxii
Copyright © 2010, Juniper Networks, Inc.
List of Figures
Part 1
Chapters
Chapter 1
Configuring ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Figure 1: ATM Interface Column . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Figure 2: NBMA Interface Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Figure 3: Configuring an ATM Interface, Subinterface, and PVC . . . . . . . . . . . . . . . 22
Chapter 2
Configuring Frame Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Figure 4: Interconnection and Relationship of NNIs and Subnetworks . . . . . . . . 107
Chapter 3
Configuring Multilink Frame Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Figure 5: MLFR Aggregation of T1 Lines into a Single Bundle . . . . . . . . . . . . . . . . 132
Figure 6: Terminating the Bundle at an MLFR Bridge . . . . . . . . . . . . . . . . . . . . . . . 132
Figure 7: Structure of MLFR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Chapter 4
Configuring Upper-Layer Protocols over Static Ethernet Interfaces . . . . . . 151
Figure 8: Multiplexing Multiple Protocols over a Single Physical Link . . . . . . . . . . 152
Figure 9: Example of IP over Ethernet Stacking Configuration Procedure . . . . . . 154
Figure 10: Example of PPPoE Stacking Configuration Procedure . . . . . . . . . . . . . 154
Figure 11: Example of IP and MPLS Stacking Configuration Procedure . . . . . . . . . 155
Figure 12: Example of IP, MPLS, and PPPoE Stacking Configuration
Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Chapter 5
Configuring VLAN and S-VLAN Subinterfaces . . . . . . . . . . . . . . . . . . . . . . . . 167
Figure 13: Use of VLANs to Multiplex Different Protocols over a Single Physical
Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Figure 14: Example of IP/VLAN/Fast Ethernet Stacking Configuration
Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Figure 15: Example of PPPoE/VLAN/Fast Ethernet Stacking Configuration
Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Figure 16: Example of MPLS/VLAN/Fast Ethernet Stacking Configuration
Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Figure 17: Example of PPPoE over VLAN with IP over VLAN Stacking Configuration
Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Figure 18: Example of PPPoE over S-VLAN Stacking Configuration Procedure . . 180
Figure 19: S-VLAN Tunnels for Ethernet Layer 2 Services over MPLS . . . . . . . . . . 182
Chapter 6
Configuring 802.3ad Link Aggregation and Link Redundancy . . . . . . . . . . 197
Figure 20: Interface Stack for 802.3ad Link Aggregation . . . . . . . . . . . . . . . . . . . 198
Figure 21: Ethernet Link Redundancy Configuration Models . . . . . . . . . . . . . . . . 209
Figure 22: GE-2 Line Module Using Physical Port Redundancy . . . . . . . . . . . . . . . 210
Figure 23: Single-Homed GE-2 Line Module Configuration . . . . . . . . . . . . . . . . . . 210
Figure 24: Single-Homed FE-8 Line Module Configuration (1:N) . . . . . . . . . . . . . 210
Copyright © 2010, Juniper Networks, Inc.
xxiii
JunosE 11.3.x Link Layer Configuration Guide
Figure 25: FE-8 Line Module with 4 Redundant Ethernet Links (1:1) . . . . . . . . . . . 211
Figure 26: Single-Homed GE-4 IOA Configuration (1:4) . . . . . . . . . . . . . . . . . . . . . 211
Figure 27: GE-8 IOA Configuration Across IOAs (1:N) . . . . . . . . . . . . . . . . . . . . . . . 212
Figure 28: Dual-Homed Configuration (1:1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Figure 29: Dual-Homed Heterogeneous Configuration in an RSTP Network . . . . 215
Chapter 7
Configuring IEEE 802.3ah OAM Link-Fault Management . . . . . . . . . . . . . . 223
Figure 30: OAM PDU Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 31: OAM Sublayer Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 32: OAM Sublayer Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figure 33: Interrelationship Between 802.3ah OAM and 802.3ad LAG .
Chapter 8
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
226
228
229
236
Configuring Point-to-Point Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Figure 34: Authentication with EAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Chapter 9
Configuring Multilink PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Figure 35: MLPPP Aggregation of T1 Lines into a Single Bundle . . . . . . . . . . . . . 300
Figure 36: Structure of MLPPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
Chapter 12
Configuring Point-to-Point Protocol over Ethernet . . . . . . . . . . . . . . . . . . . . 371
Figure 37: PPPoE over ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
Figure 38: Example of PPPoE over ATM Stacking . . . . . . . . . . . . . . . . . . . . . . . . . 387
Figure 39: Single DSLAM Connected to a PPPoE Access Concentrator . . . . . . . 393
Figure 40: Multiple DSLAMs Connected to a PPPoE Access Concentrator . . . . . 394
Figure 41: Example of Configuring IPv4 and IPv6 over PPPoE . . . . . . . . . . . . . . . 395
Figure 42: Example of PPPoE Stacking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
Chapter 14
Configuring Bridged Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
Figure 43: Bridged Ethernet Topology, Router Terminating and Routing
Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444
Figure 44: Interface Stacking for VLANs over Bridged Ethernet . . . . . . . . . . . . . . 445
Chapter 15
Configuring Transparent Bridging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
Figure 45: Bridge Group with Fast Ethernet and Gigabit Ethernet Bridge
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467
Chapter 17
Configuring Dynamic Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
Figure 46: Configuring an ATM 1483 Interface to Support Dynamic Interfaces . . 518
Figure 47: Dynamic PPP Interface Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526
Figure 48: Dynamic PPPoE Interface Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . 526
Figure 49: Dynamic PPPoE over Static PPPoE with ATM Interface Columns . . . . 531
Figure 50: Dynamic PPPoE over Static PPPoE with Non-VLAN Interface
Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533
Figure 51: Dynamic PPPoE over Static PPPoE with VLAN Interface Columns . . . 534
Figure 52: IPv4 and IPv6 Interface Columns over Static and Dynamic PPPoE . . 535
Figure 53: Dynamic PPPoE over Static PPPoE with S-VLAN Interface
Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 539
Figure 54: Dynamic IPoA over Static ATM 1483 Interface Columns . . . . . . . . . . . 550
Figure 55: Dynamic Bridged Ethernet over Static ATM 1483 Interface
Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554
Figure 56: Creating and Configuring a Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564
Figure 57: Assigning a Profile to a Static Interface . . . . . . . . . . . . . . . . . . . . . . . . 565
xxiv
Copyright © 2010, Juniper Networks, Inc.
List of Figures
Chapter 18
Configuring Dynamic Interfaces Using Bulk Configuration . . . . . . . . . . . . . 619
Figure 58: Dynamic Interface Columns over Dynamic ATM 1483
Subinterfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 625
Figure 59: Dynamic Interface Columns over Dynamic VLAN Subinterfaces . . . . 653
Figure 60: Dynamic IP and PPPoE over Single Dynamic VLAN Subinterface . . . 654
Figure 61: Dynamic VLAN Subinterfaces for Subscribers . . . . . . . . . . . . . . . . . . . 655
Copyright © 2010, Juniper Networks, Inc.
xxv
JunosE 11.3.x Link Layer Configuration Guide
xxvi
Copyright © 2010, Juniper Networks, Inc.
List of Tables
About the Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxix
Table 1: Notice Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxx
Table 2: Text and Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxx
Part 1
Chapters
Chapter 1
Configuring ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Table 3: Scheduling Priorities for Traffic Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Table 4: Traffic Parameters Used to Compute Bandwidth . . . . . . . . . . . . . . . . . . . . 7
Table 5: ATM Capabilities on Line Modules and I/O Modules . . . . . . . . . . . . . . . . . 12
Table 6: Handling of F4 and F5 Loopback Cells Received . . . . . . . . . . . . . . . . . . . 19
Table 7: F5 OAM Configuration Tasks and Associated Commands . . . . . . . . . . . . 49
Table 8: Commands to Configure VC Class Attributes . . . . . . . . . . . . . . . . . . . . . . 57
Chapter 3
Configuring Multilink Frame Relay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Table 9: LIP Messages and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Chapter 6
Configuring 802.3ad Link Aggregation and Link Redundancy . . . . . . . . . . 197
Table 10: Behavior of Member Links Using Local and Remote LACP Modes . . . . 215
Chapter 7
Configuring IEEE 802.3ah OAM Link-Fault Management . . . . . . . . . . . . . . 223
Table 11: show ethernet oam lfm discovery Output Fields . . . . . . . . . . . . . . . . . . 246
Table 12: show ethernet oam lfm statistics Output Fields . . . . . . . . . . . . . . . . . . 249
Table 13: show ethernet oam lfm status Output Fields . . . . . . . . . . . . . . . . . . . . . 251
Table 14: show ethernet oam lfm summary Output Fields . . . . . . . . . . . . . . . . . 254
Chapter 8
Configuring Point-to-Point Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
Table 15: Supported EAP Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Chapter 9
Configuring Multilink PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Table 16: Supported Configurations for MLPPP Fragmentation and
Reassembly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
Chapter 10
Configuring Multiclass Multilink PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Table 17: show ppp interface mlppp Output Fields . . . . . . . . . . . . . . . . . . . . . . . . 355
Chapter 11
Configuring Packet over SONET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359
Table 18: Most Common SONET/SDH Implementations . . . . . . . . . . . . . . . . . . 360
Chapter 12
Configuring Point-to-Point Protocol over Ethernet . . . . . . . . . . . . . . . . . . . . 371
Table 19: Sample PPPoE Service Name Table . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
Table 20: Configuring Nondefault Formats for the PPPoE Remote Circuit ID . . . 376
Table 21: Interface Specifier Format Examples for dsl-forum-1 Keyword . . . . . . 378
Copyright © 2010, Juniper Networks, Inc.
xxvii
JunosE 11.3.x Link Layer Configuration Guide
Table 22: PPPoE Duplicate Protection Scenarios for IWF and non-IWF PPPoE
Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
Table 23: Default PPPoE Service Name Table . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
Table 24: PPPoE Service Name Table with Entries . . . . . . . . . . . . . . . . . . . . . . . 406
Chapter 13
Configuring Bridged IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437
Table 25: Prerequisite Tasks for Configuring Bridged IP . . . . . . . . . . . . . . . . . . . . 440
Chapter 15
Configuring Transparent Bridging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465
Table 26: Sample Bridge Group Forwarding Table . . . . . . . . . . . . . . . . . . . . . . . . 467
Table 27: Default Subscriber Policies for Bridge Group Interfaces . . . . . . . . . . . . 468
Table 28: Prerequisite Tasks for Configuring Transparent Bridging . . . . . . . . . . . 472
Chapter 17
Configuring Dynamic Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
Table 29: Differences in Lockout Operation for Dynamic PPPoE
Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 545
xxviii
Copyright © 2010, Juniper Networks, Inc.
About the Documentation
•
E Series and JunosE Documentation and Release Notes on page xxix
•
Audience on page xxix
•
E Series and JunosE Text and Syntax Conventions on page xxix
•
Obtaining Documentation on page xxxi
•
Documentation Feedback on page xxxi
•
Requesting Technical Support on page xxxi
E Series and JunosE Documentation and Release Notes
For a list of related JunosE documentation, see
http://www.juniper.net/techpubs/software/index.html .
If the information in the latest release notes differs from the information in the
documentation, follow the JunosE Release Notes.
®
To obtain the most current version of all Juniper Networks technical documentation,
see the product documentation page on the Juniper Networks website at
http://www.juniper.net/techpubs/.
Audience
This guide is intended for experienced system and network specialists working with
Juniper Networks E Series Broadband Services Routers in an Internet access environment.
E Series and JunosE Text and Syntax Conventions
Table 1 on page xxx defines notice icons used in this documentation.
Copyright © 2010, Juniper Networks, Inc.
xxix
JunosE 11.3.x Link Layer Configuration Guide
Table 1: Notice Icons
Icon
Meaning
Description
Informational note
Indicates important features or instructions.
Caution
Indicates a situation that might result in loss of data or hardware damage.
Warning
Alerts you to the risk of personal injury or death.
Laser warning
Alerts you to the risk of personal injury from a laser.
Table 2 on page xxx defines text and syntax conventions that we use throughout the
E Series and JunosE documentation.
Table 2: Text and Syntax Conventions
Convention
Description
Examples
Bold text like this
Represents commands and keywords in text.
•
Issue the clock source command.
•
Specify the keyword exp-msg.
Bold text like this
Represents text that the user must type.
host1(config)#traffic class low-loss1
Fixed-width text like this
Represents information as displayed on your
terminal’s screen.
host1#show ip ospf 2
Routing Process OSPF 2 with Router
ID 5.5.0.250
Router is an Area Border Router
(ABR)
Italic text like this
Plus sign (+) linking key names
•
Emphasizes words.
•
Identifies variables.
•
Identifies chapter, appendix, and book
names.
Indicates that you must press two or more
keys simultaneously.
•
There are two levels of access: user and
privileged.
•
clusterId, ipAddress.
•
Appendix A, System Specifications
Press Ctrl + b.
Syntax Conventions in the Command Reference Guide
Plain text like this
Represents keywords.
terminal length
Italic text like this
Represents variables.
mask, accessListName
xxx
Copyright © 2010, Juniper Networks, Inc.
About the Documentation
Table 2: Text and Syntax Conventions (continued)
Convention
Description
Examples
| (pipe symbol)
Represents a choice to select one keyword
or variable to the left or to the right of this
symbol. (The keyword or variable can be
either optional or required.)
diagnostic | line
[ ] (brackets)
Represent optional keywords or variables.
[ internal | external ]
[ ]* (brackets and asterisk)
Represent optional keywords or variables
that can be entered more than once.
[ level1 | level2 | l1 ]*
{ } (braces)
Represent required keywords or variables.
{ permit | deny } { in | out }
{ clusterId | ipAddress }
Obtaining Documentation
To obtain the most current version of all Juniper Networks technical documentation, see
the Technical Documentation page on the Juniper Networks Web site at
http://www.juniper.net/.
To download complete sets of technical documentation to create your own
documentation CD-ROMs or DVD-ROMs, see the Portable Libraries page at
http://www.juniper.net/techpubs/resources/index.html
Copies of the Management Information Bases (MIBs) for a particular software release
are available for download in the software image bundle from the Juniper Networks Web
site athttp://www.juniper.net/.
Documentation Feedback
We encourage you to provide feedback, comments, and suggestions so that we can
improve the documentation to better meet your needs. Send your comments to
[email protected], or fill out the documentation feedback form at
https://www.juniper.net/cgi-bin/docbugreport/. If you are using e-mail, be sure to include
the following information with your comments:
•
Document or topic name
•
URL or page number
•
Software release version
Requesting Technical Support
Technical product support is available through the Juniper Networks Technical Assistance
Center (JTAC). If you are a customer with an active J-Care or JNASC support contract,
Copyright © 2010, Juniper Networks, Inc.
xxxi
JunosE 11.3.x Link Layer Configuration Guide
or are covered under warranty, and need post-sales technical support, you can access
our tools and resources online or open a case with JTAC.
•
JTAC policies—For a complete understanding of our JTAC procedures and policies,
review the JTAC User Guide located at
http://www.juniper.net/us/en/local/pdf/resource-guides/7100059-en.pdf .
•
Product warranties—For product warranty information, visit
http://www.juniper.net/support/warranty/ .
•
JTAC hours of operation—The JTAC centers have resources available 24 hours a day,
7 days a week, 365 days a year.
Self-Help Online Tools and Resources
For quick and easy problem resolution, Juniper Networks has designed an online
self-service portal called the Customer Support Center (CSC) that provides you with the
following features:
•
Find CSC offerings: http://www.juniper.net/customers/support/
•
Search for known bugs: http://www2.juniper.net/kb/
•
Find product documentation: http://www.juniper.net/techpubs/
•
Find solutions and answer questions using our Knowledge Base: http://kb.juniper.net/
•
Download the latest versions of software and review release notes:
http://www.juniper.net/customers/csc/software/
•
Search technical bulletins for relevant hardware and software notifications:
https://www.juniper.net/alerts/
•
Join and participate in the Juniper Networks Community Forum:
http://www.juniper.net/company/communities/
•
Open a case online in the CSC Case Management tool: http://www.juniper.net/cm/
To verify service entitlement by product serial number, use our Serial Number Entitlement
(SNE) Tool: https://tools.juniper.net/SerialNumberEntitlementSearch/
Opening a Case with JTAC
You can open a case with JTAC on the Web or by telephone.
•
Use the Case Management tool in the CSC at http://www.juniper.net/cm/ .
•
Call 1-888-314-JTAC (1-888-314-5822 toll-free in the USA, Canada, and Mexico).
For international or direct-dial options in countries without toll-free numbers, see
http://www.juniper.net/support/requesting-support.html .
xxxii
Copyright © 2010, Juniper Networks, Inc.
PART 1
Chapters
•
Configuring ATM on page 3
•
Configuring Frame Relay on page 105
•
Configuring Multilink Frame Relay on page 131
•
Configuring Upper-Layer Protocols over Static Ethernet Interfaces on page 151
•
Configuring VLAN and S-VLAN Subinterfaces on page 167
•
Configuring 802.3ad Link Aggregation and Link Redundancy on page 197
•
Configuring IEEE 802.3ah OAM Link-Fault Management on page 223
•
Configuring Point-to-Point Protocol on page 259
•
Configuring Multilink PPP on page 299
•
Configuring Multiclass Multilink PPP on page 345
•
Configuring Packet over SONET on page 359
•
Configuring Point-to-Point Protocol over Ethernet on page 371
•
Configuring Bridged IP on page 437
•
Configuring Bridged Ethernet on page 443
•
Configuring Transparent Bridging on page 465
•
Configuring Cisco HDLC on page 503
•
Configuring Dynamic Interfaces on page 511
•
Configuring Dynamic Interfaces Using Bulk Configuration on page 619
Copyright © 2010, Juniper Networks, Inc.
1
JunosE 11.3.x Link Layer Configuration Guide
2
Copyright © 2010, Juniper Networks, Inc.
CHAPTER 1
Configuring ATM
This chapter introduces basic Asynchronous Transfer Mode (ATM) concepts, describes
features of the ATM interfaces, and provides information for configuring ATM on E Series
routers.
This chapter contains the following sections:
•
Overview on page 3
•
Platform Considerations on page 10
•
References on page 11
•
Supported Features on page 11
•
ATM NBMA on page 13
•
Operations, Administration, and Management of ATM Interfaces on page 14
•
Before You Configure ATM on page 20
•
Configuration Tasks on page 20
•
Creating a Basic Configuration on page 21
•
Setting Optional Parameters on page 23
•
Configuring OAM on page 31
•
Configuring an NBMA Interface on page 38
•
Creating an NBMA Static Map on page 38
•
Assigning Descriptions to Interfaces on page 40
•
Sending Interface Descriptions to AAA on page 41
•
Configuring Individual ATM PVC Parameters on page 43
•
Configuring ATM VC Classes on page 53
•
Configuring Dynamic ATM 1483 Subinterfaces on page 66
•
Monitoring ATM on page 67
Overview
ATM is a high-speed networking technology that handles data in fixed-size units called
cells. It enables high-speed communication between edge routers and core routers in
an ATM network.
Copyright © 2010, Juniper Networks, Inc.
3
JunosE 11.3.x Link Layer Configuration Guide
ATM Interfaces
An ATM port can have a major interface and one or more subinterfaces. An ATM
subinterface is a mechanism that enables a single physical ATM interface to support
multiple logical interfaces. Several logical interfaces can be associated with a single
physical interface.
ATM subinterfaces meet the specifications in RFC 2684—Multiprotocol Encapsulation
over ATM Adaptation Layer 5 (September 1999), which replaces RFC 1483. All references
to ATM subinterfaces in this chapter are still to ATM 1483 subinterfaces.
ATM 1483 subinterfaces are identified by user-defined numbers. To select a subinterface,
you append a subinterface number to the port-level interface atm command.
When you create an ATM 1483 subinterface, you must configure a permanent virtual
circuit (PVC). Protocols such as ATM require one or more virtual circuits over which data
traffic is transmitted to higher layers in the protocol stack.
Figure 1 on page 4 shows a typical point-to-point ATM interface column.
Figure 1: ATM Interface Column
ATM Physical Connections
ATM interfaces and subinterfaces support two types of connections—point-to-point and
multipoint. The router defaults to point-to-point.
•
Point-to-point—Indicates a standard connection; for example, connecting two ATM
end stations
•
Multipoint—Indicates a single-source end system connected to multiple destination
end systems. Multipoint indicates a nonbroadcast multiaccess (NBMA) interface. See
“ATM NBMA” on page 13.
Depending on the type of connection you choose, you can specify one or more PVCs on
each interface. For a standard point-to-point ATM interface, you configure only one PVC.
For NBMA ATM connections, you configure multiple circuits.
4
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
ATM Virtual Connections
A virtual connection (VC) defines a logical networking path between two endpoints in an
ATM network. ATM cells travel from one point to the other over a virtual connection. An
ATM cell is a package of information that is always 53 bytes in length, unlike a frame or
packet, which has a variable length. An ATM cell has a cell header and a payload. The
payload contains the user data.
The cell header includes an 8-bit virtual path identifier (VPI) and a 16-bit virtual channel
identifier (VCI).
An ATM network can have two types of VCs, depending on the addressing used to switch
the traffic:
•
Virtual channel connection (VCC)
•
Virtual path connection (VPC)
Virtual Channel Connection
A VCC uses all the addressing bits of the cell header to move traffic from one link to
another. The VCC is formed by joining a series of virtual channels (VCs), which are logical
circuits uniquely identified for each link of the network. On a VCC, switching is done based
on the combined VPI and VCI values.
Virtual Path Connection
A VPC uses the higher-order addressing bits of the cell header to move traffic from one
link to another. A VPC carries many VCCs within it. A VPC can be set up permanently
between two points, and then switched.
VCCs can be assigned within the VPC easily and quickly. The VPC is formed by joining a
series of virtual paths, which are the logical groups of circuits uniquely defined for each
link of the network. On a VPC, switching is done based on the VPI value only.
ATM SVCs
JunosE Software does not support configuration and monitoring of ATM switched virtual
circuits (SVCs) on the router.
ATM Adaptation Layer
The ATM Adaptation Layer (AAL) defines the conversion of user information into cells
by segmenting upper-layer information into cells at the transmitter and reassembling
them at the receiver. AAL1 and AAL2 handle intermittent traffic, such as voice and video,
and are not relevant to the router. AAL3/4 and AAL5 support data communications by
segmenting and reassembling packets.
E Series routers support the following AAL5 encapsulation types as specified in RFC
2684—Multiprotocol Encapsulation over ATM Adaptation Layer 5 (September 1999),
which replaces RFC 1483:
Copyright © 2010, Juniper Networks, Inc.
5
JunosE 11.3.x Link Layer Configuration Guide
•
aal5snap—LLC/SNAP
•
aal5mux ip—VC-based multiplexing
•
aal5autoconfig—LLC/SNAP or VC-based multiplexing. (See “Configuring Dynamic
Interfaces” on page 511.)
•
aal5all—Martini encapsulation
NOTE: The Juniper Networks E120 and E320 Broadband Services Routers
do not support Martini encapsulation (aal5all) in the current release.
Local ATM Passthrough
E Series routers support local ATM passthrough for ATM layer 2 services over Multiprotocol
Label Switching (MPLS). Local ATM passthrough enables the router to emulate
packet-based ATM switching. The ATM passthrough feature is useful for customers who
run IP in most of their network but still have to carry a small amount of native ATM traffic.
Local ATM passthrough uses ATM Martini encapsulation to emulate ATM switch behavior.
You can create pairs of cross-connected ATM VCs within the router. The router then
passes AAL5 traffic between two VCs, regardless of the contents of the packets.
You can also use AAL0 encapsulation when you configure a local ATM passthrough
connection. AAL0 encapsulation causes the router to receive raw ATM cells on this circuit
and to forward the cells without performing AAL5 packet reassembly.
For more information, see chapter Configuring Layer 2 Services over MPLS in JunosE BGP
and MPLS Configuration Guide.
VCC Cell Relay Encapsulation
E Series routers support virtual channel connection (VCC) cell relay encapsulation for
ATM layer 2 services over MPLS. VCC cell relay encapsulation is useful for voice-over-ATM
applications that use AAL2-encapsulated voice transmission.
VCC cell relay encapsulation enables the router to emulate ATM switch behavior by
forwarding individual ATM cells over an MPLS pseudowire (also referred to as an MPLS
tunnel) created between two ATM VCCs, or as part of a local ATM passthrough connection
between two ATM 1483 subinterfaces on the same router. The E Series implementation
conforms to the required N-to-1 cell mode encapsulation method described in the Martini
draft, Encapsulation Methods for Transport of ATM Over MPLS
Networks—draft-ietf-pwe3-atm-encap-07.txt (April 2005 expiration), with the provision
that only a single ATM virtual circuit (VC) can be mapped to an MPLS tunnel.
For more information, see chapter Configuring Layer 2 Services over MPLS in JunosE BGP
and MPLS Configuration Guide.
NOTE: The E120 and E320 routers do not support ATM over MPLS with VCC
cell relay encapsulation in the current release.
6
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
Traffic Management
The scheduling priority for traffic classes depends on the type of router that you have.
Table 3 on page 7 describes the scheduling priorities for each type of router.
Table 3: Scheduling Priorities for Traffic Classes
Scheduling
Priority (from
Highest to
Lowest)
1
2
ERX7xx Models, ERX14xx
Models, or the ERX310
Broadband Services Router
The following traffic classes
are prioritized equally:
•
CBR
•
VBR-RT
The following traffic classes
are prioritized equally:
•
VBR-NRT
•
UBR with a peak cell rate
(PCR)
E120 and E320 routers
CBR
VBR-RT
3
UBR without PCR
VBR-NRT
4
–
UBR with or without PCR
The level of support for traffic management depends on the specific I/O module or IOA.
See “Supported Features” on page 11.
Connection Admission Control
ATM networks use connection admission control (CAC) to determine whether to accept
a connection request, based on whether allocating the connection’s requested bandwidth
causes the network to violate the traffic contracts of existing connections. CAC is a set
of actions that the network takes during connection setup or renegotiation.
The router supports CAC on PVCs on major ATM interfaces. This implementation of CAC
determines available bandwidth based on port subscription bandwidth. The router
maintains available bandwidth for each major ATM port. Bandwidth for VP tunnels is
included in CAC computations.
Table 4 on page 7 lists the traffic parameter that the router uses for each service category
to compute the bandwidth that the connection requires. For example, the peak cell rate
is used to calculate how much bandwidth is required for CBR connections.
Table 4: Traffic Parameters Used to Compute Bandwidth
Service Category
Traffic Parameter Used to Calculate Required Bandwidth
CBR
PCR
Copyright © 2010, Juniper Networks, Inc.
7
JunosE 11.3.x Link Layer Configuration Guide
Table 4: Traffic Parameters Used to Compute Bandwidth (continued)
Service Category
Traffic Parameter Used to Calculate Required Bandwidth
VBR-RT
SCR
VBR-NRT
SCR
UBR
UBR bandwidth configured on the ATM major interface
UBR with PCR
UBR bandwidth configured on the ATM major interface
How CAC Works
With no connections, the available bandwidth is equal to the subscription port bandwidth.
While connections are requested, the required bandwidth, which is based on the service
category and traffic parameters of the connection, is compared against the available
port bandwidth. If sufficient bandwidth is available, the router accepts the connection
and updates the available port bandwidth accordingly.
Similarly, when a connection is deleted, the available port bandwidth is updated
accordingly.
Configuring CAC
You enable and configure CAC on an ATM major interface using “atm cac” on page 27 .
When you enable CAC on an ATM interface, you can optionally specify a subscription
bandwidth and a UBR weight:
•
The subscription bandwidth can be greater than the effective port bandwidth to allow
oversubscription. The default value of the subscription bandwidth is the effective
bandwidth of the ATM port.
•
The UBR weight enables you to limit the number of UBR connections by assigning a
bandwidth or weight to each UBR or VBR with a PCR connection
CAC and ATM Bulk Configuration
You cannot configure CAC on an ATM interface on which you have created a
bulk-configured virtual circuit (VC) range for use by a dynamic ATM 1483 subinterface.
Conversely, you cannot create a bulk-configured VC range on an ATM interface on which
you have configured CAC. The router rejects these configurations, which causes them to
fail.
If you are upgrading to the current JunosE Software release from a lower-numbered
release, configurations that use CAC and bulk configuration on the same ATM interface
continue to work. However, we recommend that you disable CAC on these ATM interfaces
to ensure continued compatibility with future JunosE releases.
For information about how to use the atm cac command to configure CAC, see “Setting
Optional Parameters” on page 23. For information about how to use the atm bulk-config
command to create a bulk-configured VC range, see “Bulk Configuration of VC Ranges”
on page 627 in “Configuring Dynamic Interfaces Using Bulk Configuration” on page 619.
8
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
ILMI
ATM interfaces support the ATM Forum integrated local management interface (ILMI),
versions 3.0, 3.1, and 4.0. An important feature of ILMI is the ability to poll or send keepalive
messages across the UNI. ATM interfaces always respond to such messages, which are
sent by an ATM peer device. Optionally, you can configure ATM major interfaces to
generate keepalive messages, a process that enables a continuous ATM-layer connectivity
verification; if the ATM peer stops responding to keepalive messages, the router disables
the ATM interface.
The ATM interface is not reenabled until the keepalive message’s responses are received
(or until the keepalive feature is disabled on the ATM port). To enable ILMI and control
the generation of keepalive messages, use the atm ilmi-enable and atm ilmi-keepalive
commands.
VPI/VCI Address Ranges
The VPI/VCI address ranges allowed on ATM interfaces are module dependent. Certain
modules on ERX14xx models, ERX7xx models, or the Juniper Networks ERX310 Broadband
Services Router 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 example, if an ATM interface has a bit range of 18, and 4 bits are allocated to the VPI
space, then 14 bits are left for the VCI space. The resulting numeric range is 0 to 2n-1,
where n is the number of bits for each space. Completing the example, if 4 bits were
allocated for the VPI space and 14 for the VCI space, the configurable range would be 0
to 15 for VPI and 0 to 16,383 for the VCI space. To configure the bit range, use “atm
vc-per-vp” on page 30 .
See “Supported Features” on page 11 for details on how various line module and I/O
modules support configurable VPI/VCI address ranges.
NOTE: The E120 and E320 routers support the full VPI/VCI address range;
therefore, it has a fixed allocation scheme.
VP Tunneling
Virtual path (VP) tunneling enables traffic shaping to be applied to the aggregation of
all VCs within a single VP. Thus, VP tunnels can be used to ensure that the total traffic
transmitted on a VP does not exceed the specified PCR. VP tunneling uses a round-robin
algorithm to guarantee fairness among all of the VCs within the tunnel.
You can change the PCR associated with a tunnel even when VCs have already been
configured on the tunnel. The individual VCs within a tunnel must be specified as UBR
VCs. In other words, they may not have their own traffic-shaping parameters.
The level of support for VP tunneling is dependent on the specific I/O module. See
“Supported Features” on page 11 for details.
Copyright © 2010, Juniper Networks, Inc.
9
JunosE 11.3.x Link Layer Configuration Guide
Platform Considerations
You can configure ATM interfaces on the following Juniper Networks E Series Broadband
Services Routers:
•
E120 router
•
E320 router
•
ERX1440 router
•
ERX1410 router
•
ERX710 router
•
ERX705 router
•
ERX310 router
Module Requirements
For information about the modules that support ATM interfaces on ERX14xx models,
ERX7xx models, and the ERX310 router:
•
See ERX Module Guide, Table 1, Module Combinations for detailed module specifications.
•
See ERX Module Guide, Appendix A, Module Protocol Support for information about the
modules that support ATM.
For information about the modules that support ATM interfaces on the E120 and E320
routers:
•
See E120 and E320 Module Guide, Table 1, Modules and IOAs for detailed module
specifications.
•
See E120 and E320 Module Guide, Appendix A, IOA Protocol Support for information
about the modules that support MLPPP.
Interface Specifiers
The configuration task examples in this chapter use the slot/port[.subinterface ] format
to specify an ATM interface. However, the interface specifier format that you use depends
on the router that you are using.
For ERX7xx models, ERX14xx models, and ERX310 router, use the slot/port[.subinterface
] format. For example, the following command specifies ATM 1483 subinterface 10 on
slot 0, port 1 of an ERX7xx model, ERX14xx model, or ERX310 router.
host1(config)#interface atm 0/1.10
For E120 and E320 routers use the slot/adapter/port[.subinterface ] format, which includes
an identifier for the bay in which the I/O adapter (IOA) resides. In the software, adapter
0 identifies the right IOA bay (E120 router) and the upper IOA bay (E320 router); adapter
1 identifies the left IOA bay (E120 router) and the lower IOA bay (E320 router). For
10
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
example, the following command specifies ATM 1483 subinterface 20 on slot 5, adapter
0, port 0 of an E120 or E320 router.
host1(config)#interface atm 5/0/0.20
For more information about supported interface types and specifiers on E Series routers,
see Interface Types and Specifiers in JunosE Command Reference Guide.
References
For more information about ATM interfaces, consult the following resources:
•
ATM Forum—ATM User-Network Interface Specification, Version 3.0 (September
1993)
•
ATM Forum—ATM User-Network Interface Specification, Version 3.1 (September 1994)
•
ATM Forum—Integrated Local Management Interface (ILMI) Specifications, Versions
3.0, 3.1, and 4.0 (September 1996)
•
ATM Forum—Traffic Management Specification, Version 4.0 (April 1996)
•
ITU-T Draft Recommendation I.363 (AAL5 support) (January 1993)
•
RFC 2390—Inverse Address Resolution Protocol (September 1998)
•
RFC 2684—Multiprotocol Encapsulation over ATM Adaptation Layer 5 (September
1999) (RFC 2684 obsoletes RFC 1483)
•
ITU-T Recommendation I.610—B-ISDN Operation and Maintenance Principles and
Functions (February 1999)
•
Encapsulation Methods for Transport of ATM Over MPLS
Networks—draft-ietf-pwe3-atm-encap-07.txt (April 2005 expiration)
•
JunosE Release Notes, Appendix A, System Maximums—See the Release Notes
corresponding to your software release for information about maximum values
NOTE: IETF drafts are valid for only 6 months from the date of issuance.
They must be considered as works in progress. Please refer to the IETF
Web site at http://www.ietf.org for the latest drafts.
Supported Features
This section describes ATM feature support on E Series modules.
For more information about the physical layer characteristics of the modules described
in this section, including the numbering schemes, see the JunosE Physical Layer
Configuration Guide.
Module Capabilities
The level of support for certain ATM capabilities varies depending on the module. Table
5 on page 12 lists the specific differences in the capabilities of the modules.
Copyright © 2010, Juniper Networks, Inc.
11
JunosE 11.3.x Link Layer Configuration Guide
The number of VP tunnels varies with the number of ports in the associated line module.
For information about the maximum number of ATM VP tunnels supported per port for
all line modules, see JunosE Release Notes, Appendix A, System Maximums.
NOTE: Support for the OC3 (dual port) line module has been deprecated.
Table 5: ATM Capabilities on Line Modules and I/O Modules
Line
Module
I/O Module
or IOA
Number
of VP
Tunnels
OCx/STMx
ATM
OC3-4 I/O
1024
VPI/VCI
Address
Range
Configurable
Bit Range
Configurable
20
4xDS3 ATM
I/O
OCx/STMx
ATM
OC12/STM4
I/O
Number
of VCs on
Each Port
8000
active
16,000
configured
256
Configurable
20
8000
active
16,000
configured
OC3/STM1
GE/FE
OC3-2 GE
APS I/O
1024
Configurable
20
8000
active
16,000
configured
ES2 4G LM
ES2 4G LM
ES2-S1
OC3-8 STM1
ATM IOA
ES2-S1
OC12-2
STM4 ATM
IOA
1 IOA per
slot:
2048
Fixed
2 IOAs
per slot:
4096
VCI:
0–65535
1 IOA per
slot: 512
Fixed
–
8000
active
VPI: 0–255
16,000
configured
–
8000
active
VPI: 0–255
2 IOAs
per slot:
1024
VCI:
0–65535
16,000
configured
ATM Circuit
Traffic
Management
Types
VP Tunnel
Traffic
Management
Types
CBR, UBR, UBR
with PCR,
VBR-NRT,
VBR-RT
CBR, VBR-NRT
CBR, UBR, UBR
with PCR,
VBR-NRT,
VBR-RT
CBR, VBR-NRT
CBR, UBR, UBR
with PCR,
VBR-NRT,
VBR-RT
CBR, VBR-NRT
CBR, UBR, UBR
with PCR,
VBR-NRT,
VBR-RT
CBR, VBR-NRT
CBR, UBR, UBR
with PCR,
VBR-NRT,
VBR-RT
CBR, VBR-NRT
Virtual Channel Support
The number of virtual channels (VCs) that the router supports on each port varies
depending on the E Series router and module you are using. For information about the
maximum number of ATM VCs supported per chassis, per module, and per port, see
JunosE Release Notes, Appendix A, System Maximums.
12
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
ATM NBMA
The software supports nonbroadcast multiaccess (NBMA) networks, which interconnect
more than two routers and have no broadcast capabilities.
NOTE: The E120 and E320 routers do not support ATM NBMA in the current
release.
An ATM NBMA network can be thought of as an interface stack with a single IP interface
at the top, eventually fanning out to multiple independent PVCs. See Figure 2 on page 13.
Figure 2: NBMA Interface Stack
Unlike standard point-to-point ATM interfaces and broadcast-oriented Ethernet interfaces,
NBMA interfaces form a point-to-multipoint connection. For example, you can use NBMA
to connect a router to multiple stations.
An NBMA interface consists of a single ATM 1483 subinterface that has two or more VCs.
You can add circuits to an existing ATM 1483 subinterface at any time. New circuits
become usable after they have valid ARP table entries. NBMA circuits support only IP
directly over ATM 1483.
The software restricts NBMA interfaces so that all circuits reside on the same physical
interface. An NBMA interface can use as many PVCs as are available on a physical port.
ARP Table
To maintain the Address Resolution Protocol (ARP) table, you can use either static
mapping via the CLI or Inverse ARP (InARP). InARP provides a way of determining the IP
address of the device at the far end of a circuit. For NBMA interfaces, InARP enables
automatic creation of ARP table entries for each circuit on the interface.
You must enable InARP when you create a PVC by using the atm pvc command. After
you configure InARP, a protocol mapping between an ATM PVC and a network address
is learned dynamically as a result of the exchange of InARP packets.
Static Map Versus Inverse ARP
If the device at the other end of a circuit does not support InARP, static mapping is required
for that circuit. One of these two methods must be used to generate an ARP table entry
for each circuit of the NBMA interface.
Copyright © 2010, Juniper Networks, Inc.
13
JunosE 11.3.x Link Layer Configuration Guide
InARP and static mapping are complementary within an NBMA subinterface, but are not
compatible with regard to individual circuits. If InARP is configured on a circuit, the
corresponding virtual circuit descriptor (VCD) cannot be present in a static map applied
to that interface.
Aging
ARP table entries, with the exception of those declared static, are aged out based on an
aging interval defined on a subinterface basis. For the purposes of aging, entries produced
via a static map are treated as static ARP table entries. InARP-generated entries are also
treated as static; however, the InARP state machine automatically removes entries that
cannot be successfully refreshed after three successive failed InARP requests.
Removing Circuits
If a circuit is removed, it is also removed from the ARP table, but not from the static map.
If the circuit is reconfigured, a new ARP table entry is generated from the existing map
entry. If the circuit uses InARP, the ARP table entry is immediately removed on removal
of the circuit.
If a subinterface is removed, all associated circuits and their associated ARP table entries
are removed.
Operations, Administration, and Management of ATM Interfaces
ATM interfaces support the OAM standards of the ITU, per recommendation I.610. OAM
provides VC/VP integrity and fault and performance management. The E Series router
supports F4 and F5 ATM OAM fault management, loopback, and continuity check (CC)
cells. These cells perform fault detection and notification, loopback testing, and link
integrity.
ATM uses F4 and F5 cell flows as follows:
•
F4—Used in VPs
•
F5—Used in VCs
ATM interfaces always generate and validate CRC-10 checksums on OAM cells.
For information about configuring OAM on the router, see the following sections:
•
“Configuring OAM” on page 31
•
“Configuring F5 OAM for Data PVCs” on page 49
End-to-End and Segment Endpoints
An ATM connection consists of a group of points. This OAM implementation provides
management for the following points:
14
•
Connection endpoint—The end of a VC/VP connection where the ATM cells are
terminated
•
Segment endpoint—The end of a connection segment
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
Fault Management
ATM uses two types of fault management cells to convey defect information to the
endpoints of a VP/VC:
•
Alarm indication signal (AIS) cells, which are used to indicate a fault to the downstream
endpoint. AIS cells contain defect type and defect location fields, which optionally
convey information about the type of defect detected and the location of the defect.
•
Remote defect indication (RDI) cells, which are received from the remote endpoint of
the VP/VC and indicate an interruption in the cell transfer capability of the VP/VC.
Connecting points in the VP/VC that detect a fault send AIS cells in the downstream
direction to the endpoint of the VP/VC. Upon receipt of AIS cells, the downstream endpoint
generates RDI cells in the upstream direction to alert all connecting points and the remote
endpoint of an interruption in the cell transfer capability of the VP/VC.
If fault management detects a failure condition (because of arrival of AIS or RDI cells),
the router disables the corresponding VC until the fault condition is no longer detected.
How the ATM Interface Handles AIS Cells
Nodes that detect a failure send AIS cells to the downstream endpoint. Because the ATM
interface is an endpoint and there is no downstream neighbor to an ATM endpoint, the
ATM interface never generates AIS cells. The ATM interface responds to the receipt of
AIS cells as follows:
1.
When an ATM interface receives a configurable number of F4 or F5 AIS cells, it enters
the AIS state.
2. While in the AIS state, the ATM interface sends F4 or F5 RDI cells to the remote
endpoint. It sends the RDI cells at the rate of one cell per second for as long as the
AIS condition exists.
For all RDI cells sent, the defect type and defect location fields contain the values
from the received AIS cells.
3. RDI cell generation stops when one of the following conditions occurs:
•
The interface receives an F4 or F5 loopback cell or an F4 or F5 CC cell.
•
The interface does not receive an AIS cell for a configurable time period.
•
The OAM VC status field of “show atm vc atm” on page 91 shows that the circuit is
in AIS state.
How the ATM Interface Handles RDI Cells
RDI cells received from the remote endpoint of the VP/VC indicate an interruption in the
cell transfer capability of the VP/VC. For example, the remote endpoint of a VC receives
an F5 AIS cell, enters the AIS state, and transmits F5 RDI cells for the duration of the AIS
condition. On receipt of a configurable number of F4 or F5 RDI cells, the ATM interface
declares an RDI state but does not generate OAM fault management cells in response
Copyright © 2010, Juniper Networks, Inc.
15
JunosE 11.3.x Link Layer Configuration Guide
to the condition. The ATM interface leaves the RDI condition when no RDI cells have been
received for a configurable time period.
The OAM VC status field of “show atm vc atm” on page 91 shows whether the circuit is
in RDI state.
Continuity Verification
CC cells provide continual monitoring of a connection on a segment or end-to-end basis.
To verify the integrity of the link, you can set up a VP or VC to regularly send or receive
CC cells at either the segment level or at the end-to-end level.
The CC cell source generates the CC cells, and the sink receives and processes the cells.
You can set up a VP or VC as the source, the sink, or both the source and the sink. If you
enable a VP or VC as a CC cell source, it generates CC cells. The VP or VC counts CC cells
whether or not CC cell flow is enabled. You can enable CC cells only on data circuits, not
on control circuits, such as ILMI or signaling circuits.
Activation and Deactivation Cells
To enable and disable CC cell flows, ATM OAM uses activation and deactivation cells:
•
To enable a CC cell flow, the router sends activation OAM cells to the peer. The peer
replies with a confirmation or denial. If the CC sink point is not activated, all received
CC cells are dropped. (See “Activating CC Cell Flow” on page 16 for more details.)
•
To disable a CC cell flow, the router sends deactivation OAM cells to the peer. The peer
replies with a confirmation or denial.
Activating CC Cell Flow
When the router sends a CC activation cell to the peer, one of the following occurs:
•
If the router receives a positive response (Activation Confirmed), the VC or VP goes to
CC active state, and CC is enabled on the VC or VP.
•
If the router receives a negative response (Activation Req. Denied), the VC or VP goes
to CC failed state, and CC is not enabled on the VC or VP.
•
If the router does not receive a response within 5 seconds, it sends another activation
cell. This process is repeated three times. If the router does not receive a response, it
stops the activation process.
If the VC or VP is the source point, CC cell generation starts as soon as the router sends
the activation request to the peer. CC cell generation stops if the CC fails, when the
maximum number of retries is reached, or when the deactivation process is complete.
Deactivating CC Cell Flow
The process of sending a deactivation request is the same as for activation cells except
that deactivation cells are sent instead.
Also, the atm oam flush command causes the router to send a deactivation request to
the peer and suspend all CC operations. Therefore, we recommend that you disable CC
cell generation and transmission on all VCs before issuing atm oam flush.
16
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
After CC Cell Flow Is Enabled
If the VC or VP is set up as the source point, the ATM interface sends one CC cell per
second. CC cell generation stops if one of the following conditions occur:
•
The ATM interface goes down.
•
You disable OAM CC on the circuit by using the atm pvc command.
•
The peer deactivates the OAM CC cell flow.
•
You disable OAM cell reception and transmission on the ATM interface by using the
atm oam flush command.
If the VP is set up as a CC sink point and no CC cell is received for 4 seconds, the VP goes
to AIS state and sends one RDI cell per second.
To view the current state of the activation or deactivation process, including statistics,
use the show atm oam command for VPs and the show atm vc atm interface command
for VCs.
Loopback
You can use loopback cells to verify connectivity between VP/VC endpoints, as well as
segment endpoints within the VP/VC. You can use these tests to perform fault isolation
over the VP/VC.
The ATM interface supports VC integrity, which generates F5 end-to-end loopback cells.
It also supports ATM ping, which generates F4 and F5 segment and end-to-end loopback
cells to test the reachability of an endpoint or a segment endpoint.
VC Integrity
VC integrity is used to monitor the operational status of an individual VC. VC integrity
provides continuous ATM VC-layer connectivity verification by periodically sending F5
end-to-end loopback cells on individual PVCs to verify end-to-end connectivity. You can
set the frequency with which loopback cells are transmitted for an individual VC.
If VC integrity is enabled, the peer ATM host must respond to the router’s loopback cells,
or the circuit will be disabled. The ATM interface does not reenable the circuit until it
receives loopback responses or until local VC integrity is disabled.
You can set the following VC integrity parameters for an individual VC with the oam retry
command. For more information, see “oam retry” on page 52.
•
The retry frequency with which loopback cells are transmitted when the router verifies
the down status of the circuit; that is, when the peer ATM host does not respond to a
loopback cell
•
The retry frequency with which loopback cells are transmitted when the router verifies
the up status of the circuit; that is, when the ATM host resumes responding to a
loopback cell
Copyright © 2010, Juniper Networks, Inc.
17
JunosE 11.3.x Link Layer Configuration Guide
•
The number of successive loopback cell responses missed before the router determines
that the circuit is down
•
The number of successive loopback responses received before the router determines
that the circuit is up
VC integrity is a best-effort mechanism that tries to adhere to the loopback cell
transmission frequency and retry frequency values configured for each VC without
consuming excessive processing time on the line module. When you configure VC integrity
for a large number of circuits on the line module, delays in transmitting OAM loopback
cells might occur so new subscribers can connect and to maintain existing subscriber
connections.
To set up the ATM interface to transmit F5 end-to-end loopback cells over a VC, use the
oam keyword and an optional frequency with the atm pvc command. To send F5 segment
loopback cells, use the ATM ping mechanism, described in “ATM Ping” on page 18.
F5 loopback receive and transmit statistics are available with “show atm vc atm” on
page 91 .
F4 OAM Cells
You can generate F4 loopback cells using the atm oam command or the ATM ping
mechanism. F4 loopback receive and transmit statistics are available with the show
atm oam command and include statistics on incoming and outgoing F4 end-to-end and
segment loopback cells.
ATM Ping
With ATM ping you can verify whether a connection endpoint or segment point can be
reached on a VC or VP. ATM ping uses F4 and F5 loopback cells and is supported only
for data circuits and not control circuits (ILMI, signaling circuits). To generate:
•
F5 segment loopback cells or end-to-end loopback cells, issue the ping atm command
on a VC.
•
F4 segment loopback cells or end-to-end loopback cells, issue the ping atm command
on a VP.
You can specify the number of loopback cells that are sent, the location ID, and the timer
value. After the interface sends the loopback cells, the timer is started and the interface
waits for a response. On receiving the loopback response (or when the timer expires) the
ATM interface sends the next cell. This operation is repeated for the number of cells
specified.
Because F4 and F5 are OAM cells, disabling receipt and transmission of OAM cells on
the ATM interface (by using the atm oam flush command) stops all outstanding ping
operations on the ATM interface. You need to manually restart the ping operation after
you enable receipt and transmission of OAM cells for the interface.
How the ATM Interface Handles Loopback Cells Received
The ATM interface responds to received F4 and F5 loopback cells as indicated in Table
6 on page 19.
18
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
Table 6: Handling of F4 and F5 Loopback Cells Received
Loopback Cell Received
ATM Interface Response
F4 and F5 end-to-end loopback cells and
segment loopback cells with the loopback
location field set to all 1s (ones) and the
loopback indication set.
Clears the loopback indication (sets it to all
zeros) and loops back the received cell.
F4 and F5 segment loopback cells with the
loopback location field set to all 0s (zeros) and
the loopback indication set.
Resets the loopback indication and the
location ID to all 1s (ones) and loops back the
received cells.
F4 and F5 end-to-end loopback cells and
segment loopback cells with the loopback
location field set to the loopback location ID of
the ATM interface and the loopback indication
set.
Clears the loopback indication and loops back
the received cell without resetting the location
ID.
F5 end-to-end loopback cells with the loopback
location field set to a value other than all 1s and
the loopback location ID of the ATM interface.
Discards the cell.
F5 segment loopback cells with the loopback
location field set to other than all 1s (ones), set
to all 0s (zeros), or set to the loopback location
ID of the ATM interface.
Discards the cell.
Automatic Disabling of F5 OAM Services
The router automatically disables all F5 OAM fault management and VC integrity services
configured on a VC when you change the administrative status of the corresponding ATM
interface, ATM AAL5 interface, or ATM 1483 subinterface from enabled to disabled.
To set the administrative status of an interface to disabled, use the atm shutdown
command (for an ATM interface), the atm aal5 shutdown command (for an ATM AAL5
interface), or the atm atm1483 shutdown command (for an ATM 1483 subinterface).
You can also use the shutdown command to disable the interface.
When F5 OAM is disabled, the OAM VC status field in the show atm vc atm command
display indicates that the VC is not managed. The VC does not receive or transmit F5
OAM cells while F5 OAM is disabled. For examples of the show atm vc atm command
display, see “show atm vc atm” on page 91.
When the corresponding ATM interface, ATM AAL5 interface, or ATM 1483 subinterface
is reenabled, the router automatically restores F5 OAM services on the associated VCs.
Rate Limiting for F5 OAM Cells
The router implements rate limiting for ATM F5 OAM cells to protect the corresponding
ATM interface from denial-of-service (DoS) attacks. The interface discards control
packets when the rate of control packets received exceeds the rate limit for ATM
interfaces.
Copyright © 2010, Juniper Networks, Inc.
19
JunosE 11.3.x Link Layer Configuration Guide
An ATM interface has a rate limit control that is non-configurable and always in effect;
the rate limit is the same for all ATM interfaces. In addition, each ATM VC maintains its
own state and statistics counters for tracking the rate. The rate limit for ATM OAM cells
is approximately 5 packets per second.
For an ATM VC, the router increments the InOamCellDiscards statistics counter in the
show atm vc atm command display to track the number of OAM cells received on this
circuit that were discarded. The InOamCellDiscards counter operates on a per-circuit
basis, not on a per-interface basis.
For examples of the show atm vc atm command display, see “show atm vc atm” on
page 91.
Before You Configure ATM
Before you configure an ATM interface, verify that you have installed the physical module
(such as an OC3 module) correctly. For more information about preconfiguration
procedures, see the ERX Hardware Guide or the E120 and E320 Hardware Guide.
Also have the following information available:
•
Interface specifiers for the ATM interfaces that you want to create
For more information about specifying ATM interfaces and subinterfaces on E Series
routers, see Interface Types and Specifiers in JunosE Command Reference Guide.
•
Virtual path and channel numbers for each virtual circuit you want to create
•
IP addresses and subnet mask assignments for IP interfaces
You can configure the following types of dynamic interfaces over ATM:
•
IP over static ATM 1483 (IPoA)
•
IP over PPP over static ATM 1483
•
IP over PPPoE over static ATM 1483
•
IP over bridged Ethernet over static ATM 1483
•
IP over MLPPP over static ATM 1483
•
ATM 1483 over static ATM AAL5 over ATM
For information about creating these dynamic configurations, see “Configuring Dynamic
Interfaces” on page 511.
Configuration Tasks
The following sections describe how to perform these ATM configuration tasks:
20
•
Creating a Basic Configuration on page 21
•
Setting Optional Parameters on page 23
•
Configuring OAM on page 31
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
•
Configuring an NBMA Interface on page 38
•
Creating an NBMA Static Map on page 38
•
Assigning Descriptions to Interfaces on page 40
•
Sending Interface Descriptions to AAA on page 41
•
Configuring Individual ATM PVC Parameters on page 43
•
Configuring ATM VC Classes on page 53
•
Configuring Dynamic ATM 1483 Subinterfaces on page 66
Creating a Basic Configuration
To configure ATM, perform the following tasks. (Figure 3 on page 22 shows the relationship
of Steps 1 through 3.)
1.
Configure an ATM physical interface.
host1(config)#interface atm 0/1
2. Configure an ATM 1483 subinterface.
host1(config-if)#interface atm 0/1.20
3. Configure a PVC by specifying the VCD, the VPI, the VCI, and the encapsulation type.
host1(config-subif)#atm pvc 10 15 22 aal5snap
4. Assign an IP address and subnet mask to the PVC.
host1(config-subif)#ip address 192.32.10.20 255.255.255.0
5. (Optional) Verify your configuration using the appropriate show commands.
host1#show atm interface atm 0/1
host1#show atm vc atm 0/1 10
host1#show atm subinterface atm 0/1.20
Copyright © 2010, Juniper Networks, Inc.
21
JunosE 11.3.x Link Layer Configuration Guide
Figure 3: Configuring an ATM Interface, Subinterface, and PVC
ERX14xx models (rear view)
atm pvc
•
Use to configure a PVC on an ATM interface.
•
Specify one of the following encapsulation types:
aal5snap—Specifies an LLC encapsulated circuit; LLC/SNAP header precedes the
protocol datagram.
•
aal5mux ip—Specifies a VC-based multiplexed circuit. This option is used for IP only.
•
aal5autoconfig—Enables autodetection of the 1483 encapsulation (LLC/SNAP or
VC multiplexed) for dynamic interfaces. See “Configuring Dynamic Interfaces” on
page 511, for more explanation.
•
ilmi—Defines the PVC for ILMI keepalive messages. You can set this option only on
major interfaces. After the PVC is set up for ILMI, use “atm ilmi-keepalive” on page 28
to cause the router to generate ILMI keepalive messages on the interface.
•
You can optionally set the peak, average, and burst sizes. To use VBR-RT or VBR-NRT
as the service type, you must specify each of these options.
•
The default service type is UBR. To set a different service type, specify one of the
following keywords:
•
22
•
•
rt—Selects VBR-RT as the service type. You can select rt only if you set the peak,
average, and burst parameters.
•
cbr—Selects CBR as the service type. You must set the CBR rate in Kbps.
To enable VC integrity and generation of OAM F5 loopback cells on this circuit, use the
oam keyword.
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
•
Example
host1(config-if)#atm pvc 6 0 11 aal5snap cbr 10000
•
Use the no version to remove the specified PVC.
•
See atm pvc.
•
Use to configure an ATM interface or subinterface type.
•
To specify an ATM interface for ERX7xx models, ERX14xx models, and ERX310 router,
use the slot/port.[subinterface ] format.
interface atm
•
•
slot—Number of the chassis slot
•
port—Port number on the I/O module; on the OC3-2 GE APS I/O module, you can
specify ATM interfaces only in ports 0 and 1; port 2 is reserved for a Gigabit Ethernet
interface
•
subinterface—Number of the subinterface in the range 1–2147483647
To specify an ATM interface for the E120 or E320 router, use the
slot/adapter/port[.subinterface ] format.
•
slot—Number of the chassis slot
•
adapter—Identifier for the IOA within the E320 chassis, either 0 or 1, where:
•
0 indicates that the IOA is installed in the right IOA bay (E120 router) or the upper
IOA bay (E320 router)
•
1 indicates that the IOA is installed in the left IOA bay (E120 router) or the lower
IOA bay (E320 router).
•
port—Port number on the IOA
•
subinterface—Number of the subinterface in the range 1–2147483647
•
Specify the type of interface or subinterface: point-to-point or multipoint.
Point-to-point is the default.
•
Examples
host1(config-if)#interface atm 0/1.20
host1(config-if)#interface atm 0/0/4.20
•
Use the no version to remove the subinterface or the logical interface.
•
See interface atm.
Setting Optional Parameters
You can also set the following parameters:
•
Set the administrative state of an ATM AAL5 interface to disabled.
host1(config-if)#atm aal5 shutdown
Copyright © 2010, Juniper Networks, Inc.
23
JunosE 11.3.x Link Layer Configuration Guide
•
Enable CAC on the interface.
host1(config-if)#atm cac 3000000 ubr 3000
•
Configure the clock source.
host1(config-if)#atm clock internal
•
Configure framing on a T3/E3 physical interface.
host1(config-if)#atm framing g751adm
•
Enable ILMI on the interface.
host1(config-if)#atm ilmi-enable
•
Set the ILMI keepalive timer.
host1(config-if)#atm ilmi-keepalive 5
•
Specify the cable length (line build-out) for the ATM interface.
host1(config-if)#atm lbo long
•
Set the administrative state of the ATM interface to disabled.
host1(config-if)#atm shutdown
•
Configure SNMP link status traps on the interface.
host1(config-if)#atm snmp trap link-status
host1(config-if)#atm aal5 snmp trap link-status
•
Set the operational mode of the physical interface to SDH STM1.
host1(config-if)#atm sonet stm-1
•
Configure the UNI version of ILMI using one of the following methods:
•
Enable auto configuration of ILMI.
host1(config-if)#atm auto-configuration
•
Set the UNI version that the router uses when ILMI link autodetermination is
unsuccessful or ILMI is disabled.
host1(config-if)#atm uni-version 4.0
•
Configure the number of virtual circuits for each virtual path.
host1(config-if)#atm vc-per-vp 128
•
Configure a virtual path tunnel and its traffic parameters.
host1(config-if)#atm vp-tunnel 2 128
•
Enable scrambling of the ATM cell payload on a T3 or an E3 interface.
host1(config-if)#ds3-scramble
•
Set the time interval at which the router records bit and packet rates.
host1(config-if)#load-interval 90
•
Place the interface into loopback mode for router-to-router testing.
host1(config-if)#loopback diagnostic
24
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
•
Disable an interface.
host1(config-if)#shutdown
Optional Tasks on ATM 1483 Subinterfaces
You can perform the following optional tasks on ATM 1483 subinterfaces:
•
Set the MTU.
host1(config-subif)#atm atm1483 mtu 7800
•
Configure SNMP link status traps.
host1(config-subif)#atm atm1483 snmp trap link-status
•
Set the administrative state of an ATM 1483 subinterface to disabled.
host1(config-subif)#atm atm1483 shutdown
•
Configure an advisory receive speed.
host1(config-subif)#atm atm1483 advisory-rx-speed 2000
atm aal5 shutdown
•
Use to set an ATM AAL5 interface administrative state to disabled.
•
When you set the administrative state of the ATM AAL5 interface to disabled, the
router automatically disables all F5 OAM services configured on the associated VC,
and prevents the VC from receiving or transmitting F5 OAM cells.
•
Example
host1(config-if)#atm aal5 shutdown
•
Use the no version to enable a disabled interface.
•
See atm aal5 shutdown.
atm aal5 snmp trap link-status
•
Use to enable SNMP link status traps on the AAL5 layer interface.
•
Example
host1(config-if)#atm aal5 snmp trap link-status
•
Use the no version to disable the traps.
•
See atm aal5 snmp trap link-status.
atm atm1483 advisory-rx-speed
Copyright © 2010, Juniper Networks, Inc.
25
JunosE 11.3.x Link Layer Configuration Guide
•
Use to set an advisory receive speed for an ATM 1483 subinterface. This setting has
no effect on data forwarding. You can use it to indicate the speed of the client interface.
When traffic is tunneled with L2TP, the advisory receive speed is sent from the LAC to
the LNS. See LAC Configuration Prerequisites for additional information about the
advisory receive speed.
NOTE: If you specify an advisory receive speed greater than 4294967 kbps,
the speed is not accurately represented in the L2TP AVP, which is in bits
per second (bps).
•
The range is 0–2147483647 kbps.
•
Example
host1(config-subif)#atm atm1483 advisory-rx-speed 2000
•
Use the no version to restore the default behavior—the RX speed is not sent to the
LNS.
•
See atm atm1483 advisory-rx-speed.
•
Use to set the MTU size for an ATM 1483 subinterface.
•
The range is 256–9180.
•
Example
atm atm1483 mtu
host1(config-subif)#atm atm1483 mtu 7800
•
Use the no version to restore the default size of 9180.
•
See atm atm1483 mtu.
•
Use to set an ATM 1483 subinterface administrative state to disabled.
•
When you set the administrative state of the ATM 1483 subinterface to disabled, the
router automatically disables all F5 OAM services configured on the associated VC,
and prevents the VC from receiving or transmitting F5 OAM cells.
•
Example
atm atm1483 shutdown
host1(config-subif)#atm atm1483 shutdown
•
Use the no version to enable a disabled subinterface.
•
See atm atm1483 shutdown.
atm atm1483 snmp trap link-status
•
Use to enable SNMP link status traps on an ATM 1483 layer subinterface.
•
Example
host1(config-subif)#atm atm1483 snmp trap link-status
26
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
•
Use the no version to disable the traps.
•
See atm atm1483 snmp trap link-status.
•
Use to enable autoconfiguration of ILMI. Entering the atm auto-configuration command
overrides any previous configuration of the atm uni-version command.
•
Autoconfiguration is enabled by default.
•
Example
atm auto-configuration
host1(config-if)#atm auto-configuration
•
Use the no version to disable autoconfiguration and set the ILMI parameters to the
UNI version configured using the atm uni-version command, which has a default value
of UNI 4.0.
•
See atm auto-configuration.
•
Use to enable CAC on the interface. You can set a subscription limit, so you can
oversubscribe the port, and the UBR weight, so you can limit the number of UBR
connections.
•
You cannot configure CAC on an ATM interface on which you have created a
bulk-configured VC range for use by a dynamic ATM 1483 subinterface. Conversely,
you cannot create a bulk-configured VC range on an ATM interface on which you have
configured CAC. For information about creating bulk-configured VC ranges, see “Bulk
Configuration of VC Ranges” on page 627 in “Configuring Dynamic Interfaces Using Bulk
Configuration” on page 619.
•
Example
atm cac
host1(config-if)#atm cac 3000000 ubr 3000
•
Use the no version to disable CAC on the interface.
•
See atm cac.
•
Use to cause the ATM interface to generate the transmit clock internally.
•
You must specify one of the following:
atm clock internal
•
•
module—Internal clock is from the line module (the default)
•
chassis—Internal clock is from the configured system clock
Example
host1(config-if)#atm clock internal
•
Use the no version to cause ATM interfaces to recover the clock from the received
signal.
•
See atm clock internal.
Copyright © 2010, Juniper Networks, Inc.
27
JunosE 11.3.x Link Layer Configuration Guide
atm framing
•
Use to configure T3 or E3 framing on an ATM interface.
•
Specify one of the following framing types for a T3 (DS3) interface:
•
•
•
cbitadm—c-bit with ATM direct mapping
•
cbitplcp—c-bit with PLCP framing (default)
•
m23adm—M23 ATM direct mapping
•
m23plcp—M23 with PLCP framing
Specify one of the following framing types for an E3 interface:
•
g832adm—G.832 ATM direct mapping
•
g751adm—G.751 ATM direct mapping
•
g751plcp—G.751 PLCP mapping (default)
Example
host1(config-if)#atm framing g751adm
•
Use the no version to return framing to the default:
•
For a T3 interface, the default is cbitplcp
•
For an E3 interface, the default is g751plcp
•
See atm framing.
•
Use to enable ILMI on the interface.
•
Example
atm ilmi-enable
host1(config-if)#atm ilmi-enable
•
Use the no version to disable ILMI on the interface.
•
See atm ilmi-enable.
•
Use to generate ILMI keepalive messages. This value sets the time interval in seconds
between poll PDU transmissions if no sequence data PDUs are pending.
•
Example
atm ilmi-keepalive
host1(config-if)#atm ilmi-keepalive 5
•
Use the no version to disable the generation of keepalive messages.
•
See atm ilmi-keepalive.
atm lbo
28
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
•
Use to specify the cable length (line build-out) for the ATM T3 or E3 interface. The
length of cable determines power requirements.
•
Specify one of the following keywords:
•
•
long—A cable length in the range 0–225 feet
•
short—A cable length in the range 226–450 feet (the default)
Example
host1(config-if)#atm lbo long
•
Use the no version to restore the default value, short.
•
See atm lbo.
•
Use to set an ATM interface administrative state to disabled.
•
When you set the administrative state of the ATM interface to disabled, the router
automatically disables all F5 OAM services configured on the associated VC, and
prevents the VC from receiving or transmitting F5 OAM cells.
•
Example
atm shutdown
host1(config-if)#atm shutdown
•
Use the no version to enable a disabled interface.
•
See atm shutdown.
atm snmp trap link-status
•
Use to enable SNMP link status traps on the ATM layer interface.
•
Example
host1(config-if)#atm snmp trap link-status
•
Use the no version to disable the traps.
•
See atm snmp trap link-status.
•
Use to set the mode of operation on the physical interface to Synchronous Digital
Hierarchy (SDH) Synchronous Transport Mode (STM).
atm sonet stm-1
host1(config-if)#atm sonet stm-1
•
Use the no version to restore the default value, SONET STS-3c operation.
•
See atm sonet stm-1.
•
Use to specify the UNI version for the interface to use.
•
Valid values are 3.0, 3.1, or 4.0.
•
Example
atm uni-version
Copyright © 2010, Juniper Networks, Inc.
29
JunosE 11.3.x Link Layer Configuration Guide
host1(config-if)#atm uni-version 4.0
•
There is no no version.
•
See atm uni-version.
•
Use to configure the number of VCs for each VP. The router does not execute this
command when any VCs are open on the interface.
•
VCs and VP tunnels must not exist when you issue this command. If they do, you must
delete the VC and VP tunnel configuration before you issue this command.
•
The specified value must be a power of 2, or an error message is returned.
•
The minimum number of VCs per VP is 4096 for OCx/STMx ATM line modules. If you
enter a value that is below the minimum, the router uses the minimum value.
•
The E120 and the E320 routers support the entire VPI/VCI range; therefore, it does not
support this command.
•
Example
atm vc-per-vp
host1(config-if)#atm vc-per-vp 128
•
Use the no version to restore the default value.
•
See atm vc-per-vp.
•
Use to define a VP tunnel and configure the rate of traffic flow within the tunnel.
•
You specify a tunnel rate in Kbps. All circuits in the VP are restricted to the rate that
you set.
•
The tunnel rate can be a value in the range 0–4294967295, when you specify the rate
of traffic flow without the constant bit rate (CBR) service category, and can be a value
in the range 1–4294967295, when you specify the rate of traffic flow with the CBR
service class. Because the CBR service category guarantees a fixed amount of
bandwidth to be allotted to the client, an error message is displayed if you configure
a value of 0 for the tunnel rate for CBR traffic flows.
•
If any virtual circuits are open within the VPI before the tunnel is created, the router
does not execute this command.
•
For more information about configuring a shapeless VP tunnel for QoS, see ATM
Integrated Scheduler Overview.
•
Example
atm vp-tunnel
host1(config-if)#atm vp-tunnel 2 128
•
Use the no version to remove the VP tunnel. When circuits are open within the tunnel,
the router does not remove the tunnel.
•
See atm vp-tunnel.
ds3-scramble
30
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
e3-scramble
•
Use to scramble the ATM cell payload on a T3 or an E3 interface. DS3 (T3) and E3
scrambling assists clock recovery on the receiving end of the interface.
•
Example
host1(config-if)#ds3-scramble
•
Use the no version to disable scrambling.
•
See ds3-scramble.
•
See e3-scramble.
•
Use to set the time interval at which the router calculates bit and packet rate counters
for the ATM interface.
•
You can choose a multiple of 30 seconds, in the range 30–300 seconds.
•
Example
load-interval
host1(config-if)#load-interval 90
•
Use the no version to return to the default setting, 300 seconds.
•
See load-interval.
•
Use to place the interface into loopback mode.
•
Specify either:
loopback
•
•
diagnostic—Places the interface into internal loopback.
•
line —Places the interface into external loopback.
Example
host1(config-if)#loopback diagnostic
•
Use the no version to remove any loopback.
•
See loopback.
Configuring OAM
This section explains:
•
Configuring F4 OAM on page 32
•
Configuring F5 OAM on page 33
•
Setting a Loopback Location ID on page 35
•
Enabling OAM Flush on page 35
•
Running ATM Ping on page 36
Copyright © 2010, Juniper Networks, Inc.
31
JunosE 11.3.x Link Layer Configuration Guide
Configuring F4 OAM
The ATM interface does not support sending F4 segment loopback cells, but it does
respond to F4 segment loopback cells that it receives.
F4 OAM flows need their own channel, and they are identified by the VCI on which they
are sent or received. The following VCIs are reserved for F4 OAM flows for each virtual
path, and you cannot open PVCs on them:
•
VCI 3—For segment F4 flows
•
VCI 4—For end-to-end F4 flows
NOTE: You cannot enable both loopback cells and CC cells at the same
time.
To set up F4 OAM:
Enable F4 OAM on an interface or VP. The router enables F4 OAM at the interface
level unless you specify a VPI. This example opens both segment and end-to-end F4
OAM circuits on VPI 10.
1.
host1(config-if)#atm oam 10
2. (Optional) Enable only segment or end-to-end loopback.
host1(config-if)#atm oam 10 seg-loopback
host1(config-if)#atm oam 10 end-loopback
3. (Optional) To cause the interface to generate end-to-end loopback cells in addition
to receiving and responding to them, set the loopback timer.
host1(config-if)#atm oam 10 end-loopback loopback-timer 20
4. (Optional) Enable CC cell flows.
host1(config-if)#atm oam 10 seg-loopback cc source
atm oam
•
Use to configure F4 OAM on an interface or circuit. F4 OAM is configured at the interface
level unless you specify a VPI.
•
To open F4 OAM on either a segment or end-to-end basis, use the following keywords:
•
seg-loopback—Enables F4 segment OAM
•
end-loopback—Enables F4 end-to-end OAM
NOTE: If you do not specify either segment or end-to-end loopback, the
command applies to both end-to-end and segment F4 OAM circuits.
•
32
To configure CC cell flow on the PVC, use the following keywords:
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
•
•
both—Enables the PVC as both the source and the sink endpoints.
•
sink—Enables the PVC as the sink endpoint.
•
source—Enables the PVC as the source endpoint.
•
loopback-timer—When F4 OAM is enabled, the interface or circuit accepts and
responds to F4 OAM cells. However, to generate F4 loopback cells, you must configure
the loopback timer in the range 1–600 seconds. This timer represents the frequency
with which F4 loopback cells are transmitted. You can set the loopback timer only
for end-to-end loopback.
Example 1—Opens both F4 end-to-end and segment OAM circuits for VPI 8
host1(config-if)#atm oam 8
•
Example 2—Opens the F4 end-to-end OAM circuit for VPI 10 and enables sending F4
end-to-end loopback cells on the circuit at a frequency of 20 seconds
host1(config-if)#atm oam 10 end-loopback loopback-timer 20
•
Example 3—Opens both F4 end-to-end and segment OAM circuits on all VPs on this
interface
host1(config-if)#atm oam
•
Example 4—Opens F4 segment OAM circuits on all VPs on this interface
host1(config-if)#atm oam seg-loopback
•
Example 5—Opens F4 end-to-end loopback on VPI 12
host1(config-if)#atm oam 12 end-loopback
•
Example 6—Opens an F4 segment OAM circuit for VPI 8 and enables CC cell generation
on the segment
host1(config-if)#atm oam 8 seg-loopback cc source
•
Use the no version to delete F4 OAM circuits. Using the options, you can delete all F4
OAM circuits on the interface, segment or end-to-end F4 OAM circuits, or F4 OAM
circuits on a specific VPI.
•
Example 1—Deletes all F4 OAM circuits on the interface
host1(config-if)#no atm oam
•
Example 2—Deletes all F4 segment OAM circuits on the interface
host1(config-if)#no atm oam segment
•
Example 3—Deletes the F4 end-to-end OAM circuit on VPI 8
host1(config-if)#no atm oam 8 end-loopback
•
See atm oam.
Configuring F5 OAM
F5 OAM flows run over existing PVCs. The ATM interface does not support sending F5
segment loopback cells, but it does respond to F5 segment loopback cells that it receives.
Copyright © 2010, Juniper Networks, Inc.
33
JunosE 11.3.x Link Layer Configuration Guide
NOTE: You cannot enable both loopback cells and CC cells at the same time.
To set up F5 OAM:
To enable VC integrity, which causes the ATM interface to periodically send F5
end-to-end loopback cells over a VC, use the oam keyword with the atm pvc
command.
1.
You can include the frequency (in seconds) with which the router sends F5 end-to-end
loopback cells.
host1(config-if)#atm pvc 98 38 22 aal5snap oam 300
2. (Optional) To enable CC cell flows on a circuit, use the cc keyword with the atm pvc
command. You can enable cell flows on a segment or end-to-end basis, and you can
enable the PVC as a sink, source, or both a sink and a source.
host1(config-if)#atm pvc 50 0 50 aal5snap oam cc end-to-end sink
When you issue the appropriate shutdown command to change the administrative status
of the corresponding ATM interface, ATM AAL5 interface, or ATM 1483 subinterface from
enabled to disabled, the router automatically disables all F5 OAM services configured
on the associated VC. For more information, see “Automatic Disabling of F5 OAM Services”
on page 19.
atm pvc
34
•
Use the atm pvc command with the oam keyword to set up the PVC to periodically
transmit F5 end-to-end loopback cells over a VC.
•
You can use the oam keyword only if you specify one of the following encapsulation
types:
•
aal5snap
•
aal5mux ip
•
aal5autoconfig
•
The oam keyword is not available with the aal5all, aal0, or ilmi
•
Optionally, you can configure the time interval in the range 1–600 seconds between
transmissions of OAM F5 end-to-end loopback cells.
•
Use the following keywords to enable and configure CC cell flows:
•
end-to-end—Opens an end-to-end CC cell flow
•
segment—Opens a segment CC cell flow
•
sink—Enables this VC as a sink point (cell receiver)
•
source—Enables this VC as the source point (cell generator)
•
both—Enables this VC as both a sink point and a source point
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
•
Example 1—Enables F5 end-to-end loopback cells
host1(config-if)#atm pvc 20 20 20 aal5snap oam
•
Example 2—Enables end-to-end CC cell flow and enables the PVC as the sink
host1(config-if)#atm pvc 5 0 5 aal5autoconfig oam cc end-to-end sink
•
Use the no version of the atm pvc command without the oam keyword to disable F5
OAM on the PVC and without the cc keyword to disable CC cell flows on the PVC. For
example, the following command disables CC cell flow configured in Example 2.
host1(config-if)#no atm pvc 5 0 5 aal5autoconfig
•
See atm pvc.
Setting a Loopback Location ID
To enable other nodes to specifically send OAM loopback cells to the ATM interface, set
the location ID of the ATM interface or circuit.
host1(config-if)#atm oam loopback-location 01090708
NOTE: Because the router is a connection endpoint, the default loopback
location ID is all 1s (ones). This command enables you to specify a nondefault
value.
atm oam loopback-location
•
Use to set the location ID of the ATM interface. The location ID is a 4-octet field, and
the default value is all 1s (ones).
•
You can set a specific value to identify this ATM interface as the intended recipient
of OAM loopback cells.
•
You can also set the location ID to all 0s (zeros).
For information about how the router handles loopback cells based on location ID, see
Table 6 on page 19.
•
Example
host1(config-if)#atm oam loopback-location 01090708
•
Use the no version to return the loopback location ID to the default value, all 1s (ones).
•
See atm oam loopback-location.
Enabling OAM Flush
You can use the atm oam flush command to enable the OAM flush feature for an ATM
interface. When OAM flush is enabled, the router ignores all OAM cells received on the
interface, and stops sending OAM cells on this interface.
Copyright © 2010, Juniper Networks, Inc.
35
JunosE 11.3.x Link Layer Configuration Guide
You can also issue the atm oam flush command with the optional alarm-cells keyword
to cause the router to ignore only AIS and RDI cells and to accept all other OAM cells.
This is useful in diagnostic situations when you might want to exclude alarm conditions.
NOTE: The OAM flush feature is supported on all E Series ATM module
combinations.
atm oam flush
•
Use to configure the router to ignore all OAM cells received on an ATM interface, and
to stop sending OAM cells on this interface.
•
To cause the router to ignore only AIS and RDI cells and to accept all other OAM cells,
use the alarm-cells keyword.
•
Example
host1(config-if)#atm oam flush
•
Use the no version to disable OAM flush on the interface.
•
See atm oam flush.
Running ATM Ping
Keep in mind the following when you use ATM ping:
•
Before you can run ATM ping, you need to add a PVC for the VPI and VCI over which
you run the ping.
•
Because ATM ping requires the receipt of OAM cells, make sure that the receipt and
transmission of OAM cells is not disabled (using “atm oam flush” on page 36 ). To
reenable the receipt and transmission of OAM cells, enter no atm oam flush.
•
Disabling receipt of OAM cells during a ping operation stops all outstanding ping
operations. You need to manually restart the ping operation after receipt of OAM cells
for the interface is enabled.
•
Because ATM ping is a dynamic (on-demand) operation, none of the configuration
related to ATM ping is saved. To avoid acquiring excessive bandwidth for OAM, the
number of outstanding ping operations on each interface is limited to 12.
•
Use to send loopback cells from an ATM interface or circuit.
•
The VPI and VCI fields determine the type of loopback cells used for the ping operation.
By default F5 end-to-end loopback OAM cells are used.
ping atm interface atm
•
36
•
To send F4 segment loopback cells, set the VCI to 3.
•
To send F4 end-to-end loopback cells, set the VCI to 4.
Use the end-loopback keyword to send the ping to the connection endpoint.
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
•
Use the seg-loopback keyword to send the ping to the first segment point (for example,
the next neighbor switch).
•
Use the destination option to specify the value of the location ID included in the loopback
cell. The location ID is a 16-octet field, and the destination portion is 4 octets. You can
set the location ID to a specific destination or to 0s (zeros) or 1s (ones).
•
If you set the destination to 0, the loopback location ID in the loopback cell is
initialized to all 0s, and each segment point in the network responds to the ping.
•
If you set the destination to 1s, the loopback location ID in the loopback cell is
initialized to all 1s, and only the connection endpoint responds to the ping.
•
If you use the default value of 0xFFFFFFFF, the loopback location ID in the loopback
cell is initialized to all 1s.
For information about how the router handles loopback cells based on location ID, see
Table 6 on page 19.
•
The count keyword sets the number of OAM loopback cells to send to the destination.
The default value is 5. The maximum is 32.
•
The timeout keyword sets the amount of time to wait for a response to the sent OAM
loopback cell. The default value is 5 seconds.
•
The following characters can appear in the display after the ping command has been
issued:
•
•
!—Each exclamation point indicates that a reply was received
•
.—Each period indicates that the ping timed out while waiting for a reply
Example 1—This example generates end-to-end loopback cells for VPI=0 and VCI=105
on ATM interface 2/0. The count value is 5 OAM loopback cells, and the timeout value
is 2 seconds.
host1#ping atm interface atm 2/0 0 105 end-loopback count 5 timeout 2
Sending 5 53-byte OAM end-to-end loopback Echoes timeout is 2 secs
Press Ctrl+c to stop
!!!!!
Success rate = 100% (5/5), round-trip min/avg/max = 0/4/10 ms
•
Example 2—This example generates segment loopback cells for VPI=0 and VCI=105
on ATM interface 2/0. The destination is set to 0xFFFFFFFF, the count value is 3 OAM
loopback cells, and the timeout value is 1 second.
host1#ping atm interface atm 2/0 0 105 seg-loopback 0xFFFFFFFF count 3 timeout 1
Sending 3 53-byte OAM segment loopback Echoes timeout is 1 secs
Press Ctrl+c to stop
!!!
Success rate = 100% (3/3), round-trip min/avg/max = 0/3/10 ms
•
There is no no version.
•
See ping atm interface atm.
Copyright © 2010, Juniper Networks, Inc.
37
JunosE 11.3.x Link Layer Configuration Guide
Configuring an NBMA Interface
You configure an ATM NBMA 1483 subinterface in a manner similar to configuring a
standard ATM 1483 subinterface. When you specify a subinterface, however, you must
select the multipoint option if you plan to add multiple circuits to form an NBMA interface.
If you do not select multipoint, the subinterface defaults to point-to-point, and only a
single circuit can be affiliated with that subinterface.
You can configure one or more PVCs and associate them with the subinterface you create.
Also, you can enable InARP and identify a refresh rate on each specific circuit. For each
NMBA interface, either InARP must be enabled, or a static map entry must be provided
for each circuit owned by the interface; otherwise, transmitting over that circuit is
impossible.
NOTE: NBMA interfaces support only the aal5snap encapsulation.
To configure an NBMA interface:
1.
Configure a physical interface.
host1(config)#interface atm 2/0
2. Configure an ATM 1483 subinterface.
host1(config-if)#interface atm 2/0.2 multipoint
3. Configure PVCs by specifying the VCD, VPI, VCI, and encapsulation type.
host1(config-subif)#atm pvc 1 1 1 aal5snap inarp 10
host1(config-subif)#atm pvc 2 2 2 aal5snap
4. (Optional) Specify InARP and a refresh rate (also optional).
host1(config-subif)#atm pvc 3 3 3 aal5snap inarp 5
host1(config-subif)#atm pvc 4 4 4 aal5snap inarp
5. Assign an IP address and subnet mask to the PVC.
host1(config-subif)#ip address 192.32.10.20 255.255.255.0
6. (Optional) Use the appropriate show commands to verify your configuration.
host1#show atm interface atm 2/0
host1#show atm map
host1#show nbma arp atm 2/0
host1#show atm vc atm 2/0 2
host1#show atm subinterface atm 2/0.2
Creating an NBMA Static Map
Static mapping creates an association between IP address–ATM PVC pairs for one or
more member circuits of an ATM 1483 NBMA interface. Not every circuit necessarily gets
the required association from a static map.
38
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
In the following procedure, you can repeat Step 2 for each circuit you want to map. You
can associate with an interface a map group name that you have not already established.
When you define the map list, the name is associated with that interface. You can perform
Steps 3 and 4 before Steps 1 and 2 without affecting the results.
To set up a static map:
1.
Create a map list by naming it.
host1(config)#map-list charlie
2. Associate a protocol and an address with a specific virtual circuit.
host1(config-map-list)#ip 192.168.13.13 atm-vc 1 broadcast
3. Specify an ATM interface.
host1(config-if)#interface atm 2/0
4. Associate the map list with the interface.
host1(config-if)#map-group charlie
atm pvc
•
Use to configure a PVC on an ATM interface.
•
InARP and refresh rate are optional parameters.
•
InARP determines whether InARP requests are used and is specified on a per-circuit
basis. If you disable InARP, you must use a static map table entry. Transmission over
the circuit cannot occur unless you use either InARP or static map table entries.
•
The default refresh rate is 15 minutes.
•
You can configure InARP only if you specify the aal5snap encapsulation type.
•
Example
host1(config-if)#atm pvc 6 0 11 aal5snap inarp 10
•
Use the no version to remove the specified PVC.
•
See atm pvc.
•
Use to configure an ATM interface or subinterface type.
•
For information about specifying the ATM interface or subinterface, see “interface atm”
on page 23.
•
Specify multipoint to identify the subinterface as NBMA.
•
Examples
interface atm
host1(config-if)#interface atm 0/1.20
host1(config-if)#interface atm 0/0/4.20
•
Use the no version to remove the subinterface or the logical interface.
•
See interface atm.
Copyright © 2010, Juniper Networks, Inc.
39
JunosE 11.3.x Link Layer Configuration Guide
ip atm-vc
•
Use to associate a protocol and address with a specific virtual circuit.
•
Use this command repeatedly for each circuit to be mapped.
•
This command is available in Map List Configuration mode only.
•
Example
host1(config-map-list)#ip 192.168.13.13 atm-vc 1 broadcast
•
Use the no version to remove the association.
•
See ip atm-vc.
•
Use to associate the map list with an NBMA interface when configuring static mapping.
•
You can issue this command before or after the map-list command without changing
anything.
•
This command is available in Interface Configuration mode only.
•
See the map-list command.
•
Example
map-group
host1(config-if)#map-group charlie
•
Use the no version to remove the association.
•
See map-group.
•
Use to create a map list when configuring static mapped NBMA interfaces.
•
Limit the name of the map list to no more than 31 characters.
•
You can create multiple map lists; however, you can associate only one map list with
each physical interface.
•
If a map list contains an entry for a VCD that was previously configured to run InARP,
the map-group command fails. If this is the case, either reconfigure the circuit with
InARP disabled, or remove the entry for that circuit from the map list.
•
Example
map-list
host1(config)#map-list charlie
•
Use the no version to remove the map list.
•
See map-list.
Assigning Descriptions to Interfaces
You can use the description commands to assign a text description or an alias to an
interface, so that other show commands can display that information.
40
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
atm aal5 description
•
Use to assign a text description or alias to an ATM AAL5 interface.
•
Use the show atm aal5 interface command to display the text description.
•
Example
host1(config-if)#atm aal5 description boston01
•
Use the no version to remove the text description or alias.
•
See atm aal5 description.
•
Use to assign a text description or alias to an ATM 1483 subinterface.
•
The description can be a maximum of 255 characters.
•
Use the show atm subinterface command to display the text description.
•
Example
atm atm1483 description
host1(config-subif)#atm atm1483 description nyc33
•
Use the no version to remove the text description or alias.
•
See atm atm1483 description.
•
Use to assign a text description or alias to the ATM interface.
•
The description can be a maximum of 255 characters and can include the # (pound
sign) character.
•
The first 32 characters of the ATM description are pushed out to RADIUS during
authentication and accounting.
•
Use the show atm interface command to display the description.
•
Example
atm description
host1(config-if)#atm description myAtm
•
Use the no version to remove the description or alias.
•
See atm description.
Sending Interface Descriptions to AAA
During authentication the router sends ATM interface descriptions to AAA. AAA passes
the descriptions to RADIUS, and they can appear in the Calling-Station-Id attribute [31].
(For information about RADIUS and the Calling-Station-ID attribute, see JunosE Broadband
Access Configuration Guide.)
By default, the router sends the major interface descriptions to AAA on the SRP. You can
configure the router to send VP interface descriptions in place of the major interface
descriptions, or to send ATM 1483 subinterface descriptions to AAA on the line module.
Copyright © 2010, Juniper Networks, Inc.
41
JunosE 11.3.x Link Layer Configuration Guide
As a result, the VP or ATM 1483 subinterface descriptions can provide a convenient way
to identify or group broadband access subscribers.
If you set up multiple interface descriptions, they have the following precedence:
1.
ATM 1483 subinterface description
2. VP interface description
3. Major interface description
Assigning Descriptions to Virtual Paths
To assign a description to an individual VP on an ATM interface, use the atm
vp-description command. The VP description does not affect existing descriptions
configured for the ATM interface or ATM 1483 subinterface on which the VP resides.
However, if you delete the ATM interface, the descriptions of all VPs residing on that
interface are also deleted. In addition, if you decrease the VPI range by issuing the atm
vc-per-vp command, the router deletes the descriptions of any VPs that are removed.
To display the VP description, use the show atm vp-description command, as described
in “Using ATM show Commands” on page 72. Although you need not configure a VP
tunnel to specify a VP description, the router also displays the VP description in the output
of the show atm vp-tunnel command.
Exporting ATM 1483 Subinterface Descriptions
To assign a description to an ATM 1483 subinterface and configure the router to send
the ATM 1483 VC interface descriptions to the line module:
1.
Configure a text description for ATM 1483 subinterfaces with the atm atm1483
description command. This description is included in the interface identifier that is
sent to AAA.
To configure this feature for ATM 1483 subinterfaces, enter this command in Profile
Configuration mode. See “Configuring ATM 1483 Dynamic Subinterfaces” on page 624
in “Configuring Dynamic Interfaces Using Bulk Configuration” on page 619.
host1(config-subif)#atm atm1483 description VC_atm1
2. Set up the router to export ATM 1483 VC interface descriptions to the line module.
host1(config)#atm atm1483 export-subinterface-description
3. (Optional) Display the configuration of the export ATM 1483 VC interface descriptions
feature with the show atm atm1483 command.
host1#show atm atm1483
ATM1483 IF Descriptions exported
4. (Optional) Display the interface descriptions with the show atm subinterface atm
command.
atm atm1483 description
42
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
•
Use to assign a text description or alias to an ATM 1483 subinterface.
•
The description can be a maximum of 255 characters.
•
Example
host1(config-subif)#atm atm1483 description nyc33
•
Use the no version to remove the text description or alias.
•
See atm atm1483 description.
atm atm1483 export-subinterface-description
•
Use to export ATM 1483 VC interface descriptions to the line module. Descriptions for
ATM 1483 subinterfaces are configured with the atm atm1483 description command.
•
The description can have up to 255 characters; however, when the description is sent
to the line module, it is truncated to 32 characters.
•
Example
host1(config)#atm atm1483 export-subinterface-description
•
Use the no version to restore the default behavior, in which ATM 1483 interface
descriptions are not exported to the line module.
•
See atm atm1483 export-subinterface-description.
•
Use to assign a text description to an individual VP on an ATM interface or subinterface.
•
You must specify the VPI of the VP to which you want to assign the description.
•
The description string can be a maximum of 32 characters.
•
The VP description is stored in NVS and persists after a reboot.
•
Use the show atm vp-description command to display the text description.
•
Example
atm vp-description
host1(config-if)#atm vp-description 2 vpi2Subscribers
•
Use the no version to restore the default value, a null string.
•
See atm vp-description.
Configuring Individual ATM PVC Parameters
As an alternative to using the atm pvc command to configure ATM PVC parameters with
a single command, you can access ATM VC Configuration mode to configure individual
ATM PVC parameters with separate commands, one parameter at a time. You can
configure parameters for the service category, encapsulation method, F5 OAM options,
and Inverse ARP.
Copyright © 2010, Juniper Networks, Inc.
43
JunosE 11.3.x Link Layer Configuration Guide
The following sections explain the benefits of using ATM VC Configuration mode and
describes how to configure the ATM VC mode :
•
Benefits on page 44
•
Creating Control PVCs on page 45
•
Creating Data PVCs on page 45
•
Configuring the Service Category for Data PVCs on page 46
•
Configuring Encapsulation for Data PVCs on page 48
•
Configuring F5 OAM for Data PVCs on page 49
•
Configuring Inverse ARP for Data PVCs on page 52
Benefits
Using commands in ATM VC Configuration mode to configure individual ATM PVC
parameters provides the following benefits:
•
Commands in ATM VC Configuration mode are less complex and easier to use.
With the atm pvc command and keywords, you configure multiple PVC attributes on
a single command line. In addition, configuration attributes available only for control
(ILMI and signaling) PVCs or only for data PVCs are not mutually exclusive.
By contrast, ATM VC Configuration mode provides commands to configure each
parameter individually, and makes a clearer distinction between configuration of control
PVCs and configuration of data PVCs.
•
ATM VC Configuration mode interoperates with the atm pvc command.
You can configure all of the parameters currently supported by the atm pvc command
from within ATM VC Configuration mode. In addition, you can create a PVC with the
atm pvc command and modify or delete the same PVC by using ATM VC Configuration
mode. Conversely, you can modify (with certain restrictions) or delete a PVC created
in ATM VC Configuration mode by using the atm pvc command.
•
ATM VC Configuration mode supports additional F5 OAM alarm surveillance and VC
integrity options.
In most cases, you can use either an ATM VC Configuration mode command or the
atm pvc command to configure ATM PVC parameters. However, to configure F5 OAM
alarm surveillance parameters (by using the oam ais-rdi command) or VC integrity
parameters (by using the oam retry command), you must use only ATM VC
Configuration mode. There are no equivalent atm pvc commands to configure these
parameters.
You can, however, continue to use the atm pvc command to enable VC integrity and
modify the loopback frequency of an ATM data PVC.
44
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
NOTE: If you have existing configuration scripts that use the atm pvc
command, we recommend that you continue to use the atm pvc command
to configure all ATM PVC parameters except those that require you to use
the oam ais-rdi command or oam retry command in ATM VC Configuration
mode.
Creating Control PVCs
A control PVC, also referred to as a control circuit, supports services such as ILMI to
manage and control ATM networks. You must create a control PVC on an ATM major
interface, and not on an ATM 1483 subinterface that is stacked above an ATM major
interface.
To create a control PVC, you issue the pvc command from Interface Configuration mode.
However, unlike the other tasks in this section, configuring a control PVC with the pvc
command does not access ATM VC Configuration mode.
For example, the following commands create a control PVC with VCD 10, VPI 0, VCI 16,
and ILMI encapsulation.
host1(config)#interface atm 3/0
host1(config-if)#pvc 10 0/16 ilmi
host1(config-if)#
Regardless of whether you use the pvc command or the atm pvc command to create a
control PVC, you cannot modify the VCD, VPI, or VCI values after they have been
configured.
pvc
•
Use from Interface Configuration mode to create a control PVC for Integrated Local
Management Interface (ILMI).
•
To create a control PVC, specify the VCD, VPI and VCI (in the format vpi/vci), and the
ilmi keyword.
•
Example
host1(config-if)#pvc 5 0/5 ilmi
•
Use the no version to remove the specified control PVC from the router.
•
See pvc.
Creating Data PVCs
A data PVC, also referred to as a data circuit, is an ATM PVC that carries data. You must
create a data PVC on an ATM 1483 subinterface that is stacked above an ATM major
interface, and not on the ATM major interface itself.
To create a data PVC, you issue the pvc command from Subinterface Configuration
mode to access ATM VC Configuration mode. From ATM VC Configuration mode, you
can then do either of the following:
Copyright © 2010, Juniper Networks, Inc.
45
JunosE 11.3.x Link Layer Configuration Guide
•
Issue the exit command, which creates a data PVC that uses default values for service
category (unspecified bit rate without a peak cell rate), encapsulation type (aal5snap),
F5 OAM (disabled), and Inverse ARP (disabled).
•
Issue commands to configure or modify data PVC attributes including the service
category, encapsulation type, F5 OAM, and Inverse ARP.
For example, the following commands create a data PVC with VCD 32, VPI 0, VCI 100
and default values for the other attributes. Issuing the exit command causes the
configuration to take effect.
host1(config)#interface atm 3/2.2
host1(config-subif)#pvc 32 0/100
host1(config-subif-atm-vc)#exit
host1(config-subif)#
Regardless of whether you use the pvc command or the atm pvc command to create a
data PVC, you cannot modify the VCD, VPI, or VCI values after they have been configured.
pvc
•
Use from Subinterface Configuration mode to create a data PVC and access ATM VC
Configuration mode, from which you can configure and modify individual PVC attributes
one at a time.
•
To create a basic data PVC with default values for service category, encapsulation
type, F5 OAM, and Inverse ARP, specify the VCD and the VPI and VCI (in the format
vpi/vci).
•
You must issue the exit command from ATM VC Configuration mode for the
configuration to take effect.
•
Example
host1(config-subif)#pvc 10 15/50
host1(config-subif-atm-vc)#exit
•
Use the no version to remove the specified data PVC from the router.
•
See pvc.
Configuring the Service Category for Data PVCs
You can use individual commands in ATM VC Configuration mode to configure each
supported service category on a data PVC, or to restore the default service category,
unspecified bit rate (UBR) without a peak cell rate (PCR).
For example, the following commands configure a data PVC that uses the constant bit
rate (CBR) service category with a nondefault PCR (10,000 Kbps). Issuing the exit
command causes the configuration to take effect.
host1(config)#interface atm 3/0.3
host1(config-subif)#pvc 6 0/100
host1(config-subif-atm-vc)#cbr 10000
host1(config-subif-atm-vc)#exit
host1(config-subif)#
46
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
cbr
•
Use to configure the CBR service category on an ATM data PVC.
•
You must specify a PCR, in Kbps, in the range 1–149760 (for OC3 ATM modules) or
1–599040 (for OC12 ATM modules).
•
You must issue the exit command from ATM VC Configuration mode for the
configuration to take effect.
•
Example
host1(config-subif-atm-vc)#cbr 15000
host1(config-subif-atm-vc)#exit
•
Use the no version to restore the default service category, UBR without a PCR.
•
See cbr.
•
Use to configure the UBR service category on an ATM data PVC.
•
You can optionally specify a PCR, in Kbps, in the range 0–149760 (for OC3 ATM
modules) or 0–599040 (for OC12 ATM modules).
•
You must issue the exit command from ATM VC Configuration mode for the
configuration to take effect.
•
Example
ubr
host1(config-subif-atm-vc)#ubr 5000
host1(config-subif-atm-vc)#exit
•
Use the no version to restore the default service category, UBR without a PCR.
•
See ubr.
•
Use to configure the variable bit rate, nonreal time (VBR-NRT) service category on an
ATM data PVC.
•
You must specify all of the following parameters:
vbr-nrt
•
PCR, in Kbps, in the range 0–149760 (for OC3 ATM modules) or 0–599040 (for
OC12 ATM modules)
•
SCR, in Kbps, in the range 0–149760 (for OC3 ATM modules) or 0–599040 (for
OC12 ATM modules)
•
Maximum burst size (MBS), in cells, in the range 0–16777215
•
You must issue the exit command from ATM VC Configuration mode for the
configuration to take effect.
•
Example
host1(config-subif-atm-vc)#vbr-nrt 50000 10000 150
host1(config-subif-atm-vc)#exit
Copyright © 2010, Juniper Networks, Inc.
47
JunosE 11.3.x Link Layer Configuration Guide
•
Use the no version to restore the default service category, UBR without a PCR.
•
See vbr-nrt.
•
Use to configure the variable bit rate, real time (VBR-RT) service category on an ATM
data PVC.
•
You must specify all of the following parameters:
vbr-rt
•
PCR, in Kbps, in the range 0–149760 (for OC3 ATM modules) or 0–599040 (for
OC12 ATM modules)
•
SCR, in Kbps, in the range 0–149760 (for OC3 ATM modules) or 0–599040 (for
OC12 ATM modules)
•
Maximum burst size (MBS), in cells, in the range 0–16777215
•
You must issue the exit command from ATM VC Configuration mode for the
configuration to take effect.
•
Example
host1(config-subif-atm-vc)#vbr-rt 200000 30000 400
host1(config-subif-atm-vc)#exit
•
Use the no version to restore the default service category, UBR without a PCR.
•
See vbr-rt.
Configuring Encapsulation for Data PVCs
The encapsulation method on a data PVC represents the format of the data units that
traverse the circuit. You can use the encapsulation command in ATM VC Configuration
mode to configure the encapsulation method for a data PVC, or to restore the default
encapsulation method, aal5snap.
For example, the following commands configure a data PVC that uses aal5all
encapsulation. Issuing the exit command causes the configuration to take effect.
host1(config)#interface atm 3/0.3
host1(config-subif)#pvc 6 0/250
host1(config-subif-atm-vc)#encapsulation aal5all
host1(config-subif-atm-vc)#exit
host1(config-subif)#
encapsulation
48
•
Use to configure the encapsulation method on an ATM data PVC.
•
Specify one of the following encapsulation types:
•
aal0—Causes the router to receive raw ATM cells on this PVC and forward the cells
without performing AAL5 packet reassembly
•
aal5all—Configures ATM over MPLS passthrough connections; the router passes
through all ATM AAL5 traffic without interpreting it
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
•
aal5autoconfig—Enables autodetection of the 1483 encapsulation (LLC/SNAP or
VC multiplexed)
•
aal5mux ip—Configures a VC-based multiplexed circuit used for IP only
•
aal5snap—Configures an LLC encapsulated circuit; an LLC/SNAP header precedes
the protocol datagram; this is the default encapsulation method
•
You must issue the exit command from ATM VC Configuration mode for the
configuration to take effect.
•
Example
host1(config-subif-atm-vc)#encapsulation aal5mux ip
host1(config-subif-atm-vc)#exit
•
Use the no version to restore the default encapsulation method, aal5snap.
•
See encapsulation.
Configuring F5 OAM for Data PVCs
In ATM VC Configuration mode, you can use the individual commands listed in Table 7
on page 49 to configure nondefault values for F5 OAM services.
Table 7: F5 OAM Configuration Tasks and Associated Commands
To Configure
Use This Command
Surveillance parameters for alarm indication
signal (AIS) and remote defect indication (RDI)
fault management cells
oam ais-rdi
Continuity check (CC) verification
oam cc
Generation of F5 loopback cells and enabling
of VC integrity
oam-pvc
Parameters for VC integrity
oam retry
For more information about OAM parameters, see “Operations, Administration, and
Management of ATM Interfaces” on page 14.
NOTE: The oam-ais rdi command and the oam retry command are available
only in ATM VC Configuration mode. There is no equivalent atm pvc command
to configure these F5 OAM alarm surveillance and VC integrity parameters.
For example, the following commands enable VC integrity on a data PVC with a nondefault
loopback frequency (30 seconds). Issuing the exit command causes the configuration
to take effect.
host1(config)#interface atm 3/0.0
Copyright © 2010, Juniper Networks, Inc.
49
JunosE 11.3.x Link Layer Configuration Guide
host1(config-subif)#pvc 32 0/32
host1(config-subif-atm-vc)#oam-pvc manage 30
host1(config-subif-atm-vc)#exit
host1(config-subif)#
The following commands, which are available only in ATM VC Configuration mode,
configure nondefault VC integrity and alarm surveillance parameters on a data PVC. In
this example, the VC integrity parameters configured with the oam retry command
include the up retry count (4), down retry count (6), and retry frequency (2). The alarm
surveillance parameters configured with the oam ais-rdi command include the alarm
down count (2) and alarm clear timeout duration (4 seconds). Issuing the exit command
causes the configuration to take effect.
host1(config)#interface atm 3/0.0
host1(config-subif)#pvc 32 0/32
host1(config-subif-atm-vc)#oam retry 4 6 2
host1(config-subif-atm-vc)#oam ais-rdi 2 4
host1(config-subif-atm-vc)#exit
host1(config-subif)#
oam ais-rdi
•
Use to configure surveillance parameters for AIS and RDI F5 OAM fault management
cells on an ATM data PVC.
•
You can optionally specify the following values:
•
alarmDownCount—Number of successive alarm cells, in the range 1–60, for the router
to receive before reporting that a PVC is down; the default value is 1
•
alarmClearTimeout—Number of seconds, in the range 3–60, for the router to wait
before reporting that a PVC is up after the PVC has stopped receiving alarm cells;
the default value is 3
•
To configure these alarm surveillance parameters, you must use the oam ais-rdi
command in ATM VC Configuration mode. There is no equivalent atm pvc command
to configure these parameters.
•
You must issue the exit command from ATM VC Configuration mode for the
configuration to take effect.
•
Example
host1(config-subif-atm-vc)#oam ais-rdi 5 10
host1(config-subif-atm-vc)#exit
•
Use the no version to restore the default values for the alarm down count and alarm
clear timeout duration.
•
See oam ais-rdi.
•
Use to enable F5 OAM CC verification on an ATM data PVC.
•
You can optionally specify one of the following values to configure CC cell flows:
oam cc
•
50
segment—Opens an F5 OAM CC segment cell flow
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
•
•
end-to-end—Opens an F5 OAM CC end-to-end cell flow
You must specify one of the following values to enable CC verification:
•
source—Enables this VC as the source point (cell generator)
•
sink—Enables this VC as a sink point (cell receiver)
•
both—Enables this VC as both a sink point and a source point
•
You must issue the exit command from ATM VC Configuration mode for the
configuration to take effect.
•
Example 1—Enables CC verification with a source endpoint
host1(config-subif-atm-vc)#oam cc source
host1(config-subif-atm-vc)#exit
•
Example 2—Opens an F5 OAM CC segment cell flow and enables CC verification with
a sink endpoint
host1(config-subif-atm-vc)#oam cc segment sink
host1(config-subif-atm-vc)#exit
•
Use the no version to disable F5 OAM CC verification and restore the default setting
for cell termination, end-to-end.
•
See oam cc.
•
Use to enable generation of F5 OAM loopback cells on an ATM data PVC and, optionally,
enable F5 OAM VC integrity features on the circuit.
•
Use this command only on data PVCs configured with aal5snap, aal5autoconfig, or
aal5 mux ip encapsulation; the command is not valid for data PVCs configured with
other encapsulation types.
•
To enable F5 OAM VC integrity on the PVC, use the manage keyword.
•
You can optionally specify the number of seconds, in the range 1–600, for the router
to wait between the transmission of loopback cells during normal operation; the default
value is 10.
•
You must issue the exit command from ATM VC Configuration mode for the
configuration to take effect.
•
Example
oam-pvc
host1(config-subif-atm-vc)#oam-pvc manage 15
host1(config-subif-atm-vc)#exit
•
Use the no version to restore the default behavior, which disables F5 OAM VC integrity
on the router and restores the default value for loopback frequency, 10 seconds.
•
See oam-pvc.
oam retry
Copyright © 2010, Juniper Networks, Inc.
51
JunosE 11.3.x Link Layer Configuration Guide
•
Use to configure F5 OAM VC integrity parameters on an ATM data PVC.
•
You can optionally specify the following values:
•
upRetryCount—Number of successive loopback cell responses, in the range 1–60,
for the router to receive before reporting that a PVC is up; default value is 3
•
downRetryCount—Number of successive loopback cell responses, in the range 1–60,
for the router to miss before reporting that a PVC is down; default value is 5
•
retryFrequency—Number of seconds, in the range 1–600, for the router to wait
between the transmission of loopback cells when it is verifying the state of the PVC;
default value is 1
•
To configure these VC integrity parameters, you must use the oam retry command in
ATM VC Configuration mode. There is no equivalent atm pvc command to configure
these parameters.
•
You must issue the exit command from ATM VC Configuration mode for the
configuration to take effect.
•
Example
host1(config-subif-atm-vc)#oam retry 5 6 3
host1(config-subif-atm-vc)#exit
•
Use the no version to restore the default values for the up retry count, down retry count,
and retry frequency parameters.
•
See oam retry.
Configuring Inverse ARP for Data PVCs
You can use the inarp command in ATM VC Configuration mode to enable Inverse ARP
(InARP) on a data PVC that resides on an ATM 1483 NBMA subinterface configured with
the multipoint option. The PVC must use the default encapsulation method, aal5snap.
For more information about InARP, see “Configuring an NBMA Interface” on page 38.
For example, the following commands enable InARP with a nondefault refresh rate
(10 minutes) on a data PVC. The PVC uses aal5snap encapsulation by default. Issuing
the exit command causes the configuration to take effect.
host1(config)#interface atm 3/2.1 multipoint
host1(config-subif)#pvc 6 0/11
host1(config-subif-atm-vc)#inarp 10
host1(config-subif-atm-vc)#exit
host1(config-subif)#
inarp
52
•
Use to enable Inverse ARP on an ATM PVC that resides on an ATM 1483 NBMA
subinterface and uses the default encapsulation method, aal5snap.
•
You can optionally specify an Inverse ARP refresh rate, in the range 1–60 minutes; the
default value is 15.
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
•
You must issue the exit command from ATM VC Configuration mode for the
configuration to take effect.
•
Example
host1(config-subif-atm-vc)#inarp 5
host1(config-subif-atm-vc)#exit
•
Use the no version to restore the default behavior, which disables Inverse ARP on the
router.
•
See inarp.
Configuring ATM VC Classes
As an alternative to configuring individual parameters for ATM data PVCs, you can access
ATM VC Class Configuration mode to configure a class of attributes for an ATM data
PVC. A VC class is a set of attributes for a virtual circuit (VC) that can include the service
category, encapsulation method, F5 OAM options, and Inverse ARP.
After you configure the VC class, you then apply the attributes in the class as a group by
assigning the VC class to one of the following:
•
An individual PVC
•
All PVCs created on a specified static ATM major interface
•
All PVCs created on a specified static ATM 1483 subinterface
•
A base profile from which bulk-configured VC ranges are created on a dynamic
ATM 1483 subinterface
VC class assignments are valid only for ATM data PVCs created with the pvc command.
Assigning a VC class to a PVC created with the atm pvc command, or to a control (ILMI)
PVC, has no effect. For information about creating a data PVC by using the pvc command,
see “Creating Data PVCs” on page 45.
NOTE: For information about the total number of VC classes supported on
the router, see JunosE Release Notes, Appendix A, System Maximums.
Benefits
Using VC classes to configure and assign attributes to ATM data PVCs provides the
following benefits:
•
VC classes enable you to classify and group ATM PVCs based on the OAM and traffic
requirements of their associated subscribers.
In a typical scenario, you might group subscribers based on their OAM and traffic
requirements, and then create a VC class for each subscriber group. For example, you
might create two VC classes: premium-subscriber-class and economy-subscriber-class.
Copyright © 2010, Juniper Networks, Inc.
53
JunosE 11.3.x Link Layer Configuration Guide
In premium-subscriber-class, you might enable F5 OAM VC integrity (with the oam-pvc
manage command), and configure a traffic class that has a higher scheduling priority,
such as CBR (with the cbr command). Conversely, in economy-subscriber-class, you
might retain the default setting that disables F5 OAM VC integrity, and configure a
traffic class that has a lower scheduling priority, such as UBR with or without a PCR
(with the ubr command). By assigning each VC class to the appropriate interfaces or
individual circuits, you can group and manage the PVCs associated with the VC class
based on the network requirements of the subscribers they serve.
•
VC classes facilitate modifications to PVC attributes.
If the OAM or traffic requirements change for a particular subscriber group, you can
simply reconfigure the VC class associated with the PVCs for that subscriber group.
This method is easier and less time-consuming than having to modify the attributes
for a large number of PVCs by using individual CLI commands.
Modifications to the attributes in a VC class affect PVCs that are already associated
with this VC class as well as PVCs subsequently created for this class.
Precedence Levels
Precedence levels play an important role in determining how the router assigns the
attribute values for statically created and dynamically created PVCs that have associated
VC classes.
Precedence Levels for Static PVCs
For PVCs that are statically created, the router determines the PVC attribute values
according to the following precedence levels, in order from highest precedence to lowest
precedence:
1.
The most recent explicitly set value for a PVC attribute always has the highest
precedence and overrides any settings in the VC class. Explicitly set values for PVC
attributes are those values configured with the CLI (by using the atm pvc command
or commands in ATM VC Configuration mode), SNMP, or assigned by RADIUS.
2. If an attribute value is not explicitly specified, the router takes the value for that
attribute from the assigned VC class, in the following order of precedence:
a. Attribute value specified in the VC class assigned to this PVC
b. Attribute value specified in the VC class assigned to the ATM 1483 subinterface
on which this PVC is created
c. Attribute value specified in the VC class assigned to the ATM major interface on
which this PVC is created
3. If no PVC attributes are explicitly specified and no VC class assignments exist, the
router applies the default values for the commands listed in Table 8 on page 57. For
information about the default value for each command, see the command descriptions
in “Configuring VC Classes” on page 56.
54
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
Precedence Levels for Dynamic PVCs
For PVCs that are dynamically created, the router determines the PVC attribute values
according to the following precedence levels, in order from highest precedence to lowest
precedence:
The attribute value specified in the VC class assigned in the base profile always has
the highest precedence.
1.
2. If no VC class is assigned in the base profile, the router takes the value for that attribute
from the VC class assigned to the associated ATM major interface.
3. If neither the base profile nor the ATM major interface has a VC class assigned, the
router takes the value for that attribute from the individually specified attributes in
the base profile.
4. If neither the base profile nor the ATM major interface has a VC class assigned, and
no attributes are individually specified in the base profile, the router applies the default
values for the commands listed in Table 8 on page 57. For information about the
default value for each command, see the command descriptions in “Configuring VC
Classes” on page 56.
Precedence Level Examples
For examples that illustrate how precedence levels affect the assignment of VC classes,
see “Precedence Level Examples for Assigning VC Classes” on page 64.
To help you better understand these examples, we recommend that you first read the
following sections to learn how to configure and assign VC classes:
Upgrade Considerations
The following considerations apply to using ATM VC classes when you upgrade to the
current JunosE Software release from a lower-numbered JunosE Software release:
•
•
It is possible to use VC classes for PVCs created in a lower-numbered release with the
atm pvc command. In such cases, the router uses the following rules to determine the
PVC attribute values:
•
Nondefault values explicitly specified for PVC attributes with the atm pvc command
take precedence over the attribute values specified in the associated VC class. As a
result, the router takes the values for these attributes from the atm pvc command
settings.
•
Default values implicitly specified for PVC attributes with the atm pvc command
have a lower precedence than the attribute values specified in the associated VC
class. As a result, the router takes the values for these attributes from the assigned
VC class.
The output of the show configuration command uses either the pvc command format
or the atm pvc command format to display ATM PVCs. The display format of
configuration information for ATM PVCs created with the atm pvc command depends
on the JunosE Software release from which you are upgrading, as follows:
Copyright © 2010, Juniper Networks, Inc.
55
JunosE 11.3.x Link Layer Configuration Guide
When you upgrade to the current JunosE Software release from a JunosE release
numbered lower than Release 7.3.x, the output of the show configuration command
uses the pvc command format (pvc vcd vpi/vci) to display configuration information
for all ATM PVCs. This occurs even if those PVCs were created in a JunosE release
numbered lower than Release 7.3.x with the atm pvc command. For example, assume
that you created a PVC in JunosE Release 7.2.x by issuing the command atm pvc 2
0 33 aal5snap 0 0 0. The show configuration command in the current JunosE
Software release displays the identifier for this PVC as follows:
•
pvc 2 0/33
When you upgrade to the current JunosE Software release from JunosE Release 7.3.x
or a higher-numbered release, the output of the show configuration command uses
the atm pvc command format to display configuration information for ATM PVCs
created with the atm pvc command. For example, assume that you created a PVC
in JunosE Release 7.3.x or Release 8.0.x by issuing the command atm pvc 2 0 33
aal5snap 0 0 0. The show configuration command in the current JunosE Software
release displays the identifier for this PVC as follows:
•
atm pvc 2 0 33 aal5snap 0 0 0
For PVCs previously created in the lower-numbered release by using the pvc
command, the show configuration command displays configuration information
using the pvc command format, as described previously.
For information about how to use the show configuration command, see chapter
Managing the System in JunosE System Basics Configuration Guide.
To make the most efficient use of the VC class feature when you upgrade to the current
JunosE Software release, we recommend that you follow these steps:
1.
Delete any PVCs created with the atm pvc command and recreate them by using the
pvc command. For information about creating a data PVC by using the pvc command,
see “Creating Data PVCs” on page 45.
2. Configure the VC class as described in “Configuring VC Classes” on page 56.
3. Assign the VC class in one of the following ways:
•
Assign the VC class to the individual PVC when you create or modify the PVC.
•
Assign the VC class to the associated ATM major interface or ATM 1483 subinterface
before you create the PVC.
Configuring VC Classes
To configure a VC class, you issue the vc-class atm command to create and name the
VC class. The vc-class atm command accesses ATM VC Class Configuration mode, from
which you configure a set of attributes to apply to an ATM data PVC.
Table 8 on page 57 lists the commands that you can use in ATM VC Class Configuration
mode to configure a set of attributes for a data PVC. These commands are identical to
the commands in ATM VC Configuration mode described in “Configuring Individual ATM
56
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
PVC Parameters” on page 43. For more information about the syntax of each command,
see the JunosE Command Reference Guide.
Table 8: Commands to Configure VC Class Attributes
cbr
oam-pvc
encapsulation
oam retry
inarp
ubr
oam ais-rdi
vbr-nrt
oam cc
vbr-rt
For example, the following commands configure two VC classes:
premium-subscriber-class and dsl-subscriber-class. You must issue the exit command
from ATM VC Class Configuration mode for each VC class configuration to take effect.
! Configure VC class premium-subscriber-class.
host1(config)#vc-class atm premium-subscriber-class
host1(config-vc-class)#encapsulation aal5autoconfig
host1(config-vc-class)#cbr 200
host1(config-vc-class)#oam-pvc manage 60
host1(config-vc-class)#oam ais-rdi 5
host1(config-vc-class)#exit
! Configure VC class dsl-subscriber-class.
host1(config)#vc-class atm dsl-subscriber-class
host1(config-vc-class)#encapsulation aal5autoconfig
host1(config-vc-class)#ubr
host1(config-vc-class)#exit
host1(config)#
In premium-subscriber-class:
•
The encapsulation command sets the encapsulation method to aal5autoconfig.
•
The cbr command sets the service category to CBR with a PCR of 200 Kbps.
•
The oam-pvc command enables generation of F5 OAM loopback cells and F5 OAM
VC integrity.
•
The oam ais-rdi command configures the alarm down count for successive AIS and
RDI alarm cells to 5.
In dsl-subscriber-class:
•
The encapsulation command sets the encapsulation method to aal5autoconfig.
•
The ubr command configures the UBR service category without a PCR.
To configure an ATM VC class with systemwide default values, you can issue the vc-class
atm command followed immediately by the exit command. For example, the following
commands create a VC class named default-vc-class. Because no attribute values are
explicitly specified in default-vc-class, the router applies the default values for the
Copyright © 2010, Juniper Networks, Inc.
57
JunosE 11.3.x Link Layer Configuration Guide
commands listed in Table 8 on page 57. For information about the default value for each
command, see the command descriptions in this section.
! Configure VC class with default values.
host1(config)#vc-class atm default-subscriber-class
host1(config-vc-class)#exit
host1(config)#
To verify the VC class configuration, use the show atm vc-class command. For information
about how to use this command, see “show atm vc-class” on page 97.
cbr
•
Use to configure the CBR service category on an ATM data PVC.
•
For detailed information about how to use this command, see “cbr” on page 47.
•
You must issue the exit command from ATM VC Class Configuration mode for the
configuration to take effect.
•
Example
host1(config-vc-class)#cbr 15000
host1(config-vc-class)#exit
•
Use the no version to restore the default service category, UBR without a PCR.
•
See cbr.
•
Use to configure the encapsulation method on an ATM data PVC.
•
For detailed information about how to use this command, see “encapsulation” on
page 48.
•
You must issue the exit command from ATM VC Class Configuration mode for the
configuration to take effect.
•
Example
encapsulation
host1(config-vc-class)#encapsulation aal5mux ip
host1(config-vc-class)#exit
•
Use the no version to restore the default encapsulation method, aal5snap.
•
See encapsulation.
•
Use to enable Inverse ARP on an ATM PVC that resides on an ATM 1483 NBMA
subinterface and uses the default encapsulation method, aal5snap.
•
For detailed information about how to use this command, see “inarp” on page 52.
•
You must issue the exit command from ATM VC Class Configuration mode for the
configuration to take effect.
•
Example
inarp
host1(config-vc-class)#inarp 5
58
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
host1(config-vc-class)#exit
•
Use the no version to restore the default behavior, which disables Inverse ARP on the
router.
•
See inarp.
•
Use to configure surveillance parameters for AIS and RDI F5 OAM fault management
cells on an ATM data PVC.
•
For detailed information about how to use this command, see “oam ais-rdi” on page 50.
•
You must issue the exit command from ATM VC Class Configuration mode for the
configuration to take effect.
•
Example
oam ais-rdi
host1(config-vc-class)#oam ais-rdi 5 10
host1(config-vc-class)#exit
•
Use the no version to restore the default values for the alarm down count (1 successive
alarm cell) and alarm clear timeout duration (3 seconds).
•
See oam ais-rdi.
•
Use to enable F5 OAM CC verification on an ATM data PVC.
•
For detailed information about how to use this command, see “oam cc” on page 50.
•
You must issue the exit command from ATM VC Class Configuration mode for the
configuration to take effect.
•
Example 1—Enables CC verification with a source endpoint
oam cc
host1(config-vc-class)#oam cc source
host1(config-vc-class)#exit
•
Example 2—Opens an F5 OAM CC segment cell flow and enables CC verification with
a sink endpoint
host1(config-vc-class)#oam cc segment sink
host1(config-vc-class)#exit
•
Use the no version to disable F5 OAM CC verification and restore the default setting
for cell termination, end-to-end.
•
See oam cc.
•
Use to enable generation of F5 OAM loopback cells on an ATM data PVC and, optionally,
enable F5 OAM VC integrity features on the circuit.
•
For detailed information about how to use this command, see “oam-pvc” on page 51.
•
You must issue the exit command from ATM VC Class Configuration mode for the
configuration to take effect.
oam-pvc
Copyright © 2010, Juniper Networks, Inc.
59
JunosE 11.3.x Link Layer Configuration Guide
•
Example
host1(config-vc-class)#oam-pvc manage 15
host1(config-vc-class)#exit
•
Use the no version to restore the default behavior, which disables F5 OAM VC integrity
on the router and restores the default value for loopback frequency, 10 seconds.
•
See oam-pvc.
•
Use to configure F5 OAM VC integrity parameters on an ATM data PVC.
•
For detailed information about how to use this command, see “oam retry” on page 52.
•
You must issue the exit command from ATM VC Class Configuration mode for the
configuration to take effect.
•
Example
oam retry
host1(config-vc-class)#oam retry 5 6 3
host1(config-vc-class)#exit
•
Use the no version to restore the default values for the up retry count (3 successive
loopback cell responses), down retry count (5 successive loopback cell responses),
and retry frequency (1 second).
•
See oam retry.
•
Use to configure the UBR service category on an ATM data PVC.
•
For detailed information about how to use this command, see “ubr” on page 47.
•
You must issue the exit command from ATM VC Class Configuration mode for the
configuration to take effect.
•
Example
ubr
host1(config-vc-class)#ubr 5000
host1(config-vc-class)#exit
•
Use the no version to restore the default service category, UBR without a PCR.
•
See ubr.
•
Use to configure the VBR-NRT service category on an ATM data PVC.
•
For detailed information about how to use this command, see “vbr-nrt” on page 47.
•
You must issue the exit command from ATM VC Class Configuration mode for the
configuration to take effect.
•
Example
vbr-nrt
host1(config-vc-class)#vbr-nrt 50000 10000 150
host1(config-vc-class)#exit
60
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
•
Use the no version to restore the default service category, UBR without a PCR.
•
See vbr-nrt.
•
Use to configure the VBR-RT service category on an ATM data PVC.
•
For detailed information about how to use this command, see “vbr-rt” on page 48.
•
You must issue the exit command from ATM VC Class Configuration mode for the
configuration to take effect.
•
Example
vbr-rt
host1(config-vc-class)#vbr-rt 200000 30000 400
host1(config-vc-class)#exit
•
Use the no version to restore the default service category, UBR without a PCR.
•
See vbr-rt.
•
Use to create and name a VC class for an ATM data PVC.
•
You must specific a VC class name of up to 32 alphanumeric characters.
•
The vc-class atm command accesses ATM VC Class Configuration mode, from which
you can configure a set of attributes for the PVC including the service category,
encapsulation method, F5 OAM options, and Inverse ARP.
•
You must issue the exit command from ATM VC Class Configuration mode for the VC
class configuration to take effect.
•
For information about the total number of VC classes supported on the router, see
JunosE Release Notes, Appendix A, System Maximums.
•
Example
vc-class atm
host1(config)#vc-class atm dsl-subscriber-class
host1(config-vc-class)#exit
•
Use the no version to remove the named VC class from the router. You cannot remove
a VC class that is currently assigned to at least one ATM PVC, ATM 1483 subinterface,
or ATM major interface without first issuing the no class-vc command or the no
class-int command to remove the VC class association with the PVC, interface, or
subinterface.
•
See vc-class atm.
Assigning VC Classes to Individual PVCs
To assign a previously configured VC class to an individual ATM data PVC, you use the
class-vc command from ATM VC Configuration mode. Issuing this command applies
the set of attributes configured in the specified VC class to the ATM data PVC.
Copyright © 2010, Juniper Networks, Inc.
61
JunosE 11.3.x Link Layer Configuration Guide
NOTE: The class-vc command is valid only for a data PVC created with the
pvc command. It has no effect for data PVCs created with the atm pvc
command, or for control (ILMI) PVCs. For information about creating a data
PVC by using the pvc command, see “Creating Data PVCs” on page 45.
For example, the following commands assign the VC class named
premium-subscriber-class to the ATM data PVC with VCD 2, VPI 0, and VCI 200.
! Assign VC class premium-subscriber-class to PVC 2/0.200
host1(config)#interface atm 2/0.200
host1(config-subif)#pvc 200 0/200
host1(config-subif-atm-vc)#class-vc premium-subscriber-class
host1(config-subif-atm-vc)#exit
For those attributes that you do not explicitly specify for the ATM PVC, the router applies
the values specified in the VC class. As explained in “Precedence Levels” on page 54, the
values in a VC class assigned to an individual PVC take precedence over both of the
following:
•
Values in a VC class assigned to an ATM 1483 subinterface
•
Values in a VC class assigned to an ATM major interface
For examples that illustrate how precedence levels affect the assignment of VC classes,
see “Precedence Level Examples for Assigning VC Classes” on page 64.
class-vc
•
Use to assign a previously configured VC class to an individual ATM data PVC.
•
The class-vc command is valid only for data PVCs created with the pvc command.
•
You must issue the exit command from ATM VC Configuration mode for the VC class
association to take effect.
•
Example
host1(config-subif-atm-vc)#class-vc dsl-subscriber-class
host1(config-subif-atm-vc)#exit
•
Use the no version to remove the VC class association with the data PVC.
•
See class-vc.
Assigning VC Classes to ATM Major Interfaces
To assign a previously configured VC class to an ATM major interface, you use the class-int
command from Interface Configuration mode. Issuing this command applies the set of
attributes in the specified VC class to the ATM data PVCs statically or dynamically created
on this interface.
For example, the following commands assign the VC class named dsl-subscriber-class
to an ATM major interface configured on slot 5, port 0.
62
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
! Assign VC class dsl-subscriber-class to ATM interface 5/0.
host1(config)#interface atm 5/0
host1(config-if)#class-int dsl-subscriber-class
host1(config-if)#exit
For those attributes that you do not explicitly specify for an ATM PVC, the router applies
the values specified in the VC class. As explained in “Precedence Levels” on page 54, the
values in a VC class assigned to an ATM major interface have a lower precedence than
both of the following:
•
Values in a VC class assigned to an individual ATM PVC
•
Values in a VC class assigned to an ATM 1483 subinterface
This means that if a VC class is assigned to an individual PVC or ATM 1483 subinterface
configured on the major interface, the attribute values configured in the VC class assigned
to the PVC or subinterface override the attribute values configured in the VC class assigned
to the major interface.
For examples that illustrate how precedence levels affect the assignment of VC classes,
see “Precedence Level Examples for Assigning VC Classes” on page 64.
class-int
•
Use from Interface Configuration mode to assign a previously configured VC class to
an ATM major interface.
•
You must issue the exit command from Interface Configuration mode for the VC class
association to take effect.
•
Example
host1(config-if)#class-int gold-subscriber-class
host1(config-if)#exit
•
Use the no version to remove the VC class association with the interface. Issuing the
no version causes the router to set the PVC attributes to their systemwide default
values, or to the values set in the associated VC class with the next highest order of
precedence.
•
See class-int.
Assigning VC Classes to Static ATM 1483 Subinterfaces
To assign a previously configured VC class to a static ATM 1483 subinterface, you use
the class-int command from Subinterface Configuration mode. Issuing this command
applies the set of attributes in the specified VC class to the ATM data PVCs statically or
dynamically created on this subinterface.
For example, the following commands assign the VC class named
premium-subscriber-class to an ATM 1483 subinterface configured on slot 5, port 0,
subinterface 100.
! Assign VC class dsl-subscriber-class to ATM 1483 subinterface 5/0.100.
host1(config)#interface atm 5/0.100
host1(config-subif)#class-int premium-subscriber-class
Copyright © 2010, Juniper Networks, Inc.
63
JunosE 11.3.x Link Layer Configuration Guide
host1(config-subif)#exit
For those attributes that you do not explicitly specify for an ATM PVC, the router applies
the values specified in the VC class. As explained in “Precedence Levels” on page 54, the
values in a VC class assigned to an ATM 1483 subinterface take precedence over the
values in a VC class assigned to an ATM major interface, but have a lower precedence
than the values in a VC class assigned to an individual ATM PVC.
This means that if a VC class is assigned to a PVC configured on the subinterface, the
attribute values configured in the VC class assigned to the individual PVC override the
attribute values configured in the VC class assigned to the subinterface.
For examples that illustrate how precedence levels affect the assignment of VC classes,
see “Precedence Level Examples for Assigning VC Classes” on page 64.
class-int
•
Use from Subinterface Configuration mode to assign a previously configured VC class
to a static ATM 1483 subinterface.
•
You must issue the exit command from Subinterface Configuration mode for the VC
class association to take effect.
•
Example
host1(config-subif)#class-int silver-subscriber-class
host1(config-subif)#exit
•
Use the no version to remove the VC class association with the subinterface. Issuing
the no version causes the router to set the VC attributes to their systemwide default
values, or to the values set in the associated VC class with the next highest order of
precedence.
•
See class-int.
Assigning VC Classes to Base Profiles for Bulk-Configured VC Ranges
To assign a VC class to a base profile for a dynamic ATM 1483 subinterface, you can use
the atm class-vc command from Profile Configuration mode. Issuing this command
applies the set of attributes in the specified VC class to all bulk-configured VC ranges
that are dynamically created from this profile.
For more information, see “Configuring ATM 1483 Dynamic Subinterfaces” on page 624 in
“Configuring Dynamic Interfaces Using Bulk Configuration” on page 619.
Precedence Level Examples for Assigning VC Classes
The examples in this section illustrate how the precedence level rules described in
“Precedence Levels” on page 54 affect the assignment of VC classes and PVC attribute
values.
For all of these examples, assume that you have issued the following commands to
configure a VC class named my-premium-class:
host1(config)#vc-class atm my-premium-class
64
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
host1(config-vc-class)#encapsulation aal5autoconfig
host1(config-vc-class)#cbr 200
host1(config-vc-class)#oam-pvc manage 60
host1(config-vc-class)#oam ais-rdi 5
host1(config-vc-class)#exit
Example 1 and Example 2 illustrate the effect of precedence levels when you assign the
VC class my-premium-class to an individual PVC with VCD 200, VPI 0, and VCI 200.
Example 3 illustrates how using the atm pvc command affects VC class assignment.
Finally, Example 4 illustrates how modifications to a VC class affect PVC attributes
applied through RADIUS.
Example 1: Explicitly Changing the Service Category
Explicitly specified attribute values take precedence over attribute values specified in a
VC class. As a result, the following commands cause the router to use the most recent
explicitly specified value, UBR with a PCR of 200 Kbps, as the service category for this
PVC instead of the service category specified in my-premium-class, CBR with a PCR of
200 Kbps. The router takes the values for the other attributes from the VC class
my-premium-class.
host1(config)#interface atm 2/0.200
host1(config-subif)#pvc 200 0/200
host1(config-subif-vc)#ubr 200
host1(config-subif-vc)#class-vc my-premium-class
host1(config-subif-vc)#exit
The following commands change the service category for the PVC to VBR-RT because
this is the most recent explicitly specified value for this attribute. The router takes the
values for the other attributes from the VC class my-premium-class, which is still assigned
to the PVC.
host1(config)#interface atm 2/0.200
host1(config-subif)#pvc 200 0/200
host1(config-subif-vc)#vbr-rt 200 150 200
host1(config-subif-vc)#exit
The following commands cause the router to retain the VBR-RT service category for the
PVC because it is still the most recent explicitly specified value for this attribute. The
router takes the values for the other attributes from the VC class my-premium-class.
host1(config)#interface atm 2/0.200
host1(config-subif)#pvc 200 0/200
host1(config-subif-vc)#class-vc my-premium-class
host1(config-subif-vc)#exit
Example 2: Changing the Encapsulation Method in the VC Class
The following commands change the value for the encapsulation method in the VC class
my-premium-class from aal5autoconfig to aal5snap. As a result, the router now uses
aal5snap instead of aal5autoconfig as the encapsulation method for the PVCs to which
this VC class is assigned.
host1(config)#vc-class atm my-premium-class
host1(config-vc-class)#encapsulation aal5snap
host1(config-vc-class)#exit
Copyright © 2010, Juniper Networks, Inc.
65
JunosE 11.3.x Link Layer Configuration Guide
Example 3: Effect of Using the atm pvc Command
The following commands, which attempt to assign the my-premium-class VC class to
a PVC originally created with the atm pvc command, have no effect. The router interprets
all attribute values specified with the atm pvc command as explicitly specified values,
and therefore takes the values for these attributes from the atm pvc command instead
of from the VC class. As a result, the router continues to use aal5mux ip as the
encapsulation method for this PVC instead of the encapsulation method specified in the
VC class my-premium-class.
host1(config)#interface atm 2/0.300
host1(config-subif)#atm pvc 300 0 300 aal5mux ip
host1(config-subif)#pvc 300 0/300
host1(config-subif-vc)#class-vc my-premium-class
host1(config-subif-vc)#exit
Example 4: Overriding RADIUS Values
If RADIUS is configured to provide traffic parameters for PVCs, a more recent, explicitly
specified change in the VC class associated with that PVC overrides the PVC values
applied through RADIUS.
In the following example, assume that RADIUS has been configured to apply a service
category of CBR with a PCR of 400 Kbps to the PVC. Initially, the PVC uses the service
category configured in my-premium-class, CBR with a PCR of 200 Kbps. However, when
the subscriber logs in through RADIUS, the router applies the RADIUS-configured service
category, CBR with a PCR of 400 Kbps.
While the subscriber is still logged in, my-premium-class is modified to change the service
category to CBR with a PCR of 600 Kbps. Because this VC class modification results in
the most recent, explicitly specified value for the service category, the router now uses
CBR with a PCR of 600 Kbps as the service category for the PVC instead of the service
category configured through RADIUS.
host1(config)#interface atm 2/0.200
host1(config-subif)#pvc 200 0/200
host1(config-subif-vc)#class-vc my-premium-class
host1(config-subif-vc)#exit
! Subscriber logs in through RADIUS, which applies service category of CBR
! with a PCR of 400 Kbps to PVC.
host1(config)#vc-class atm my-premium-class
host1(config-vc-class)#cbr 600
host1(config-vc-class)#exit
! Router now applies service category of CBR with a PCR of 600 Kbps to PVC.
Configuring Dynamic ATM 1483 Subinterfaces
As an alternative to the static ATM interface configurations described in this chapter,
you can also configure dynamic ATM 1483 subinterfaces over static ATM AAL5 interfaces
over ATM. Dynamic ATM 1483 subinterfaces can perform autodetection and dynamic
creation of the following upper-layer encapsulation types:
66
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
•
Bridged Ethernet
•
IP
•
PPP
•
PPPoE
For details, see “Configuring ATM 1483 Dynamic Subinterfaces” on page 624 in “Configuring
Dynamic Interfaces Using Bulk Configuration” on page 619.
Monitoring ATM
This section explains how to set a statistics baseline, display bit rate and packet rate
statistics for ATM virtual circuits (VCs), and use the show commands to view your ATM
configuration and monitor ATM VCs and VPs.
NOTE: The E120 and E320 routers output for monitor and show commands
is identical to output from other E Series routers, except that the E120 and
E320 routers output also includes information about the adapter identifier
in the interface specifier (slot/adapter/port).
Setting Statistics Baselines
You can set a statistics baseline for ATM interfaces, ATM virtual circuits, and ATM virtual
paths configured on the router.
baseline atm vp interface
•
Use to set a statistics baseline for an ATM virtual path (VP) interface.
•
The router implements the baseline by reading and storing the statistics at the time
the baseline is set and then subtracting this baseline whenever baseline-relative
statistics are retrieved.
•
To set the baseline for an ATM VP, specify the VPI. The numeric range of the VPI
depends on the line module capabilities and current configuration.
•
To display baseline statistics, use the delta keyword with ATM show commands.
•
Examples
host1#baseline atm vp interface atm 12/0 0
host1#baseline atm vp interface atm 5/0/0 1
•
There is no no version.
•
See baseline atm vp interface.
•
Use to set a statistics baseline for ATM interfaces or a specific virtual circuit.
•
The router implements the baseline by reading and storing the statistics at the time
the baseline is set and then subtracting this baseline whenever baseline-relative
statistics are retrieved.
baseline interface atm
Copyright © 2010, Juniper Networks, Inc.
67
JunosE 11.3.x Link Layer Configuration Guide
•
To set the baseline for a circuit, specify a VCD in the range 1–2147483647.
•
To set the baseline on an interface, omit the VCD.
•
To display baseline statistics, use the delta keyword with ATM show commands.
•
Examples
host1#baseline interface atm 9/1 123
host1#baseline interface atm 5/0/0 123
•
There is no no version.
•
See baseline interface.
Displaying Interface Rate Statistics for ATM VCs and ATM VPs
You can use the following commands to display bit rate and packet rate statistics over
a specified time interval for one or more ATM virtual circuits (VCs) or virtual paths (VPs)
configured on the router.
•
To monitor the data rate for ATM VCs, use the monitor atm vc command.
•
To monitor the data rate for ATM VPs, use the monitor atm vp command.
To monitor the data rate for ATM VCs and ATM VPs:
1.
Log in to the router by using a local console session or a virtual terminal (vty) session
(such as a Telnet session).
While you use the monitor atm vc command or the monitor atm vp command, you
must keep the console or terminal session open. You cannot issue any other commands
during the session.
For information about logging in to the router, see section Accessing the CLI in JunosE
System Basics Configuration Guide.
2. Access User Exec mode or Privileged Exec mode.
For information, see section Accessing Command Modes in JunosE System Basics
Configuration Guide.
3. Specify the interface identifier and VCD (for each ATM VC) or VPI (for each ATM VP)
that you want to monitor. For information about specifying an ATM interface, see
Interface Types and Specifiers in JunosE Command Reference Guide.
host1#monitor atm vc atm 12/0 1 atm 8/0 1 display-time-of-day
host1#monitor atm vp atm 12/0 0 atm 12/0 1 load-interval 15 display-time-of-day
By default, the router uses a 5-second time interval between polls to calculate bit
rates and packet rates for each specified VC or VP. Optionally, you can use the
load-interval keyword to specify a nondefault time interval in the range 5–30 seconds
(for ATM VCs) or 5–300 seconds (for ATM VPs).
You can also include the optional display-time-of-day keyword to show the time of
day at which the router gathers statistics for each interval. Displaying the time of day
enables you to monitor when a particular VC or VP is underutilized or overutilized.
68
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
4. Review the command output.
host1#monitor atm vc atm 12/0 1 atm 8/0 1 display-time-of-day
Seconds
between
Time
Interface
VCD
polls
Input bps/pps
Output bps/pps (UTC)
--------------- ---- -------- --------------- --------------- -------ATM 12/0
1
0
--/---/-10:43:11
ATM 8/0
1
0
--/---/-10:43:11
ATM 12/0
1
5
121840/100
121840/100
10:43:16
ATM 8/0
5
121600/100
121600/100
10:43:16
ATM 12/0
1
5
98008/80
98008/80
10:43:21
ATM 8/0
1
5
98008/80
98008/80
10:43:21
...
host1#monitor atm vp atm 12/0 0 atm 12/0 1 load-interval 15 display-time-of-day
Seconds
between
Time
Interface
VPI
polls
Input bps/pps Output bps/pps
(UTC)
---------------- ----- -------- --------------- --------------- -------ATM 12/0
0
0
--/---/-09:47:18
ATM 12/0
1
0
--/---/-09:47:18
ATM 12/0
0
15
6635792/6480
6635792/6480
09:47:33
ATM 12/0
1
15
6635312/6479
6635312/6479
09:47:33
ATM 12/0
0
15
6635176/6479
6635176/6479
09:47:48
ATM 12/0
1
15
6634424/6478
6634424/6478
09:47:48
ATM 12/0
0
15
6635448/6479
6635448/6479
09:48:03
The monitor atm vc command and monitor atm vp command display similar
information, except that the monitor atm vc command displays the VCD for each
interface and the monitor atm vp command displays the VPI for each interface.
The router polls the statistics of each VC or VP identified in the command at the
specified load interval to calculate and display bit rate and packet rate statistics. The
first line of output for each interface always displays 0 (zero) for the number of seconds
between polls, and dashes (--/--) in the Input bps/pps and Output bps/pps columns.
These values indicate that the router initially takes a baseline for each interface against
which to measure subsequent statistics. The router continues to display subsequent
lines of output for each interface at the specified load interval until you press Ctrl+c
to stop the command.
For a description of the fields in the command display, see “monitor atm vc” on page 70
and “monitor atm vp” on page 70.
5. If you remove an ATM interface or (for VCs) an ATM 1483 subinterface while you are
monitoring one or more VCs or VPs that reside on the deleted interface, press Ctrl+c
to stop the monitor atm vc command or monitor atm vp command, and then restart
the command to ensure accurate interface rate statistics are displayed.
If you leave the monitor atm vc command or monitor atm vp command running after
you remove the interface, the command displays undefined or inaccurate statistics
for the VC or VP on the interface that has been removed. The display of undefined or
inaccurate statistics can result when you remove the interface by issuing either the
no interface atm command or slot erase command, and can continue even after you
recreate the interface with the same VC or VP configuration.
6. When you are finished monitoring, press Ctrl+c to stop the monitor atm vc command
or monitor atm vp command.
Copyright © 2010, Juniper Networks, Inc.
69
JunosE 11.3.x Link Layer Configuration Guide
host1#^C
monitor atm vc
monitor atm vp
•
Use the monitor atm vc command to display bit rate and packet rate statistics over a
specified time interval for one or more ATM VCs.
•
Use the monitor atm vp command to display bit rate and packet rate statistics over
a specified time interval for one or more ATM VPs.
•
You must use either command in a dedicated console or terminal session for the
duration of the monitoring session.
•
Specify the interface identifier and VCD (for each ATM VC) or VPI (for each ATM VP)
that you want to monitor.
•
To specify a nondefault time interval in the range 5–30 seconds (for ATM VCs) or
5–300 seconds (for ATM VPs) at which the router calculates bit rate and packet rate
statistics, use the optional load-interval keyword. The default time interval for either
command is 5 seconds.
•
To display the time at which the router calculates bit rate and packet rate statistics
for the current interval, use the optional display-time-of-day keyword.
•
To stop either command, press Ctrl+c.
•
Field descriptions
•
•
Interface—Interface identifier for the ATM interface on which the VC or VP resides
•
VCD—Virtual circuit descriptor that identifies the VC (monitor atm vc command
only)
•
VPI—Virtual path identifier of the PVC (monitor atm vp command only)
•
Seconds between polls—Number of seconds at which the router calculates bit rate
and packet rate statistics
•
Input bps/pps—Number of bits per second (bps) and packets per second (pps)
received on this interface during the specified load interval
•
Output bps/pps—Number of bits per second (bps) and packets per second (pps)
transmitted on this interface during the specified load interval
•
Time—Time of day, in hh:mm:ss format, at which the router calculates the bit rate
and packet rate statistics for the current interval
Example 1—Displays bit rate and packet rate statistics over the default (5-second)
load interval for a single ATM VC
host1#monitor atm vc atm 12/0 100
Seconds
between
Interface
VCD
polls
Input bps/pps Output bps/pps
------------------ ----- -------- --------------- --------------ATM 12/0
100
0
--/---/--
70
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
ATM 12/0
ATM 12/0
ATM 12/0
ATM 12/0
ATM 12/0
host1#^C
•
100
100
100
100
100
5
5
5
5
5
6631624/6476
6630808/6475
6632448/6477
6629168/6473
6631008/6475
6631624/6476
6631008/6475
6632240/6476
6629168/6473
6631216/6475
Example 2—Displays bit rate and packet rate statistics over the default (5-second)
load interval for two ATM VCs, with the time of day that the statistics were calculated
host1#monitor atm vc atm 12/0 100 atm 12/0 200 display-time-of-day
Seconds
between
Time
Interface
VCD
polls
Input bps/pps Output bps/pps
(UTC)
------------------ ----- -------- --------------- --------------- -------ATM 12/0
100
0
--/---/-- 17:33:06
ATM 12/0
200
0
--/---/-- 17:33:06
ATM 12/0
100
5
6635104/6479
6635104/6479 17:33:11
ATM 12/0
200
5
6633264/6477
6633472/6478 17:33:11
ATM 12/0
100
5
6632856/6477
6632856/6477 17:33:16
ATM 12/0
200
5
6633264/6477
6633056/6477 17:33:16
host1# ^C
•
Example 3—Displays bit rate and packet rate statistics over a 10-second load interval
for two ATM VPs
host1#monitor atm vp atm 12/0 0 atm 12/0 1 load-interval 10
Seconds
between
Interface
VPI polls
Input bps/pps Output bps/pps
----------------- ----- -------- --------------- --------------ATM 12/0
0
0
--/---/-ATM 12/0
1
0
--/---/-ATM 12/0
0
10
6635312/6479
6635312/6479
ATM 12/0
1
10
6634288/6478
6634288/6478
ATM 12/0
0
10
6637664/6482
6637664/6482
ATM 12/0
1
10
6637872/6482
6637872/6482
host1#^C
•
Example 4—Displays bit rate and packet rate statistics over a 15-second load interval
for two ATM VPs, with the time of day that the statistics were calculated
host1#monitor atm vp atm 12/0 0 atm 12/0 1 load-interval 15 display-time-of-day
Seconds
between
Time
Interface
VPI
polls
Input bps/pps Output bps/pps
(UTC)
----------------- ----- -------- --------------- --------------- -------ATM 12/0
0
0
--/---/-17:36:19
ATM 12/0
1
0
--/---/-17:36:19
ATM 12/0
0
15
6634352/6478
6634352/6478
17:36:34
ATM 12/0
1
15
6633608/6478
6633608/6478
17:36:34
ATM 12/0
0
15
6635176/6479
6635176/6479
17:36:49
ATM 12/0
1
15
6635040/6479
6635040/6479
17:36:49
host1# ^C
•
There is no no version.
•
See monitor atm vc.
•
See monitor atm vp.
Copyright © 2010, Juniper Networks, Inc.
71
JunosE 11.3.x Link Layer Configuration Guide
Using ATM show Commands
Use the show commands described in this section to display information about your
ATM configuration and monitor ATM interfaces.
You can use the output filtering feature of the show command to include or exclude lines
of output based on a text string you specify. See section show Commands in JunosE
System Basics Configuration Guide.
show atm aal5 interface
•
Use to display information about a configured ATM AAL5 interface.
•
Field descriptions
•
•
AAL5 Interface operational status—Operational status of the AAL5 interface: up,
down, lowerlayerDown
•
time since last status change—Time since last reported change to the AAL5 interface
operational status
•
SNMP trap link-status—Whether SNMP link status traps are enabled or disabled on
the ATM AAL5 interface
•
Auto configure ATM 1483 status—Setting of the autoconfiguration feature for a
dynamic ATM 1483 subinterface configured over the ATM AAL5 interface:
•
enabled—Autodetection of the ATM 1483 dynamic encapsulation type is enabled
on the ATM AAL5 interface
•
disabled—Autodetection of the ATM 1483 dynamic encapsulation type is not
currently enabled on the ATM AAL5 interface
•
InPackets—Number of packets received on this interface
•
InBytes—Number of bytes received on this interface
•
OutPackets—Number of packets transmitted on this interface
•
OutBytes—Number of bytes transmitted on this interface
•
InErrors—Number of incoming errors received on this interface
•
OutErrors—Number of outgoing errors on this interface
•
InPacketDiscards—Number of incoming packets discarded on this interface
•
OutDiscards—Number of outgoing packets discarded on this interface
Example
host1#show atm aal5 interface atm 3/0
AAL5 Interface ATM 3/0 operational status:
lowerLayerDown
time since last status change: 00:08:46
SNMP trap link-status: disabled
Auto configure ATM 1483 status: disabled
72
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
InPackets:
InBytes:
OutPackets:
OutBytes:
InErrors:
OutErrors:
InPacketDiscards:
OutDiscards:
0
0
0
0
0
0
0
0
•
See show atm aal5 interface.
•
Use to display whether or not the router is set up to export ATM 1483 subinterface
descriptions to the line module.
•
Example
show atm atm1483
host1#show atm atm1483
ATM1483 IF Descriptions exported
•
See show atm atm1483.
•
Use to display configuration and state information and statistics about a specific ATM
interface, or to display a brief description of all ATM interfaces configured in the router.
•
To specify an ATM interface for ERX7xx models, ERX14xx models, and ERX310 router,
use the slot/port format.
show atm interface
show interfaces atm
•
•
slot—Number of the chassis slot
•
port—Port number on the I/O module; on the OC3-2 GE APS I/O module, you can
specify ATM interfaces only in ports 0 and 1; port 2 is reserved for a Gigabit Ethernet
interface
To specify an ATM interface for the E120 and E320 routers, use the slot/adapter/port
format.
•
slot—Number of the chassis slot
•
adapter—Identifier for the IOA within the E320 chassis, either 0 or 1, where:
•
•
0 indicates that the IOA is installed in the right IOA bay (E120 router) or the upper
IOA bay (E320 router).
•
1 indicates that the IOA is installed in the left IOA bay (E120 router) or the lower
IOA bay (E320 router).
port—Port number on the IOA
•
To display the status and number of configured VCs for all ATM interfaces configured
in the router, use the brief keyword.
•
Field descriptions
Copyright © 2010, Juniper Networks, Inc.
73
JunosE 11.3.x Link Layer Configuration Guide
74
•
ATM Interface status—State of the physical interface: up, down
•
line protocol—State of the ILMI protocol: disabled, up, down
•
AAL5 operational status—Operational status of the ATM AAL5 interface: up, down,
lowerLayerDown
•
time since last status change—Time since last reported change to the AAL5
operational status
•
ATM operational status—Operational status of the ATM interface: up, down,
lowerLayerDown
•
time since last status change—Time since last reported change to the ATM
operational status
•
UNI version—UNI version: 3.0, 3.1, 4.0
•
Maximum VCs—Maximum number of virtual circuits supported on this interface
•
Current VCs—Current number of virtual circuits configured
•
ILMI VPI/VCI—Number of VPI and VCI configured for ILMI (displayed only when ILMI
is configured on the interface)
•
VCD—Number of VCD (displayed only when ILMI is configured on the interface)
•
ILMI keepalive—State and status of the ILMI (displayed only when ILMI is configured
on the interface)
•
Max VCI per VPI—Maximum number of virtual circuits on each virtual path
•
CAC admin state—Enabled, disabled
•
Subscription bandwidth—Maximum allowable bandwidth on the port (displayed
only when CAC is enabled)
•
UBR weight—Configured bandwidth for UBR and UBR-PCR connections (displayed
only when CAC is enabled)
•
Available bandwidth—Bandwidth currently available on the port (displayed only
when CAC is enabled)
•
SNMP trap link-status—Enabled, disabled
•
OAM cell receive status—Whether the ATM interface processes or flushes OAM cells:
enabled, disabled
•
OAM cell filter—Whether the interface flushes all OAM cells or flushes only AIS and
RDI alarm cells (displayed only when OAM cell receive status is enabled)
•
atm oam loopback-location—Loopback location ID for this interface
•
Interface Alias—Text description or alias if configured for the interface
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
•
•
Assigned VC Class—Name of the VC class assigned to this interface, if configured
•
InPackets—Number of packets received on this interface
•
InBytes—Number of bytes received on this interface
•
InCells—Number of cells received on this interface
•
OutPackets—Number of packets transmitted on this interface
•
OutBytes—Number of bytes transmitted on this interface
•
OutCells—Number of cells transmitted on this interface
•
InErrors—Number of incoming errors received on this interface
•
OutErrors—Number of outgoing errors on this interface
•
InPacketDiscards—Number of incoming packets discarded on this interface
•
InByteDiscards—Number of incoming bytes discarded on this interface
•
InCellErrors—Increments when a T3 or an E3 ATM interface receives cells for a VPI
or VCI that is not configured on that interface
Field descriptions specific to the applicable physical interface. In Example 1, the output
contains the following physical interface fields:
•
SONET path operational status—State of the SONET path interface: up, down,
lowerLayerDown
•
time since last status change—Time since last reported change to the SONET path
operational status
•
SONET operational status—State of SONET interface: up, down, lowerLayerDown
•
time since last status change—Time since last reported change to the SONET
operational status
•
PHY Type—Physical port type on which this interface is running
•
Framing—Framing type of the physical interface
•
TX clocking—Clocking type for the physical interface
•
Loopback—Loopback status for the physical interface: enabled, disabled
•
Receive FIFO Overruns—Number of times received FIFO was overrun
•
qos-mode-port—Status of SAR backpressure: enabled, disabled
•
queue—Hardware packet queue associated with the specified traffic class and
interface
•
Forwarded packets, Bytes—Number of packets and bytes forwarded on this queue
Copyright © 2010, Juniper Networks, Inc.
75
JunosE 11.3.x Link Layer Configuration Guide
•
•
Dropped committed packets, Bytes—Number of committed packets and bytes that
were dropped
•
Dropped conformed packets 0, Bytes 0—Number of conformed packets and bytes
that were dropped
•
Dropped exceeded packets 0, Bytes 0—Number of exceeded packets and bytes that
were dropped
•
Interface—ATM interface identifier
•
Status—Status of the ATM interface: up, down, lowerLayerDown
•
Configured VCs—Number of VCs configured on the interface
Example 1—Displays information about a specific interface
host1#show atm interface atm 2/0
ATM Interface 2/0 is down, line protocol is down
AAL5 operational status:
lowerLayerDown
time since last status change: 22:08:21
ATM operational status:
down
time since last status change: 22:02:11
SONET path operational status: lowerLayerDown
time since last status change: 1 day, 0 hours
SONET operational status:
down
time since last status change: 1 day, 0 hours
UNI version: 3.0, Maximum VCs: 4096
Current VCs: 1
ILMI VPI/VCI: 17/23, VCD 26, ILMI keepalive: disabled
Max VCI per VPI: 32768
CAC admin state: enabled
Subscription bandwidth: 3000000 kbps
UBR weight: 3000 kbps
Available bandwidth: 2992000 kbps
SNMP trap link-status: enabled
OAM cell receive status: enabled
OAM cell filter : all cells
atm oam loopback-location 0XFFFFFFFF
Interface Alias: ATM interface slot #2 port 0
Assigned VC class
: dsl-subscriber-class
PHY Type: oc3, Framing: sonet, TX clocking: line
Loopback: none, Receive FIFO Overruns: 0
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
InPackets:
InBytes:
InCells:
OutPackets:
OutBytes:
OutCells:
InErrors:
OutErrors:
InPacketDiscards:
InByteDiscards:
76
0
0
0
0
0
0
0
0
0
0
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
InCellErrors:
0
qos-mode-port disabled
queue 0: traffic class control, bound to ATM2/0
Forwarded packets 643, Bytes 36008
Dropped committed packets 0, Bytes 0
Dropped conformed packets 0, Bytes 0
Dropped exceeded packets 0, Bytes 0
•
Example 2—Shows a summary of all ATM interfaces
host1#show atm interface brief
Interface
--------ATM 2/0
ATM 2/1
ATM 2/2
ATM 2/3
ATM 4/0
ATM 6/0
Status
-------------up
up
lowerLayerDown
down
up
lowerLayerDown
Configured
VCs
---------2
3
4
5
2
2
•
See show atm interface.
•
See show interfaces.
•
Use to display the list of all configured ATM static maps to remote hosts on an ATM
network.
•
Field descriptions
show atm map
•
•
Map list—Name of map list and method used to enter the map list. PERMANENT
indicates that the map entry was configured; it was not entered automatically by a
process.
•
protocol address maps to VCx—Name of protocol, the protocol address, and the
VCD that the address is mapped to (for ATM VCs configured with the atm pvc
command).
•
VC—Number of the virtual circuit
•
broadcast—Indicates pseudo-broadcasting
•
connection up—Indicates a point-to-point virtual circuit
Example 1
host1#show atm map
Map list my-map : PERMANENT
ip 192.168.2.10 maps to VC 10
ip 192.168.2.20 maps to VC 11
ip 192.168.2.30 maps to VC 12
Map list other-map : PERMANENT
ip 192.10.2.10 maps to VC 100
ip 192.10.2.20 maps to VC 101
ip 192.10.2.30 maps to VC 102
•
atm 2/0
atm 2/0
atm 2/0
atm 2/1
atm 2/1
atm 2/1
broadcast
broadcast
Example 2
Copyright © 2010, Juniper Networks, Inc.
77
JunosE 11.3.x Link Layer Configuration Guide
host1#show atm map brief
Map list my-map : PERMANENT
Map list other-map : PERMANENT
•
Example 3
host1#show atm map my-map
Map list my-map : PERMANENT
ip 192.168.2.10 maps to VC 10 atm 2/0
ip 192.168.2.20 maps to VC 11 atm 2/0
ip 192.168.2.30 maps to VC 12 atm 2/0
broadcast
•
See show atm map.
•
Use to display F4 OAM statistics for an ATM interface.
•
You must specify a VPI value in addition to the required ATM interface specifier.
•
You can use the following keywords.
show atm oam
78
•
segment—Displays information about segment loopbacks
•
end-to-end—Displays information about end-to-end loopbacks
•
To see F4 OAM circuits that are open, use the show atm vc command.
•
Field descriptions
•
Sending End To End Loopback Cells—Enabled, disabled
•
Frequency—Frequency configured on this circuit
•
End To End OAM CC verification—Whether end-to-end CC verification is enabled or
disabled
•
OAM CC Type—Whether the circuit is a sink or a source, or both a sink and a source
•
OAM Current CC state
•
Ready—OAM CC is not enabled
•
Active—OAM CC cell flow is running
•
Activation Failed—OAM CC activation failed
•
Wait Activate—Waiting for interface to come up before the software sends the
activation request
•
Wait Activation Confirmation—Waiting for activation confirmation from the peer
•
Wait DeActivate—Waiting for interface to come up before the software sends the
deactivation request
•
Wait DeActivation Confirmation—Waiting for deactivation confirmation from the
peer
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
•
Segment OAM CC verification—Whether segment CC verification is enabled or
disabled
•
VP State—State of the VP: up, down
•
VP End To End Oam State
•
•
not managed—Circuit is in normal OAM state; no OAM fault conditions
•
AIS—Circuit is in AIS state
•
RDI—Circuit is in RDI state
VP Segment Oam State
•
not managed—Circuit is in normal OAM state; no OAM fault conditions
•
AIS—Circuit is in AIS state
•
RDI—Circuit is in RDI state
•
InOamF4Cells—Number of F4 OAM cells received
•
InOamF4CellsDropped—Number of incoming F4 OAM cells that were dropped
•
InOamF4EndLoopbackCells—Total number of F4 end-to-end loopback cells received
on this interface, which is the sum of the following counts:
•
•
InOamF4EndLoopbackCommands—Number of F4 end-to-end loopback
commands received
•
InOamF4EndLoopbackResponses—Number of F4 end-to-end loopback responses
received
InOamF4SegLoopbackCells—Total number of F4 segment loopback cells received
on this interface, which is the sum of the following counts:
•
InOamF4SegLoopbackCommands—Number of F4 segment loopback commands
received
•
InOamF4SegLoopbackResponses—Number of F4 segment loopback responses
received
•
InOamF4EndAisCells—Number of F4 end-to-end AIS cells received
•
InOamF4SegAisCells—Number of F4 segment AIS cells received
•
InOamF4EndRdiCells—Number of F4 end-to-end RDI cells received
•
InOamF4SegRdiCells—Number of F4 segment RDI cells received
•
InOamF4EndCCActDeActCells—Number of F4 end-to-end activation or deactivation
CC cells received
•
InOamF4SegCCActDeActCells—Number of F4 segment activation or deactivation
CC cells received
Copyright © 2010, Juniper Networks, Inc.
79
JunosE 11.3.x Link Layer Configuration Guide
•
InOamF4EndCCCells—Number of F4 end-to-end CC cells received
•
InOamF4SegCCCells—Number of F4 segment CC cells received
•
OutOamF4Cells—Number of F4 OAM cells sent
•
OutOamF4EndLoopbackCells—Total number of F4 end-to-end loopback cells sent
on this interface, which is the sum of the following counts:
•
•
•
OutOamF4EndLoopbackCommands—Number of F4 end-to-end loopback
commands sent
•
OutOamF4EndLoopbackResponses—Number of F4 end-to-end loopback
responses sent
OutOamF4SegLoopbackCells—Total number of F4 segment loopback cells sent on
this interface, which is the sum of the following counts:
•
OutOamF4SegLoopbackCommands—Number of F4 segment loopback commands
sent
•
OutOamF4SegLoopbackResponses—Number of F4 segment loopback responses
sent
•
OutOamF4EndRdiCells—Number of end-to-end RDI cells sent
•
OutOAM F4SegRdiCells—Number of segment RDI cells sent
•
OutOamF4EndCCActDeActCells—Number of F4 end-to-end activation or
deactivation CC cells sent
•
OutOamF4SegCCActDeActCells—Number of F4 segment activation or deactivation
CC cells sent
•
OutOamF4EndCCCells—Number of F4 end-to-end CC cells sent
•
OutOamF4SegCCCells—Number of F4 segment CC cells sent
Example 1
host1#show atm oam 2/1 0
Sending End To End Loopback Cells is Enabled: Frequency = 20 secs
End To End OAM CC verification enabled
OAM CC Type : CC Sink End Point
OAM Current CC state : Ready
Segment OAM CC verification enabled
OAM CC Type : CC Sink End Point
OAM Current CC state : Ready
VP State
:down
VP End To End Oam State
:not managed
VP Segment Oam State
:not managed
InOamF4Cells
:0
InOamF4CellsDropped
:0
InOamF4EndLoopbackCells
:0
InOamF4EndLoopbackCommands
:0
InOamF4EndLoopbackResponses
:0
InOamF4SegLoopbackCells
:0
InOamF4SegLoopbackCommands
:0
80
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
InOamF4SegLoopbackResponses
InOamF4EndAisCells
InOamF4SegAisCells
InOamF4EndRdiCells
InOamF4SegRdiCells
InOamF4EndCCActDeActCells
InOamF4SegCCActDeActCells
InOamF4EndCCCells
InOamF4SegCCCells
OutOamF4Cells
OutOamF4EndLoopbackCells
OutOamF4EndLoopbackCommands
OutOamF4EndLoopbackResponses
OutOamF4SegLoopbackCells
OutOamF4SegLoopbackCommands
OutOamF4SegLoopbackResponses
OutOamF4EndRdiCells
OutOamF4SegRdiCells
OutOamF4EndCCActDeActCells
OutOamF4SegCCActDeActCells
OutOamF4EndCCCells
OutOamF4SegCCCells
Time since last status change
•
:0
:0
:0
:0
:0
:0
:0
:0
:0
:0
:0
:0
:0
:0
:0
:0
:0
:0
:0
:0
:0
:0
:00:00:33
Example 2
host1#show atm oam 2/1 0 segment
Segment OAM CC verification enabled
OAM CC Type : CC Sink End Point
OAM Current CC state: Ready
VP State
:down
VP Oam State
:not managed
InOamF4SegmentCells
:0
InOamF4SegmentCellsDropped
:0
InOamF4SegLoopbackCells
:0
InOamF4SegLoopbackCommands
:0
InOamF4SegLoopbackResponses
:0
InOamF4SegCCActDeActCells
:0
InOamF4SegCCCells
:0
OutOamF4SegmentCells
:0
OutOamF4SegLoopbackCells
:0
OutOamF4SegLoopbackCommands
:0
OutOamF4SegLoopbackResponses
:0
OutOamF4SegRdiCells
:0
OutOamF4SegCCActDeActCells
:0
OutOamF4SegCCCells
:0
Time since last status change
:00:00:53
•
Example 3
host1#show atm oam 2/1 0 end-to-end
Sending End To End Loopback Cells Disabled:
End To End OAM CC verification enabled
OAM CC Type : CC Sink End Point
OAM Current CC state: Ready
VP State
:down
VP Oam State
:not managed
InOamF4EndCells
:0
InOamF4EndCellsDropped
:0
InOamF4EndLoopbackCells
:0
InOamF4EndLoopbackCommands
:0
Copyright © 2010, Juniper Networks, Inc.
81
JunosE 11.3.x Link Layer Configuration Guide
InOamF4EndLoopbackResponses
InOamF4EndAisCells :0
InOamF4EndRdiCells :0
InOamF4EndCCActDeActCells
InOamF4EndCCCells
OutOamF4EndCells
OutOamF4EndLoopbackCells
OutOamF4EndLoopbackCommands
OutOamF4EndLoopbackResponses
OutOamF4EndRdiCells
OutOamF4EndCCActDeActCells
OutOamF4EndCCCells
Time since last status change
:0
:0
:0
:0
:0
:0
:0
:0
:0
:0
:00:00:53
•
See show atm oam.
•
Use to show all existing ping entries, both completed and outstanding. Remember that
ping statistics are overwritten when a new ping is issued on the circuit.
•
You can specify the following options to show ping for entries for a specific interface,
VPI, or VCI.
show atm ping
•
82
•
interfaceSpecifier—Shows ping entries for this interface
•
vpi—Shows details of the last ping atm command on this VPI
•
vci—Shows details of the last ping atm command on this VCI
Field descriptions
•
Interface—Interface number
•
VPI—Virtual path identifier
•
VCI—Virtual channel identifier
•
CellCount—OAM loopback cell count configured on the interface
•
TimeOut—Timeout configured on the interface
•
SentCellCount—Number of loopback cells sent
•
RespCount—Number of loopback response cells received
•
Status—Status of the ping
•
Ping Cell Count—Cell count configured on the circuit
•
Ping Time Out—Timeout, in seconds, configured on the circuit
•
No Of Cells Sent—Number of ping cells sent on this circuit
•
No Of Response Received—Number of ping responses received on this circuit
•
Success Rate—Percentage of successful responses received for pings sent
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
•
round-trip min/max/avg—Minimum, maximum, and average time in milliseconds
that it took to receive responses to ping messages sent
•
Ping Status—Results of the ping operation
•
•
•
Ping Completed—Number of ping requests in the cell count were sent
•
Ping in Progress—Ping is in operation
•
Ping Not Started—Ping operation is not started; you may see this via SNMP
•
Ping Stopped—Ping operation was manually stopped
•
Ping Stopped OAM Down—atm oam flush command was issued when ping was
enabled
•
ATM Interface Down—Ping operation is stopped as a result of interface down
operational status
OAM Flow Type—Segment, End-to-end
Example 1—Displays all entries in the router
host1#show atm ping
Interface VPI VCI CellCount TimeOut SentCellCount RespCount Status
--------- --- --- --------- ------- ------------- --------- ------ATM 2/1
0
100
5
5
5
5
Ping Completed
ATM 2/1
0
200
5
5
5
5
Ping Completed
ATM 2/2
0
100
5
5
5
5
Ping Completed
ATM 2/2
0
200
5
5
5
5
Ping Completed
% Found 4 Entries in the system
•
Example 2—Displays entries on an interface
host1#show atm ping 2/1
Interface VPI VCI CellCount TimeOut
--------- --- --- --------- ------ATM 2/1
0
100
5
5
ATM 2/1
0
200
5
5
% Found 2 Entries in this Interface
•
SentCellCount RespCount
------------- ---------5
5
Ping
5
5
Ping
Status
------Completed
Completed
Example 3—Displays entries on a circuit
host1#show atm ping atm 2/1 0 100
Ping Cell Count
:5
Ping Time Out
:5secs
No Of Cells Sent
:5
No Of Response Received
:5
Success Rate
:100%
round-trip min/max/avg
:0/10/2 ms
Ping Status
:Completed
Oam Flow Type
:Segment
•
See show atm ping.
show atm subinterface
Copyright © 2010, Juniper Networks, Inc.
83
JunosE 11.3.x Link Layer Configuration Guide
•
Use to display the current state of all ATM subinterfaces, all ATM subinterfaces
configured on a specified ATM physical interface, or a specific ATM subinterface.
•
To specify an ATM subinterface for ERX7xx models, ERX14xx models, and ERX310
router, use the slot/port.subinterface format.
•
slot—Number of the chassis slot
•
port—Port number on the I/O module
•
subinterface—Number of the subinterface in the range 1–2147483647
To specify an ATM subinterface for the E120 and E320 routers, use the
slot/adapter/port.subinterface format.
•
slot—Number of the chassis slot
•
adapter—Identifier for the IOA within the E320 chassis, either 0 or 1, where:
•
0 indicates that the IOA is installed in the right IOA bay (E120 router) or the upper
IOA bay (E320 router).
•
1 indicates that the IOA is installed in the left IOA bay (E120 router) or the lower
IOA bay (E320 router).
•
port—Port number on the IOA
•
subinterface—Number of the subinterface in the range 1–2147483647
•
To display brief summary information for all ATM subinterfaces, or for ATM
subinterfaces configured on a specified ATM physical interface, use the summary
keyword.
•
To display status information only for ATM subinterfaces with a specific operating
status, use the status keyword with one of the following status values. (See the Status
field description for an explanation of these values.)
•
84
•
•
dormant
•
dormantLockout
•
down
•
lowerLayerDown
•
notPresent
•
up
To display the current state of an ATM subinterface created on the PVC with the
specified VPI and VCI values, use the atm slot/port/vpi/vci format (for ERX7xx models,
ERX14xx models, and ERX310 router) or the slot/adapter/port/vpi/vci format (for E120
and E320 routers) to identify the ATM subinterface (Example 5).
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
NOTE: You can use the atm slot/port/vpi/vci format as an alternative to
the atm slot/port.subinterface format with the specific show interface and
show subinterface commands to monitor all ATM 1483 subinterfaces
(except NBMA interfaces) as well as the upper-layer interfaces configured
over an ATM 1483 subinterface. You cannot, however, use the atm
slot/port/vpi/vci format to create or modify an ATM 1483 subinterface.
These guidelines also apply to E120 and E320 routers when you use the
atm slot/adapter/port/vpi/vci format as an alternative to the
atm slot/adapter/port.subinterface format.
•
For more information, see “Creating a Basic Configuration” on page 21.
•
Field descriptions
•
Interface—Interface identifier
•
ATM-Prot—One of the following ATM protocol types:
•
RFC-1483—Multiprotocol encapsulation over AAL5
•
NBMA—Nonbroadcast multiaccess interface
•
ATM/MPLS—Local ATM passthrough interface
•
VCD—Virtual circuit descriptor
•
VPI—Virtual path identifier
•
VCI—Virtual circuit (or channel) identifier
•
Circuit Type—Type of circuit: PVC
•
Encap—Administered encapsulation method based on what was configured with
the atm pvc command
•
MTU—Maximum transmission unit size for the interface
•
Status—One of the following ATM 1483 subinterface states:
•
absent—Represents the notPresent state and indicates that, although the SRP
detects the ATM 1483 subinterface, the module on which the subinterface resides
has not completed booting up, has failed, or is disabled.
•
dormant—Indicates that the ATM 1483 subinterface is performing autodetection
of one or more upper-layer encapsulation types and is waiting to receive a packet
of that type on a lower-layer interface. An ATM 1483 subinterface transitions from
the dormant state to the up state when the router receives a valid packet of the
specified encapsulation type on the interface.
•
dormantLockout—Indicates that a dormant ATM 1483 subinterface has one or
more upper-layer encapsulation types currently undergoing encapsulation type
lockout. An ATM 1483 subinterface transitions from the dormantLockout state to
Copyright © 2010, Juniper Networks, Inc.
85
JunosE 11.3.x Link Layer Configuration Guide
the dormant state when the lockout time expires for all upper-layer encapsulation
types undergoing lockout. An ATM 1483 subinterface transitions from the
dormantLockout state to the up state when the router receives a valid packet for
an encapsulation type that is configured for autodetection but is not undergoing
lockout.
86
•
down—Indicates that the ATM 1483 subinterface is administratively disabled or
has a circuit that is down or not configured.
•
lowerLayerDown—Indicates that a lower-layer interface below the ATM 1483
subinterface is down.
•
up—Indicates that the ATM 1483 subinterface is up and able to transfer data. For
an ATM 1483 subinterface that supports one or more dynamic upper-layer
interfaces, indicates that the router has created the dynamic upper-layer interface
or is in the process of creating it.
•
Interface Type—Type of ATM 1483 subinterface: dynamic or static
•
Auto configure status—Setting of the autoconfiguration feature
•
dynamic—Autodetection is on; the router automatically detects the next upper
interface
•
static—Autodetection is off
•
Auto configure interface(s)—Types of dynamic upper interfaces configured with the
auto-configure command: bridged Ethernet, IP, PPP, or PPPoE
•
Detected 1483 encapsulation—If the encapsulation type is set to aal5autoconfig,
displays the 1483 encapsulation type detected on the subinterface (displays AUTO
until a packet is detected)
•
Detected dynamic interface—Type of dynamic upper interface detected during
autoconfiguration: bridged Ethernet, IP, PPP, PPPoE, or (if no packet has been
received) none
•
Interface types in lockout—Encapsulation types currently experiencing lockout:
bridged Ethernet, IP, PPP, PPPoE, or none
•
Lockout state (seconds)—Settings of encapsulation type lockout for the upper-layer
encapsulation type indicated
•
Min—Minimum lockout time, in seconds
•
Max—Maximum lockout time, in seconds
•
Current—Current lockout time, in seconds; displays 0 (zero) if lockout is not
occurring
•
Elapsed—Time elapsed into the lockout time, in seconds; displays 0 (zero) if
lockout is not occurring
•
Next—Lockout time for the router to use for the next lockout event, in seconds
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
•
•
Assigned profile—For each dynamic interface type, indicates whether or not a profile
is assigned and, if assigned, displays the profile name
•
Interface Alias—Text description or alias if configured for the subinterface
•
Subscriber info—Subscriber login information for the specified dynamic interface
type (bridged Ethernet or IP)
•
Assigned VC Class—Name of the VC class assigned to this subinterface, if configure
•
SNMP trap link-status—Trap link status: enabled or disabled
•
Advisory receive speed—Configured receive speed, in Kbps, for the dynamic ATM 1483
subinterface. The E Series LAC sends this value to the LNS in the RX Connect-Speed
AVP [38].
•
InPackets—Number of packets received on this interface
•
InBytes—Number of bytes received on this interface
•
OutPackets—Number of packets transmitted on this interface
•
OutBytes—Number of bytes transmitted on this interface
•
InErrors—Number of errors received on this interface
•
OutErrors—Number of outgoing errors on this interface
•
InPacketDiscards—Number of incoming packets discarded on this interface
•
InPacketsUnknownProtocol—Number of incoming packets with an unknown protocol
type
•
OutDiscards—Number of outgoing packets discarded on this interface
Example 1—Displays the current state of all ATM subinterfaces
host1#show atm subinterface
Interface ATM-Prot
----------- -------ATM 2/0.101 RFC-1483
ATM 2/0.102 RFC-1483
ATM 2/0.103 RFC-1483
3 interface(s) found
•
Circuit
Interface
VCD VPI VCI Type Encap MTU
Status
Type
--- --- --- ----- ----- ---- -------------- --------101 0 101 PVC
AUTO 9180 dormantLockout Static
102 0 102 PVC
AUTO 9180 up
Dynamic
103 0 103 PVC
AUTO 9180 dormant
Static
Example 2—Displays summary information for all ATM subinterfaces shown in Example
1
host1#show atm subinterface summary
3 subinterfaces: 1 up, 0 down,
1 dormant, 1 dormantLockout,
0 lowerLayerDown, 0 not present
•
Example 3—Displays status information about the current state of all ATM subinterfaces
in the dormantLockout state
Copyright © 2010, Juniper Networks, Inc.
87
JunosE 11.3.x Link Layer Configuration Guide
host1#show atm subinterface status dormantLockout
Circuit
Interface
Interface ATM-Prot VCD VPI VCI Type Encap MTU
Status
Type
----------- -------- --- --- --- ----- ----- ---- ------------- --------ATM 2/0.101 RFC-1483 101 0 101 PVC
AUTO 9180 dormantLockout Static
1 interface(s) found
•
Example 4—Displays the current state of a specific ATM subinterface
host1#show atm subinterface atm 2/0.101
Circuit
Interface
Interface ATM-Prot VCD VPI VCI Type Encap MTU
Status
Type
----------- -------- --- --- --- ----- ----- ---- ------------ --------ATM 2/0.101 RFC-1483 101 0 101 PVC
AUTO 9180 dormantLockout Static
Auto configure status
:
Auto configure interface(s)
:
Detected 1483 encapsulation
:
Detected dynamic interface
:
Interface types in lockout
:
Lockout state (seconds)
:
------------------------------IP
BridgedEnet
PPP
PPPoE
dynamic
IP bridgedEthernet PPP PPPoE
AUTO
none
IP
Min Max Current Elapsed Next
--- ---- ------- ------- ---1
30
16
7
30
900 3600
0
0 900
1 300
0
0
1
1 300
0
0
1
Assigned
Assigned
Assigned
Assigned
Assigned
ipoa
beth
ppptest
pppoetest
none assigned
profile
profile
profile
profile
profile
(IP)
:
(BridgedEnet):
(PPP)
:
(PPPoE)
:
(any)
:
Interface Alias: atm20101
BridgedEnet subscriber info
:
Username: [email protected]
Password: putty
Authenticate: enabled
Assigned VC class
: premium-subscriber-class
SNMP trap link-status: disabled
InPackets:
InBytes:
OutPackets:
OutBytes:
InErrors:
OutErrors:
InPacketDiscards:
InPacketsUnknownProtocol:
OutDiscards:
1 interface(s) found
•
0
1904
0
0
0
0
14
0
0
Example 5—Displays the current state of a specific ATM subinterface created on the
PVC with the specified VPI and VCI values
host1#show atm subinterface atm 0/0/0/101
Circuit
Interface
Interface
ATM-Prot VCD VPI VCI Type
Encap MTU Status
Type
----------- -------- --- --- --- ------- ----- ---- ------ --------ATM 0/0.101 RFC-1483 101
0 101 PVC
AUTO 9180 up
Static
88
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
Auto configure status
Auto configure interface(s)
Detected 1483 encapsulation
Detected dynamic interface
Interface types in lockout
:
:
:
:
:
dynamic
PPPoE
SNAP
PPPoE
none
Lockout state (seconds)
: Min Max Current Elapsed Next
------------------------------- --- --- ------- ------- ---PPPoE
1 300
0
0
1
Assigned
Assigned
Assigned
Assigned
Assigned
profile
profile
profile
profile
profile
(IP)
:
(BridgedEnet):
(PPP)
:
(PPPoE)
:
(any)
:
none assigned
none assigned
none assigned
pppoeprofile
none assigned
Assigned VC class
: dsl-subscriber-class
SNMP trap link-status: disabled
Advisory receive speed: 2000
InPackets:
InBytes:
OutPackets:
OutBytes:
InErrors:
OutErrors:
InPacketDiscards:
InPacketsUnknownProtocol:
OutDiscards:
1 interface(s) found
5119
358672
5107
357510
0
0
3
0
0
•
See show atm subinterface.
•
Use to display a summary of all configured ATM virtual circuits (VCs) and reserved VC
ranges.
•
You can specify one or more of the following keywords individually or in combination:
show atm vc
•
vpi—Displays VCs on a specific VPI
•
category—Displays VCs that have a specific service category
•
status—Displays VCs with a certain status
•
You can also specify the reserved keyword with no other keywords to display only a
summary of all reserved VC ranges on the router. This includes VPI/VCI ranges reserved
for use by dynamic ATM 1483 subinterfaces and by MPLS.
•
Field descriptions
•
Interface—Interface number
•
VPI—Virtual path identifier
•
VCI—Virtual channel identifier
•
VCD—Virtual circuit descriptor
Copyright © 2010, Juniper Networks, Inc.
89
JunosE 11.3.x Link Layer Configuration Guide
•
•
Type—Type of circuit: PVC
•
Encap—Encapsulation method: AUTO, AAL5, AAL0, MUX, SNAP, ILMI, F4-OAM
•
Category—Service type configured on the VC: UBR, UBR-PCR, NRT-VBR, RT-VBR,
or CBR
•
Rx/Tx Peak—Peak rate, in Kbps
•
Rx/Tx Avg—Average rate, in Kbps
•
Rx/Tx Burst—Maximum number of cells that can be burst at the peak cell rate
•
Status—State of the virtual circuit: Up or Down
•
Start VPI—Starting virtual path identifier (inclusive) of the reserved VC range
•
Start VCI—Starting virtual circuit identifier (inclusive) of the reserved VC range
•
End VPI—Ending virtual path identifier (inclusive) of the reserved VC range
•
End VCI—Ending virtual circuit identifier (inclusive) of the reserved VC range
Example 1—Displays all VCs and reserved VC ranges on the router
host1#show atm vc
Interface
VPI VCI
------------ --- ---ATM 3/0.2
0 101
ATM 3/0.3
0 102
...
ATM 3/0.8099
1 8099
ATM 3/0.8100
1 8100
8000 circuit(s) found
Reserved VCC ranges:
VCD
---4375
4376
8099 PVC
8100 PVC
Start Start End
Interface VPI
VCI VPI
--------- ----- ----- --ATM 2/0
2
100
2
ATM 2/0
3
300
3
2 reservation(s) found
•
Type
---PVC
PVC
Encap
----AUTO
AUTO
Cate Rx/Tx Rx/Tx Rx/Tx Sta
gory Peak
Avg Burst tus
---- ----- ----- ----- --CBR
1000
0
0 UP
CBR
1000
0
0 DOWN
SNAP
SNAP
UBR
UBR
0
0
0
0
0 UP
0 DOWN
End
VCI
--102
303
Example 2—Displays VCs with a VPI of zero (0)
host1#show atm vc vpi 0
Cate Rx/Tx Rx/Tx Rx/Tx Sta
Interface
VPI VCI VCD Type Encap gory Peak
Avg Burst tus
------------ --- ---- ---- ---- ----- ---- ----- ----- ----- --ATM 3/0.2
0 101 4375 PVC AUTO CBR
1000
0
0 UP
ATM 3/0.3
0 102 4376 PVC AUTO CBR
1000
0
0 DOWN
2 circuit(s) found that match filter criteria
•
Example 3—Displays VCs with a VPI of 1 (one) that are assigned the service category
UBR
host1#show atm vc vpi 1 category ubr
Cate Rx/Tx Rx/Tx Rx/Tx Sta
90
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
Interface
VPI VCI VCD Type Encap gory Peak
Avg Burst tus
------------ --- ---- ---- ---- ----- ---- ----- ----- ----- --ATM 3/0.8099
1 8099 8099 PVC SNAP UBR
0
0
0 UP
ATM 3/0.8100
1 8100 8100 PVC SNAP UBR
0
0
0 DOWN
2 circuit(s) found that match filter criteria
•
Example 4—Displays VCs with a VPI of 0 (zero) and a service category of CBR that
have a status of up
host1#show atm vc vpi 0 category cbr status up
Cate Rx/Tx Rx/Tx Rx/Tx Sta
Interface
VPI VCI VCD Type Encap gory Peak
Avg Burst tus
------------ --- ---- ---- ---- ----- ---- ----- ----- ----- --ATM 3/0.2
0 101 4375 PVC AUTO CBR
1000
0
0 UP
1 circuit(s) found that match the filter criteria
•
Example 5—Displays all reserved VC ranges on the router
host1#show atm vc reserved
Reserved VCC ranges:
Start Start End
Interface VPI
VCI VPI
--------- ----- ----- --ATM 2/0
2
100
2
ATM 2/0
3
300
3
2 reservation(s) found
End
VCI
--102
303
•
See show atm vc.
•
Use to display information about a specific VC.
•
To specify the circuit to display, do one of the following:
show atm vc atm
•
•
Enter the VCD.
•
Use the vpi-vci keyword and enter the VPI and VCI.
•
Enter the description configured for the ATM 1483 subinterface (with the atm
atm1483 description command) on which the VC resides.
Field descriptions
•
VCD—Virtual circuit descriptor
•
VPI—Virtual path identifier
•
VCI—Virtual channel identifier
•
Encap—Encapsulation method
•
Service Type—Service type configured on the VC: UBR, UBR-PCR, NRT-VBR, RT-VBR,
CBR
•
Inverse ARP enable—Whether or not Inverse ARP is enabled: yes, no
•
Assigned VC class—Name of the VC class assigned to this VC, if configured
Copyright © 2010, Juniper Networks, Inc.
91
JunosE 11.3.x Link Layer Configuration Guide
•
InPackets—Number of packets received on this circuit
•
InBytes—Number of bytes received on this circuit
•
InCells—Number of ATM cells received on this circuit
•
OutPackets—Number of packets transmitted on this circuit
•
OutBytes—Number of bytes transmitted on this circuit
•
OutCells—Number of ATM cells transmitted on this circuit
•
InErrors—Number of errors received on this circuit
•
OutErrors—Number of outgoing errors on this circuit
•
InPacketDiscards—Number of incoming packets discarded on this circuit
•
InPacketUnknownProtocol—Number of incoming packets with an unknown protocol
type
•
InByteDiscards—Number of incoming bytes discarded on this circuit
•
CrcErrors—Number of CRC errors detected on this circuit
•
SAR time-outs—Number of segmentation and reassembly (SAR) timeouts reached
on this circuit
•
Over-sized SDUs—Number of oversized service data units (SDUs) received on this
circuit
•
Alarm drop count—Number of successive alarm cells that the router receives before
reporting that the PVC is down
•
Alarm clear timeout—Number of seconds that the router waits before reporting that
the PVC is up after the PVC stops receiving alarm cells
•
OAM VC verification—Whether OAM verification is enabled or disabled
•
OAM loopback cell status:
•
92
•
disabled—VC integrity disabled for VC
•
sent—OAM loopback cell sent; waiting for response
•
received—OAM loopback cell response received
•
failed—OAM loopback reply not received within frequency period, or reply contained
a bad correlation tag
OAM VC status:
•
AIS—VC is in AIS state
•
RDI—VC is in RDI state
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
•
Down Retry—OAM loopback failed; using retry frequency to verify that the VC is
really down
•
Down—OAM loopback failed after Down Retry verification
•
Up Retry—OAM loopback successful; using retry frequency to verify that the VC
is really up
•
Up—OAM loopback successful after Up Retry verification
•
Not Managed—VC integrity is not enabled; for more information about this status
value, see “Automatic Disabling of F5 OAM Services” on page 19
•
OAM loopback frequency—Frequency with which OAM loopback cells are transmitted
(when enabled), in seconds
•
OAM up retry count—Number of consecutive successfully looped OAM cells required
to mark the VC as Up
•
OAM down retry count—Number of consecutive unsuccessfully looped OAM cells
required to mark the VC as Down
•
OAM loopback retry frequency—Frequency with which OAM cells are transmitted in
verification mode, in seconds
•
OAM CC verification—Whether CC verification is enabled or disabled
•
OAM CC Type—Whether the VC is a sink or a source, or both sink and source end
point
•
OAM CC Flow Type—End-to-end or segment
•
OAM Current CC state
•
Ready—OAM CC is not enabled
•
Active—OAM CC cell flow is running
•
Activation Failed—OAM CC activation failed
•
Wait Activate—Waiting for interface to come up before the software sends the
activation request
•
Wait Activation Confirmation—Waiting for activation confirmation from the peer
•
Wait DeActivate—Waiting for interface to come up before the software sends the
deactivation request
•
Wait DeActivation Confirmation—Waiting for deactivation confirmation from the
peer
•
InOamF5Cells—Number of F5 OAM cells received on this circuit
•
InOamCellDiscards—Number of received OAM cells that were dropped; dropped
cells include unsupported and invalid F5 cells. The InOamCellDiscards counter is
Copyright © 2010, Juniper Networks, Inc.
93
JunosE 11.3.x Link Layer Configuration Guide
not incremented after an OAM flush is performed with the atm oam flush command.
For more information about the InOamCellDiscards counter, see “Rate Limiting for
F5 OAM Cells” on page 19.
•
•
•
InF5EndLoopCommands—Number of F5 end-to-end loopback commands received
•
InF5EndLoopResponses—Number of F5 end-to-end loopback responses received
InF5SegLoopCells—Total number of F5 segment loopback cells received on this
circuit, which is the sum of the following counts:
•
InF5SegLoopCommands—Number of F5 segment loopback commands received
•
InF5SegLoopResponses—Number of F5 segment loopback responses received
•
InF5EndAisCells—Number of F5 end-to-end AIS cells received on this circuit
•
InF5SegAisCells—Number of F5 segment AIS cells received on this circuit
•
InF5EndRdiCells—Number of F5 end-to-end RDI cells received on this circuit
•
InF5SegRdiCells—Number of F5 segment RDI cells received on this circuit
•
InF5EndCCActDeActCells—Number of F5 end-to-end activation and deactivation
CC cells received on this circuit
•
InF5SegCCActDeActCells—Number of F5 segment activation and deactivation CC
cells received on this circuit
•
InF5EndCCCells—Number of F5 end-to-end CC cells received on this circuit
•
InF5SegCCCells—Number of F5 segment CC cells received on this circuit
•
OutOamF5Cells—Number of F5 OAM cells transmitted on this circuit
•
OutF5EndLoopCells—Total number of F5 end-to-end loopback cells transmitted
on this circuit, which is the sum of the following counts:
•
•
94
InF5EndLoopCells—Total number of F5 end-to-end loopback cells received on this
circuit, which is the sum of the following counts:
•
OutF5EndLoopCommands—Number of F5 end-to-end loopback commands
transmitted
•
OutF5EndLoopResponses—Number of F5 end-to-end loopback responses
transmitted
OutF5SegLoopCells—Total number of F5 segment loopback cells transmitted on
this circuit, which is the sum of the following counts:
•
OutF5SegLoopCommands—Number of F5 segment loopback commands
transmitted
•
OutF5SegLoopResponses—Number of F5 segment loopback responses transmitted
OutF5EndRdiCells—Number of F5 end-to-end RDI cells transmitted on this circuit
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
•
•
OutF5SegRdiCells—Number of F5 segment RDI cells transmitted on this circuit
•
OutF5EndCCActDeActCells—Number of F5 end-to-end activation and deactivation
CC cells transmitted on this circuit
•
OutF5SegCCActDeActCells—Number of F5 segment activation and deactivation
CC cells transmitted on this circuit
•
OutF5EndCCCells—Number of F5 end-to-end CC cells transmitted on this circuit
•
OutF5SegCCCells—Number of F5 segment CC cells transmitted on this circuit
•
Circuit is Up/Down—Status of the circuit and time since the status of the circuit last
changed
Example 1—Displays statistics for the VC with a VPI of 46 and a VCI of 47
host1#show atm vc atm 2/0 vpi-vci 46 47
ATM 2/0.1.1: VCD: 45, VPI: 46, VCI: 47, Encap: AAL5-AUTO
Service Type: Ubr
Inverse ARP enable:No
Assigned VC class :premium-subscriber-class
InPackets:
0
InBytes:
0
InCells:
0
OutPackets:
0
OutBytes:
0
OutCells:
0
InErrors:
0
OutErrors:
0
InPacketDiscards: 0
InPacketUnknownProtocol: 0
InByteDiscards:
0
CrcErrors:
0
SAR time-outs:
0
Over-sized SDUs:
0
Alarm drop count: 1
Alarm clear timeout:3
OAM VC verification: enabled
OAM loopback cell status: sent
OAM VC status: up
OAM loopback frequency: 10 second interval
OAM up retry count: 3, OAM down retry count: 5
OAM loopback retry frequency: 1 second interval
OAM CC verification: disabled
InOamF5Cells:
258
InOamCellDiscards: 12598
InF5EndLoopCells: 258
InF5EndLoopCommands:
50
InF5EndLoopResponses:
208
InF5SegLoopCells: 46
InF5SegLoopCommands:
17
InF5SegLoopResponses:
29
InF5EndAisCells:
49
InF5SegAisCells:
0
InF5EndRdiCells:
0
InF5SegRdiCells:
0
InF5EndCCActDeActCells: 0
InF5SegCCActDeActCells: 0
InF5EndCCCells:
0
Copyright © 2010, Juniper Networks, Inc.
95
JunosE 11.3.x Link Layer Configuration Guide
InF5SegCCCells:
0
OutOamF5Cells:
258
OutF5EndLoopCells: 258
OutF5EndLoopCommands:
OutFEndLoopResponses:
OutF5SegLoopCells: 48
OutF5SegLoopCommands:
OutF5SegLoopResponses:
OutF5EndRdiCells:
50
OutF5SegRdiCells:
0
OutF5EndCCActDeActCells:1
OutF5SegCCActDeActCells:0
OutF5EndCCCells:
1
OutF5SegCCCells:
0
208
50
19
29
Circuit is Up, time since last change: 5 days, 23 hours
•
Example 2—Displays statistics for the VC that resides on the ATM 1483 subinterface
configured with the specified description (myAtm301)
host1#show atm vc myAtm301
ATM3/0.1: VCD: 10, VPI: 5, VCI: 100, Encap: SNAP
Service Type: Ubr
Assigned VC class
:dsl-subscriber-class
InPackets:
0
InBytes:
0
InCells:
0
OutPackets:
0
OutBytes:
0
OutCells:
0
InErrors:
0
OutErrors:
0
InPacketDiscards:
0
InPacketUnknownProtocol:
0
InByteDiscards:
0
CrcErrors:
0
SAR time-outs:
0
Over-sized SDUs:
0
Alarm drop count:
1
Alarm clear timeout:
3
OAM VC verification:
disabled
OAM VC status:
not managed
OAM CC verification:
disabled
InOamF5Cells:
0
InOamCellDiscards:
384723
InF5EndLoopCells:
0
InF5EndLoopCommands:
0
InF5EndLoopResponses:
0
InF5SegLoopCells:
0
InF5SegLoopCommands:
0
InF5SegLoopResponses:
0
InF5EndAisCells:
0
InF5SegAisCells:
0
InF5EndRdiCells:
0
InF5SegRdiCells:
0
InF5EndCCActDeActCells:
0
InF5SegCCActDeActCells:
0
InF5EndCCCells:
0
InF5SegCCCells:
0
OutOamF5Cells:
0
OutF5EndLoopCells:
0
96
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
OutF5EndLoopCommands:
OutFEndLoopResponses:
OutF5SegLoopCells:
OutF5SegLoopCommands:
OutF5SegLoopResponses:
OutF5EndRdiCells:
OutF5SegRdiCells:
OutF5EndCCActDeActCells:
OutF5SegCCActDeActCells:
OutF5EndCCCells:
OutF5SegCCCells:
0
0
0
0
0
0
0
0
0
0
0
Circuit is DOWN, time since last change: 02:25:52
•
See show atm vc atm.
•
Use to display information about the VC classes configured on the router.
•
To display only the names of all VC classes configured on the router, use the command
with no keywords.
•
To display detailed configuration information about a particular VC class, specify the
name of the VC class.
•
To display the settings for parameters in the VC class that are configured with default
values, use the include-defaults keyword.
•
Field descriptions
show atm vc-class
•
Encapsulation Type—Encapsulation method configured in the VC class: AUTO, AAL5,
AAL0, MUX, SNAP
•
Service Category—Service category configured in the VC class: UBR, UBR-PCR,
NRT-VBR, RT-VBR, CBR
•
Peak Cell Rate—Peak cell rate (PCR), in Kbps, configured for the service category
•
OAM VC Integrity—Status of F5 OAM VC integrity features on the PVC: enabled or
disabled
•
OAM VC Integrity loop-back timer—Number of seconds the router waits between
the transmission of loopback cells during normal operation
•
OAM VC Integrity Up Retry Count—Number of successive loopback cell responses
that the router receives before reporting that a PVC is up
•
OAM VC Integrity Down Retry Count—Number of successive loopback cell responses
that the router misses before reporting that a PVC is down
•
OAM VC Integrity Retry Frequency—Number of seconds that the router waits between
the transmission of loopback cells when it is verifying the state of a PVC
•
OAM alarm down count—Number of successive alarm cells that the router receives
before reporting that a PVC is down
Copyright © 2010, Juniper Networks, Inc.
97
JunosE 11.3.x Link Layer Configuration Guide
•
•
OAM alarm clear time out—Number of seconds that the router waits before reporting
that a PVC is up after the PVC has stopped receiving alarm cells
•
OAM continuity check—Status of F5 OAM continuity check verification on the PVC:
enabled or disabled
•
Inverse ARP—Status of Inverse ARP (InARP) on the PVC: enabled or disabled
Example 1
host1#show atm vc-class
premium-subscriber-class
dsl-subscriber-class
found 2 VC class entrie(s) in the system
•
Example 2
host1#show atm vc-class premium-subscriber-class
Encapsulation Type
:AUTO
Service Category
:CBR
Peak Cell Rate
:200 kbps
OAM VC Integrity
:enabled
OAM VC Integrity loop-back timer
:60 seconds
OAM alarm down count
:5
•
Example 3
host1#show atm vc-class premium-subscriber-class include-defaults
Encapsulation Type
:AUTO
Service Category
:CBR
Peak Cell Rate
:200 kbps
OAM VC Integrity
:enabled
OAM VC Integrity loop-back timer
:60 seconds
OAM VC Integrity Up Retry Count
:3
OAM VC Integrity Down Retry Count
:5
OAM VC Integrity Retry Frequency
:1
OAM alarm down count
:5
OAM alarm clear time out
:3 seconds
OAM continuity check
:disabled
Inverse ARP
:disabled
•
See show atm vc-class.
•
Use to display detailed statistics for a specific ATM VP configured on the router.
•
Field descriptions
show atm vp
98
•
ServiceCategory—Service type on the VP tunnel, if configured: UBR, UBR-PCR,
VBR-NRT, VBR-RT, or CBR
•
Peak Cell Rate—Peak cell rate in kilobits per second, if a VP tunnel is configured
•
Maximum VCI per VPI—Maximum number of virtual circuits on each virtual path
•
Current VCs—Number of VCs currently configured on the router
•
InPackets—Number of packets received
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
•
InBytes—Number of bytes received
•
InCells—Number of ATM cells received
•
OutPackets—Number of packets transmitted
•
OutBytes—Number of bytes transmitted
•
OutCells—Number of ATM cells transmitted
•
InErrors—Number of packets with errors received
•
OutErrors—Number of packets not transmitted on this VP due to errors
•
InPacketDiscards—Number of incoming packets discarded
•
InPacketUnknownProtocol—Number of incoming packets with an unknown protocol
type
•
InByteDiscards—Number of incoming bytes discarded
•
CrcErrors—Number of CRC errors detected
•
SAR time-outs—Number of segmentation and reassembly (SAR) timeouts reached
•
Over-sized SDUs—Number of oversized service data units (SDUs) received
•
The following fields appear only if F4 OAM is enabled on the VP:
•
Sending End to End Loopback Cells—Enabled, Disabled
•
End to End OAM CC verification—Enabled, Disabled
•
VP State—State of the VP: up, down
•
VP Oam State—OAM state of the VP: not managed (normal OAM state with no
OAM fault conditions), AIS, RDI
•
InOamF4EndCells—Number of F4 end-to-end cells received
•
InOamF4EndCellsDropped—Number of incoming F4 end-to-end cells that were
dropped
•
InOamF4EndLoopbackCells—Number of F4 end-to-end loopback cells received
•
InOamF4EndLoopbackCommands—Number of F4 end-to-end loopback
commands received
•
InOamF4EndLoopbackResponses—Number of F4 end-to-end loopback responses
received
•
InOamF4EndAisCells—Number of F4 end-to-end AIS cells received
•
InOamF4EndRdiCells—Number of F4 end-to-end RDI cells received
Copyright © 2010, Juniper Networks, Inc.
99
JunosE 11.3.x Link Layer Configuration Guide
100
•
InOamF4EndCCActDeActCells—Number of F4 end-to-end activation or
deactivation CC cells received
•
InOamF4EndCCCells—Number of F4 end-to-end CC cells received
•
OutOamF4EndCells—Number of F4 end-to-end CC cells transmitted
•
OutOamF4EndLoopbackCells—Number of F4 end-to-end loopback cells
transmitted
•
OutOamF4EndLoopbackCommands—Number of F4 end-to-end loopback
commands transmitted
•
OutOamF4EndLoopbackResponses—Number of F4 end-to-end loopback
responses transmitted
•
OutOamF4EndRdiCells—Number of F4 end-to-end RDI cells transmitted
•
OutOamF4EndCCActDeActCells—Number of F4 end-to-end activation or
deactivation CC cells transmitted
•
OutOamF4EndCCCells—Number of F4 end-to-end CC cells transmitted
•
Time since last status change—Time since last reported change to the end-to-end
OAM circuit status
•
Segment OAM CC verification—Enabled or Disabled
•
VP State—State of the VP: up, down
•
VP Oam State—OAM state of the VP: not managed (normal OAM state with no
OAM fault conditions), AIS, RDI
•
InOamF4SegmentCells—Number of F4 segment cells received
•
InOamF4SegmentCellsDropped—Number of incoming F4 segment cells that were
dropped
•
InOamF4SegmentLoopbackCells—Number of F4 segment loopback cells received
•
InOamF4SegmentLoopbackCommands—Number of F4 segment loopback
commands received
•
InOamF4SegmentLoopbackResponses—Number of F4 segment loopback
responses received
•
InOamF4SegCCActDeActCells—Number of F4 segment activation or deactivation
CC cells received
•
InOamF4SegCCCells—Number of F4 segment CC cells received
•
OutOamF4SegmentCells—Number of F4 segment cells transmitted
•
OutOamF4SegmentLoopbackCells—Number of F4 segment loopback cells
transmitted
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
•
•
•
OutOamF4SegmentLoopbackCommands—Number of F4 segment loopback
commands transmitted
•
OutOamF4SegmentLoopbackResponses—Number of F4 segment loopback
responses transmitted
•
OutOamF4SegRdiCells—Number of F4 segment RDI cells transmitted
•
OutOamF4SegCCActDeActCells—Number of F4 segment activation or deactivation
CC cells transmitted
•
OutOamF4SegCCCells—Number of F4 segment CC cells transmitted
•
Time since last status change—Time since last reported change to the segment
OAM circuit status
VP Description—Text description for this VP, if configured
Example
host1#show atm vp atm 12/0 1
Maximum VCI per VPI: 65535
Current VCs: 3
InPackets
:1604710953
InBytes
:205403001984
InCells
:519165564
OutPackets
:1604632002
OutBytes
:205392896256
OutCells
:4813896006
InErrors
:0
OutErrors
:0
InPacketDiscards
:0
InPacketUnknownProtocol
:0
InByteDiscards
:0
CrcErrors
:0
SAR time-outs
:0
Over-sized SDUs
:0
Sending End To End Loopback Cells Disabled:
End To End OAM CC verification Disabled
VP State
:up
VP Oam State
:not managed
InOamF4EndCells
:0
InOamF4EndCellsDropped
:0
InOamF4EndLoopbackCells
:0
InOamF4EndLoopbackCommands
:0
InOamF4EndLoopbackResponses
:0
InOamF4EndAisCells
:0
InOamF4EndRdiCells
:0
InOamF4EndCCActDeActCells
:0
InOamF4EndCCCells
:0
OutOamF4EndCells
:0
OutOamF4EndLoopbackCells
:0
OutOamF4EndLoopbackCommands
:0
OutOamF4EndLoopbackResponses
:0
OutOamF4EndRdiCells
:0
OutOamF4EndCCActDeActCells
:0
OutOamF4EndCCCells
:0
Time since last status change
:08:48:43
Segment OAM CC verification Disabled
VP State
:up
Copyright © 2010, Juniper Networks, Inc.
101
JunosE 11.3.x Link Layer Configuration Guide
VP Oam State
:not managed
InOamF4SegmentCells
:0
InOamF4SegmentCellsDropped
:0
InOamF4SegmentLoopbackCells
:0
InOamF4SegmentLoopbackCommands
:0
InOamF4SegmentLoopbackResponses :0
InOamF4SegCCActDeActCells
:0
InOamF4SegCCCells
:0
OutOamF4SegmentCells
:0
OutOamF4SegmentLoopbackCells
:0
OutOamF4SegmentLoopbackCommands :0
OutOamF4SegmentLoopbackResponses :0
OutOamF4SegRdiCells
:0
OutOamF4SegCCActDeActCells
:0
OutOamF4SegCCCells
:0
Time since last status change
:08:48:44
VP Description: ATM-12/0-VPI-1
•
See show atm vp.
•
Use to display VP descriptions configured using the atm vp-description command.
•
To display all VP descriptions configured on the router, issue the command without
an ATM identifier or VPI number (Example 1).
•
To display all VP descriptions for a particular ATM interface, specify the ATM interface
identifier without the VPI number (Example 2).
•
To display the VP description for a particular VPI, specify both the ATM interface
identifier and the VPI number (Example 3).
•
Field descriptions
show atm vp-description
•
•
Interface—ATM interface identifier
•
VPI—Virtual path identifier
•
Description—Text description configured for the VP
Example 1—Displays all VP descriptions configured on the router
host1#show atm vp-description
Interface
VPI
Description
ATM 2/0
0
atm20Vpi0Subscribers
ATM 2/0
1
atm20Vpi1Subscribers
ATM 2/1
0
atm21Vpi0Subscribers
•
Example 2—Displays all VP descriptions for the specified ATM interface
host1#show atm vp-description atm 2/0
Interface
VPI
Description
ATM 2/0
0
atm20Vpi0Subscribers
ATM 2/0
1
atm20Vpi1Subscribers
•
102
Example 3—Displays the VP description for the specified VPI
Copyright © 2010, Juniper Networks, Inc.
Chapter 1: Configuring ATM
host1#show atm vp-description atm 2/0 1
Interface
VPI
Description
ATM 2/0
1
atm20Vpi1Subscribers
•
See show atm vp-description.
•
Use to display a summary of all configured ATM virtual path tunnels.
•
Field descriptions
show atm vp-tunnel
•
•
Intfc—Interface number
•
VPI—Virtual path identifier
•
Type—VP tunnel traffic management type
•
Kbps—Rate, in Kbps
•
Description—Text description for the VP, if configured
Example
host1#show atm vp-tunnel 9/1
Intfc
VPI Type Kbps
ATM 9/1 2
Cbr
4096
•
Description
atm91Vpi2Subscribers
See show atm vp-tunnel.
show mpls cross-connects atm
•
Use to display all ATM cross-connects (passthrough connections between local
subinterfaces).
•
See section Monitoring ATM Cross-Connects for Layer 2 Services over MPLS in JunosE
BGP and MPLS Configuration Guide for information about using the show mpls
cross-connects atm command.
•
See show mpls cross-connects atm.
•
Use to display ARP table entries for ATM NBMA interfaces.
•
Field descriptions
show nbma arp
•
•
IP Address—IP address of the entry
•
VPI/VCI—VPI and VCI of the entry
•
Interface—Interface specifier of the entry
Example
host1#show nbma arp
NBMA ARP Table Entries
IP Address
VPI/VCI
1.1.1.2
0/100
2.2.2.2
0/101
Copyright © 2010, Juniper Networks, Inc.
Interface
4/1
4/1
103
JunosE 11.3.x Link Layer Configuration Guide
•
104
See show nbma arp.
Copyright © 2010, Juniper Networks, Inc.
CHAPTER 2
Configuring Frame Relay
This chapter describes how to configure a Frame Relay interface on E Series routers.
This chapter contains the following sections:
•
Overview on page 105
•
Platform Considerations on page 107
•
References on page 108
•
Before You Configure Frame Relay on page 108
•
Configuring Frame Relay on page 108
•
End-to-End Fragmentation and Reassembly on page 116
•
Monitoring Frame Relay on page 120
Overview
Frame Relay is a public, connection-oriented packet service based on the core aspects
of the Integrated Services Digital Network (ISDN). Frame Relay eliminates all processing
at the network layer and greatly restricts data-link layer processing. Such simplified
processing is possible because of the availability of virtually error-free physical connections
and the presence of intelligent protocols at the end-user site, which can detect and
retransmit faulty or discarded packets.
Frame Relay shifts responsibility for error recovery and flow control to the end user,
thereby reducing protocol complexity and allowing high-speed packet delivery with low
transit delay.
For a list of the modules on which you can configure Frame Relay, see ERX Module Guide,
Appendix A, Module Protocol Support.
Framing
E Series routers support the following framing features:
•
HDLC for data-link framing
•
2-byte addresses only
Copyright © 2010, Juniper Networks, Inc.
105
JunosE 11.3.x Link Layer Configuration Guide
•
8188-byte information field size (8192 minus 2 bytes for the address and a 16-bit CRC)
or 8186-byte information field size (8192 minus 2 bytes for the address and a 32-bit
CRC)
The router does not support:
•
Protocol-dependent fragmentation
•
Autodetection of the Local Management Interface (LMI) protocol type
Error Frames
The router relies on higher-layer protocols to detect and recover from Frame Relay data
loss. All Frame Relay error frames are discarded.
Unicast and Multicast Addressing
Most Frame Relay services support both unicast (individual) and multicast (group)
addressing. Under the most common implementation of multicasting, the Frame Relay
network maps multiple individual addresses to a single multicast data-link connection
identifier (DLCI) and delivers copies of a single Frame Relay packet to each member of
the group.
NOTE: The E Series router supports only unicast addressing.
User-to-Network and Network-to-Network Interfaces
The Frame Relay User-to-Network Interface (UNI) is a protocol that permits users to
access private or public Frame Relay networks and to establish a communications path
to another user within the same network.
The Network-to-Network Interface (NNI) makes connections possible between users
connected to different Frame Relay networks. These separate Frame Relay networks
can be considered as subnetworks within a complete network service.
Figure 4 on page 107 shows the interconnection of these types of subnetworks and the
location of NNI between them.
106
Copyright © 2010, Juniper Networks, Inc.
Chapter 2: Configuring Frame Relay
Figure 4: Interconnection and Relationship of NNIs and Subnetworks
Platform Considerations
You can configure Frame Relay interfaces on the following E Series Broadband Services
Routers:
•
ERX1440 router
•
ERX1410 router
•
ERX710 router
•
ERX705 router
•
ERX310 router
NOTE: The E120 and E320 Broadband Services Routers do not support
configuration of Frame Relay interfaces.
Module Requirements
For information about the modules that support Frame Relay interfaces on ERX14xx
models, ERX7xx models, and the ERX310 router:
•
See ERX Module Guide, Table 1, Module Combinations for detailed module specifications.
•
See ERX Module Guide, Appendix A, Module Protocol Support for information about the
modules that support Frame Relay.
Interface Specifiers
The interface specifier format that you use depends on the type of physical interface on
which you want to configure Frame Relay.
Copyright © 2010, Juniper Networks, Inc.
107
JunosE 11.3.x Link Layer Configuration Guide
For more information about supported interface types and specifiers on E Series routers,
see Interface Types and Specifiers in JunosE Command Reference Guide.
References
For more information about Frame Relay, consult the following resources:
•
RFC 2115—Management Information Base for Frame Relay DTEs Using SMIv2
(September 1997)
•
RFC 2863—The Interfaces Group MIB (June 2000)
•
RFC 2427—Multiprotocol Interconnect over Frame Relay (September 1998)
•
Frame Relay Forum—User-to-Network Implementation Agreement (UNI), FRF 1.1
(January 1996)
•
Frame Relay Forum—Frame Relay Fragmentation Implementation Agreement, FRF.12
(December 1997)
•
ANSI T1.617 Annex D
•
ITU-T Recommendation Q.922, Integrated Services Digital Network (ISDN) Data Link
Layer Specification for Frame Mode Bearer Services; Annex A (February 1992)
•
ITU-T Q.933 Annex A
Before You Configure Frame Relay
Before you attempt to configure a Frame Relay interface, configure the physical line
interface over which Frame Relay traffic flows.
This process is described in the following chapters:
•
Chapter Configuring Channelized T3 Interfaces in JunosE Physical Layer Configuration
Guide
•
Chapter Configuring T3 and E3 Interfaces in JunosE Physical Layer Configuration Guide
The procedures described in this chapter assume that a physical interface has been
configured.
Configuring Frame Relay
Configure a Frame Relay interface by entering Interface Configuration mode. The
procedure that follows is an example of a Frame Relay configuration on a serial interface.
All tasks are mandatory unless otherwise noted.
To configure a Frame Relay interface:
1.
From Configuration mode, enter the physical interface on which you want to configure
Frame Relay.
host1(config)#interface serial 3/1:2/1
108
Copyright © 2010, Juniper Networks, Inc.
Chapter 2: Configuring Frame Relay
2. Select Frame Relay as the encapsulation method for the interface.
host1(config-if)#encapsulation frame-relay ietf
3. (Optional) Assign a text description or an alias to the major interface.
host1(config-if)#frame-relay description boston01
4. (Optional) Enable SNMP link status processing on the major interface.
host1(config-if)#snmp trap frame-relay link-status
5. Configure the interface as a DTE, DCE, or NNI.
host1(config-if)#frame-relay intf-type dte
6. Configure the LMI type.
host1(config-if)#frame-relay lmi-type ansi
7. (Optional) Configure Frame Relay counters and timers.
host1(config-if)#frame-relay lmi-n391dte 20
8. Configure the cyclic redundancy check (CRC).
host1(config-if)#crc 32
9. Create a subinterface.
host1(config)#interface serial 3/1:2/1.1
10. (Optional) Assign a text description or an alias to the subinterface.
host1(config-subif)#frame-relay description westford011
11. (Optional) Enable SNMP link status processing on the subinterface.
host1(config-subif)#snmp trap frame-relay link-status
12. Add a circuit to a subinterface.
host1(config-subif)#frame-relay interface-dlci 17 ietf
13. Assign a local IP address to the circuit.
host1(config-subif)#ip address 192.32.10.2 255.255.255.0
14. (Optional) Use show commands to verify that your configuration changes are correct
by checking the state of the interfaces.
host1#show frame-relay lmi
host1#show frame-relay map
host1#show frame-relay pvc
15. (Optional) Disable the local management interface.
host1#no frame-relay keepalive
16. (Optional) Disable the interface.
host1(config-if)#shutdown
crc
Copyright © 2010, Juniper Networks, Inc.
109
JunosE 11.3.x Link Layer Configuration Guide
•
Use to set the number of bits used for CRC.
•
The CRC is an error-checking technique that uses a calculated numeric value to detect
errors in transmitted data.
•
16 and 32 indicate the number of bits per frame that are used to calculate the frame
check sequence (FCS).
•
A 32-bit CRC transmits longer streams at faster rates and therefore provides better
ongoing error detection, such as for an OC12/STM4 POS module.
•
The default is 16. You must configure CRC (CRC16 or CRC32) to match the configuration
on the other side of the Frame Relay connection.
•
Example
host1(config-if)#crc 32
•
Use the no version to set the CRC to the default value.
•
See crc.
encapsulation frame-relay ietf
•
Use to specify Frame Relay as the encapsulation method for the interface.
•
The router uses IETF format (RFC 2427 encapsulation).
•
Example
host1(config-if)#encapsulation frame-relay ietf
•
Use the no version to remove Frame Relay configuration from an interface.
•
See encapsulation frame-relay ietf.
•
Use to assign a text description or an alias to a Frame Relay interface or subinterface.
•
You can use this command to help you identify the interface and keep track of interface
connections.
•
The description or alias can be a maximum of 80 characters.
•
Use “show frame-relay interface” on page 121 or “show frame-relay subinterface” on
page 127 to display the text description.
•
Examples
frame-relay description
host1(config-if)#frame-relay description boston01
host1(config-subif)#frame-relay description toronto011
•
Use the no version to remove the text description or alias.
•
See frame-relay description.
frame-relay interface-dlci ietf
110
•
Use to configure a Frame Relay permanent virtual circuit (PVC) over a subinterface.
•
The ietf keyword is mandatory and indicates RFC 2427 encapsulation.
Copyright © 2010, Juniper Networks, Inc.
Chapter 2: Configuring Frame Relay
•
Define a DLCI in the range 16–1007.
•
To configure a Frame Relay PVC, you must specify a DLCI.
•
Frame Relay service is offered in the form of PVCs. A PVC is a data-link connection
that is predefined on both ends of the connection. A network operator assigns the
endpoints of the circuit. Although the actual path taken through the network may vary
from time to time, the beginning and end of the circuit do not change. This type of
circuit behaves like a dedicated point-to-point circuit.
•
PVCs are identified by DLCIs. A DLCI is a 10-bit channel number that is attached to
data frames to tell a Frame Relay network how to route the data. Frame Relay is
statistically multiplexed, which means that only one frame can be transmitted at a
time, but many logical connections can coexist on a single physical line. The DLCI
allows the data to be logically tied to one of the connections, so that when the data
gets to the network, the network knows where to send it.
•
DLCIs on the same physical line must match. However, DLCIs have local significance;
that is, if the DLCIs are not on the same physical line, the end devices at two different
ends of a connection may use a different DLCI to refer to the same connection.
•
The router does not support switched virtual circuits (SVCs). An SVC is an any-to-any
connection that can be established or removed as needed. With SVCs, you initiate calls
using Frame Relay by requesting a destination address and assigning a DLCI, which is
established for the duration of the call.
•
Example
host1(config-subif)#frame-relay interface-dlci 17 ietf
•
Use the no version to remove DLCI/PVC assignment.
•
See frame-relay interface-dlci ietf.
•
Use to configure a Frame Relay interface circuit to operate as data communications
equipment (DCE), data terminal equipment (DTE), or NNI.
•
Frame Relay provides packet-switching data communications between user devices
and network equipment across the interface. User devices are referred to as DTE.
•
Network equipment that interfaces with a DTE is referred to as a DCE.
•
NNI provides a connection between two Frame Relay subnetworks.
•
If your router is connected to a Frame Relay switch, configure the interface as a DTE.
If your router is connected by a point-to-point line, configure one end as the DTE and
the other as the DCE.
•
Example
frame-relay intf-type
host1(config-if)#frame-relay intf-type dte
•
Use the no version to set the default of DTE.
•
See frame-relay intf-type.
frame-relay keepalive
Copyright © 2010, Juniper Networks, Inc.
111
JunosE 11.3.x Link Layer Configuration Guide
•
Use to enable the LMI on the interface.
•
You can specify the keepalive interval in seconds.
•
Make sure the value on the DTE is less than the value set on the DCE.
•
The default is 10 seconds.
•
Example
host1#no frame-relay keepalive
•
Use the no version to disable LMI on the interface.
•
See frame-relay keepalive.
•
Use to configure LMI counters and timers.
•
LMI counters and timers have configurable ranges that allow you to control the state
of the Frame Relay interface. In general, accept the default values for the timers and
counters, unless you need to modify them according to a special arrangement with
your customers.
•
Some commands have DTE and DCE versions. Use the dte version of the command if
the interface is operating as a DTE. Use the dce version of the command if the interface
is operating as a DCE. Use both versions of the command if the interface is operating
as an NNI.
•
Use the frame-relay lmi-n391dte command to set the N391 full-status polling counter.
When you set this counter to a number, n, the nth request is a full-status request. The
range is 1–255 event messages. The default is 6 event messages.
•
Use the frame-relay lmi-n392dte or frame-relay lmi-n392dce command to set the
N392 error threshold counter, which specifies the number of errors within N393 events
that will place the interface in an operationally down state. The range is 1–10. The
default for the DTE version is 3. The default for the DCE version is 2.
•
Use the frame-relay lmi-n393dte or frame-relay lmi-n393dce command to set the
N393 monitored events counter to specify the diagnostic window used to verify link
integrity. Detection of N392 errors within the window of N393 samples places the
interface in an operationally down state. The range is 1–10 events. The default for the
DTE version of the command is 4 events. The default for the DCE version is 2 events.
•
Use the frame-relay lmi-t391dte command to set the T391 link integrity polling timer
interval between status inquiries issued by the DTE. The network checks that the DTE
frame-relay lmi-n391dte
frame-relay lmi-n392dce
frame-relay lmi-n392dte
frame-relay lmi-n393dce
frame-relay lmi-n393dte
frame-relay lmi-t391dte
frame-relay lmi-t392dce
112
Copyright © 2010, Juniper Networks, Inc.
Chapter 2: Configuring Frame Relay
polls within the verification interval, T392. The range is 5–30 seconds. The default is
10 seconds.
•
Use the frame-relay lmi-t392dce command to set the T392 polling verification timer
that specifies the maximum interval (in seconds) between the receipt of status inquiries
from the DTE equipment before it considers it as an error event. The range is 5–30
seconds. The default is 15 seconds.
•
Example
host1(config-if)#frame-relay lmi-n391dte 20
•
Use the no version to remove the current setting and set the default.
•
See frame-relay lmi-n391dte.
•
See frame-relay lmi-n392dce.
•
See frame-relay lmi-n392dte.
•
See frame-relay lmi-n393dce.
•
See frame-relay lmi-n393dte.
•
See frame-relay lmi-t391dte
•
See frame-relay lmi-t392dce
•
Use to configure one of the local management interface types.
•
LMI provides configuration and status information relating to the virtual circuits
operating over Frame Relay.
•
LMI specifies polling mechanisms to receive incremental and full-status updates from
the network.
•
E Series routers conform to the following LMI specifications:
frame-relay lmi-type
•
ansi—ANSI T1.617 Annex D
•
q933a—ITU-T Q.933 Annex A
•
cisco—Original Group of Four specification developed by DEC, Northern Telecom,
Stratacom, and Cisco
•
none—Suppresses LMI
•
The default is cisco.
•
Example
host1(config-if)#frame-relay lmi-type ansi
•
Use the no version to return to the default LMI type.
•
See frame-relay lmi-type.
•
Use to configure a POS interface in slot/port format:
interface pos
Copyright © 2010, Juniper Networks, Inc.
113
JunosE 11.3.x Link Layer Configuration Guide
•
•
slot—Router chassis slot
•
port—Line module port
Example
host1(config)#interface pos 0/1
•
Use the no version to remove the POS interface.
•
See interface pos.
•
Use to configure a serial interface in the appropriate format by selecting a previously
configured physical interface on which you want to configure Frame Relay. For example,
for a channelized T3 interface use slot/port:channel/subchannel.
•
Use to configure a Frame Relay subinterface in the appropriate format by selecting a
previously configured physical interface. For example, for a T3-Frame interface use
slot/port.subinterface ; for a channelized T1/channelized E1 interface use
slot/port.channel-group.subinterface.
interface serial
NOTE: Before you configure Frame Relay, see the appropriate chapter in
this guide for details on configuring physical interfaces.
•
•
slot—Router chassis slot
•
port—CT3, T3, or E3 module I/O port
•
channel—T1 (DS1) channel
•
subchannel—Set of DS0 timeslots. See section Fractional T1 in JunosE Physical Layer
Configuration Guide
•
subinterface—User-assigned nonnegative number that identifies a Frame Relay
subinterface
Example
host1(config-if)#interface serial 3/1:2/1.1
•
Use the no version to remove the subinterface or the serial interface.
•
See interface serial.
•
Use to assign an IP address and subnet mask to a subinterface.
•
Example
ip address
host1(config-subif)#ip address 192.32.10.2 255.255.255.0
114
•
Use the no version to remove an IP address or to disable IP processing.
•
See ip address.
Copyright © 2010, Juniper Networks, Inc.
Chapter 2: Configuring Frame Relay
pos description
•
Use to assign a text description or an alias to a POS HDLC interface.
•
You can use this command to help you identify the interface and keep track of interface
connections.
•
The description or alias can be a maximum of 80 characters.
•
Use “show interfaces pos” on page 367 to display the text description. For details, see
“Monitoring POS” on page 366 in “Configuring Packet over SONET” on page 359.
•
Example
host1(config-if)#pos description austin01 pos interface
•
Use the no version to remove the text description or alias.
•
See pos description.
•
Use to assign a text description or an alias to a serial HDLC interface.
•
You can use this command to help you identify the interface and keep track of interface
connections.
•
The description or alias can be a maximum of 80 characters.
•
Use the show interfaces serial command to display information about the serial
interfaces you configured. For more information about the descriptions of the fileds
displayed in the output of this command, see the show interfaces serial section in JunosE
Physical Layer Configuration Guide. For example, for a channelized T3 interface, see
the Monitoring Interfaces section in JunosE Physical Layer Configuration Guide.
•
Example
serial description
host1(config-if)#serial description ottawa012 hdlc channel
•
Use the no version to remove the text description or alias.
•
See serial description.
•
Use to disable a Frame Relay interface.
•
Example
shutdown
host1(config-if)#shutdown
•
Use the no version to restart a disabled interface.
•
See shutdown.
snmp trap frame-relay link-status
•
Use to enable SNMP link status processing for a Frame Relay major interface or
subinterface.
•
To enable SNMP link status processing for a Frame Relay major interface, you must
issue the command from Interface Configuration mode.
Copyright © 2010, Juniper Networks, Inc.
115
JunosE 11.3.x Link Layer Configuration Guide
•
To enable SNMP link status processing for a Frame Relay subinterface, you must issue
the command from Subinterface Configuration mode.
•
Examples
host1(config-if)#snmp trap frame-relay link-status
host1(config-subif)#snmp trap frame-relay link-status
•
Use the no version to disable SNMP link status processing for a Frame Relay major
interface or subinterface.
•
See snmp trap frame-relay link-status.
End-to-End Fragmentation and Reassembly
The fragmentation and reassembly feature reduces excessive delays of Frame Relay
packets by breaking them up into smaller fragments and interleaving them with real-time
frames. By doing this, real-time and non-real-time data frames can be carried together
on lower-speed links without causing excessive delays to the real-time traffic. On receiving
the smaller fragments by the peer interface, the fragments are reassembled into their
original packet. For example, short delay-sensitive packets, such as packetized voice,
can race ahead of larger delay-insensitive packets, such as common data packets.
E Series routers support end-to-end fragmentation according to the FRF.12
Implementation Agreement standard. Unlike UNI and NNI fragmentation, end-to-end
supports fragmentation only at the endpoints. End-to-end fragmentation and reassembly
are supported only on non-multilink Frame Relay interfaces on cOC12/STM4 and CT3 12
FO modules.
You configure end-to-end fragmentation at the Frame Relay subinterface level.
Fragmentation is applied to all PVCs associated with the subinterface. In most cases,
fragmentation and reassembly are used together. Fragmentation and reassembly,
however, can be configured separately for each map class.
For additional information, see Frame Relay Forum—Frame Relay Fragmentation
Implementation Agreement, FRF.12 (December 1997).
Frame Fragmentation
When you enable fragmentation, you can specify a maximum payload size of the resulting
fragments. If the maximum payload size is not specified, the default value of 52 bytes is
used. When enabled, fragmentation begins when the portion of the packet that has not
been transmitted in previous fragments exceeds the configured maximum payload size.
The fragmentation process continues until the entire packet has been transmitted. Frames
that do not exceed the configured maximum payload size are not fragmented.
If you disable fragmentation, all packets transmitted by the Frame Relay subinterface
are transmitted intact.
Frame Reassembly
When reassembly is disabled and a data frame is received, a few scenarios may occur:
116
Copyright © 2010, Juniper Networks, Inc.
Chapter 2: Configuring Frame Relay
•
If the frame is not a fragment, it is forwarded normally.
•
If the frame is a fragment and the upper interface is IP (that is, the interface above the
Frame Relay subinterface), then the fragment is immediately discarded.
If you enable reassembly, then received fragments undergo the reassembly process.
Packets that are not fragments are forwarded as normal.
Map Class
Within Frame Relay, a map class acts as a container or context for fragmentation and
reassembly parameters. Within the map class context, you can explicitly enable
fragmentation and reassembly.
After you define a map class, you can apply it to an unlimited number of subinterfaces.
This allows you to change fragmentation and reassembly parameters one time and have
the changes immediately reflected in all subinterfaces configured to use that map class.
Configuring End-to-End Fragmentation
You configure end-to-end fragmentation and reassembly on a subinterface in much the
same way you configure a standard Frame Relay interface. In this example, end-to-end
fragmentation and reassembly is configured on a single subinterface with a 100-byte
fragment size (maximum payload size). All tasks are mandatory unless otherwise noted.
NOTE: The procedure described in this section assumes that a physical
interface has been configured. See “Before You Configure Frame Relay” on
page 108.
To configure end-to-end fragmentation and reassembly:
1.
Create a map class that you can apply to subinterfaces.
host1(config)#map-class frame-relay testmap
2. Specify fragmentation and reassembly for the map class. Optionally, you can specify
the maximum payload size of a fragment.
host1(config-map-class)#frame-relay fragment 100
3. Enter the physical interface on which you want to configure Frame Relay end-to-end
fragmentation and reassembly.
host1(config-map-class)#interface serial 5/0:4/1
4. Select Frame Relay as the encapsulation method for the interface.
host1(config-if)#encapsulation frame-relay ietf
5. Create a subinterface.
host1(config-if)#interface serial 5/0:4/1.1
6. Add a circuit to a subinterface.
host1(config-subif)#frame-relay interface-dlci 16 ietf
Copyright © 2010, Juniper Networks, Inc.
117
JunosE 11.3.x Link Layer Configuration Guide
7. Assign a local IP address to the circuit.
host1((config-subif)#ip address 42.42.42.41 255.255.255.0
8. Associate a map class with a subinterface.
host1(config-subif)#frame-relay class testmap
encapsulation frame-relay ietf
•
Use to specify Frame Relay as the encapsulation method for the interface.
•
The router uses IETF format (RFC 2427 encapsulation).
•
Example
host1(config-if)#encapsulation frame-relay ietf
•
Use the no version to remove Frame Relay configuration from an interface.
•
See encapsulation frame-relay ietf.
•
Use to associate a map class with a subinterface.
•
Example
frame-relay class
host1(config-subif)#frame-relay class testmap
•
Use the no version to remove the association between the subinterface and the
specified map class from the subinterface.
•
See frame-relay class.
•
Use to configure fragmentation and reassembly for the map class.
•
Specify the keyword fragmentation-only to specify only fragmentation, so that
reassembly is not performed.
•
Specify the keyword reassembly-only to specify only reassembly, so that fragmentation
is not performed.
•
Specify the maximum payload size of a fragment by using a value from 16–8188 bytes.
If a value is not specified, the default value of 52 bytes is used.
•
Make sure the value for the maximum payload size of a fragment is less than or equal
to the MTU size, otherwise fragmentation never occurs.
•
Make sure the maximum payload size is larger than any voice packet so that voice
frames are not fragmented.
•
Examples
frame-relay fragment
host1(config-map-class)#frame-relay fragment 100
host1(config-map-class)#frame-relay fragment fragmentation-only
118
•
Use the no version to stop fragmentation and reassembly on the subinterface.
•
See frame-relay fragment.
Copyright © 2010, Juniper Networks, Inc.
Chapter 2: Configuring Frame Relay
frame-relay interface-dlci ietf
•
Use to configure a Frame Relay PVC over a subinterface.
•
The ietf keyword is mandatory and indicates RFC 2427 encapsulation.
•
Define a DLCI in the range 16–1007.
•
To configure a Frame Relay PVC, you must specify a DLCI.
•
Frame Relay service is offered in the form of PVCs. A PVC is a data-link connection
that is predefined on both ends of the connection. A network operator assigns the
endpoints of the circuit. Although the actual path taken through the network may vary
from time to time, the beginning and end of the circuit do not change. This type of
circuit behaves like a dedicated point-to-point circuit.
•
PVCs are identified by DLCIs. A DLCI is a 10-bit channel number that is attached to
data frames to tell a Frame Relay network how to route the data. Frame Relay is
statistically multiplexed, which means that only one frame can be transmitted at a
time, but many logical connections can coexist on a single physical line. The DLCI
allows the data to be logically tied to one of the connections, so that when the data
gets to the network, the network knows where to send it.
•
DLCIs on the same physical line must match. However, DLCIs have local significance;
that is, if the DLCIs are not on the same physical line, the end devices at two different
ends of a connection may use a different DLCI to refer to the same connection.
•
The router does not support SVCs. An SVC is an any-to-any connection that can be
established or removed as needed. With SVCs, you initiate calls using Frame Relay by
requesting a destination address and assigning a DLCI, which is established for the
duration of the call.
•
Example
host1(config-subif)#frame-relay interface-dlci 16 ietf
•
Use the no version to remove DLCI/PVC assignment.
•
See frame-relay interface-dlci ietf.
•
Use to configure a serial interface in the appropriate format by selecting a previously
configured physical interface on which you want to configure Frame Relay. For example,
for a channelized T3 interface use slot/port:channel/subchannel.
•
Use to configure a Frame Relay subinterface in the appropriate format by selecting a
previously configured physical interface. For example, for a T3-Frame interface use
slot/port.subinterface; for a channelized T1/channelized E1 interface use
slot/port.channel-group.subinterface.
interface serial
NOTE: See “Before You Configure Frame Relay” on page 108 for more
information about configuring the underlying physical interfaces.
Copyright © 2010, Juniper Networks, Inc.
119
JunosE 11.3.x Link Layer Configuration Guide
•
•
slot—Router chassis slot
•
port—CT3, T3, or E3 module I/O port
•
channel—T1 (DS1) channel
•
subchannel—Set of DS0 timeslots; for information, see section Fractional T1 in JunosE
Physical Layer Configuration Guide
•
subinterface—User-assigned nonnegative number that identifies a Frame Relay
subinterface
Example
host1(config-if)#interface serial 5/0:4/1.1
•
Use the no version to remove the subinterface or the serial interface.
•
See interface serial.
•
Use to assign an IP address and subnet mask to a subinterface.
•
Example
ip address
host1((config-subif)#ip address 42.42.42.41 255.255.255.0
•
Use the no version to remove an IP address or to disable IP processing.
•
See ip address.
•
Use to create a map class.
•
Example
map-class frame-relay
host1(config)#map-class frame-relay testmap
•
Use the no version to remove a map class.
•
See map-class frame-relay.
Monitoring Frame Relay
Use the show frame-relay commands described in this section to monitor Frame Relay
interfaces.
You can set a statistics baseline for Frame Relay interfaces, subinterfaces, or circuits
using the baseline frame-relay command.
You can use the output-filtering feature of the show command to include or exclude
lines of output based on a text string you specify. See show Commands in JunosE System
Basics Configuration Guide for details.
If you do not specify an interface type for the appropriate show command, the output
indicates whether a serial or POS interface is being displayed.
120
Copyright © 2010, Juniper Networks, Inc.
Chapter 2: Configuring Frame Relay
baseline frame-relay interface
•
Use to set a statistics baseline at the Frame Relay layer for multilink Frame Relay, POS,
serial or GRE tunnel interfaces, subinterfaces, or circuits.
•
The router implements the baseline by reading and storing the statistics at the time
the baseline is set and then subtracting this baseline whenever baseline-relative
statistics are retrieved.
•
Specify an interface or subinterface using the interface type and specifier. For more
information, see Interface Types and Specifiers in JunosE Command Reference Guide.
•
Specify a circuit using the interface type and specifier and the dlci keyword and the
dlci number.
•
You cannot set a baseline for groups of interfaces, subinterfaces, or circuits. You must
set baselines individually.
•
When baselining is requested, the time since the last baseline was set is displayed in
hours:minutes:seconds or days/hours format. If a baseline has not been set, the message
“ No baseline has been set” is displayed instead.
•
The regular interface statistics and LMI statistics for interfaces are subject to the same
baseline timestamp. You cannot set separate baselines.
•
Use the optional delta keyword with Frame Relay show commands to specify that
baselined statistics are to be shown.
•
Example
host1#baseline frame-relay interface serial 2/0:1/1
host1#show frame-relay interface delta
Frame relay interface 2/0:1/1, status is lowerLayerDown
Number of interface down transitions is 0
Time since last status change 21:06:34
Number of configured circuits: 0
Time since last baseline 00:00:05
In bytes: 0
Out bytes: 0
In frames: 0
Out frames: 0
In errors: 0
Out errors: 0
In discards: 0
Out discards: 0
In unknown protos: 0
•
There is no no version.
•
See baseline frame-relay interface.
show frame-relay interface
•
Use to display statistics for the Frame Relay layer in a multilink Frame Relay, POS,
serial, or GRE tunnel interface.
•
Optionally, you can specify an interface using the interface type and specifier. For more
information, see Interface Types and Specifiers in JunosE Command Reference Guide.
•
Use the brief keyword to display the operational status of all configured interfaces.
•
Use the optional delta keyword to specify that baselined statistics are to be shown.
Copyright © 2010, Juniper Networks, Inc.
121
JunosE 11.3.x Link Layer Configuration Guide
•
Field descriptions
•
•
status—One of the following states:
•
Up—Traffic can flow on the interface
•
Offline—Traffic cannot flow because hardware is unavailable
•
Down—Traffic cannot flow because of a problem in the interface at the current
protocol layer
•
LowerLayerDown—Traffic cannot flow because of a problem in an interface at a
lower protocol layer
•
AdministrativelyDown—Traffic cannot flow because of manual administrative
intervention
•
Description—Text description or alias if configured for the interface
•
In bytes—Number of inbound bytes received on the interface
•
Out bytes—Number of outbound bytes transmitted on the interface
•
In frames—Number of inbound frames received on the interface
•
Out frames—Number of outbound frames transmitted on the interface
•
In errors—Number of inbound errors received on the interface
•
Out errors—Number of outbound errors transmitted on the interface
•
In discards—Number of inbound packets discarded
•
Out discards—Number of outbound packets discarded
•
In unknown protos—Number of packets received on the interface with unknown
protocols
•
Time since last status change—Time since the last status change on the interface
Example
host1#show frame-relay interface
Frame relay interface 3/2:1/1, status is up
Description: boston01
Time since last status change 01:21:10
In bytes: 19712
Out bytes: 60918
In frames: 1232
Out frames: 1232
In errors: 0
Out errors: 0
In discards: 0
Out discards: 0
In unknown protos: 0
Frame relay interface 3/2:2/1, status is up
Description: newyork02
Time since last status change 03:06:18
In bytes: 19728
Out bytes: 60702
In frames: 1233
Out frames: 1233
In errors: 0
Out errors: 0
In discards: 0
Out discards: 0
In unknown protos: 0
122
Copyright © 2010, Juniper Networks, Inc.
Chapter 2: Configuring Frame Relay
Frame relay interface 3/2:3/1, status is up
Description: chicago03
Time since last status change 01:20:38
In bytes: 19696
Out bytes: 60744
In frames: 1231
Out frames: 1231
In errors: 0
Out errors: 0
•
See show frame-relay interface.
•
Use to display configuration and state information and statistics about the LMI for a
multilink Frame Relay, POS, serial, or GRE tunnel interface.
•
Optionally, you can specify an interface using the interface type and specifier. For more
information, see Interface Types and Specifiers in JunosE Command Reference Guide.
•
Use the optional delta keyword to specify that baselined statistics are to be shown.
•
Field descriptions
show frame-relay lmi
•
This command displays both DTE and DCE fields for NNI.
•
For the DTE:
•
•
Enquiries sent—Total number of LMI status enquiries sent by the DTE on this
interface
•
Full enquiries sent—Total number of LMI full-status enquiries sent by the DTE on
this interface
•
Enquiry responses received—Total number of LMI full- and regular-status responses
received by the DTE on this interface
•
Full enquiry responses received—Total number of LMI full-status responses received
by the DTE on this interface
•
Async updates received—Total number of LMI asynchronous updates received by
the DTE on this interface
•
Unknown messages received—Total number of unknown LMI messages received
on this interface
•
Loss of sequencing detected—Total number of times a loss of sequencing in
received LMI messages was detected by the DTE on this interface
•
No response timeouts—Total number of times a timeout occurred without receiving
a response to an LMI request by the DTE on this interface
•
Last sequence number sent—Last sequence number sent on this interface
•
Last sequence number received—Last sequence number received on this interface
For the DCE:
Copyright © 2010, Juniper Networks, Inc.
123
JunosE 11.3.x Link Layer Configuration Guide
•
•
Enquiries received—Total number of LMI status enquiries received by the DCE on
this interface
•
Enquiry responses sent—Total number of LMI status responses sent by the DCE
on this interface
•
Full enquiry responses sent—Total number of LMI full-status responses sent by
the DCE on this interface
•
Async updates sent—Total number of LMI asynchronous updates sent by the DCE
on this interface
•
Unknown messages received—Total number of unknown LMI messages received
on this interface
•
Loss of sequencing detected—Total number of times a loss of sequencing in
received LMI messages was detected by the DCE on this interface
•
No response timeouts—Total number of times a timeout occurred without receiving
a status inquiry from the DTE on this interface
•
Last sequence number sent—Last sequence number sent on this interface
•
Last sequence number received—Last sequence number received on this interface
Example
host1#show frame-relay lmi
LMI information for frame relay NNI interface 3/2:1/1
DTE Parameter N391 is 6, N392 is 3, N393 is 4, T391 is 10
DCE Parameter N392 is 2, N393 is 2, T392 is 15
Configured LMI type is ANSI, status is up
Time since last status change 01:21:14
Enquiries received: 1232
Full enquiries received: 207
Enquiry responses sent: 1232
Full enquiry responses sent: 207
Async updates sent: 0
Unknown messages received: 0
Loss of sequencing detected: 2
No response timeouts: 0
Last sequence number sent: 0
Last sequence number received: 0
Unknown messages received: 0
Loss of sequencing detected: 2
LMI information for frame relay DCE interface 3/2:2/1
Parameter N392 is 2, N393 is 2, T392 is 15
Configured LMI type is ANSI, status is up
Time since last status change 03:06:22
Enquiries received: 1233
Full enquiries received: 207
Enquiry responses sent: 1233
Full enquiry responses sent: 207
Async updates sent: 0
Last sequence number sent: 0
Last sequence number received: 0
•
124
See show frame-relay lmi.
Copyright © 2010, Juniper Networks, Inc.
Chapter 2: Configuring Frame Relay
show frame-relay map
•
Use to display the current Frame Relay map entries and information about Frame Relay
connections.
•
Field descriptions
•
•
•
Frame relay sub-interface—Interface number and one of the following states:
•
Up—Traffic can flow on the interface
•
Offline—Traffic cannot flow because hardware is unavailable
•
Down—Traffic cannot flow because of a problem in the interface at the current
protocol layer
•
LowerLayerDown—Traffic cannot flow because of a problem in an interface at a
lower protocol layer
•
AdministrativelyDown—Traffic cannot flow because of manual administrative
intervention
DLCI—Provides decimal value, hexadecimal value, and its value as it appears on the
wire
Example
host1#show frame-relay map
Frame relay sub-interface
Frame relay sub-interface
Frame relay sub-interface
Frame relay sub-interface
Frame relay sub-interface
Frame relay sub-interface
Frame relay sub-interface
Frame relay sub-interface
Frame relay sub-interface
Frame relay sub-interface
Frame relay sub-interface
Frame relay sub-interface
Frame relay sub-interface
Frame relay sub-interface
Frame relay sub-interface
Frame relay sub-interface
Frame relay sub-interface
Frame relay sub-interface
Frame relay sub-interface
Frame relay sub-interface
3/2:1/1.1 (up): DLCI 101(0x65,0x58)
3/2:1/1.2 (up): DLCI 102(0x66,0x78)
3/2:1/1.3 (up): DLCI 103(0x67,0x78)
3/2:1/1.4 (up): DLCI 104(0x68,0x98)
3/2:1/1.5 (up): DLCI 105(0x69,0x98)
3/2:1/1.6 (up): DLCI 106(0x6a,0xb8)
3/2:1/1.7 (up): DLCI 107(0x6b,0xb8)
3/2:1/1.8 (up): DLCI 108(0x6c,0xd8)
3/2:1/1.9 (up): DLCI 109(0x6d,0xd8)
3/2:1/1.10 (up): DLCI 110(0x6e,0xf8)
3/2:1/1.11 (up): DLCI 111(0x6f,0xf8)
3/2:1/1.12 (up): DLCI 112(0x70,0x1c)
3/2:1/1.17 (up): DLCI 117(0x75,0x5c)
3/2:1/1.18 (up): DLCI 118(0x76,0x7c)
3/2:1/1.19 (up): DLCI 119(0x77,0x7c)
3/2:1/1.20 (up): DLCI 120(0x78,0x9c)
3/2:1/1.21 (up): DLCI 121(0x79,0x9c)
3/2:1/1.22 (up): DLCI 122(0x7a,0xbc)
3/2:1/1.23 (up): DLCI 123(0x7b,0xbc)
3/2:1/1.24 (up): DLCI 124(0x7c,0xdc)
•
See show frame-relay map.
•
Use to display statistics about PVCs for Frame Relay layer on a multilink Frame Relay,
POS, serial, or GRE tunnel interface or a specific PVC.
•
Optionally, you can specify an interface using the interface type and specifier. For more
information, see Interface Types and Specifiers in JunosE Command Reference Guide.
show frame-relay pvc
Copyright © 2010, Juniper Networks, Inc.
125
JunosE 11.3.x Link Layer Configuration Guide
•
Specify a virtual circuit using the DLCI number.
•
Use the brief keyword to display abbreviated PVC information.
•
Use the optional delta keyword to specify that baselined statistics are to be shown.
•
Field descriptions
•
126
•
DLCI—DLCI number
•
interface—Identifies an interface in slot/port:channel/subchannel format or a
subinterface in slot/port:channel/subchannel.subinterface format
•
PVC status—Status of the circuit; valid states are active and inactive.
•
Number of circuit status inactive transitions—number of times a circuit came down
because of error conditions
•
Time since creation—Time since the PVC was created
•
last status change—Time since the PVC status last changed
•
In pkts—Number of incoming packets received on the circuit
•
Out pkts—Number of outgoing packets transmitted on the circuit
•
In bytes—Number of input bytes received on the circuit
•
Out bytes—Number of output bytes received on the circuit
•
In FECN pkts—Number of packets received with the forward explicit congestion
notification (FECN) bit set. The FECN bit is set by a network to notify the user that
congestions may be experienced by data traffic in the direction of the frame carrying
the FECN bit. The FECN bit is set by the network (not by the transmitting user), and
there is no obligation for end systems to take any action regarding the FECN bit.
•
Out FECN pkts—Number of packets transmitted with the FECN bit set
•
In BECN pkts—Number of packets received with the backward explicit congestion
notification (BECN) bit set. The BECN bit is set by a network to notify the user that
congestions may be experienced by data traffic in the opposite direction of the frame
carrying the BECN bit. The BECN bit is set by the network, and there is no obligation
for end systems to take any action regarding the BECN bit.
•
Out BECN pkts—Number of packets transmitted with the BECN bit set
•
In DE pkts—Number of packets received with the discard eligibility (DE) bit set. When
the DE bit is set, it indicates that the frame is discarded in preference to other frames
without the DE bit set. The DE bit may be set by the network or the user. Once it is
set, it cannot be reset by the user.
•
Out DE pkts—Number of packets transmitted with the DE bit set
•
Dropped packets—Number of dropped packets
Example
Copyright © 2010, Juniper Networks, Inc.
Chapter 2: Configuring Frame Relay
host1#show frame-relay pvc
PVC information for frame relay NNI interface 3/2:1/1
DLCI 101 in sub-interface 3/2:1/1.1, status is active
Number of circuit status inactive transitions is 0
Time since creation 03:27:29, last status change 01:21:29
In pkts: 0
Out pkts: 0
In bytes: 0
Out bytes: 0
In FECN pkts: 0
Out FECN pkts: 0
In BECN pkts: 0
Out BECN pkts: 0
In DE pkts: 0
Out DE pkts: 0
Dropped pkts: 0
DLCI 102 in sub-interface 3/2:1/1.2, status is active
Number of circuit status inactive transitions is 0
Time since creation 03:27:28, last status change 01:21:29
In pkts: 0
Out pkts: 0
In bytes: 0
Out bytes: 0
In FECN pkts: 0
Out FECN pkts: 0
In BECN pkts: 0
Out BECN pkts: 0
In DE pkts: 0
Out DE pkts: 0
Dropped pkts: 0
DLCI 103 in sub-interface 3/2:1/1.3, status is active
Number of circuit status inactive transitions is 0
Time since creation 03:27:28, last status change 01:21:29
In pkts: 0
Out pkts: 0
In bytes: 0
Out bytes: 0
In FECN pkts: 0
Out FECN pkts: 0
In BECN pkts: 0
Out BECN pkts: 0
In DE pkts: 0
Out DE pkts: 0
Dropped pkts: 0
•
See show frame-relay pvc.
show frame-relay subinterface
•
Use to display the state of the Frame Relay subinterface.
•
The subinterface can be in one of the following states:
•
Up—Traffic can flow on the interface
•
Offline—Traffic cannot flow because hardware is unavailable
•
Down—Traffic cannot flow because of a problem in the interface at the current
protocol layer
•
LowerLayerDown—Traffic cannot flow because of a problem in an interface at a
lower protocol layer
•
AdministrativelyDown—Traffic cannot flow because of manual administrative
intervention
•
Use the optional delta keyword to specify that baselined statistics are to be shown.
•
The brief keyword displays only the operational status of all configured subinterfaces.
•
Field descriptions
Copyright © 2010, Juniper Networks, Inc.
127
JunosE 11.3.x Link Layer Configuration Guide
•
•
sub-interface—Identifies the subinterface in slot/port:channel/subchannel.subinterface
format
•
status—Status of the subinterface
•
Description—Text description or alias if configured for the subinterface
•
Time since last status change—Time since the last status change on the subinterface
•
In bytes—Number of inbound bytes received on the subinterface
•
Out bytes—Number of outbound bytes transmitted on the subinterface
•
In frames—Number of inbound frames received on the interface
•
Out frames—Number of outbound frames transmitted on the interface
•
In errors—Number of inbound errors received on the subinterface
•
Out errors—Number of outbound errors transmitted on the subinterface
•
In discards—Number of inbound packets discarded
•
Out discards—Number of outbound packets discarded
•
In unknown protos—Number of packets received on the subinterface with unknown
protocols
Example
host1#show frame-relay subinterface
Frame relay sub-interface 3/2:1/1.1, status is up
Description: toronto011
Time since last status change 01:21:26
In bytes: 0
Out bytes: 0
In frames: 0
Out frames: 0
In errors: 0
Out errors: 0
In discards: 0
Out discards: 0
In unknown protos: 0
Frame relay sub-interface 3/2:1/1.2, status is up
Description: ottawa012
Time since last status change 01:21:26
In bytes: 0
Out bytes: 0
In frames: 0
Out frames: 0
In errors: 0
Out errors: 0
In discards: 0
Out discards: 0
In unknown protos: 0
Frame relay sub-interface 3/2:1/1.3, status is up
Description: montreal013
Time since last status change 01:21:26
In bytes: 0
Out bytes: 0
In frames: 0
Out frames: 0
In errors: 0
Out errors: 0
In discards: 0
Out discards: 0
In unknown protos: 0
•
128
See show frame-relay subinterface.
Copyright © 2010, Juniper Networks, Inc.
Chapter 2: Configuring Frame Relay
show frame-relay summary
•
•
Use to scan all defined Frame Relay interfaces and circuits; reports aggregate status
as one of the following:
•
Up—Traffic can flow on the interface
•
Down—Traffic cannot flow because of a problem in the network
•
Unavailable—Traffic cannot flow because hardware is unavailable
Example
host1#show frame-relay summary
28 interface(s) defined, 28 up, 0 down
840 sub-interface(s) defined, 840 up, 0 down
840 circuit(s) defined, 840 up, 0 down
•
See show frame-relay summary.
Copyright © 2010, Juniper Networks, Inc.
129
JunosE 11.3.x Link Layer Configuration Guide
130
Copyright © 2010, Juniper Networks, Inc.
CHAPTER 3
Configuring Multilink Frame Relay
This chapter describes how to configure Multilink Frame Relay (MLFR) interfaces on
E Series routers.
This chapter contains the following sections:
•
Overview on page 131
•
Platform Considerations on page 133
•
References on page 134
•
Supported MLFR Features on page 134
•
Unsupported MLFR Features on page 135
•
Before You Configure MLFR on page 136
•
Configuration Tasks on page 136
•
Monitoring MLFR on page 138
Overview
MLFR aggregates multiple physical links into a single logical bundle. More specifically,
MLFR bundles multiple link-layer channels into a single network layer channel.
The routers joined by the multilink each assign the same unique name to the bundle. A
bundle can consist of multiple physical links of the same type—such as multiple
asynchronous lines—or can consist of physical links of different types—such as leased
synchronous lines and dial-up asynchronous lines.
The router treats MLFR like nonmultilink Frame Relay. Packets received with an MLFR
header are subject to sequencing. Packets received without the MLFR header cannot be
sequenced and can be delivered only on a first-come, first-served basis.
T1/E1 Connections
Some users need more bandwidth than a T1 or an E1 channel can provide, but cannot
afford the expense or do not need the bandwidth of T3 or E3. Equal-cost multipath
(ECMP) is one way to achieve a bandwidth greater than DS1 service without going to the
expense and infrastructure required for DS3 service. MLFR is commonly used as an
alternative to ECMP to deliver NxT1 service. Cost-analysis of NxT1 versus DS3 service
Copyright © 2010, Juniper Networks, Inc.
131
JunosE 11.3.x Link Layer Configuration Guide
typically imposes a practical limit of 8xT1 service; that is, aggregation of no more than
eight T1 or E1 connections into an MLFR bundle.
This implementation of MLFR logically aggregates up to eight T1 or E1 connections into
a single virtual connection, known as a bundle, to a given customer site. The connections
can terminate at a CPE (Figure 5 on page 132) or a Multilink Frame Relay bridge (Figure
6 on page 132).
Figure 5: MLFR Aggregation of T1 Lines into a Single Bundle
Figure 6: Terminating the Bundle at an MLFR Bridge
MLFR Link Integrity Protocol
Member links in an MLFR bundle support the MLFR Link Integrity Protocol (LIP). LIP offers
several types of messages, which allow member links to join and leave a bundle. See
Table 9 on page 132.
Table 9: LIP Messages and Functions
132
LIP Message
Function
Add-Link
Member link sends this message to request to join a bundle.
Add-Link-Ack
Member link sends this message when it receives an Add-Link
message.
Add-Link-Rej
Member link sends this message to reject a request to join a
bundle.
Hello
Member link sends this message to check the status of another
member.
Hello-Ack
Member link sends this message when it receives a Hello
message.
Remove-Link
Member link sends this message to request to leave a bundle.
Copyright © 2010, Juniper Networks, Inc.
Chapter 3: Configuring Multilink Frame Relay
Table 9: LIP Messages and Functions (continued)
LIP Message
Function
Remove-Link-Ack
Member link sends this message when it receives a Remove-Link
message.
The DTE creates a link management interface (LMI) with the network by encapsulating
the Frame Relay frame within an MLFR frame. You assign one or more data link control
identifiers (DLCIs) to a bundle.
Interface Stacking
Because MLFR aggregates multiple link-layer channels onto a single network layer IP
interface, protocol layering within the router is different than it is for nonmultilink Frame
Relay. See Figure 7 on page 133.
Figure 7: Structure of MLFR
The MLFR Link Integrity Protocol runs on each link in a bundle. However, from the major
Frame Relay interface (the bundle) upward, the interface stacking is the same as for
nonmultilink Frame Relay. For example, LMI runs only on the bundle. The bundle sends
and receives all MLFR packets.
Platform Considerations
You can configure MLFR interfaces on the following E Series Broadband Services Routers:
•
ERX1440 router
•
ERX1410 router
•
ERX710 router
•
ERX705 router
•
ERX310 router
NOTE: The E120 and E320 Broadband Services Routers do not support
configuration of MLFR interfaces.
Copyright © 2010, Juniper Networks, Inc.
133
JunosE 11.3.x Link Layer Configuration Guide
Module Requirements
For information about the modules that support MLFR interfaces on ERX14xx models,
ERX7xx models, and the ERX310 router:
•
See ERX Module Guide, Table 1, Module Combinations for detailed module specifications.
•
See ERX Module Guide, Appendix A, Module Protocol Support for information about the
modules that support MLFR.
Interface Specifiers
The interface specifier format that you use depends on the type of physical interface on
which you want to configure MLFR.
For more information about supported interface types and specifiers on E Series routers,
see Interface Types and Specifiers in JunosE Command Reference Guide.
References
For more information about the MLFR protocol, consult the following resources:
•
Multilink Frame Relay UNI/NNI Implementation Agreement, FRF.16 (April 2000)
•
Frame Relay Forum—Frame Relay Fragmentation Implementation Agreement, FRF.12
(December 1997)
•
ANSI T1.617 Annex D
•
ITU-T Q.933 Annex A
Supported MLFR Features
E Series routers support the following MLFR features on the cOCx/STMx and CT3 line
modules:
•
Logical aggregation of up to eight T1 or E1 links in a bundle
•
Monotonically increasing sequence numbers for each circuit
All packets distributed across the member links have monotonically increasing sequence
numbers for each circuit. This feature enables the remote router on the customer
premises to perform resequencing (if it is configured to do so).
134
•
Static configuration of the links participating in a multilink bundle
•
Round-robin packet distribution
•
On CT3 line modules, packet distribution across the member links in a bundle is
handled only in a round-robin fashion. The round-robin approach is used even when
the member links have different line rates.
•
On cOCx/STMx and COCX-F3 line modules, the router keeps track of the link with
the least traffic. If this link cannot forward a packet, the router attempts to forward
Copyright © 2010, Juniper Networks, Inc.
Chapter 3: Configuring Multilink Frame Relay
the traffic on a different link. If this attempt also fails, the router uses a round-robin
approach.
You can configure bundles as follows:
•
•
•
On a cOCx/STMx line module and its corresponding I/O modules, you can configure:
•
Member links from different OC3/STM1 ports in the same bundle
•
The 336 available T1 channels combined in any manner that does not exceed 8 links
per bundle (for example, 336 single-link T1 bundles, 42 eight-link bundles, or 41
eight-link bundles and 8 single-link bundles)
•
The 252 available E1 channels combined in any manner that does not exceed 8 links
per bundle (for example, 252 single-link E1 bundles, 34 eight-link bundles, or 33
eight-link bundles and 8 single-link bundles)
On a COCX-F3 line module and its corresponding I/O modules, you can configure:
•
Up to 8 member links from different ports in the same bundle
•
Up to 12 bundles
On a CT3 or CT3/T3-F0 line module and its corresponding I/O module, you can
configure:
•
Only member links from the same T3 interfaces into the same bundle. You cannot
configure member links from different T3 ports in the same bundle.
•
The 28 available T1 channels on each port combined in any manner that does not
exceed 8 links per bundle (for example, 28 single-link T1 bundles or 3 eight-link
bundles and 4 single-link bundles per port)
Unsupported MLFR Features
E Series routers do not support the following MLFR features:
•
Fragmentation
The router does not support MLFR fragmentation or reassembly. When using MLFR
on the router, configure all peer devices so that they do not fragment MLFR frames.
The router drops all fragmented frames that it receives.
•
Resequencing of out-of-order packets in the absence of fragmentation
Given the location in the network where the router resides, the NxT1 links to a customer
site represent one of many places across the IP network where packets might be
received out of order. For example, if the router has multiple uplinks to a core router,
packets might be received out of order across these links. Packet resequencing is
therefore left as an exercise for the end station rather than the aggregation router.
Copyright © 2010, Juniper Networks, Inc.
135
JunosE 11.3.x Link Layer Configuration Guide
Before You Configure MLFR
Before you begin configuring MLFR, you must configure the physical layer interfaces that
will be aggregated by MLFR.
The procedures described in this chapter assume that a physical layer interface, such as
a T1 or T3 interface, has been configured. For details about configuring physical layer
interfaces, see the JunosE Physical Layer Configuration Guide.
Configuration Tasks
MLFR configuration consists of three major tasks, each with several steps:
1.
Create the member links to be aggregated into a multilink bundle.
a. Specify the interface on which you want to configure MLFR.
host1(config)#interface serial 2/0:1
b. Specify MLFR as the encapsulation method on the interface.
host1(config-if)#encapsulation mlframe-relay ietf
2. Add member links to a multilink bundle.
a. Define the MLFR bundle.
host1(config)#interface mlframe-relay boston
b. Add each member link.
host1(config-if)#member-interface serial 2/0:1
c. (Optional) Add a description to the major interface.
host1(config-if)#frame-relay description bostonBundleDescription
d. (Optional) Configure Frame Relay parameters.
host1(config-if)#frame-relay intf-type dce
host1(config-if)#frame-relay lmi-type cisco
3. Configure the Frame Relay subinterface.
a. Define the subinterface for the MLFR bundle.
host1(config)#interface mlframe-relay boston.1
b. Assign a DLCI for the subinterface.
host1(config-subif)#frame-relay interface-dlci 16 ietf
c. (Optional) Add a description to the subinterface.
host1(config-subif)#frame-relay description bostonBundleSubOneDescription
d. Assign an IP address to the subinterface.
host1(config-subif)#ip address 10.10.100.1 255.255.255.0
136
Copyright © 2010, Juniper Networks, Inc.
Chapter 3: Configuring Multilink Frame Relay
Configuration Example
The following commands configure three T1 lines and aggregate them into a multilink
bundle named boston.
host1(config)#interface serial 2/0:1
host1(config-if)#encapsulation mlframe-relay ietf
host1(config-if)#exit
host1(config)#interface serial 2/0:2
host1(config-if)#encapsulation mlframe-relay ietf
host1(config-if)#exit
host1(config)#interface serial 2/0:3
host1(config-if)#encapsulation mlframe-relay ietf
host1(config-if)#exit
host1(config)#interface mlframe-relay boston
host1(config-if)#member-interface serial 2/0:1
host1(config-if)#frame-relay description bostonBundleDescription
host1(config-if)#frame-relay intf-type dce
host1(config-if)#frame-relay lmi-type cisco
host1(config-if)#member-interface serial 2/0:2
host1(config-if)#member-interface serial 2/0:3
host1(config-if)#exit
host1(config)#interface mlframe-relay boston.1
host1(config-subif)frame-relay description bostonBundleSubOneDescription
host1(config-subif)#frame-relay interface-dlci 16 ietf
host1(config-subif)#ip address 10.10.100.1 255.255.255.0
Configuring Frame Relay Versus MLFR
All the configuration commands that apply to Frame Relay also apply to MLFR. The
following listing describes commands specific to configuring MLFR; for other Frame Relay
commands, see “Configuring Frame Relay” on page 105.
encapsulation mlframe-relay ietf
•
Use to configure MLFR as the encapsulation method on an individual interface.
•
Use this command only within the context of an individual interface. Issuing this
command creates an MLFR link, also referred to as an MLFR bundle member.
•
Example
host1(config)#interface serial 2/0:1
host1(config-if)#encapsulation mlframe-relay ietf
•
Use theno version to disable MLFR on an interface.
•
See encapsulation mlframe-relay ietf.
•
Use to create a Frame Relay major interface, also known as the MLFR bundle.
•
Example
interface mlframe-relay
host1(config-if)#interface mlframe-relay group2
Copyright © 2010, Juniper Networks, Inc.
137
JunosE 11.3.x Link Layer Configuration Guide
•
Use the no version to delete the MLFR bundle.
•
See interface mlframe-relay.
•
Use to add an MLFR interface—also known as an MLFR bundle member—to an MLFR
bundle.
•
Example
member-interface
host1(config-if)#member-interface serial 2/0:1
•
Use the no version to remove the specified interface from the MLFR bundle.
•
See member-interface.
Monitoring MLFR
Use the commands in this section to display information about MLFR interfaces.
You can set a statistics baseline for an MLFR bundle or subinterface using the baseline
frame-relay interface mlframe-relay command. Similarly, you can set a statistics baseline
for an MLFR link with the baseline frame-relay multilink interface command. Use the
delta keyword with the show commands described below to display statistics with the
baseline values subtracted.
After you configure multilink Frame Relay, you can use the show frame-relay commands
to view information about the multilink. For information about these commands, see
“Configuring Frame Relay” on page 105.
You can use the output filtering feature of the show command to include or exclude lines
of output based on a text string you specify. Refer to the section show Commands in
JunosE System Basics Configuration Guide, for details.
baseline frame-relay interface
138
•
Use to set a statistics baseline for the Frame Relay layer on MLFR bundles, Frame Relay
interfaces, subinterfaces, and circuits.
•
Specify the keyword mlframe-relay and the name of the MLFR bundle to set a baseline
for the Frame Relay statistics on an MLFR bundle.
•
The router implements the baseline by reading and storing the statistics at the time
the baseline is set and then subtracting this baseline whenever baseline-relative
statistics are retrieved.
•
You cannot set a baseline for groups of interfaces, subinterfaces, or circuits. You must
set baselines one at a time.
•
When baselining is requested, the time since the last baseline was set is displayed in
hours:minutes:seconds or days/hours format. If a baseline has not been set, the message
“ No baseline has been set” is displayed instead.
•
The regular interface statistics and LMI statistics for interfaces are subject to the same
baseline timestamp. You cannot set separate baselines for these statistics.
Copyright © 2010, Juniper Networks, Inc.
Chapter 3: Configuring Multilink Frame Relay
•
Use the optional delta keyword with Frame Relay show commands to specify that
baselined statistics are to be shown.
•
Example
host1#baseline frame-relay interface mlframe-relay boston
•
There is no no version.
•
See baseline frame-relay interface.
baseline frame-relay multilinkinterface
•
Use to set a statistics baseline for MLFR links.
•
The router implements the baseline by reading and storing the statistics at the time
the baseline is set and then subtracting this baseline whenever baseline-relative
statistics are retrieved.
•
When baselining is requested, the time since the last baseline was set is displayed in
hours:minutes:seconds or days/hours format. If a baseline has not been set, the message
“ No baseline has been set” is displayed instead.
•
The regular interface statistics and LIP statistics for interfaces are subject to the same
baseline timestamp. You cannot set separate baselines for these statistics.
•
Use the optional delta keyword with Frame Relay show commands to specify that
baselined statistics are to be shown.
•
Example
host1#baseline frame-relay multilinkinterface serial 3/2
•
There is no no version.
•
See baseline frame-relay multilinkinterface.
show frame-relay interface
•
Use to display the information about the Frame Relay layer of the interface.
•
Use the brief keyword to display the operational status of all configured interfaces.
•
Use the optional delta keyword to specify that baselined statistics are to be shown.
•
Field descriptions
•
Frame relay interface mlframe-relay—Name of the MLFR bundle
•
Status of the major Frame Relay interface—One of the following states:
•
Up—Traffic can flow on the interface
•
Offline—Traffic cannot flow because hardware is unavailable
•
Down—Traffic cannot flow because of a problem in the interface at the current
protocol layer
Copyright © 2010, Juniper Networks, Inc.
139
JunosE 11.3.x Link Layer Configuration Guide
•
•
LowerLayerDown—Traffic cannot flow because of a problem in an interface at a
lower protocol layer
•
AdministrativelyDown—Traffic cannot flow because of manual administrative
intervention
•
Number of interface down transitions—Number of interfaces that have changed to
a down state
•
Time since last status change—Time since the interface last changed its state
•
In bytes—Number of inbound bytes received on the interface
•
In frames—Number of inbound frames received on the interface
•
In errors—Number of inbound errors received on the interface
•
In discards—Number of inbound packets discarded
•
In unknown protos—Number of packets received on the interface with unknown
protocols
•
Out bytes—Number of outbound bytes transmitted on the interface
•
Out frames—Number of outbound frames transmitted on the interface
•
Out errors—Number of outbound errors transmitted on the interface
•
Out discards—Number of outbound packets discarded
Example 1
host1#show frame-relay interface brief
Frame relay interface mlframe-relayTEST, status is up
•
Example 2
host1#show frame-relay interface mlframe-relay TEST
Frame relay interface mlframe-relayTEST, status is up
Number of interface down transitions is 0
Time since last status change 00:01:47
Number of configured circuits: 2
In bytes: 452
Out bytes: 198
In frames: 19
Out frames: 11
In errors: 0
Out errors: 0
In discards: 8
Out discards: 0
In unknown protos: 0
•
Example 3
host1#show frame-relay interface mlframe-relay members
Frame relay interface mlframe-relay TEST is up
Frame relay multilink member-interface 4/0:1 is up
Frame relay multilink member-interface 4/1:1 is up
•
See show frame-relay interface.
show frame-relay lip
140
Copyright © 2010, Juniper Networks, Inc.
Chapter 3: Configuring Multilink Frame Relay
•
Use to display the state of MLFR Link Integrity Protocol (LIP) on an MLFR link.
•
Use the brief keyword to display the operational status of all configured interfaces.
•
Use the delta keyword to specify that baselined statistics are to be shown.
•
Field descriptions
•
Frame relay interface—Specifier for the Frame Relay interface
•
Status of the major Frame Relay interface—One of the following states:
•
Up—Traffic can flow on the interface
•
Offline—Traffic cannot flow because hardware is unavailable
•
Down—Traffic cannot flow because of a problem in the interface at the current
protocol layer
•
LowerLayerDown—Traffic cannot flow because of a problem in an interface at a
lower protocol layer
•
AdministrativelyDown—Traffic cannot flow because of manual administrative
intervention
•
Number of interface down transitions—Number of interfaces that have changed to
a down state
•
Time since last status change—Time since the interface last changed its state
•
Add Links sent—Number of Add Link messages sent from this interface
•
Add Links received—Number of Add Link messages received on this interface
•
Add Link Acknowledgments sent—Number of Add Link acknowledgments sent from
this interface
•
Add Link Acknowledgments received—Number of Add Link acknowledgments
received on this interface
•
Add Link Rejects sent—Number of Add Link Reject messages sent from this interface
•
Add Link Rejects received—Number of Add Link Reject messages received on this
interface
•
Hellos sent—Number of Hello messages sent from this interface
•
Hellos received—Number of Hello messages received on this interface
•
Hello Acknowledgments sent—Number of Hello messages sent from this interface
•
Hello Acknowledgments received—Number of Hello messages received on this
interface
•
Remove Links sent—Number of Remove Link messages sent from this interface
•
Remove Links received—Number of Remove Link messages received on this interface
Copyright © 2010, Juniper Networks, Inc.
141
JunosE 11.3.x Link Layer Configuration Guide
•
•
Remove Link Acknowledgments sent—Number of Remove Link acknowledgments
sent from this interface
•
Remove Link Acknowledgments received—Number of Remove Link acknowledgments
received on this interface
Example 1
host1#show frame-relay lip brief
LIP information for frame relay interface 4/0:1, status is up
Number of interface down transitions is 0
Time since last status change 00:03:16
LIP information for frame relay interface 4/1:1, status is up
Number of interface down transitions is 0
Time since last status change 00:03:20
•
Example 2
host1#show frame-relay lip interface serial 4/0:1
LIP information for frame relay interface 4/0:1, status is up
Number of interface down transitions is 0
Time since last status change 00:05:19
Add Links sent: 1
Add Links received: 1
Add Link Acknowledgements sent: 1
Add Link Acknowledgements received: 1
Add Link Rejects sent: 0
Add Link Rejects received: 0
Hellos sent: 32
Hellos received: 31
Hello Acknowledgements sent: 31
Hello Acknowledgements received: 32
Remove Links sent: 0
Remove Links received: 0
Remove Link Acknowledgements sent: 0
Remove Link Acknowledgements received: 0
•
See show frame-relay lip.
•
Use to display configuration and state information and statistics about the LMI.
•
You can specify an interface type and location.
•
Use the brief keyword to display abbreviated PVC information.
•
Use the delta keyword to specify that baselined statistics are to be shown.
•
DTE field descriptions
show frame-relay lmi
142
•
Frame relay DTE interface mlframe-relay—Name of the MLFR bundle
•
N391—Value of the N391 full-status polling counter
•
N392—Value of the N392 error threshold counter
•
N393—Value of the N393 monitored events counter
•
T391—Value of the T391 link integrity polling timer interval
Copyright © 2010, Juniper Networks, Inc.
Chapter 3: Configuring Multilink Frame Relay
•
•
Configured LMI type—One of the following options:
•
ANSI—ANSI T1.617 Annex D
•
Q933A—ITU-T Q.933 Annex A
•
Cisco—Original Group of Four specification developed by DEC, Northern Telecom,
Stratacom, and Cisco
•
None—Suppresses LMI
•
status is up—Availability of the MLFR bundle: up or down
•
Number of interface down transitions—Number of times the interface has become
unavailable
•
Time since last status change—elapsed time since LMI information changed
•
Enquiries sent—Total number of LMI status inquiries sent by the DTE on this
interface
•
Full enquiries sent—Total number of LMI full status inquiries sent by the DTE on
this interface
•
Enquiry responses received—Total number of LMI full and regular status responses
received by the DTE on this interface
•
Full enquiry responses received—Total number of LMI full status responses received
by the DTE on this interface
•
Async updates received—Total number of asynchronous LMI updates received by
the DTE on this interface
•
Unknown messages received—Total number of unknown LMI messages received
on this interface
•
Loss of sequencing detected—Total number of times a loss of sequencing in
received LMI messages was detected by the DTE on this interface
•
No response timeouts—Total number of times a timeout occurred without receiving
a response to an LMI request by the DTE on this interface
•
Last sequence number sent—Last sequence number sent on this interface
•
Last sequence number received—Last sequence number received on this interface
DCE field descriptions:
•
Frame relay DCE interface mlframe-relay—Name of the MLFR bundle
•
N391—Value of the N391 full-status polling counter
•
N392—Value of the N392 error threshold counter
•
T392—Value of the T392 polling verification timer
Copyright © 2010, Juniper Networks, Inc.
143
JunosE 11.3.x Link Layer Configuration Guide
•
•
Configured LMI type: one of the following options:
•
ANSI—ANSI T1.617 Annex D
•
Q933A—ITU-T Q.933 Annex A
•
Cisco—Original Group of Four specification developed by DEC, Northern Telecom,
Stratacom, and Cisco
•
None—Suppresses LMI
•
status is up—Availability of the MLFR bundle: up or down
•
Number of interface down transitions—Number of times the interface has become
unavailable
•
Time since last status change—Elapsed time since LMI information changed
•
Enquiries received—Total number of LMI status inquiries received by the DCE on
this interface
•
Enquiry responses sent—Total number of LMI status responses sent by the DCE
on this interface
•
Full enquiry responses sent—Total number of LMI full status responses sent by
the DCE on this interface
•
Async updates sent—Total number of LMI ASYNC updates sent by the DCE on
this interface
•
Unknown messages received—Total number of unknown LMI messages received
on this interface
•
Loss of sequencing detected—Total number of times a loss of sequencing in
received LMI messages was detected by the DCE on this interface
•
No response timeouts—Total number of times a timeout occurred without receiving
a status inquiry from the DTE on this interface
•
Last sequence number sent—Last sequence number sent on this interface
•
Last sequence number received—last sequence number received on this interface
Example 1
host1#show frame-relay lmi brief
LMI information for frame relay DTE interface mlframe-relayTEST
DTE parameter N391 is 6, N392 is 3, N393 is 4, T391 is 10
Configured LMI type is ANSI, status is up
Number of interface down transitions is 0
Time since last status change 00:05:39
•
Example 2
host1#show frame-relay lmi interface mlframe-relay TEST
LMI information for frame relay DTE interface mlframe-relayTEST
DTE parameter N391 is 6, N392 is 3, N393 is 4, T391 is 10
144
Copyright © 2010, Juniper Networks, Inc.
Chapter 3: Configuring Multilink Frame Relay
Configured LMI type is ANSI, status is up
Number of interface down transitions is 0
Time since last status change 00:06:20
Enquiries sent: 39
Full enquiries sent: 7
Enquiry responses received: 39
Full enquiry responses received: 7
Async updates received: 0
Unknown messages received: 0
Loss of sequencing detected: 0
No response timeouts: 0
Last sequence number sent: 39
Last sequence number received: 39
•
See show frame-relay lmi.
•
Use to display the current Frame Relay and MLFR map entries.
•
Field descriptions
show frame-relay map
•
subinterface—Name and subinterface number of the MLFR bundle in the format
bundle-name.subinterface-number
•
State of the subinterface—One of the following states:
•
•
•
Up—Traffic can flow on the interface
•
Offline—Traffic cannot flow because hardware is unavailable
•
Down—Traffic cannot flow because of a problem in the interface at the current
protocol layer
•
LowerLayerDown—Traffic cannot flow because of a problem in an interface at a
lower protocol layer
•
AdministrativelyDown—Traffic cannot flow because of manual administrative
intervention
DLCI number—Decimal value, hexadecimal value, and value as it appears on the
wire of the DLCI
Example
host1#show frame-relay map
Frame relay sub-interface mlframe-relayTEST.1 (up): DLCI 16(0x10,0x4)
Frame relay sub-interface mlframe-relayTEST.2 (up): DLCI 17(0x11,0x14)
•
See show frame-relay map
show frame-relay multilinkInterface
•
Use to display the statistics about all MLFR interfaces or the specified MLFR interfaces.
•
Field descriptions
•
Multilink Frame relay interface—Specifier for the Frame Relay interface
•
State of the MLFR interface—One of the following states:
Copyright © 2010, Juniper Networks, Inc.
145
JunosE 11.3.x Link Layer Configuration Guide
•
•
Up—Traffic can flow on the interface
•
Offline—Traffic cannot flow because hardware is unavailable
•
Down—Traffic cannot flow because of a problem in the interface at the current
protocol layer
•
LowerLayerDown—Traffic cannot flow because of a problem in an interface at a
lower protocol layer
•
AdministrativelyDown—Traffic cannot flow because of manual administrative
intervention
•
Number of multilink interface down transitions—Number of interfaces that have
changed to a down state
•
Time since last status change—Time since the interface last changed its state
•
In bytes—Number of inbound bytes received on the interface
•
In frames—Number of inbound frames received on the interface
•
In errors—Number of inbound errors received on the interface
•
In discards—Number of inbound packets discarded
•
In unknown protos—Number of packets received on the interface with unknown
protocols
•
Out bytes—Number of outbound bytes transmitted on the interface
•
Out frames—Number of outbound frames transmitted on the interface
•
Out errors—Number of outbound errors transmitted on the interface
•
Out discards—Number of outbound packets discarded
Example
host1#show frame-relay multilinkInterface
Multilink Frame relay interface 6/2:2, status is down
Number of multilink interface down transitions is 0
Time since last status change 2 days, 23 hours
In bytes: 0
Out bytes: 0
In frames: 0
Out frames: 0
In errors: 0
Out errors: 0
In discards: 0
Out discards: 0
In unknown protos: 0
•
See show frame-relay multilinkInterface.
•
Use to display statistics about PVCs for Frame Relay interfaces.
•
Specify a DLCI number or an interface type and location.
•
Use the optional delta keyword to specify that baselined statistics are to be shown.
show frame-relay pvc
146
Copyright © 2010, Juniper Networks, Inc.
Chapter 3: Configuring Multilink Frame Relay
•
The brief keyword displays abbreviated PVC information.
•
Field descriptions
•
•
DLCI—DLCI number
•
subinterface—Name and subinterface number of the MLFR bundle in the format
bundle-name.subinterface-number
•
status—Status of the PVC
•
Number of circuit status inactive transitions—Number of times a circuit came down
because of error conditions
•
Time since creation—Time since the PVC was created
•
last status change—Time since the PVC status last changed
•
In pkts—Number of incoming packets received on the circuit
•
Out pkts—Number of outgoing packets transmitted on the circuit
•
In bytes—Number of input bytes received on the circuit
•
Out bytes—Number of output bytes received on the circuit
•
In FECN pkts—Number of packets received with the forward explicit congestion
notification (FECN) bit set. The FECN bit is set by a network to notify the user that
data traffic may experience congestion in the direction of the frame carrying the
FECN bit. The FECN bit is set by the network (not by the transmitting user), and there
is no obligation for end systems to take any action regarding the FECN bit.
•
Out FECN pkts—Number of packets transmitted with the FECN bit set
•
In BECN pkts—Number of packets received with the backward explicit congestion
notification (BECN) bit set. The BECN bit is set by a network to notify the user that
data traffic may experience congestion in the opposite direction of the frame carrying
the BECN bit. The BECN bit is set by the network, and there is no obligation for end
systems to take any action regarding the BECN bit.
•
Out BECN pkts—Number of packets transmitted with the BECN bit set
•
In DE pkts—Number of packets received with the discard eligibility (DE) bit set. When
the DE bit is set, it indicates that the frame is discarded in preference to other frames
without the DE bit set. The DE bit may be set by the network or the user. Once it is
set, it cannot be reset by the user.
•
Out DE pkts—Number of packets transmitted with the DE bit set
•
Dropped packets—Number of dropped packets
Example 1
host1#show frame-relay pvc brief
PVC information for frame relay DTE interface mlframe-relayTEST
Copyright © 2010, Juniper Networks, Inc.
147
JunosE 11.3.x Link Layer Configuration Guide
DLCI 16 in sub-interface mlframe-relayTEST.1, status is active
DLCI 17 in sub-interface mlframe-relayTEST.2, status is active
•
Example 2
host1#show frame-relay pvc interface mlframe-relay TEST
PVC information for frame relay DTE interface mlframe-relayTEST
DLCI 16 in sub-interface mlframe-relayTEST.1, status is active
Number of circuit status inactive transitions is 0
Time since creation 00:07:20, last status change 00:07:11
In pkts: 14
Out pkts: 0
In bytes: 420
Out bytes: 0
In FECN pkts: 0
Out FECN pkts: 0
In BECN pkts: 0
Out BECN pkts: 0
In DE pkts: 0
Out DE pkts: 0
Dropped pkts: 14
DLCI 17 in sub-interface mlframe-relayTEST.2, status is active
Number of circuit status inactive transitions is 0
Time since creation 00:07:20, last status change 00:07:11
In pkts: 14
Out pkts: 0
In bytes: 420
Out bytes: 0
In FECN pkts: 0
Out FECN pkts: 0
In BECN pkts: 0
Out BECN pkts: 0
In DE pkts: 0
Out DE pkts: 0
Dropped pkts: 14
•
See show frame-relay pvc.
show frame-relay subinterface
148
•
Use to display the state of the subinterface.
•
The subinterface can be in one of the following states:
•
Up—Traffic can flow on the interface
•
Offline—Traffic cannot flow because hardware is unavailable
•
Down—Traffic cannot flow because of a problem in the interface at the current
protocol layer
•
LowerLayerDown—Traffic cannot flow because of a problem in an interface at a
lower protocol layer
•
AdministrativelyDown—Traffic cannot flow because of manual administrative
intervention
•
Use the brief keyword to display only the operational status of all configured
subinterfaces.
•
Use the optional delta keyword to specify that baselined statistics are to be shown.
•
Field descriptions
•
Frame relay sub-interface mlframe-relay—Name and subinterface number of the
MLFR bundle in the format bundle-name.subinterface-number
•
status—State of the subinterface, as follows:
Copyright © 2010, Juniper Networks, Inc.
Chapter 3: Configuring Multilink Frame Relay
•
•
Up—Traffic can flow on the interface
•
Offline—Traffic cannot flow because hardware is unavailable
•
Down—Traffic cannot flow because of a problem in the interface at the current
protocol layer
•
LowerLayerDown—Traffic cannot flow because of a problem in an interface at a
lower protocol layer
•
AdministrativelyDown—Traffic cannot flow because of manual administrative
intervention
•
Number of sub-interface down transitions—Number of times a subinterface came
down because of error conditions
•
Time since last status change—Time since the last status change on the subinterface
•
In bytes—Number of inbound bytes received on the subinterface
•
Out bytes—Number of outbound bytes transmitted on the subinterface
•
In frames—Number of inbound frames received on the interface
•
Out frames—Number of outbound frames transmitted on the interface
•
In errors—Number of inbound errors received on the subinterface
•
Out errors—Number of outbound errors transmitted on the subinterface
•
In discards—Number of inbound packets discarded
•
Out discards—Number of outbound packets discarded
•
In unknown protos—Number of packets received on the subinterface with unknown
protocols
Example 1
host1#show frame-relay subinterface brief
Frame relay sub-interface mlframe-relayTEST.1, status is up
Frame relay sub-interface mlframe-relayTEST.2, status is up
•
Example 2
host1#show frame-relay subinterface mlframe-relay TEST
Frame relay sub-interface mlframe-relayTEST.1, status is up
Number of sub-interface down transitions is 0
Time since last status change 00:07:49
In bytes: 512
Out bytes: 0
In frames: 16
Out frames: 0
In errors: 0
Out errors: 0
In discards: 16
Out discards: 0
In unknown protos: 0
Frame relay sub-interface mlframe-relayTEST.2, status is up
Number of sub-interface down transitions is 0
Time since last status change 00:07:50
Copyright © 2010, Juniper Networks, Inc.
149
JunosE 11.3.x Link Layer Configuration Guide
In
In
In
In
In
•
bytes: 512
frames: 16
errors: 0
discards: 16
unknown protos: 0
Out
Out
Out
Out
bytes: 0
frames: 0
errors: 0
discards: 0
See show frame-relay subinterface.
show frame-relay summary
•
•
Use to scan all defined Frame Relay interfaces and circuits and to report the status for
each discovered interface and circuit as follows:
•
Up—Traffic can flow on the interface
•
Down—Traffic cannot flow because of a problem in the network
•
Unavailable—Traffic cannot flow because hardware is unavailable
Example
host1#show frame-relay summary
2 multilink interface(s) defined, 2 up, 0 down
1 interface(s) defined, 1 up, 0 down
2 sub-interface(s) defined, 2 up, 0 down
2 circuit(s) defined, 2 up, 0 down
•
150
See show frame-relay summary.
Copyright © 2010, Juniper Networks, Inc.
CHAPTER 4
Configuring Upper-Layer Protocols over
Static Ethernet Interfaces
This chapter describes how to configure upper-layer protocols over static Ethernet
interfaces on E Series routers.
This chapter contains the following sections:
•
Upper-Layer Protocols over Static Ethernet Overview on page 151
•
Upper-Layer Protocols over Static Ethernet Platform Considerations on page 152
•
Upper-Layer Protocols over Static Ethernet References on page 153
•
Configuring IP over a Static Ethernet Interface on page 153
•
Configuring PPPoE over a Static Ethernet Interface on page 154
•
Configuring IP and MPLS over a Static Ethernet Interface on page 155
•
Configuring IP, MPLS, and PPPoE over Ethernet on page 155
•
L2TP and Ethernet on page 156
•
Multinetting and Ethernet on page 157
•
Monitoring Upper-Level Protocols over Ethernet on page 157
Upper-Layer Protocols over Static Ethernet Overview
You can configure one or more protocols over Ethernet with or without VLANs. This
section focuses on non-VLAN configurations only. You can configure the following
upper-layer protocols on Fast Ethernet, Gigabit Ethernet, and 10-Gigabit Ethernet
interfaces:
•
IP
•
Point-to-Point Protocol over Ethernet (PPPoE)
•
Multiprotocol Label Switching (MPLS)
The Ethernet configuration examples in this section use combinations of these protocols.
Figure 8 on page 152 illustrates how different protocols can be multiplexed over a single
physical link without the use of VLANs.
Copyright © 2010, Juniper Networks, Inc.
151
JunosE 11.3.x Link Layer Configuration Guide
Figure 8: Multiplexing Multiple Protocols over a Single Physical Link
ERX14xx models (rear view)
The following sections describe how to create the following common non-VLAN
configurations, which you can configure on Fast Ethernet, Gigabit Ethernet, and 10-Gigabit
Ethernet interfaces:
•
IP over Ethernet
•
PPPoE over Ethernet
•
IP over Ethernet and MPLS over Ethernet
•
IP over Ethernet, MPLS over Ethernet, and PPPoE over Ethernet
NOTE: You can also configure upper-layer protocols over dynamic
interfaces. See “Configuring Dynamic Interfaces” on page 511 and
“Configuring Dynamic Interfaces Using Bulk Configuration” on page 619.
Upper-Layer Protocols over Static Ethernet Platform Considerations
You can configure upper-layer protocols over Ethernet on the following E Series
Broadband Services Routers:
152
•
E120 router
•
E320 router
•
ERX1440 router
•
ERX1410 router
•
ERX710 router
•
ERX705 router
•
ERX310 router
Copyright © 2010, Juniper Networks, Inc.
Chapter 4: Configuring Upper-Layer Protocols over Static Ethernet Interfaces
Module Requirements
For information about the modules supported on E Series routers:
•
See the ERX Module Guide for modules supported on ERX7xx models, ERX14xx models,
and the ERX310 router.
•
See the E120 and E320 Module Guide for modules supported on the E120 and E320
routers.
Interface Specifiers
The configuration task examples in this chapter use the format for ERX7xx models,
ERX14xx models, and the ERX310 router to specify a VLAN or S-VLAN subinterface.
For ERX7xx models, ERX14xx models, and ERX310 router, use the slot/port[.subinterface
] format. For example, the following command specifies a VLAN subinterface configured
on port 0 of an I/O module in slot 4.
host1(config)#interface fastEthernet 4/0.1
For E120 and E320 routers, use the slot/adapter/port[.subinterface ] format, which includes
an identifier for the bay in which the I/O adapter (IOA) resides. For example, the following
command specifies a VLAN subinterface configured on port 0 of the IOA installed in the
upper adapter bay of slot 3.
host1(config)#interface gigabitEthernet 3/0/0.1
For more information about interface types and specifiers on E Series models, see Interface
Types and Specifiers in JunosE Command Reference Guide.
Upper-Layer Protocols over Static Ethernet References
For more information about upper-layer protocol implementations over Ethernet, consult
the following resources:
•
RFC 894—A Standard for the Transmission of IP Datagrams over Ethernet Networks
(April 1984)
•
RFC 1042—A Standard for the Transmission of IP Datagrams over IEEE 802 Networks
(February 1988)
•
RFC 1112—Host Extensions for IP Multicasting (August 1989)
•
RFC 2516—Method for Transmitting PPP over Ethernet (PPPoE) (February 1998)
Configuring IP over a Static Ethernet Interface
To configure IP over an Ethernet interface:
1.
Specify a Fast Ethernet, Gigabit Ethernet, or 10-Gigabit Ethernet port.
host1(config)#interface fastEthernet 4/1
2. Create an IP interface.
Copyright © 2010, Juniper Networks, Inc.
153
JunosE 11.3.x Link Layer Configuration Guide
host1(config-if)#ip address 192.5.127.8 255.255.255.0
Figure 9 on page 154 illustrates this configuration.
Figure 9: Example of IP over Ethernet Stacking Configuration Procedure
Configuring PPPoE over a Static Ethernet Interface
To configure PPPoE over an Ethernet interface:
1.
Specify a Fast Ethernet, Gigabit Ethernet, or 10-Gigabit Ethernet port.
host1(config)#interface fastEthernet 4/1
2. Specify PPPoE as the encapsulation method on the interface.
host1(config-if)#pppoe
3. Create a PPPoE subinterface.
host1(config-if)#pppoe subinterface fastEthernet 4/1.1
4. Specify PPP as the encapsulation method on the interface.
host1(config-if)#encapsulation ppp
5. Assign an IP address and mask.
host1(config-if)#ip address 164.10.6.51 255.255.255.0
6. (Optional) Configure additional PPPoE subinterfaces by completing Steps 3 through
5 using unique numbering.
Figure 10 on page 154 illustrates this configuration.
Figure 10: Example of PPPoE Stacking Configuration Procedure
154
Copyright © 2010, Juniper Networks, Inc.
Chapter 4: Configuring Upper-Layer Protocols over Static Ethernet Interfaces
Configuring IP and MPLS over a Static Ethernet Interface
To configure both IP and MPLS over an Ethernet interface:
1.
Specify a Fast Ethernet, Gigabit Ethernet, or 10-Gigabit Ethernet port.
host1(config)#interface fastEthernet 4/0
2. Create an IP interface.
host1(config-if)#ip address 192.5.127.8 255.255.255.0
3. Create an MPLS interface.
host1(config-if)#mpls
Figure 11 on page 155 illustrates this configuration.
Figure 11: Example of IP and MPLS Stacking Configuration Procedure
Configuring IP, MPLS, and PPPoE over Ethernet
To configure IP, MPLS, and PPPoE over an Ethernet interface:
1.
Specify a Fast Ethernet, Gigabit Ethernet, or 10-Gigabit Ethernet port.
host1(config)#interface fastEthernet 4/0
2. Create an IP interface.
host1(config-if)#ip address 192.5.127.8 255.255.255.0
3. Create an MPLS interface.
host1(config-if)#mpls
4. Create a PPPoE interface by specifying PPPoE as the encapsulation method on the
interface.
host1(config-if)#pppoe
5. Create a PPPoE subinterface.
host1(config-if)#pppoe subinterface fastEthernet 4/1.1
6. Specify PPP as the encapsulation method on the interface.
host1(config-if)#encapsulation ppp
7. Assign an IP address and mask.
Copyright © 2010, Juniper Networks, Inc.
155
JunosE 11.3.x Link Layer Configuration Guide
host1(config-if)#ip address 192.6.129.5 255.255.255.0
8. (Optional) Configure additional PPPoE subinterfaces by completing Steps 5 through
7 using unique numbering.
Figure 12 on page 156 illustrates this configuration.
Figure 12: Example of IP, MPLS, and PPPoE Stacking Configuration
Procedure
mpls
•
Use to enable, disable, or delete MPLS on an interface. MPLS is disabled by default.
•
Example
host1(config)#mpls
•
Use the no version to halt MPLS on the interface and delete the MPLS interface
configuration.
•
See mpls.
L2TP and Ethernet
Most Ethernet interfaces support L2TP. To use L2TP, you must first create a PPP interface.
See L2TP Overview for information about configuring L2TP.
156
Copyright © 2010, Juniper Networks, Inc.
Chapter 4: Configuring Upper-Layer Protocols over Static Ethernet Interfaces
Multinetting and Ethernet
Ethernet interfaces, except for bridged Ethernet interfaces, support multinetting; that is,
adding more than one IP address to an IP interface. If you want to add multiple IP
addresses to a single IP interface, use the ip address command with the secondary
keyword, which is described in the chapter Configuring IP in JunosE IP, IPv6, and IGP
Configuration Guide.
Monitoring Upper-Level Protocols over Ethernet
This section explains how to use the show commands to display the physical
characteristics and the configured settings for Ethernet interfaces.
NOTE: The E120 and E320 routers output for monitor and show commands
is identical to output from other E Series routers, except that the E120 and
E320 routers output also includes information about the adapter identifier
in the interface specifier (slot/adapter/port).
You can use various show commands to monitor upper-layer protocols. For more
information, see:
•
“Configuring Point-to-Point Protocol over Ethernet” on page 371
•
Chapter Configuring IP in JunosE IP, IPv6, and IGP Configuration Guide
•
Chapter Configuring MPLS in JunosE BGP and MPLS Configuration Guide
show interfaces fastEthernet
•
Use to display the status of Fast Ethernet interfaces, VLAN subinterfaces, or S-VLAN
subinterfaces.
•
You can specify the following keywords:
•
•
delta—Specifies that baselined statistics are to be shown
•
brief—Displays the operational status of all configured interfaces
Field descriptions
•
•
•
FastEthernet interfaceSpecifier—Status of the hardware on this interface
•
up—Hardware is operational
•
down—Hardware is not operational
Administrative status—Operational state that you configured for this interface
•
up—Interface is enabled
•
down—Interface is disabled
Hardware—Type of MAC device on this interface
Copyright © 2010, Juniper Networks, Inc.
157
JunosE 11.3.x Link Layer Configuration Guide
•
Address—MAC address of the processor on this interface
•
MAU—Type of medium attachment unit (MAU) on the physical port:
•
•
•
•
158
•
10BASE-T (10 Mbps)
•
100BASE-TX (100 Mbps)
•
100BASE-FX-MM (100 Mbps) with the distance appearing after the type
•
100BASE-LX-SM (100 Mbps)
•
SFP (Empty)—SFPs that are empty
•
SFP (Non-compliant Juniper Part)—SFPs that are installed in the FE-8 I/O module
and do not have a Juniper Networks part number programmed
MTU—Size of the MTU for this interface
•
Operational—Size of the largest packet processed
•
Administrative—Setting for MTU size that you specified
Duplex Mode—Duplex option for this interface
•
Operational—Duplex option currently used
•
Administrative—Setting for duplex that you specified
Speed—Line speed for this interface
•
Operational—Current rate at which packets are processed
•
Administrative—Setting for line speed
•
5 minute input rate—Data rates based on traffic received in the last 5 minutes
•
5 minute output rate—Data rates based on traffic sent in the last 5 minutes
In—Analysis of inbound traffic on this interface
•
Bytes—Number of bytes received in error-free packets
•
Unicast—Number of unicast packets received
•
Multicast—Number of multicast packets received
•
Broadcast—Number of broadcast packets received
•
Errors—Total number of errors in all received packets; some packets might contain
more than one error
•
Discards—Total number of discarded incoming packets
•
Mac Errors—Number of incoming packets discarded because of MAC sublayer
failures
•
Alignment—Number of incomplete octets received
Copyright © 2010, Juniper Networks, Inc.
Chapter 4: Configuring Upper-Layer Protocols over Static Ethernet Interfaces
•
•
•
•
CRC—Number of packets discarded because the checksum the router computed
from the data does not match the checksum generated by the originating devices
•
Too Longs—Number of packets discarded because the size exceeded the MTU
•
Symbol Errors—Number of symbols received that the router did not correctly
decode
Out—Analysis of outbound traffic on this interface
•
Bytes—Number of bytes sent
•
Unicast—Number of unicast packets sent
•
Multicast—Number of multicast packets sent
•
Broadcast—Number of broadcast packets sent
•
Errors—Total number of errors in all transmitted packets; some packets might
contain more than one error
•
Discards—Total number of discarded outgoing packets
•
Mac Errors—Number of outgoing packets discarded because of MAC sublayer
failures
•
Deferred—Number of packets that the router delayed sending because the line
was busy. In half duplex mode, a high number of deferrals means the link is very
busy with traffic from other stations. In full duplex mode, when the link is always
available for transmission, this number is zero.
•
No Carrier—Number of packets sent when carrier sense was unavailable
Collisions—Analysis of the collisions that occurred
•
Single—Number of packets sent after one collision
•
Multiple—Number of packets sent after multiple collisions
•
Late—Number of packets aborted during sending because of collisions after 64
bytes
•
Excessive—Number of packets not sent because of too many collisions
ARP Statistics—Analysis of ARP traffic on this interface; In fields are for traffic received
on the interface and Out fields are for traffic sent on the interface
•
ARP requests—Number of ARP requests
•
ARP responses—Number of ARP responses
Copyright © 2010, Juniper Networks, Inc.
159
JunosE 11.3.x Link Layer Configuration Guide
•
•
•
Errors—Total number of errors in all ARP packets
•
Discards—Total number of discarded ARP packets
queue—Hardware packet queue associated with the specified traffic class and
interface
•
Queue length—Length of the queue, in bytes
•
Forwarded packets, bytes—Number of packets and bytes that were forwarded on
this queue
•
Dropped committed packets, bytes—Number of committed packets and bytes
that were dropped
•
Dropped conformed packets, bytes—Number of conformed packets and bytes
that were dropped
•
Dropped exceeded packets, bytes—Number of exceeded packets and bytes that
were dropped
Example—Displays the status of a Fast Ethernet interface
host1:vr2#show interfaces fastEthernet 2/0
FastEthernet2/0 is Up, Administrative status is Up
Hardware is Intel 21440, address is 0090.1a10.0552 MAU is 10BASE-T
MTU: Operational 1518, Administrative 1518
Duplex Mode: Operational Full Duplex, Administrative Auto Negotiate
Speed: Operational 100 Mbps, Administrative Auto Negotiate
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
In: Bytes 39256, Unicast 612
Multicast 0, Broadcast 0
Errors 0, Discards 0, Mac Errors 0, Alignment 0
CRC 0, Too Longs 0, Symbol Errors 0
Out: Bytes 4579036, Unicast 610
Multicast 0, Broadcast 70932
Errors 0, Discards 0, Mac Errors 0, Deferred 0, No Carrier 3
Collisions: Single 0, Multiple 0, Late 0, Excessive 0
ARP Statistics:
In: ARP requests 0, ARP responses 0
Errors 0, Discards 0
Out: ARP requests 0, ARP responses 0
Errors 0, Discards 0
Administrative qos-shaping-mode: none
Operational qos-shaping-mode: none
queue 0: traffic class control, bound to FastEthernet2/0
Queue length 0 bytes
Forwarded packets 1, bytes 46
Dropped committed packets 0, bytes 0
Dropped conformed packets 0, bytes 0
Dropped exceeded packets 0, bytes 0
•
See show interfaces.
show interfaces gigabitEthernet
160
Copyright © 2010, Juniper Networks, Inc.
Chapter 4: Configuring Upper-Layer Protocols over Static Ethernet Interfaces
show interfaces tenGigabitEthernet
•
Use to display the status of Gigabit Ethernet interfaces, 10-Gigabit Ethernet interfaces,
VLAN subinterfaces, or S-VLAN subinterfaces.
•
You can specify the following keywords:
•
•
delta—Specifies that baselined statistics are to be shown
•
brief—Displays the operational status of all configured interfaces
Field descriptions
•
•
GigabitEthernet or tenGigabitEthernet interfaceSpecifier—Status of the hardware
on this interface
•
up—Hardware is operational
•
down—Hardware is not operational
Administrative status—Operational state that you configured for this interface
•
up—Interface is enabled
•
down—Interface is disabled
•
Hardware—Type of MAC device on this interface
•
Address—MAC address of the processor on this interface
•
MAU—Type of medium attachment unit (MAU) on the primary and secondary physical
ports:
•
SFP—1000BASE-LH, 1000BASE-SX, 1000BASE-ZX; for SFPs that are empty,
SFP (Empty) appears in this field; for SFPs that are installed in the OC3-2 GE APS
I/O module and do not have a Juniper Networks part number programmed, SFP
(GE Compliant) appears in this field
•
XFP—10GBASE-SR (10 Gbps), 10GBASE-LR (10 Gbps), 10GBASE-ER (10 Gbps);
for XFPs that are empty, XFP (Empty) appears in this field
•
TX Output Power—Transmitted output optical power
•
RX Input Power—Received input optical power
•
MTU—Size of the MTU for this interface
•
•
•
Operational—Size of the largest packet processed
•
Administrative—Setting for MTU size that you specified
Duplex Mode—Duplex option for this interface
•
Operational—Duplex option currently used
•
Administrative—Setting for duplex that you specified
Speed—Line speed for this interface
Copyright © 2010, Juniper Networks, Inc.
161
JunosE 11.3.x Link Layer Configuration Guide
•
•
•
162
•
Operational—Current rate at which packets are processed
•
Administrative—Setting for line speed that you specified
Debounce—Debounce configuration for this interface
•
State is—Enabled, Disabled
•
Interval is—Number of seconds that this interface maintains a given state before
the state change is reported to the upper-layer links
Clear arp—State of the removal of the ARP entries on an interface with redundant
ports
•
Enabled—Clears ARP entries on the interface when the primary link fails
•
Disabled—Maintains ARP entries on the interface until the specified timeout elapses
Link—Link information for this interface
•
Operational Link Selected—Port that the I/O module is currently using: primary or
secondary
•
Administrative link selected—Port that the I/O module is configured to use:
•
primary—Only primary port is configured to operate
•
secondary—Only redundant port is configured to operate
•
automatically—Software controls port redundancy automatically
•
Link Failover Timeout — Time to wait for a failed link to be active before the router
uses a different active link
•
Primary link selected x times—Number of times that the I/O has used the primary
port since the module was last rebooted
•
Secondary link selected x times—Number of times that the I/O has used the
secondary port since the module was last rebooted
•
Primary/Secondary link signal detected, Primary/Secondary link signal not
detected—Specifies the port (primary or secondary) on which the router detects a
signal
•
5 minute input rate—Data rates based on the traffic received in the last 5 minutes
•
5 minute output rate—Data rates based on the traffic sent in the last 5 minutes
•
In—Analysis of inbound traffic on this interface
•
Bytes—Number of bytes received in error-free packets
•
Unicast—Number of unicast packets received
•
Multicast—Number of multicast packets received
•
Broadcast—Number of broadcast packets received
Copyright © 2010, Juniper Networks, Inc.
Chapter 4: Configuring Upper-Layer Protocols over Static Ethernet Interfaces
•
•
•
Errors—Total number of errors in all received packets; some packets might contain
more than one error
•
Discards—Total number of discarded incoming packets
•
Mac Errors—Number of incoming packets discarded because of MAC sublayer
failures
•
Alignment—Number of incomplete octets received
•
CRC—Number of packets discarded because the checksum that the router
computed from the data does not match the checksum generated by the originating
devices
•
Too Longs—Number of packets discarded because the size exceeded the MTU
•
Symbol Errors—Number of symbols received that the router did not correctly
decode
Out—Analysis of outbound traffic on this interface
•
Bytes—Number of bytes sent
•
Unicast—Number of unicast packets sent
•
Multicast—Number of multicast packets sent
•
Broadcast—Number of broadcast packets sent
•
Errors—Total number of errors in all transmitted packets; note that some packets
might contain more than one error
•
Discards—Total number of discarded outgoing packets
•
Mac Errors—Number of outgoing packets discarded because of MAC sublayer
failures
•
Deferred—Number of packets that the router delayed sending because the line
was busy. In half duplex mode, a high number of deferrals means the link is very
busy with traffic from other stations. In full duplex mode, when the link is always
available for transmission, this number is zero.
•
No Carrier—Number of packets sent when carrier sense was unavailable
Collisions—Analysis of the collisions that occurred
•
Single—Number of packets sent after one collision
•
Multiple—Number of packets sent after multiple collisions
•
Late—Number of packets aborted during sending because of collisions after 64
bytes
•
Excessive—Number of packets not sent because of too many collisions
Copyright © 2010, Juniper Networks, Inc.
163
JunosE 11.3.x Link Layer Configuration Guide
•
Policed Statistics—Number of packets that exceeded the number allowed and were
policed (or dropped)
•
ARP Statistics—Analysis of ARP traffic on this interface; In fields are for traffic received
on the interface and Out fields are for traffic sent on the interface
•
•
•
164
•
ARP requests—Number of ARP requests
•
ARP responses—Number of ARP responses
•
Errors—Total number of errors in all ARP packets
•
Discards—Total number of discarded ARP packets
Administrative qos-shaping-mode—QoS shaping mode:
•
disabled—Shaping mode is configured but not operational
•
frame—Statistics are reported about bytes in frames, such as transmitted bytes
and dropped bytes.
•
cell—Shaping mode for shaping and policing rates is cell-based; resulting traffic
stream conforms exactly to the policing rates configured in downstream devices.
Reports statistics in bytes in cells and accounts for cell encapsulation and padding
overhead.
•
none—Shaping mode is not configured
Operational qos-shaping-mode—Actual shaping mode for the interface:
•
disabled
•
frame
•
cell
•
none
queue—Hardware packet queue associated with the specified traffic class and
interface
•
traffic class—Name of traffic class
•
bound to—Interface to which queue is bound
•
Queue length—Length of the queue, in bytes
•
Forwarded packets, bytes—Number of packets and bytes that were forwarded on
this queue
•
Dropped committed packets, bytes—Number of committed packets and bytes
that were dropped
Copyright © 2010, Juniper Networks, Inc.
Chapter 4: Configuring Upper-Layer Protocols over Static Ethernet Interfaces
•
•
Dropped conformed packets, bytes—Number of conformed packets and bytes
that were dropped
•
Dropped exceeded packets, bytes—Number of exceeded packets and bytes that
were dropped
Example—Displays the status of a Gigabit Ethernet interface
host1#show interfaces gigabitEthernet 14/0/0
GigabitEthernet14/0/0 is Up, Administrative status is Up
Hardware is Intel IXF1104, address is 0090.1a42.0b87
MAU is 1000BASE-SX
TX Output Power: 469.6 uW RX Input Power: 0.5 uW
MTU: Operational 1518, Administrative 1518
Duplex Mode: Operational Full Duplex, Administrative Auto Negotiate
Speed: Operational 1000 Mbps, Administrative Auto Negotiate
Debounce: State is Disabled
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
In: Bytes 0, Unicast 0
Multicast 0, Broadcast 0
Errors 0, Discards 0, Mac Errors 0, Alignment 0
CRC 0, Too Longs 0, Symbol Errors 0
Out: Bytes 0, Unicast 0
Multicast 0, Broadcast 0
Errors 0, Discards 0, Mac Errors 0, Deferred 0, No Carrier 0
Collisions: Single 0, Multiple 0, Late 0, Excessive 0
Policed Statistics:
In: 0, Out: 0
ARP Statistics:
In: ARP requests 0, ARP responses 0
Errors 0, Discards 0
Out: ARP requests 0, ARP responses 0
Example—Displays the status of a 10 Gigabit Ethernet interface
host1#show interfaces tenGigabitEthernet 4/0/0
TenGigabitEthernet4/0/0 is Up, Administrative status is Up
Hardware is Marvell GT64260, address is 0090.1a42.14b5
Primary MAU is 10000BASE-LR 10km, secondary MAU is XFP (Empty)
TX Output Power: 480.8 uW RX Input Power: 1 uW
MTU: Operational 1522, Administrative 1522
Duplex Mode: Operational Full Duplex, Administrative Full Duplex
Speed: Operational 10000 Mbps, Administrative 10000 Mbps
Debounce: State is Disabled
Link: Operational Primary Link Selected,
Administrative Link Selected Automatically
Link Failover Timeout: Operational 336 ms, Administrative default
Primary link selected 1 time, Secondary link selected 0 times
Primary link signal not detected, Secondary link signal not detected
Cleararp: State is Disabled
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
In: Bytes 0, Unicast 0
Multicast 0, Broadcast 0
Errors 0, Discards 0, Mac Errors 0, Alignment 0
CRC 0, Too Longs 0, Symbol Errors 0
Out: Bytes 768, Unicast 0
Multicast 0, Broadcast 12
Copyright © 2010, Juniper Networks, Inc.
165
JunosE 11.3.x Link Layer Configuration Guide
Errors 0, Discards 0, Mac Errors 0, Deferred 0, No Carrier 0
Collisions: Single 0, Multiple 0, Late 0, Excessive 0
Policed Statistics:
In: 0, Out: 0
ARP Statistics:
In: ARP requests 0, ARP responses 0
Errors 0, Discards 0
Out: ARP requests 0, ARP responses 0
Errors 0, Discards 0
•
166
See show interfaces.
Copyright © 2010, Juniper Networks, Inc.
CHAPTER 5
Configuring VLAN and S-VLAN
Subinterfaces
This chapter describes how to configure VLAN and S-VLAN subinterfaces on E Series
routers.
This chapter contains the following sections:
•
VLAN Overview on page 167
•
S-VLAN Overview on page 168
•
VLAN and S-VLAN Platform Considerations on page 169
•
VLAN and S-VLAN References on page 170
•
Creating a VLAN Subinterface on page 170
•
Configuring an S-VLAN Subinterface on page 178
•
Configuring S-VLAN Tunnels for Layer 2 Services over MPLS on page 182
•
S-VLAN Oversubscription on page 185
•
Monitoring VLAN and S-VLAN Subinterfaces on page 186
VLAN Overview
A virtual LAN (VLAN) enables multiplexing multiple IP and PPPoE interfaces and MPLS
interfaces over a single physical Ethernet port. This multiplexing is accomplished through
VLAN subinterfaces. Ethernet interfaces support the 802.1q-1998 IEEE Standards for
Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks, which the
router uses as its standardized format for frame tagging.
The Ethernet V2 frame format enables multiplexing of different protocols over a single
physical link. IEEE 802.1q compatibility extends the frame format by adding a tag that
contains a VLAN ID. This feature enables multiplexing of different channels (VLANs)
over the physical link; each channel is able to multiplex different protocols.
This capability works very much like ATM encapsulation as described in RFC
2684—Multiprotocol Encapsulation over ATM Adaptation Layer 5 (September 1999).
This encapsulation type enables multiplexing of multiple protocols over a single ATM
virtual circuit (VC).
Copyright © 2010, Juniper Networks, Inc.
167
JunosE 11.3.x Link Layer Configuration Guide
As shown in Figure 13 on page 168, VLANs are similar to ATM VCs, with the VLAN ID serving
the same function as the virtual path identifier (VPI) and virtual channel identifier (VCI)
to multiplex the different channels over the physical link. The Ethernet protocol type
serves the same function within a VLAN as the logical link control (LLC) subnetwork
attachment point (SNAP) within a VC, to multiplex the different protocols over the
channel.
Figure 13: Use of VLANs to Multiplex Different Protocols over a Single Physical Link
ERX14xx models (rear view)
In a VLAN configuration, the router can send VLAN 0 tagged or untagged frames.
All VLAN subinterfaces use the MAC address of the Ethernet interface over which they
are configured. However, some configurations, such as multiple IP over VLAN
subinterfaces, require that you connect many VLAN subinterfaces to a single device. In
these cases, the device uses the MAC address to identify and select the correct VLAN to
use. When the MAC address is the same for all VLANs, uneven load balancing of traffic
occurs. To ensure proper load balancing, you must assign unique MAC addresses to the
individual VLAN subinterfaces that are connected to the device. Any ARP requests and
responses generated for the IP address assigned to a VLAN subinterface use this MAC
address.
You must assign the MAC address when you configure the VLAN ID. If you change the
MAC address of the VLAN subinterface after you configure it, system errors can occur.
To change the MAC address, you must first remove the VLAN subinterface and then
reconfigure it.
For more information, see:
•
•
Chapter Configuring IP in JunosE IP, IPv6, and IGP Configuration Guide
“Configuring Point-to-Point Protocol over Ethernet” on page 371
S-VLAN Overview
As described in “VLAN Overview” on page 167, VLANs permit multiplexing multiple IP
interfaces and PPPoE interfaces over a single physical Ethernet port by creating VLAN
subinterfaces. As specified in IEEE Standard 802.1q, the 12-bit VLAN identifier’s tagged
168
Copyright © 2010, Juniper Networks, Inc.
Chapter 5: Configuring VLAN and S-VLAN Subinterfaces
frames enables the construction of a maximum of 4096 distinct VLANs. In an Ethernet
B-RAS application environment, however, this VLAN limit is inadequate. A stacked VLAN
(S-VLAN) provides a two-level VLAN tag structure, which extends the VLAN ID space to
more than 16 million VLANs.
Creating an S-VLAN requires the use of a second encapsulation tag. The router performs
decapsulation twice, once to get the S-VLAN tag and once to get the VLAN tag. This
double tagging approach enables more than 16 million address possibilities, which more
than satisfies the scaling requirement for Ethernet B-RAS applications.
VLAN and S-VLAN subinterfaces can coexist over the same VLAN major interface. You
configure S-VLANs in the same way that you configure VLANs, with the addition of certain
commands.
NOTE: See JunosE Release Notes, Appendix A, System Maximums for S-VLAN
limitations.
Like VLANs, all S-VLAN subinterfaces use the MAC address of the Ethernet interface
over which they are configured. For more information about assigning unique MAC address
to the S-VLAN subinterface when assigning VLAN or S-VLAN IDs, see “VLAN Overview”
on page 167.
VLAN and S-VLAN Platform Considerations
You can configure VLAN and S-VLAN subinterfaces on the following E Series Broadband
Services Routers:
•
E120 router
•
E320 router
•
ERX1440 router
•
ERX1410 router
•
ERX710 router
•
ERX705 router
•
ERX310 router
Module Requirements
For information about the modules supported on E Series routers:
•
See the ERX Module Guide for modules supported on ERX7xx models, ERX14xx models,
and the ERX310 router.
•
See the E120 and E320 Module Guide for modules supported on the E120 and E320
routers.
Copyright © 2010, Juniper Networks, Inc.
169
JunosE 11.3.x Link Layer Configuration Guide
Interface Specifiers
The configuration task examples in this chapter use the format for ERX7xx models,
ERX14xx models, and the ERX310 router to specify a VLAN or S-VLAN subinterface.
For ERX7xx models, ERX14xx models, and ERX310 router, use the slot/port[.subinterface
] format. For example, the following command specifies a VLAN subinterface configured
on port 0 of an I/O module in slot 4.
host1(config)#interface fastEthernet 4/0.1
For E120 and E320 routers, use the slot/adapter/port[.subinterface ] format, which includes
an identifier for the bay in which the I/O adapter (IOA) resides. For example, the following
command specifies a VLAN subinterface configured on port 0 of the IOA installed in the
upper adapter bay of slot 3.
host1(config)#interface gigabitEthernet 3/0/0.1
For more information about interface types and specifiers on E Series models, see Interface
Types and Specifiers in JunosE Command Reference Guide.
VLAN and S-VLAN References
For more information about VLAN and S-VLAN implementations, consult the following
resources:
•
IEEE 802.1q (Virtual LANs)
Creating a VLAN Subinterface
Ethernet interfaces support IP, PPPoE, MPLS, or both IP and PPPoE on each VLAN. In
addition to a VLAN major interface level, a VLAN subinterface level distinguishes the
VLAN.
NOTE: You cannot configure VLANs on the Fast Ethernet port of the SRP
module.
Tasks to configure VLAN subinterface are:
170
•
“Creating a VLAN Major Interface” on page 171
•
“Configuring IP over VLAN” on page 171
•
“Configuring PPPoE over VLAN” on page 172
•
“Configuring MPLS over VLAN” on page 173
•
“Configuring IP over VLAN and PPPoE over VLAN” on page 174
Copyright © 2010, Juniper Networks, Inc.
Chapter 5: Configuring VLAN and S-VLAN Subinterfaces
Creating a VLAN Major Interface
To use VLANs, you must first configure the Ethernet interface for VLAN encapsulation.
This creates the VLAN major interface. For example:
1.
Specify a Fast Ethernet, Gigabit Ethernet, or 10-Gigabit Ethernet port.
host1(config)#interface fastEthernet 4/0
2. Specify VLAN as the encapsulation method.
host1(config-if)#encapsulation vlan
The router creates the VLAN major interface.
You can now create multiple VLAN subinterfaces to carry higher-level protocols. For
examples, see “Creating a VLAN Subinterface” on page 170, next.
Configuring IP over VLAN
To configure IP over VLAN over an Ethernet interface:
1.
Specify a Fast Ethernet, Gigabit Ethernet, or 10-Gigabit Ethernet port.
host1(config)#interface fastEthernet 4/0
2. Specify VLAN as the encapsulation method.
host1(config-if)#encapsulation vlan
The VLAN major interface is added.
3. Create a VLAN subinterface by adding a subinterface number to the interface
identification command.
host1(config-if)#interface fastEthernet 4/0.3
4. Do one of the following:
a. Assign a VLAN ID for the subinterface.
host1(config-if)#vlan id 201
b. Assign a VLAN ID and the optional unique MAC address for the subinterface.
host1(config-if)#vlan id 201 mac-address 0090.1a01.1234
5. Assign an IP address and mask.
host1(config-if)#ip address 192.6.129.5 255.255.255.0
6. (Optional) Configure additional VLAN subinterfaces by completing Steps 3 through
5.
Figure 14 on page 172 illustrates the IP/VLAN/Fast Ethernet stacking, showing two separate
VLAN subinterfaces. Configure one VLAN subinterface entirely; then configure the next
VLAN subinterface.
Copyright © 2010, Juniper Networks, Inc.
171
JunosE 11.3.x Link Layer Configuration Guide
Figure 14: Example of IP/VLAN/Fast Ethernet Stacking Configuration
Procedure
Configuring PPPoE over VLAN
To configure PPPoE over VLAN over an Ethernet interface:
1.
Specify a Fast Ethernet, Gigabit Ethernet, or 10-Gigabit Ethernet port.
host1(config)#interface fastEthernet 4/1
2. Specify VLAN as the encapsulation method.
host1(config-if)#encapsulation vlan
The VLAN major interface is added.
3. Create a VLAN subinterface by adding a subinterface number to the interface
identification command.
host1(config-if)#interface fastEthernet 4/1.1
4. Do one of the following:
•
Assign a VLAN ID for the subinterface.
host1(config-if)#vlan id 201
•
Assign a VLAN ID and the optional unique MAC address for the subinterface.
host1(config-if)#vlan id 201 mac-address 0090.1a01.1234
5. Specify PPPoE as the encapsulation method on the interface.
host1(config-if)#pppoe
6. Create a PPPoE subinterface.
host1(config-if)#pppoe subinterface fastEthernet 4/1.1.1
7. Specify PPP as the encapsulation method on the interface.
172
Copyright © 2010, Juniper Networks, Inc.
Chapter 5: Configuring VLAN and S-VLAN Subinterfaces
host1(config-if)#encapsulation ppp
8. Assign an IP address and mask.
host1(config-if)#ip address 192.6.129.5 255.255.255.0
9. (Optional) Configure additional VLAN subinterfaces by completing Steps 3 through
8.
Figure 15 on page 173 illustrates the PPPoE/VLAN/Fast Ethernet stacking, showing two
separate VLAN subinterfaces. One VLAN subinterface has two PPPoE subinterfaces,
and one VLAN subinterface has one PPPoE subinterface.
Figure 15: Example of PPPoE/VLAN/Fast Ethernet Stacking Configuration Procedure
Configuring MPLS over VLAN
To configure MPLS over VLAN over an Ethernet interface:
1.
Specify a Fast Ethernet, Gigabit Ethernet, or 10-Gigabit Ethernet port.
host1(config)#interface fastEthernet 4/0
2. Specify VLAN as the encapsulation method.
host1(config-if)#encapsulation vlan
The VLAN major interface is added.
Copyright © 2010, Juniper Networks, Inc.
173
JunosE 11.3.x Link Layer Configuration Guide
3. Create a VLAN subinterface by adding a subinterface number to the interface
identification command.
host1(config-if)#interface fastEthernet 4/1.1
4. Do one of the following:
•
Assign a VLAN ID for the subinterface.
host1(config-if)#vlan id 400
•
Assign a VLAN ID and the optional unique MAC address for the subinterface.
host1(config-if)#vlan id 400 mac-address 0090.1a01.1234
5. Enable MPLS on the interface.
host1(config-if)#mpls
Figure 16 on page 174 illustrates the MPLS/VLAN/Fast Ethernet stacking, showing one
VLAN subinterface.
Figure 16: Example of MPLS/VLAN/Fast Ethernet Stacking Configuration
Procedure
Configuring IP over VLAN and PPPoE over VLAN
To configure IP over VLAN with PPPoE over the same VLAN over an Ethernet interface:
1.
Specify a Fast Ethernet, Gigabit Ethernet, or 10-Gigabit Ethernet port.
host1(config)#interface fastEthernet 4/1
2. Specify VLAN as the encapsulation method.
host1(config-if)#encapsulation vlan
The VLAN major interface is added.
3. Create a VLAN subinterface by adding a subinterface number to the interface
identification command.
host1(config-if)#interface fastEthernet 4/1.1
4. Do one of the following:
•
174
Assign a VLAN ID for the subinterface.
Copyright © 2010, Juniper Networks, Inc.
Chapter 5: Configuring VLAN and S-VLAN Subinterfaces
host1(config-if)#vlan id 400
•
Assign a VLAN ID and the optional unique MAC address for the subinterface.
host1(config-if)#vlan id 400 mac-address 0090.1a01.1234
5. Create an IP interface on the same VLAN as the PPPoE interface.
host1(config-if)#ip address 164.10.6.71 255.255.255.0
6. Specify PPPoE as the encapsulation method on the interface.
host1(config-if)#pppoe
7. Create a PPPoE subinterface.
host1(config-if)#pppoe subinterface fastEthernet 4/1.1.1
8. Specify PPP as the encapsulation method on the interface.
host1(config-if)#encapsulation ppp
9. Assign an IP address and mask.
host1(config-if)#ip address 192.6.129.5 255.255.255.0
10. (Optional) Configure additional PPPoE subinterfaces by completing Steps 7 through
9 using unique numbering.
To configure additional IP interfaces over the VLAN major interface:
1.
Create a new VLAN subinterface by adding a unique subinterface number to the
interface identification command.
host1(config-if)#interface fastEthernet 4/1.2
2. Assign a VLAN ID for the subinterface.
host1(config-if)#vlan id 401
3. Assign an IP address and mask.
host1(config-if)#ip address 164.10.6.51 255.255.255.0
Figure 17 on page 176 illustrates the configuration steps for two VLAN subinterfaces. In
this example:
•
VLAN subinterface 4/1.1 has an IP interface, a PPPoE interface, and multiple PPPoE
subinterface stacks.
•
VLAN subinterface 4/1.2 has only an IP interface.
NOTE: Before you can remove a VLAN subinterface, you must remove the
upper-layer interface stack.
Copyright © 2010, Juniper Networks, Inc.
175
JunosE 11.3.x Link Layer Configuration Guide
Figure 17: Example of PPPoE over VLAN with IP over VLAN Stacking Configuration Procedure
encapsulation ppp
•
Use to configure PPP as the encapsulation method for the interface.
•
Example
host1(config-if)#encapsulation ppp
•
Use the no version to disable PPP on the interface.
•
See encapsulation ppp.
•
Use to configure VLAN as the encapsulation method for the interface.
•
Example
encapsulation vlan
host1(config-if)#encapsulation vlan
•
Use the no version to disable VLAN on an interface.
•
See encapsulation vlan.
•
Use to set a primary or secondary IP address for an interface or subinterface.
•
Specify the layer 2 encapsulation before you set the IP address.
ip address
176
Copyright © 2010, Juniper Networks, Inc.
Chapter 5: Configuring VLAN and S-VLAN Subinterfaces
•
Example
host1(config-if)#ip address 192.6.129.5 255.255.255.0
•
Use the no version to remove an IP address or disable IP processing.
•
See ip address.
•
Use to configure PPPoE as the encapsulation method on the interface.
•
Example
pppoe
host1(config-if)#pppoe
•
Use the no version to disable PPPoE on the interface.
•
See pppoe.
pppoe subinterface fastEthernet
•
Use to create a PPPoE subinterface on a Fast Ethernet interface.
•
Example
host1(config-if)#pppoe subinterface fastEthernet 4/1.1.1
•
Use the no version to remove a PPPoE subinterface on a Fast Ethernet interface.
•
See pppoe subinterface.
pppoe subinterface gigabitEthernet
pppoe subinterface tenGigabitEthernet
•
Use to create a PPPoE subinterface on a Gigabit Ethernet interface or on a 10-Gigabit
Ethernet interface.
•
Example 1—Creates a PPPoE subinterface on an ERX7xx model, ERX14xx model, or
the ERX310 router
host1(config-if)#pppoe subinterface gigabitEthernet 4/2.1.1
•
Example 2—Creates a PPPoE subinterface on the E320 router
host1(config-if)#pppoe subinterface tenGigabitEthernet 4/0/2.1.1
•
Use the no version to remove a PPPoE subinterface on a Gigabit Ethernet interface or
on a 10-Gigabit Ethernet interface.
•
See pppoe subinterface.
•
Use to assign an alias or description to a VLAN subinterface.
•
You can use a maximum of 64 characters for the description or to name the alias.
•
Example
vlan description
host1(config-if)#vlan description randolph56a
Copyright © 2010, Juniper Networks, Inc.
177
JunosE 11.3.x Link Layer Configuration Guide
•
Use the no version to remove the VLAN description.
•
See vlan description.
•
Use to specify the VLAN ID.
•
Use a VLAN ID that is in the range 0–4095 and is unique within the Ethernet interface.
•
Issue the vlan id command before any upper bindings are made, such as IP or PPPoE.
•
Use the mac-address keyword to specify a unique MAC address for the VLAN
subinterface. When you do not specify a unique MAC address, the VLAN uses the MAC
address of the Ethernet interface.
•
Use the optional keyword untagged to specify that frames be sent untagged. The
keyword is valid only for VLAN ID 0. Tagged frames can be received, but untagged
frames are sent.
•
Examples
vlan id
host1(config-if)#vlan id 400
host1(config-if)#vlan id 4 255 mac-address 0090.1a01.1234
•
There is no no version.
•
See vlan id.
Configuring an S-VLAN Subinterface
Tasks to configure a S-VLAN subinterface include:
•
“Configuring an S-VLAN Subinterface” on page 178
•
“Configuring PPPoE over an S-VLAN” on page 179
Configuring an S-VLAN Subinterface
To configure an S-VLAN subinterface:
1.
Specify a Fast Ethernet, Gigabit Ethernet, or 10-Gigabit Ethernet port.
host1(config)#interface fastEthernet 4/0
2. Specify VLAN as the encapsulation method.
host1(config-if)#encapsulation vlan
The VLAN major interface is added.
3. Create a VLAN subinterface by adding a subinterface number to the interface
identification command.
host1(config-if)#interface fastEthernet 4/1.1
4. Assign an S-VLAN ID and a VLAN ID for the subinterface.
host1(config-if)#svlan id 4 255
178
Copyright © 2010, Juniper Networks, Inc.
Chapter 5: Configuring VLAN and S-VLAN Subinterfaces
5. Assign an S-VLAN Ethertype.
host1(config-if)#svlan ethertype 88a8
Configuring PPPoE over an S-VLAN
To configure PPPoE over an S-VLAN over an Ethernet interface:
1.
Specify a Fast Ethernet, Gigabit Ethernet, or 10-Gigabit Ethernet port.
host1(config)#interface fastEthernet 4/0
2. Specify VLAN as the encapsulation method.
host1(config-if)#encapsulation vlan
The VLAN major interface is added.
3. Create a VLAN subinterface by adding a subinterface number to the interface
identification command.
host1(config-if)#interface fastEthernet 4/1.1
4. Assign an S-VLAN ID and a VLAN ID for the subinterface.
host1(config-if)#svlan id 4 255
5. Assign an S-VLAN Ethertype.
host1(config-if)#svlan ethertype 88a8
6. Specify PPPoE as the encapsulation method on the interface.
host1(config-if)#pppoe
7. Create a PPPoE subinterface.
host1(config-if)#pppoe subinterface fastEthernet 4/1.1.1
8. Specify PPP as the encapsulation method on the interface.
host1(config-if)#encapsulation ppp
9. Assign an IP address and mask.
host1(config-if)#ip address 164.10.6.61 255.255.255.0
10. (Optional) Configure additional PPPoE subinterfaces by completing Steps 7 through
9 using unique numbering.
Figure 18 on page 180 shows one S-VLAN subinterface with multiple PPPoE subinterface
stacks.
NOTE: Before you can remove an S-VLAN/VLAN subinterface, you must
remove the upper-layer interface stack.
Copyright © 2010, Juniper Networks, Inc.
179
JunosE 11.3.x Link Layer Configuration Guide
Figure 18: Example of PPPoE over S-VLAN Stacking Configuration Procedure
encapsulation ppp
•
Use to configure PPP as the encapsulation method for the interface.
•
Use the no version to remove PPP as the encapsulation method on the interface.
•
See encapsulation ppp.
•
Use to configure VLAN as the encapsulation method for the interface.
•
Use the no version to remove VLAN as the encapsulation method on the interface.
•
See encapsulation vlan.
•
Use to set a primary or secondary IP address for an interface or subinterface.
•
Specify the layer 2 encapsulation before you set the IP address.
•
Use the no version to remove an IP address or disable IP processing.
•
See ip address.
•
Use to configure PPPoE as the encapsulation method on the interface.
•
Use the no version to disable PPPoE on the interface.
•
See pppoe.
encapsulation vlan
ip address
pppoe
180
Copyright © 2010, Juniper Networks, Inc.
Chapter 5: Configuring VLAN and S-VLAN Subinterfaces
pppoe subinterface fastEthernet
•
Use to create a PPPoE subinterface on a Fast Ethernet interface.
•
Use the no version to remove a PPPoE subinterface on a Fast Ethernet interface.
•
See pppoe subinterface.
pppoe subinterface gigabitEthernet
pppoe subinterface tenGigabitEthernet
•
Use to create a PPPoE subinterface on a Gigabit Ethernet interface or on a 10-Gigabit
Ethernet interface.
•
Use the no version to remove a PPPoE subinterface on a Gigabit Ethernet interface or
on a 10-Gigabit Ethernet interface.
•
See pppoe subinterface.
•
Use to assign an Ethertype value for the S-VLAN subinterface.
•
Choose one of the following Ethertype values:
svlan ethertype
•
8100—Specifies Ethertype value 0x8100, as defined in IEEE Standard 802.1q
•
88a8—Specifies Ethertype value 0x88a8, as defined in draft IEEE Standard 802.1ad
•
9100—Specifies Ethertype value 0x9100, which is the default
•
Use an Ethertype value that matches the Ethertype value set on the customer premises
equipment (CPE) to which your router connects.
•
Example
host1(config-if)#svlan ethertype 8100
•
Use the no version to restore the default value, 9100.
•
See svlan ethertype.
•
Use to assign S-VLAN IDs and VLAN IDs to VLAN subinterfaces.
•
Use S-VLAN ID and VLAN ID numbers that are in the range 0–4095 and that are unique
within the Ethernet interface.
•
Use the mac-address keyword to specify a unique MAC address for the VLAN
subinterface. When you do not specify a unique MAC address, the VLAN uses the MAC
address of the Ethernet interface.
•
Examples
svlan id
host1(config-if)#svlan id 4 255
host1(config-if)#svlan id 4 255 mac-address 0090.1a01.1234
•
Issue the svlan id command before any upper bindings are made, such as IP or PPPoE.
Copyright © 2010, Juniper Networks, Inc.
181
JunosE 11.3.x Link Layer Configuration Guide
•
There is no no version.
•
See svlan id.
Configuring S-VLAN Tunnels for Layer 2 Services over MPLS
When you configure Ethernet layer 2 services over MPLS, you can create a special type
of S-VLAN called an S-VLAN tunnel that uses a single interface to tunnel traffic from
multiple VLANs across an MPLS network. The S-VLAN tunnel enables multiple VLANs,
each configured with a unique VLAN ID tag, to share a common S-VLAN ID tag when
they traverse an MPLS network.
Advantages
Using S-VLAN tunnels provides an easier and faster way to configure Ethernet layer 2
services over MPLS than using standard S-VLANs. For example, consider the network
configuration shown in Figure 19 on page 182.
Figure 19: S-VLAN Tunnels for Ethernet Layer 2 Services over MPLS
In this example, traffic from three VLAN subinterfaces must traverse the MPLS network.
To accomplish this using standard S-VLANs, you issue the following commands to
configure three separate S-VLANs with the same S-VLAN ID value and different VLAN
IDs, as follows:
host1(config-if)#svlan id 33 10
host1(config-if)#svlan id 33 20
host1(config-if)#svlan id 33 30
By contrast, using an S-VLAN tunnel achieves the same result, but requires you to issue
only a single svlan id command with the keyword any in place of the VLAN ID value. For
example, the following command creates a single interface that tunnels traffic from
VLANs configured with an S-VLAN ID of 33 and any VLAN ID to the same destination
across the MPLS network. In effect, this command tunnels traffic from all three VLANs
shown in Figure 19 on page 182.
host1(config-if)#svlan id 33 any
182
Copyright © 2010, Juniper Networks, Inc.
Chapter 5: Configuring VLAN and S-VLAN Subinterfaces
Interface Stacking
When you configure Ethernet layer 2 services over MPLS using S-VLAN tunnels, the only
interface that you can stack over an S-VLAN tunnel is an MPLS tunnel, which you configure
using the MPLS tunneling command (mpls-relay or route interface) that is appropriate
for your configuration. Attempting to configure any other interface type—such as IP, MPLS
(nontunnel), or PPPoE—over the S-VLAN tunnel causes the router to generate an error
and reject the configuration as invalid.
For details about configuring MPLS and layer 2 services over MPLS, see:
•
•
Chapter Configuring MPLS in JunosE BGP and MPLS Configuration Guide
Chapter Configuring Layer 2 Services over MPLS in JunosE BGP and MPLS Configuration
Guide
Configuration Example
This section uses the sample network topology shown in Figure 19 on page 182 to illustrate
the steps for configuring S-VLAN tunnels for Ethernet layer 2 services over MPLS.
To configure S-VLAN tunnels for Ethernet layer 2 services over MPLS:
1.
Specify a Fast Ethernet, Gigabit Ethernet, or 10-Gigabit Ethernet port.
host1(config)#interface fastEthernet 4/0
2. Specify VLAN as the encapsulation method to create the VLAN major interface.
host1(config-if)#encapsulation vlan
3. Create a VLAN subinterface.
host1(config-if)#interface fastEthernet 8/1.1
4. Create the S-VLAN tunnel. This interface tunnels traffic from VLANs configured with
an S-VLAN ID of 33 and any VLAN ID to the same destination across the MPLS network.
host1(config-if)#svlan id 33 any
5. Assign an S-VLAN Ethertype.
host1(config-if)#svlan ethertype 8100
6. Create the MPLS tunnel interface using the appropriate MPLS tunneling command
for your configuration. For example:
host1(config-if)#route interface tunnel mpls:tunnel3 45
For complete instructions on configuring the MPLS tunnel, see chapter Configuring
Layer 2 Services over MPLS in JunosE BGP and MPLS Configuration Guide.
7. Repeat Steps 1 through 6 using unique values to configure the S-VLAN tunnel and
MPLS tunnel interfaces on the remote E Series router. For example:
host2(config)#interface fastEthernet 3/1
host2(config-if)#encapsulation vlan
host2(config-if)#interface fastEthernet 3/1.1
host2(config-if)#svlan id 83 any
Copyright © 2010, Juniper Networks, Inc.
183
JunosE 11.3.x Link Layer Configuration Guide
host2(config-if)#svlan ethertype 88a8
host2(config-if)#route interface tunnel mpls:tunnel2 45
encapsulation vlan
•
Use to configure VLAN as the encapsulation method for the interface.
•
Use the no version to disable VLAN on an interface.
•
See encapsulation vlan.
•
Use to select a Fast Ethernet interface on a line module.
•
Example
interface fastEthernet
host1(config)#interface fastEthernet 3/1
•
Use the no version to remove the interface or subinterface. You must issue the no
version from the highest level down; you cannot remove an interface or subinterface
if the one above it still exists.
•
See interface fastEthernet.
•
Use to route layer 2 traffic on a specific tunnel interface.
•
Use the no version to negate this command.
route interface
NOTE: For details on the use of this command, see chapter Configuring
Layer 2 Services over MPLS in JunosE BGP and MPLS Configuration Guide.
•
See route interface.
•
Use to assign an Ethertype value for the S-VLAN tunnel interface.
•
Choose one of the following Ethertype values:
svlan ethertype
•
8100—Specifies Ethertype value 0x8100, as defined in IEEE Standard 802.1q
•
88a8—Specifies Ethertype value 0x88a8, as defined in draft IEEE Standard 802.1ad
•
9100—Specifies Ethertype value 0x9100, which is the default
•
Use an Ethertype value that matches the Ethertype value set on the customer premises
equipment (CPE) to which your router connects.
•
Example
host1(config-if)#svlan ethertype 8100
184
•
Use the no version to restore the default value, 9100.
•
See svlan ethertype.
Copyright © 2010, Juniper Networks, Inc.
Chapter 5: Configuring VLAN and S-VLAN Subinterfaces
svlan id
•
Use to create an S-VLAN tunnel interface for configuring Ethernet layer 2 services over
MPLS.
•
Assign an S-VLAN ID value in the range 0–4095 that is unique within the Ethernet
interface.
•
Use the any keyword to tunnel traffic from VLANs configured with the specified S-VLAN
ID and any VLAN ID to the same destination across an MPLS network.
•
Issue the svlan id command with the any keyword before you configure the upper
binding, which must be an MPLS tunnel interface. Attempting to configure any other
interface type over the S-VLAN tunnel causes an error.
•
Example
host1(config-if)#svlan id 1000 any
•
There is no no version.
•
See svlan id.
S-VLAN Oversubscription
When you configure S-VLAN subinterfaces over Ethernet interfaces to support dynamic
PPPoE subinterfaces, you can take advantage of S-VLAN oversubscription.
The following module combinations support S-VLAN oversubscription:
•
GE/FE line module and all of its associated I/O modules
•
GE-2 line module and the GE-2 SFP I/O module
•
GE-HDE line module and its associated I/O modules
•
OC3/STM1 GE/FE line module and the OC3-2 GE APS I/O module
•
ES2 4G LM and its associated Gigabit Ethernet and 10-Gigabit Ethernet IOAs
•
ES2 10G LM and its associated Gigabit Ethernet and 10-Gigabit Ethernet IOAs
The maximum number of S-VLANs that you can create per I/O module with PPPoE major
interfaces stacked over them is greater than the maximum number of dynamic PPPoE
subinterfaces. The maximum number of PPP interfaces supported per line module is
directly proportional to the maximum number of PPPoE subinterfaces.
As a result, you can oversubscribe S-VLANs by configuring up to the maximum number
of S-VLANs supported on these I/O modules, knowing that no more than the maximum
number of supported PPP sessions can be connected to the router at any one time.
For configuration instructions, see “Configuring Dynamic PPPoE over Static PPPoE with
Ethernet and S-VLAN Interface Columns” on page 539 in “Configuring Dynamic Interfaces”
on page 511.
Copyright © 2010, Juniper Networks, Inc.
185
JunosE 11.3.x Link Layer Configuration Guide
For specific information about the maximum number of S-VLANs supported per I/O
module and the maximum number of PPP interfaces and PPPoE subinterfaces supported
per line module, see JunosE Release Notes, Appendix A, System Maximums.
NOTE: The E120 and E320 routers can support up to two IOAs per line module.
This maximum number of S-VLANs per line module does not change if one
or two IOAs are installed.
Monitoring VLAN and S-VLAN Subinterfaces
This section explains how to display bit rate and packet rate statistics for VLAN
subinterfaces and use the show commands to display the physical characteristics and
the configured settings for VLAN and S-VLAN subinterfaces.
NOTE: The E120 and E320 routers output for monitor and show commands
is identical to output from other E Series routers, except that the E120 and
E320 routers output also includes information about the adapter identifier
in the interface specifier (slot/adapter/port).
Displaying Interface Rate Statistics for VLAN Subinterfaces
You can use the monitor vlan interface command to display bit rate and packet rate
statistics over a specified time interval for one or more VLAN subinterfaces configured
on the router.
To display interface rate statistics for VLAN subinterfaces:
1.
Log in to the router by using a local console session or a virtual terminal (vty) session
(such as a Telnet session).
While you are using the monitor vlan interface command, you must keep the console
or terminal session open and you cannot issue any other commands at the session
during this time.
For information about logging in to the router, see Accessing the CLI in JunosE System
Basics Configuration Guide.
2. Access User Exec mode or Privileged Exec mode.
For information, see Accessing Command Modes in JunosE System Basics Configuration
Guide.
3. Specify the interface identifier for each VLAN subinterface that you want to monitor.
host1#monitor vlan interface fastEthernet 0/0.1 fastEthernet 4/0.1 display-time-of-day
For information about specifying interface identifiers for VLAN subinterfaces configured
over Ethernet interfaces, see “VLAN Overview” on page 167. For information about
specifying interface identifiers for VLAN subinterfaces configured over LAG bundles,
see “Configuring a VLAN Subinterface for a LAG Bundle” on page 202.
186
Copyright © 2010, Juniper Networks, Inc.
Chapter 5: Configuring VLAN and S-VLAN Subinterfaces
By default, the router uses a 5-second time interval between polls to calculate bit
rates and packet rates for each specified VLAN subinterface. Optionally, you can use
the load-interval keyword to specify a nondefault time interval in the range 5–30
seconds.
You can also include the optional display-time-of-day keyword to show the time of
day at which the router gathers statistics for each interval. Displaying the time of day
enables you to monitor when a particular VLAN subinterface is underutilized or
overutilized.
4. Review the command output.
host1#monitor vlan interface fastEthernet 0/0.1 fastEthernet 4/0.1
display-time-of-day
Seconds
between
Time
Interface
polls
Input bps/pps
Output bps/pps
(UTC)
----------------------- -------- --------------- --------------- -------FastEthernet 0/0.1
0
--/---/-- 10:50:07
FastEthernet 4/0.1
0
--/---/-- 10:50:07
FastEthernet 0/0.1
5
120240/100
120240/100 10:50:12
FastEthernet 4/0.1
5
120000/100
120000/100 10:50:12
FastEthernet 0/0.1
5
120240/100
120240/100 10:50:17
FastEthernet 4/0.1
5
120000/100
120000/100 10:50:17
The router polls each VLAN subinterface at the specified load interval (the default
5-second interval in this example) to calculate and display bit rate and packet rate
statistics. The first line of output for each interface always displays 0 (zero) for the
number of seconds between polls, and dashes (--/--) in the Input bps/pps and Output
bps/pps columns. These values indicate that the router initially takes a baseline for
each interface against which to measure subsequent statistics. The router continues
to display subsequent lines of output for each interface at the specified load interval
until you press Ctrl+c to stop the command.
For a description of each field in the monitor vlan interface command output, see
“monitor vlan interface” on page 187.
5. When you are finished, press Ctrl+c to stop the monitor vlan interface command.
host1#^C
monitor vlan interface
•
Use to display bit rate and packet rate statistics over a specified time interval for one
or more VLAN subinterfaces.
•
You must use the monitor vlan interface command in a dedicated console or terminal
session for the duration of the monitoring session.
•
Specify the interface identifier for each VLAN subinterface that you want to monitor.
•
To specify a nondefault time interval in the range 5–30 seconds at which the router
calculates bit rate and packet rate statistics, use the optional load-interval keyword.
The default time interval is 5 seconds.
•
To display the time at which the router calculates bit rate and packet rate statistics
for the current interval, use the optional display-time-of-day keyword.
Copyright © 2010, Juniper Networks, Inc.
187
JunosE 11.3.x Link Layer Configuration Guide
•
To stop the monitor vlan interface command, press Ctrl+c.
•
Field descriptions
•
•
Interface—Interface identifier for the Ethernet or LAG interface on which the VLAN
subinterface resides
•
Seconds between polls—Number of seconds at which the router calculates bit rate
and packet rate statistics
•
Input bps/pps—Number of bits per second (bps) and packets per second (pps)
received on this interface during the specified load interval
•
Output bps/pps—Number of bits per second (bps) and packets per second (pps)
transmitted on this interface during the specified load interval
•
Time—Time of day, in hh:mm:ss format, at which the router calculates the bit rate
and packet rate statistics for the current interval
Example 1—Displays bit rate and packet rate statistics over the default (5-second)
load interval for a single VLAN subinterface
host1#monitor vlan interface fastEthernet 0/0.1
Seconds
between
Interface
polls
Input bps/pps
Output bps/pps
----------------------- -------- --------------- --------------FastEthernet 0/0.1
0
--/---/-FastEthernet 0/0.1
5
120240/100
120240/100
FastEthernet 0/0.1
5
120000/100
120000/100
FastEthernet 0/0.1
5
92400/77
92400/77
FastEthernet 0/0.1
5
88800/74
88800/74
FastEthernet 0/0.1
5
120000/100
120000/100
host1#^C
•
Example 2—Displays bit rate and packet rate statistics over a 10-second load interval
for two VLAN subinterfaces, with the time of day that the statistics were calculated
host1#monitor vlan interface fastEthernet 0/0.1 fastEthernet 4/0.1
load-interval 10 display-time-of-day
Seconds
between
Time
Interface
polls
Input bps/pps
Output bps/pps
(UTC)
----------------------- -------- --------------- --------------- -------FastEthernet 0/0.1
0
--/---/-- 10:50:33
FastEthernet 4/0.1
0
--/---/-- 10:50:33
FastEthernet 0/0.1
10
120120/100
120120/100 10:50:43
FastEthernet 4/0.1
10
120000/100
120000/100 10:50:43
FastEthernet 0/0.1
10
120000/100
120000/100 10:50:53
FastEthernet 4/0.1
10
120000/100
120000/100 10:50:53
host1#^C
188
•
There is no no version.
•
See monitor vlan interface.
Copyright © 2010, Juniper Networks, Inc.
Chapter 5: Configuring VLAN and S-VLAN Subinterfaces
Using Ethernet show Commands
Use the show commands described in this section to display information about your
Ethernet configuration and to monitor Ethernet interfaces.
show interfaces fastEthernet
•
Use to display the status of Fast Ethernet interfaces, VLAN subinterfaces, or S-VLAN
subinterfaces.
•
You can specify the following keywords:
•
•
delta—Specifies that baselined statistics are to be shown
•
brief—Displays the operational status of all configured interfaces
Field descriptions when you display the status of a Fast Ethernet VLAN or S-VLAN
subinterface
•
Subinterface number—Location of the subinterface that carries the VLAN or S-VLAN
traffic
•
Administrative status—Operational state that you configured for this interface; up
or down
•
VLAN ID—Domain number of the VLAN
•
SVLAN ID—Domain number of the stacked VLAN
•
Ethertype—Ethertype assignment for the S-VLAN subinterface, 0x8100, 0x88a8, or
0x9100; 0x9100 is the default
•
In—Analysis of inbound traffic on this interface
•
•
Bytes—Number of bytes received on the VLAN or S-VLAN subinterface
•
Packets—Sum of all unicast, broadcast, and multicast packets received on the
VLAN or S-VLAN subinterface
•
Multicast—Number of multicast packets received on the VLAN or S-VLAN
subinterface
•
Broadcast—Number of broadcast packets received on the VLAN or S-VLAN
subinterface
•
Errors—Total number of errors in all received packets; some packets might contain
more than one error
•
Discards—Total number of discarded incoming packets
Out—Analysis of outbound traffic on this interface
•
Bytes—Number of bytes sent on the VLAN or S-VLAN subinterface
•
Packets—Number of packets sent on the VLAN or S-VLAN subinterface
•
Multicast—Number of multicast packets sent on the VLAN or S-VLAN subinterface
Copyright © 2010, Juniper Networks, Inc.
189
JunosE 11.3.x Link Layer Configuration Guide
•
•
Broadcast—Number of broadcast packets sent on the VLAN or S-VLAN
subinterface
•
Errors—Total number of errors in all transmitted packets; note that some packets
might contain more than one error
•
Discards—Total number of discarded outgoing packets
Example 1—Displays the status of a Fast Ethernet VLAN subinterface
host1:vr2#show interfaces fastEthernet 8/3.1
FastEthernet8/3.1 is Up, Administrative status is Up
VLAN ID: 10, address 0090.5e00.0001
In: Bytes 39256, Packets 612
Multicast 0, Broadcast 0
Errors 0, Discards 0
Out: Bytes 4536220, Packets 70873
Multicast 0, Broadcast 70258
Errors 0, Discards 0
ARP Statistics:
In: ARP requests 1, ARP responses 0
Errors 0, Discards 0
Out: ARP requests 1, ARP responses 0
Errors 0, Discards 0
•
Example 2—Displays the status of a Fast Ethernet S-VLAN subinterface
host1:vr2#show interfaces fastEthernet 0/0.1
FastEthernet0/0.1 is Up, Administrative status is Up
SVLAN ID: 1, VLAN ID: 0, Ethertype 0x9100
In: Bytes 39256, Packets 612
Multicast 0, Broadcast 0
Errors 0, Discards 0
Out: Bytes 4536220, Packets 70873
Multicast 0, Broadcast 70258
Errors 0, Discards 0
ARP Statistics:
In: ARP requests 0, ARP responses 0
Errors 0, Discards 0
Out: ARP requests 0, ARP responses 0
Errors 0, Discards 0
•
See show interfaces.
show interfaces gigabitEthernet
show interfaces tenGigabitEthernet
190
•
Use to display the status of Gigabit Ethernet interfaces, 10-Gigabit Ethernet interfaces,
VLAN subinterfaces, or S-VLAN subinterfaces.
•
You can specify the following keywords:
•
delta—Specifies that baselined statistics are to be shown
•
brief—Displays the operational status of all configured interfaces
Copyright © 2010, Juniper Networks, Inc.
Chapter 5: Configuring VLAN and S-VLAN Subinterfaces
•
Field descriptions when you display the status of a Gigabit Ethernet or 10-Gigabit
Ethernet VLAN or S-VLAN subinterface
•
Subinterface number—Location of the subinterface that carries the VLAN or S-VLAN
traffic
•
Administrative status—Operational state that you configured for this interface; up
or down
•
VLAN ID—Domain number of the VLAN
•
SVLAN ID—Domain number of the stacked VLAN
•
Ethertype—Ethertype assignment for the S-VLAN subinterface, 0x8100, 0x88a8, or
0x9100; 0x9100 is the default
•
In—Analysis of inbound traffic on this interface
•
•
•
Bytes—Number of bytes received on the VLAN or S-VLAN subinterface
•
Packets—Sum of all unicast, broadcast, and multicast packets received on the
VLAN or S-VLAN subinterface
•
Multicast—Number of multicast packets received on the VLAN or S-VLAN
subinterface
•
Broadcast—Number of broadcast packets received on the VLAN or S-VLAN
subinterface
•
Errors—Total number of errors in all received packets; some packets might contain
more than one error
•
Discards—Total number of discarded incoming packets
Out—Analysis of outbound traffic on this interface
•
Bytes—Number of bytes sent on the VLAN or S-VLAN subinterface
•
Packets—Number of packets sent on the VLAN or S-VLAN subinterface
•
Multicast—Number of multicast packets sent on the VLAN or S-VLAN subinterface
•
Broadcast—Number of broadcast packets sent on the VLAN or S-VLAN
subinterface
•
Errors—Total number of errors in all transmitted packets; some packets might
contain more than one error
•
Discards—Total number of discarded outgoing packets
Example 1—Displays the status of a Gigabit Ethernet VLAN subinterface
host1:vr2#show interfaces gigabitEthernet 2/0.1
GigabitEthernet2/0.1 is Up, Administrative status is Up
VLAN ID: 10, address 0090.5e00.0001
Copyright © 2010, Juniper Networks, Inc.
191
JunosE 11.3.x Link Layer Configuration Guide
In: Bytes 2357, Packets 23
Multicast 0, Broadcast 0
Errors 0, Discards 0
Out: Bytes 4872, Packets 57
Multicast 0, Broadcast 0
Errors 0, Discards 0
ARP Statistics:
In: ARP requests 0, ARP responses 0
Errors 0, Discards 0
Out: ARP requests 0, ARP responses 0
Errors 0, Discards 0
•
Example 2—Displays the status of a Gigabit Ethernet S-VLAN subinterface
host1:vr2#show interfaces gigabitEthernet 2/0.2
GigabitEthernet2/0.2 is Up, Administrative status is Up
SVLAN ID: 10, VLAN ID: 100, Ethertype 0x9100
In: Bytes 2357, Packets 23
Multicast 0, Broadcast 0
Errors 0, Discards 0
Out: Bytes 4872, Packets 57
Multicast 0, Broadcast 57
ARP Statistics:
In: ARP requests 0, ARP responses 0
Errors 0, Discards 0
Out: ARP requests 0, ARP responses 0
Errors 0, Discards 0
•
See show interfaces.
•
Use to display configuration and status information for a specified VLAN subinterface
or for all VLAN subinterfaces configured on the router.
•
Use the summary keyword to display only the counts of all VLAN subinterfaces and
VLAN major interfaces configured on the router.
•
Use the mac-address keyword to display information about the VLAN subinterfaces
that were configured with unique MAC addresses.
•
Use the vlan or svlan keywords to display information about specific S-VLAN IDs or
VLAN IDs.
•
Field descriptions
show vlan subinterface
192
•
Interface—Type and specifier of the VLAN subinterface
•
Status—Status of the VLAN subinterface: up, down, dormant, lowerLayerDown,
absent
•
MTU—Maximum allowable size (in bytes) of the maximum transmission unit (MTU)
for the VLAN subinterface
•
Svlan Id—S-VLAN ID value, if configured
•
Vlan Id—VLAN ID value for the VLAN subinterface
Copyright © 2010, Juniper Networks, Inc.
Chapter 5: Configuring VLAN and S-VLAN Subinterfaces
•
Ethertype—S-VLAN Ethertype value, if configured
•
Type—Type of VLAN subinterface
•
•
•
•
Static—VLAN or S-VLAN subinterface was configured statically
•
Dynamic—VLAN or S-VLAN subinterface was configured dynamically
In—Analysis of inbound traffic on this interface
•
Bytes—Number of bytes received on the VLAN or S-VLAN subinterface
•
Packets—Sum of all unicast, broadcast, and multicast packets received on the
VLAN or S-VLAN subinterface
•
Multicast—Number of multicast packets received on the VLAN or S-VLAN
subinterface
•
Broadcast—Number of broadcast packets received on the VLAN or S-VLAN
subinterface
•
Errors—Total number of errors in all received packets; some packets might contain
more than one error
•
Discards—Total number of discarded incoming packets
Out—Analysis of outbound traffic on this interface
•
Bytes—Number of bytes sent on the VLAN or S-VLAN subinterface
•
Packets—Number of packets sent on the VLAN or S-VLAN subinterface
•
Multicast—Number of multicast packets received on the VLAN or S-VLAN
subinterface
•
Broadcast—Number of broadcast packets received on the VLAN or S-VLAN
subinterface
•
Errors—Total number of errors in all transmitted packets; some packets might
contain more than one error
•
Discards—Total number of discarded outgoing packets
ARP Statistics—Analysis of ARP traffic on this interface; In fields are for traffic received
on the interface and Out fields are for traffic sent on the interface
•
ARP requests—Number of ARP requests
•
ARP responses—Number of ARP responses
Copyright © 2010, Juniper Networks, Inc.
193
JunosE 11.3.x Link Layer Configuration Guide
•
•
•
Errors—Total number of errors in all ARP packets
•
Discards—Total number of discarded ARP packets
Total VLAN interfaces—Total numbers of VLAN subinterfaces and VLAN major
interfaces configured on the router; this is the only field that appears when you specify
the summary keyword
Example 1—Displays full status and configuration information for all VLAN subinterfaces
configured on the router
host1#show vlan subinterface
Interface
Status
----------------- -------ATM 3/0.1.2
Up
ATM 3/0.1.3
Up
ATM 3/1.1.1
Up
ATM 3/1.1.2
Up
ATM 3/2.1.1
Down
FastEthernet 4/5.1 Up
6 vlan subinterfaces found
•
MTU Svlan Id
---- -------1522 ---1522 ---1522 ---1522 ---1526 4
1522 ----
Vlan Id Ethertype Type
------ --------- ------11
---Static
12
---Static
13
---Static
14
---Static
255
0x9100
Static
1
---Dynamic
Example 2—Displays full status and configuration information for the specified VLAN
subinterface
host1#show vlan subinterface fastEthernet 0/0.1
Interface
Status MTU Svlan Id Vlan Id Ethertype Type
------------------- ------ ---- -------- ------ --------- ------FastEthernet 0/0.1
Up
1526
1
0
0x9100
Static
In: Bytes 39256, Packets 612
Multicast 0, Broadcast 0
Errors 0, Discards 0
Out: Bytes 4538652, Packets 70911
Multicast 0, Broadcast 70296
Errors 0, Discards 0
ARP Statistics:
In: ARP requests 0, ARP responses 0
Errors 0, Discards 0
Out: ARP requests 0, ARP responses 0
Errors 0, Discards 0
•
Example 3—Displays only brief summary information for all VLAN subinterfaces
configured on the router
host1#show vlan subinterface summary
Total VLAN interfaces: 6 subinterfaces, 3 major interfaces
•
Example 4—Displays full status and configuration information for all VLAN subinterfaces
configured with a unique MAC address
host1#show vlan subinterface mac-address
Interface
Svlan Id Vlan Id
MAC Address
---------------------- -------- -------- -------------FastEthernet 4/0.25
---25
0090.dfad.2abd
FastEthernet 4/0.10050
1
50
0090.adad.0abd
2 vlan subinterfaces found
194
Copyright © 2010, Juniper Networks, Inc.
Chapter 5: Configuring VLAN and S-VLAN Subinterfaces
•
Example 5—Displays full status and configuration information for a VLAN subinterface
on a LAG bundle
host1#show vlan subinterface lag boston.1
Interface
Status MTU Svlan Id Vlan Id Ethertype Type
---------------- -------- ---- -------- -------- --------- -----lag boston.1
Up
1522 ---1
---Static
•
Example 6—Displays full status and configuration information for the specified S-VLAN
ID
host1#show vlan subinterface svlan 100 53
Interface
Status MTU
------------------------ ------ ---FastEthernet 0/0.1
Up
1526
FastEthernet 4/6.1
Up
1526
2 vlan subinterfaces found
•
Svlan Id
-------100
100
Vlan Id Ethertype Type
-------- --------- ------53
0x9100
Static
53
0x9100
Dynamic
See show vlan subinterface.
Copyright © 2010, Juniper Networks, Inc.
195
JunosE 11.3.x Link Layer Configuration Guide
196
Copyright © 2010, Juniper Networks, Inc.
CHAPTER 6
Configuring 802.3ad Link Aggregation and
Link Redundancy
This chapter describes how to configure 802.3ad link aggregation and link redundancy
on E Series routers.
This chapter contains the following sections:
•
802.3ad Link Aggregation for Ethernet Overview on page 197
•
802.3ad Link Aggregation Platform Considerations on page 199
•
802.3ad Link Aggregation References on page 200
•
Configuring 802.3ad Link Aggregation on page 200
•
Example: Configuring an IP Interface for a LAG Bundle on page 205
•
Example: Configuring a PPPoE Subinterface for a LAG Bundle on page 205
•
Example: Configuring a PPPoE Subinterface over a VLAN for a LAG Bundle on page 206
•
Example: Configuring MPLS for a LAG Bundle on page 207
•
Example: Configuring MPLS over a VLAN for a LAG Bundle on page 207
•
Ethernet Link Redundancy Overview on page 208
•
Ethernet Link Redundancy Behavior on page 212
•
Configuring Ethernet Link Redundancy on page 217
•
Monitoring 802.3ad Link Aggregation on page 218
802.3ad Link Aggregation for Ethernet Overview
IEEE 802.3ad link aggregation enables you to group Ethernet interfaces at the physical
layer to form a single link layer interface, also known as a link aggregation group (LAG)
or bundle. For more information, see IEEE Standard 802.3ad, Link Aggregation.
Some users require more bandwidth in their network than a single Fast Ethernet link can
provide, but cannot afford the expense or do not need the bandwidth of a higher-speed
Gigabit Ethernet link. Using IEEE 802.3ad link aggregation in this situation provides
increased port density and bandwidth at lower cost. For example, if you need 450 Mbps
of bandwidth to transmit data and have only a 100-Mbps Fast Ethernet link, creating a
LAG bundle containing five 100-Mbps Fast Ethernet links is more cost effective than
purchasing a single Gigabit Ethernet link.
Copyright © 2010, Juniper Networks, Inc.
197
JunosE 11.3.x Link Layer Configuration Guide
For information about the modules that support link aggregation, see ERX Module Guide,
Appendix A, Module Protocol Support and E120 and E320 Module Guide, Appendix A, IOA
Protocol Support.
LACP
The Link Aggregation Control Protocol (LACP) is a mechanism for exchanging port and
system information to create and maintain LAG bundles. The LAG bundle distributes
MAC clients across the link layer interface and collects traffic from the links to present
to the MAC clients of the LAG bundle.
To create the links in the LAG bundles, you can add one or more Ethernet physical
interfaces to it. The LACP detects Ethernet interfaces as links if they are configured on
the same line module and have the same physical layer characteristics. The LACP also
assigns to the LAG bundle the same MAC address of the Ethernet link with the highest
port priority, which is the lowest value.
The LACP also controls the exchange of LACP protocol data units (PDUs) between the
Ethernet links in the LAG bundle. The PDUs contain information about each link and
enable the LAG bundle to maintain them.
By default, Ethernet links do not exchange PDUs, which contain information about the
state of the link. You can configure Ethernet links to actively transmit PDUs, or passively
transmit them, sending out LACP PDUs only when it receives them from another link.
The transmitting link is known as the Actor and the receiving link is known as the Partner.
Higher-Level Protocols
After you configure the LAG bundle, you can route IP traffic over it, create a VLAN over
it, route PPPoE traffic over it, or route MPLS traffic over it.
Figure 20 on page 198 displays the interface stack for 802.3ad link aggregation.
Figure 20: Interface Stack for 802.3ad Link Aggregation
IP
OR
VLAN
OR
PPPoE
OR
MPLS
802.3ad Link Agg
regation Interf
ace
MAC
MAC
MAC
net Fast Ether
net Fast Ether
net
Fast Ether
net Fast Ether
interface
interface
interface
interface
4/2
4/3
4/5
4/0
LAG bundle
g016437
MAC
For information about configuring higher-level protocols over VLANs, see “Configuring
VLAN and S-VLAN Subinterfaces” on page 167.
198
Copyright © 2010, Juniper Networks, Inc.
Chapter 6: Configuring 802.3ad Link Aggregation and Link Redundancy
NOTE: On the ES2 10G LM and ES2-S1 GE-8 IOA combination, you can only
configure IP or VLAN over a LAG bundle.
Load Balancing and QoS
You can configure load balancing across 802.3ad links to provide quality of service (QoS).
To ensure that QoS is symmetrically applied to all the links, the router periodically
rebalances the traffic on the LAG. When you attach a QoS profile to the LAG, the load
balancing properties that are configured are applied to the LAG, and determines how
traffic is distributed.
For example, if VLANs are configured, IP queues are provisioned over the VLANs. In this
case, the default behavior is per-VLAN load balancing.
For more information, see Providing QoS for Ethernet Overview.
Ethernet Link Aggregation and MPLS
CE-side load balancing in a Martini layer 2 transport environment enables an E Series
router to interoperate with an 802.3ad switch in a topology designed for Ethernet link
aggregation. See chapter Configuring Layer 2 Services over MPLS in JunosE BGP and MPLS
Configuration Guide for more information.
802.3ad Link Aggregation Platform Considerations
You can configure 802.3ad link aggregation on the following E Series Broadband Services
Routers:
•
E120 router
•
E320 router
•
ERX1440 router
•
ERX1410 router
•
ERX710 router
•
ERX705 router
•
ERX310 router
Module Requirements
For information about the modules that support 802.3ad link aggregation on ERX14xx
models, ERX7xx models, and the ERX310 router:
•
See ERX Module Guide, Table 1, Module Combinations for detailed module specifications.
•
See ERX Module Guide, Appendix A, Module Protocol Support for information about the
modules that support 802.3ad link aggregation.
Copyright © 2010, Juniper Networks, Inc.
199
JunosE 11.3.x Link Layer Configuration Guide
For information about the modules that support 802.3ad link aggregation on the E120
and E320 routers:
•
See E120 and E320 Module Guide, Table 1, Modules and IOAs for detailed module
specifications.
•
See E120 and E320 Module Guide, Appendix A, IOA Protocol Support for information
about the modules that support 802.3ad link aggregation.
Interface Specifiers
The configuration task examples in this chapter use the format for ERX7xx models,
ERX14xx models, and the ERX310 router to specify 802.3ad link aggregation.
For example, the following command specifies a Gigabit Ethernet interface on port 0 of
an I/O module in slot 4.
host1(config)#interface gigabitEthernet 4/0
When you configure a Gigabit Ethernet interface or a 10-Gigabit Ethernet interface on
E120 or E320 routers, you must include the adapter identifier as part of the interface
specifier. For example, the following command specifies a Gigabit Ethernet interface on
port 0 of the IOA installed in the upper adapter bay of slot 3.
host1(config)#interface gigabitEthernet 3/0/0
For more information about interface types and specifiers on E Series models, see Interface
Types and Specifiers in JunosE Command Reference Guide.
802.3ad Link Aggregation References
For more information about 802.3ad link aggregation implementations, consult the
following resources:
•
IEEE 802.1w (Rapid Reconfiguration of Spanning Tree)
•
IEEE 802.3ad (Link Aggregation)
Configuring 802.3ad Link Aggregation
To configure link aggregation on Ethernet interfaces, you must configure the Ethernet
interface, create the LAG bundle, and add the Ethernet interface as a member link in the
LAG bundle. Optionally, you can then configure IP, a VLAN subinterface, a PPPoE
subinterface, or MPLS for the LAG bundle.
For more information about specifying LAG interfaces and subinterfaces on E Series
routers, see Interface Types and Specifiers in JunosE Command Reference Guide.
Tasks to configure 802.3ad link aggregation interfaces are:
200
•
“Configuring an Ethernet Physical Interface” on page 201
•
“Configuring a LAG Bundle” on page 201
Copyright © 2010, Juniper Networks, Inc.
Chapter 6: Configuring 802.3ad Link Aggregation and Link Redundancy
•
“Configuring IP for a LAG Bundle” on page 201
•
“Configuring a VLAN Subinterface for a LAG Bundle” on page 202
•
“Configuring a PPPoE Subinterface for a LAG Bundle” on page 202
•
“Configuring MPLS for a LAG Bundle” on page 202
Configuring an Ethernet Physical Interface
To configure a member link, perform the following steps:
1.
Specify a Fast Ethernet or Gigabit Ethernet interface for which you want to create a
member link.
host1(config)#interface gigabitEthernet 2/0
2. Configure LACP in passive or active mode.
host1(config-if)#lacp active
3. Specify the speed and the duplex mode for the Ethernet interface.
host1(config-if)#speed 100
host1(config-if)#duplex full
4. Specify the MTU.
host1(config-if)#mtu 9000
5. To configure additional member links, repeat steps 1 through 4.
NOTE: All of the member links that you configure must be on the same
line module and have the same physical layer characteristics, such as
speed, duplex mode, and MTU.
Configuring a LAG Bundle
To configure a LAG bundle and add member links, perform the following steps:
1.
Create the LAG bundle.
host1(config)#interface lag bundleBoston
2. Add a member link to the LAG bundle.
host1(config-if)#member–interface gigabitEthernet 2/0
3. (Optional) Configure the minimum number of member links required in the LAG bundle
for the LAG interface to be considered up.
host1(config-if)#minimum-links 2
Configuring IP for a LAG Bundle
To configure IP for a LAG bundle, perform the following steps:
1.
Specify the LAG bundle.
Copyright © 2010, Juniper Networks, Inc.
201
JunosE 11.3.x Link Layer Configuration Guide
host1(config)#interface lag bundleBoston
2. Assign an IP address and mask.
host1(config-if)#ip address 192.5.127.8 255.255.255.0
Configuring a VLAN Subinterface for a LAG Bundle
To configure a VLAN subinterface for the LAG bundle, perform the following steps:
1.
Specify VLAN as the encapsulation method.
host1(config-if)#encapsulation vlan
2. Specify the VLAN subinterface for the LAG bundle by adding a unique subinterface
number to the LAG interface identification command.
host1(config)#interface lag bundleBoston.1
3. Assign a VLAN ID for the subinterface.
host1(config-if)#vlan id 203
4. Assign an IP address and mask.
host1(config-if)#ip address 192.168.1.1 255.255.0.0
Configuring a PPPoE Subinterface for a LAG Bundle
To configure a PPPoE subinterface for the LAG bundle, perform the following steps:
1.
Specify PPPoE as the encapsulation method.
host1(config-if)#encapsulation pppoe
2. Specify the PPPoE subinterface for the LAG bundle in either of the following ways:
•
Use the interface lag command to add a unique subinterface number to the LAG
bundle name.
host1(config)#interface lag bundleBoston.2
•
Use the pppoe subinterface lag command to add a unique subinterface number
to the LAG bundle name.
host1(config)#pppoe subinterface lag bundleBoston.2
3. Specify PPP as the encapsulation method on the PPPoE subinterface.
host1(config-if)#encapsulation ppp
4. Assign an IP address and mask.
host1(config-if)#ip address 192.168.1.2 255.255.0.0
You can also configure a PPPoE subinterface over a VLAN subinterface over a LAG bundle.
For an example of this configuration, see “Example: Configuring a PPPoE Subinterface
over a VLAN for a LAG Bundle” on page 206.
Configuring MPLS for a LAG Bundle
To configure MPLS for a LAG bundle, perform the following steps:
202
Copyright © 2010, Juniper Networks, Inc.
Chapter 6: Configuring 802.3ad Link Aggregation and Link Redundancy
1.
Specify the LAG bundle.
host1(config)#interface lag bundleBoston
2. Create an MPLS interface.
host1(config-if)#mpls
interface lag
•
Use to create an IEEE 802.3ad LAG interface, also known as a LAG bundle, or a
subinterface for the LAG bundle.
•
Examples
host1(config)#interface lag boston
host1(config)#interface lag boston.2
host1(config)#interface lag boston.2.1
•
Use the no version to delete the LAG bundle.
•
See interface lag.
•
Use to configure whether an Ethernet link in a LAG bundle participates actively or
passively in the LACP.
•
Use the active keyword to indicate that the Ethernet link participates in the protocol
regardless of whether its Partner member link is set to active or passive LACP PDU
participation.
•
Use the passive keyword to indicate that the Ethernet link to transmit LACP PDUs only
when it receives LACP PDUs from its Partner member link.
•
By default, Ethernet links in a LAG bundle do not send LACP PDUs.
•
Example
lacp
host1(config-if)#lacp active
•
Use the no version to restore the default behavior.
•
See lacp.
•
Use to set the priority for an Ethernet link in a LAG bundle.
•
The member with the lowest value has the highest priority, and is selected to join the
LAG bundle first.
•
Valid values are in the range 0–65535.
•
Example
lacp port-priority
host1(config-if)#lacp port-priority 100
•
Use the no version to restore the default value of 32768.
•
See lacp port-priority.
Copyright © 2010, Juniper Networks, Inc.
203
JunosE 11.3.x Link Layer Configuration Guide
member-interface
•
Use to add a Fast Ethernet interface or Gigabit Ethernet interface, also known as a
bundle member, to a LAG bundle.
•
Example
host1(config-if)#member-interface fastEthernet 4/0
•
Use the no version to remove the specified Ethernet link from the bundle.
•
See member-interface.
•
Use to configure the minimum number of member links in the link aggregation group
(LAG) bundle for the LAG interface to be considered up. The minimum number of
member links that you can configure, depends on the IOA. For example, for ES2–S1
GE-4 IOA, the number of minimum links is in the range 0–4. For ES2–S1 GE-8 IOA, the
number of minimum links is in the range 0–8 and for ES2–S3 GE-20 IOA, the number
of minimum links is in the range 0–8.
•
Example
minimum-links
host1(config-if)#minimum—links 2
•
Use the no version to reset the minimum number of member links to the default value,
1.
•
See minimum-links
•
Use to enable, disable, or delete MPLS on an interface. MPLS is disabled by default.
•
Example
mpls
host1(config)#mpls
•
Use the no version to halt MPLS on the interface and delete the MPLS interface
configuration.
•
See mpls.
•
Use to specify the MTU for a LAG bundle.
•
Specify a value in the range 64–9188 bytes. The range for FE-8 I/O modules is 64–9042
bytes.
•
This command does not work for the Fast Ethernet port on the SRP module.
•
Example
mtu
host1(config-if)#mtu 9000
•
Use the no version to specify the default, 1518.
•
See mtu.
pppoe subinterface lag
204
Copyright © 2010, Juniper Networks, Inc.
Chapter 6: Configuring 802.3ad Link Aggregation and Link Redundancy
•
Use to create a PPPoE subinterface on a LAG bundle.
•
Example
host1(config-if)#pppoe subinterface lag boston.1
•
Use the no version to remove the PPPoE subinterface from the LAG bundle.
•
See pppoe subinterface.
•
From Global Configuration mode, use this command to create a virtual router or access
the context of a previously created virtual router or a VRF.
•
Example
virtual-router
host1(config)#virtual-router boston
•
Use the no version of the command only to delete the VR and return the router to the
default VR.
•
See virtual-router.
Example: Configuring an IP Interface for a LAG Bundle
The following example displays configuration of LACP for two Fast Ethernet interfaces
in slot 0. The interfaces are enabled for active LACP. The speed and duplex characteristics
are the same for both interfaces.
host1(config)#interface fastEthernet 0/0
host1(config-if)#speed 100
host1(config-if)#duplex full
host1(config-if)#lacp active
host1(config-if)#interface fastEthernet 0/5
host1(config-if)#speed 100
host1(config-if)#duplex full
host1(config-if)#lacp active
The following commands create a virtual router, add the Ethernet physical interfaces to
a LAG bundle named bundleBoston, and assign an IP address and mask to the bundle.
host1(config)#virtual-router boston
host1:boston(config)#interface lag boston
host1:boston(config-if)#member-interface fastEthernet 0/0
host1:boston(config-if)#member-interface fastEthernet 0/5
host1:boston(config-if)#ip address 1.1.1.1 255.255.255.0
Example: Configuring a PPPoE Subinterface for a LAG Bundle
The following example displays LACP configuration for two Fast Ethernet interfaces in
slot 4. The interfaces are enabled for passive LACP. The speed and duplex characteristics
are the same for both interfaces.
host1(config)#interface fastEthernet 4/0
host1(config-if)#speed 100
host1(config-if)#duplex full
Copyright © 2010, Juniper Networks, Inc.
205
JunosE 11.3.x Link Layer Configuration Guide
host1(config-if)#lacp passive
host1(config-if)#interface fastEthernet 4/3
host1(config-if)#speed 100
host1(config-if)#duplex full
host1(config-if)#lacp passive
The following commands add the Ethernet physical interfaces to a LAG bundle named
chicago.
host1(config)#interface lag chicago
host1(config-if)#member-interface fastEthernet 4/0
host1(config-if)#member-interface fastEthernet 4/3
The following commands configure a PPPoE subinterface for the LAG bundle named
chicago. In the LAG interface identification command (interface lag chicago.1), the
number 1 represents the subinterface number for the PPPoE subinterface.
host1(config-if)#encapsulation pppoe
host1(config)#interface lag chicago.1
host1(config-if)#encapsulation ppp
host1(config-if)#ip address 10.10.1.1 255.255.0.0
As an alternative to using the command interface lag chicago.1 to configure the PPPoE
subinterface in this example, you can also use the command pppoe subinterface lag
chicago.1 to achieve the same result. For more information, see “pppoe subinterface lag”
on page 205.
Example: Configuring a PPPoE Subinterface over a VLAN for a LAG Bundle
The following example displays LACP configuration for two Fast Ethernet interfaces in
slot 3. The interfaces are enabled for active LACP. The speed and duplex characteristics
are the same for both interfaces.
host1(config)#interface fastEthernet 3/0
host1(config-if)#speed 100
host1(config-if)#duplex full
host1(config-if)#lacp active
host1(config-if)#interface fastEthernet 3/1
host1(config-if)#speed 100
host1(config-if)#duplex full
host1(config-if)#lacp active
The following commands add the Ethernet physical interfaces to a LAG bundle named
sunnyvale.
host1(config)#interface lag sunnyvale
host1(config-if)#member-interface fastEthernet 3/0
host1(config-if)#member-interface fastEthernet 3/1
The following commands configure a VLAN subinterface for the LAG bundle named
sunnyvale. In the LAG interface identification command (interface lag sunnyvale.1), the
number 1 represents the subinterface number for the VLAN subinterface.
host1(config-if)#encapsulation vlan
host1(config)#interface lag sunnyvale.1
host1(config-if)#vlan id 100
206
Copyright © 2010, Juniper Networks, Inc.
Chapter 6: Configuring 802.3ad Link Aggregation and Link Redundancy
The following commands configure a PPPoE subinterface over the VLAN subinterface
for the LAG bundle named sunnyvale. In the LAG interface identification command
(interface lag sunnyvale.1.2), the number 2 represents the subinterface number for the
PPPoE subinterface.
host1(config-if)#encapsulation pppoe
host1(config)#interface lag sunnyvale.1.2
host1(config-if)#encapsulation ppp
host1(config-if)#ip address 10.10.2.2 255.255.0.0
As an alternative to using the command interface lag sunnyvale.1.2 to configure the
PPPoE subinterface in this example, you can also use the command pppoe subinterface
lag sunnyvale.1.2 to achieve the same result. For more information, see “pppoe
subinterface lag” on page 205.
Example: Configuring MPLS for a LAG Bundle
The following example displays configuration of LACP for two Fast Ethernet interfaces
in slot 5. The interfaces are enabled for active LACP. The speed and duplex characteristics
are the same for both interfaces.
host1(config)#interface fastEthernet 5/0
host1(config-if)#speed 100
host1(config-if)#duplex full
host1(config-if)#lacp active
host1(config-if)#interface fastEthernet 5/1
host1(config-if)#speed 100
host1(config-if)#duplex full
host1(config-if)#lacp active
The following commands create a virtual router, add the Ethernet physical interfaces to
a LAG bundle named kanata, assign an IP address, and configure MPLS.
host1(config)#virtual router kanata
host1:kanata(config)#interface lag kanata
host1:kanata(config-if)#member-interface fastEthernet 0/0
host1:kanata(config-if)#member-interface fastEthernet 0/5
host1:kanata(config-if)#ip address 1.1.1.1 255.255.255.0
host1(config-if)#mpls
Example: Configuring MPLS over a VLAN for a LAG Bundle
The following example displays configuration of LACP for two Fast Ethernet interfaces
in slot 5. The interfaces are enabled for active LACP. The speed and duplex characteristics
are the same for both interfaces.
host1(config)#interface fastEthernet 5/0
host1(config-if)#speed 100
host1(config-if)#duplex full
host1(config-if)#lacp active
host1(config-if)#interface fastEthernet 5/1
host1(config-if)#speed 100
host1(config-if)#duplex full
host1(config-if)#lacp active
Copyright © 2010, Juniper Networks, Inc.
207
JunosE 11.3.x Link Layer Configuration Guide
The following commands add the Ethernet physical interfaces to a LAG bundle named
kanata.
host1(config)#virtual router kanata
host1:kanata(config)#interface lag kanata
host1:kanata(config-if)#member-interface fastEthernet 5/0
host1:kanata(config-if)#member-interface fastEthernet 5/1
The following commands configure a VLAN subinterface for the LAG bundle named
kanata. In the LAG interface identification command (interface lag kanata.1), the number
1 represents the subinterface number for the VLAN subinterface.
host1:kanata(config-if)#encapsulation vlan
host1:kanata(config)#interface lag kanata.1
host1:kanata(config-if)#vlan id 100
The following command creates an MPLS interface.
host1:kanata(config)#mpls
Ethernet Link Redundancy Overview
You can use 802.3ad Link Aggregation (LAG) to configure Ethernet link redundancy for
Fast Ethernet and Gigabit Ethernet interfaces. Ethernet link redundancy enables you to
protect against physical link failure and account for network topology changes that
redirect network traffic to redundant ports.
The following configurations are available:
•
LAG to LAG—Provides redundancy capabilities for two or more ports that are assigned
to a LAG. One member link is configured as the backup interface for all other ports in
the LAG bundle (1:N). Traffic is not forwarded over the backup member interface; it is
disabled until it takes over for an active member interface.
•
LAG to non-LAG—Provides redundancy capabilities when redundant ports are
connected to a bridged network that has Rapid Spanning Tree Protocol (RSTP)
controlling the topology. This configuration supports only two links in the LAG.
For information about the modules that support link aggregation, see ERX Module Guide,
Appendix A, Module Protocol Support and E120 and E320 Module Guide, Appendix A, IOA
Protocol Support.
Ethernet Link Redundancy Configuration Models
The link connections determine the configuration model for link redundancy. The following
connection types are available:
208
•
Single-homed—Connections are between the local Ethernet interface and a single
remote device. When the peer is also configured with LAG, LACP can be used to control
link access.
•
Dual-homed—Connections are between two separate, uncoordinated remote devices.
The remote interfaces can be on the same module or on separate hardware. If LAG is
not configured on the peers, LACP cannot be used to select ports; other protocols such
as RSTP can be used.
Copyright © 2010, Juniper Networks, Inc.
Chapter 6: Configuring 802.3ad Link Aggregation and Link Redundancy
The type of hardware used for connections further characterizes the single-homed and
dual-homed configuration models. The following hardware types are available:
•
Homogeneous—Remote interface is on another Fast Ethernet or Gigabit Ethernet port
in a back-to-back router configuration of identical hardware and JunosE Software
versions. Both interfaces support the same redundant cabling and algorithm. The
interfaces can be cabled on the same ports (port 0–port 0, port 1–port 1) or
cross-cabled (port 0–port 1, port 1–port 0).
•
Heterogeneous—Remote interface is on a different type of hardware that might or
might not support redundant cabling, or on the same type of equipment with different
software versions. For example, a heterogeneous configuration can include an ES2-S1
GE-4 IOA and an ES2-S1 GE-8 IOA on the E320 router, or an E Series router operating
JunosE Software connected to another vendor’s router and software.
NOTE: You cannot configure link redundancy across different types of line
modules in a router. You also cannot configure link redundancy across two
GE-4 IOAs on the E120 or the E320 routers.
Figure 21 on page 209 illustrates the configuration models for Ethernet link redundancy.
Figure 21: Ethernet Link Redundancy Configuration Models
Ethernet Link Redundancy Configuration Diagrams
The diagrams in this section illustrate examples of Ethernet link redundancy
configurations. The diagrams display adjacent ports bundled in a LAG.
GE-2 Line Module
Configurations
These diagrams compare physical port redundancy and link redundancy on a GE-2 line
module.
Copyright © 2010, Juniper Networks, Inc.
209
JunosE 11.3.x Link Layer Configuration Guide
Figure 22 on page 210 displays a GE-2 line module with physical port redundancy on both
ports.
Figure 22: GE-2 Line Module Using Physical Port Redundancy
Figure 23 on page 210 displays a single-homed configuration with port 0 backing up port
1 on a GE-2 line module.
Figure 23: Single-Homed GE-2 Line Module Configuration
FE-8 Line Module
Configurations
Figure 24 on page 210 displays an FE-8 line module with a link failure in a 1:N single-homed
configuration.
Figure 24: Single-Homed FE-8 Line Module Configuration (1:N)
Figure 25 on page 211 displays an FE-8 line module with four redundant Ethernet links in
a 1:1 configuration.
210
Copyright © 2010, Juniper Networks, Inc.
Chapter 6: Configuring 802.3ad Link Aggregation and Link Redundancy
Figure 25: FE-8 Line Module with 4 Redundant Ethernet Links (1:1)
E120 and E320 Routers
Configurations
Figure 26 on page 211 and Figure 27 on page 212 display link redundancy configurations on
the E120 and E320 routers.
Figure 26 on page 211 displays a single-homed 1:4 configuration on an E120 router.
Figure 26: Single-Homed GE-4 IOA Configuration (1:4)
Figure 27 on page 212 displays an E320 router with 1:N configuration across IOAs.
Copyright © 2010, Juniper Networks, Inc.
211
JunosE 11.3.x Link Layer Configuration Guide
Figure 27: GE-8 IOA Configuration Across IOAs (1:N)
Dual-Homed
Configurations with
LAG Disabled
Figure 28 on page 212 displays how you can configure Ethernet link redundancy with LACP
disabled locally using a dual-homed configuration. LACP is disabled because there is no
LAG at the peer.
Figure 28: Dual-Homed Configuration (1:1)
Ethernet Link Redundancy Behavior
When you create a LAG bundle, you can configure LACP with the Disabled, Passive, or
Active states. For more information about these states, see “LACP” on page 198.
The following sections describe link redundancy behavior when the:
212
Copyright © 2010, Juniper Networks, Inc.
Chapter 6: Configuring 802.3ad Link Aggregation and Link Redundancy
•
Configuration and status of LACP changes during link failure and acquisition.
•
Configuration of the endpoints of the member links is different.
•
Configuration is LAG to non-LAG in an RSTP network.
Link Failure and Acquisition
Link failure on the local system occurs when the active link is no longer active. Failures
can be characterized as physical link failure or virtual link failure.
Each type of link failure has different requirements for detection, failover, and link
acquisition. In all cases, you configure the link to fail over when it fails by issuing
“redundant-port” on page 217 . Optionally, you can force the failover automatically by
issuing “redundant-port force-failover” on page 218 .
Protecting Against Physical Link Failure
Physical link failures can occur when a cable is cut.
To protect against physical link failure, issue the transmitter keyword with the
redundant-port command to enable or disable the local redundant link. When the
redundant link needs to be down, the link behavior in failure detection and failover follows
a similar port redundancy scheme available with line modules such as the GE-2 line
module. Disabling the transmitter also enables the remote end of the redundant link to
be in the operational Down state, which might be a requirement for third-party equipment
when supporting redundancy over LAG.
Enabling the transmitter provides for a quick LAG failover in the event one of the
non-redundant links in the LAG fail. This is particularly true when LACP has been enabled
on the LAG, because it can take several seconds for LACP to converge on a link. When
the transmitter on the remote end is enabled on the redundant link before it fails over,
the local system considers the redundant link to be viable and enables the transmitter
if it is disabled. If the remote end is disabled, the local end must enable the transmitter
and wait for the remote end to enable.
Protecting Against Virtual Link Failure
A virtual link failure can occur when the active link is no longer used by the network
because of topology changes caused by physical failure in the network. Topology changes
can occur when, for example, a link is blocked because of network protocols such as
RSTP blocking the port leading to selection of the redundant port connected to the
receiver.
To protect against virtual link failure in conjunction with network protocols, use the
packet-sampling keyword with the redundant-port command to detect link the viability.
For example, when there is a network protocol decision that changes the topology and
blocks a link to compensate for failures in the network, the system monitors the traffic
to detect the change in network topology and fails over to the redundant port if necessary.
It also determines whether the failover is successful. For more information, see “Member
Link with Non-LAG Partner” on page 215.
Copyright © 2010, Juniper Networks, Inc.
213
JunosE 11.3.x Link Layer Configuration Guide
Reverting After a Failover
When you specify the auto-revert keyword with the redundant-port command, the
redundant link reverts back to redundant mode when the failed link becomes active
again.
The system uses the following processes when the auto-revert feature is enabled (by
specifying the auto-revert keyword) or disabled.
When auto-revert is enabled:
1.
An active link fails and a redundant link becomes active.
2. The original active link becomes active.
3. The original redundant link fails over to the original active link.
4. The redundant link can fail over to any other active link again.
When auto-revert is disabled:
1.
An active link fails and a redundant link becomes active.
2. The original active link becomes active.
3. The original redundant link remains the active link.
4. You can force the link to fail over by issuing the redundant-port force-failover
command.
LACP Configuration and Member Link Behavior
By default, when a redundant member link is configured, the system disables LACP and
the transmitter on that link.
When a member link is administratively down, the link state is operationally down at the
local and remote ends, which means it does not transmit or receive PDUs.
The active link does not fail over when:
•
An active link goes down and you set the redundant member link to administratively
down.
•
An active link is set to administratively down.
LACP configurations affect member link behavior based on the local or remote endpoint.
For a remote end to include a member link in link aggregation, the two member links that
are connected must have LACP configured.
Table 10 on page 215 lists the acceptable configurations that enable redundant behavior
for LACP modes at local and remote endpoints.
214
Copyright © 2010, Juniper Networks, Inc.
Chapter 6: Configuring 802.3ad Link Aggregation and Link Redundancy
Table 10: Behavior of Member Links Using Local and Remote LACP Modes
Remote LACP Mode
Local LACP Mode
Disabled
Passive
Active
Disabled
✓
✓
–
Passive
✓
✓
✓
Active
–
✓
✓
Member Link with Non-LAG Partner
When a member link has a non-LAG partner, there are two separate links in a 1:1
configuration. To successfully configure this, you must disable LACP.
When a failover occurs and LACP is active, the partner might receive a new LAG ID and
the LACP PDUs receive a new MAC address; therefore, the member links are not
aggregated or the bundle is disabled, terminating the sessions above it.
The partner that is connected to the redundant link must not be forwarding network
traffic; that is, it is either blocked through a protocol such as RSTP, or MAC address
learning has selected the active port. The redundant link must not transmit over the
redundant link to that MAC. The behavior of the redundant link depends on the failure
detection method that is controlled by the network protocol that is blocking the port.
Ethernet Link Redundancy and RSTP
In a LAG to non-LAG configuration, you can configure redundancy capabilities when
redundant ports are connected to a bridged network that has RSTP controlling the
topology.
On external devices, we recommend that you configure RSTP-enabled bridged ports
that are connected to the LAG interfaces as edge ports to enable the ports to transition
quickly to forwarding state upon reconfiguration, and to avoid the listening and learning
states required by the spanning tree protocol. The edge port designation instructs the
local bridge that bridge loops do not exist through the interface, enabling it to skip the
listening and learning states.
Figure 29: Dual-Homed Heterogeneous Configuration in an RSTP Network
Copyright © 2010, Juniper Networks, Inc.
215
JunosE 11.3.x Link Layer Configuration Guide
Figure 29 on page 215 displays a network with RSTP enabled on Gigabit Ethernet switches
1 and 2. The local port receives bridge PDUs (BPDU), Ethernet broadcasts, and flooded
unicast packets. If Link 1 is initially active and Link 2 is the backup, initial traffic destined
for the LAG can be Ethernet broadcasts, PPPoE PDUs, or flooded Ethernet unicasts. The
responses are only sent on the active link; in this case, Link 1.
The Ethernet network topology that is managed by RSTP learns that the MAC for the
LAG group is through Link 1. Broadcasts and flooded packets are still sent on Link 2. If
Link 1 is no longer viable, but has not suffered a physical failure, then that address ages
out of the bridge databases and any packets directed to the LAG are flooded. The LAG
detects traffic on Link 2 after the minimum delay time and then fails over.
Acquiring Initial Links
In an RSTP network, the system uses the following process for acquiring new links:
1.
Based on the configuration, the system selects a link as active and the other as
redundant.
2. The spanning tree converges on a topology.
3. When convergence occurs and the status of the spanning tree ports change to
forwarding, network traffic appears on the links.
4. The local port detects the traffic and confirms the active member as active and the
other as the redundant port. Because the initial traffic is broadcast or flooded, both
ports receive the packets. However, because of the timing difference, the selected
active port remains active.
Detecting Failures
In an RSTP network, the system uses the following process for detecting when the link
has switched over due to topology changes:
1.
BPDUs are ignored on the redundant port and system time is not retrieved. Because
MAC learning forces non-flooded unicast packets to the active link, traffic to the
redundant link does not receive non-flooded packets. The most recent system time
is always retrieved when a network packet is received.
2. When the network cannot reach the active link because of topology changes, traffic
appears on the redundant link. The redundant port detects the traffic and captures
the latest timestamp. When the difference between the timestamp of the first
non-bridged PDU and the time the last packet that was received on the active port is
sufficiently large to account for the minimum spanning tree convergence time and
latency for flooded and broadcast packets, then the port fails over.
Failing Over
In an RSTP network, the system uses the following process to fail over:
1.
When the link has failed over, the system monitors the previously active port.
2. When a network packet is received on the redundant port, the system retrieves the
timestamp. If the difference in timestamps between that one and the most recent on
the current active port is more than the configured failover delay time, then the link
216
Copyright © 2010, Juniper Networks, Inc.
Chapter 6: Configuring 802.3ad Link Aggregation and Link Redundancy
fails over. If the difference is less than the delay time, the system ignores it but counts
the event. If many of these transitions occur in a time period, then the system
administratively brings the ports down. If no network traffic is received on either port,
then failover does not occur.
Configuring Ethernet Link Redundancy
To configure Ethernet link redundancy:
1.
Specify the Fast Ethernet or Gigabit Ethernet interface on which to configure a
redundant link.
host1(config)#interface gigabitEthernet 1/1
2. For LAG to non-LAG configurations only, specify that LACP is disabled on the port.
host1(config-if)#no lacp
3. Configure a backup interface and disable LACP on it.
host1(config)#interface gigabitEthernet 1/0
host1(config-if)#no lacp
4. Configure a LAG interface and assign a member link to the backup interface.
host1(config)#interface lag myBundle
host1(config-if)#member-interface gigabitEthernet 1/0
host1(config-if)#member-interface gigabitEthernet 1/1
5. Do one of the following:
•
Configure link redundancy on the port you specified in step 1.
host1(config-if)#redundant-port gigabitEthernet 1/1
•
Force the port you specified in step 1 to fail over.
host1(config-if)#redundant-port gigabitEthernet 1/1 force-failover
6. (Optional) Configure the redundant link to revert back to redundant mode when the
failed link becomes active again.
host1(config-if)#redundant-port gigabitEthernet 1/1 auto-revert
redundant-port
•
Use to specify a member link in a LAG bundle as redundant.
•
Use the failover timeout keyword to configure the amount of time between the current
link event leading to failover or reversion and the previous link failover or reversion. The
default value is 1000 milliseconds.
•
Use the packet-sampling keyword to configure redundancy on a LAG to non-LAG
application where packet sampling is used for failover detection. By default, packet
sampling is disabled. Use the optional delay keyword to control the minimum time
difference to force packets on the active and redundant port to fail over. The default
value is 0 milliseconds.
Copyright © 2010, Juniper Networks, Inc.
217
JunosE 11.3.x Link Layer Configuration Guide
•
Use the transmitter keyword to enable or disable the transmitter when in redundant
mode.
•
Disabling the transmitter enables the remote end of the redundant link to also be in
the operational Down state, which might be a requirement for third-party equipment
when supporting redundancy over LAG.
•
Enabling the transmitter provides for a quick LAG failover in the event one of the
non-redundant links in the LAG fail. This is particularly true when LACP has been
enabled on the LAG, because it can take several seconds for LACP to converge on
a link.
•
Use the auto-revert keyword to instruct the redundant link to revert back to redundant
mode when the failed link becomes active again. By default, auto-revert is disabled.
•
Example 1—Specifies that the Gigabit Ethernet interface in slot 4, port 0 is a redundant
member interface
host1(config-if)#redundant-port gigabitEthernet 4/0
•
Example 2—Specifies that the Gigabit Ethernet interface in slot 1, port 1 is a redundant
member interface with a packet sampling delay of 500 ms
host1(config-if)#redundant-port gigabitEthernet 1/1 packet-sampling delay 500
•
Use the no version to disable the redundant status of the member interface or disable
the specified redundancy setting for the member.
•
See redundant-port.
redundant-port force-failover
•
Use to force the specified member interface to fail over when more than one active
member exists.
•
Example
host1(config-if)#redundant-port gigabitEthernet 4/0 force-failover
•
There is no no version.
•
See redundant-port force-failover.
Monitoring 802.3ad Link Aggregation
This section explains how to use the show commands to display the characteristics and
the configured settings for 802.3ad link aggregation.
NOTE: The E120 and E320 routers output for monitor and show commands
is identical to output from other E Series routers, except that the E120 and
E320 routers output also includes information about the adapter identifier
in the interface specifier (slot/adapter/port).
show interfaces lag
218
Copyright © 2010, Juniper Networks, Inc.
Chapter 6: Configuring 802.3ad Link Aggregation and Link Redundancy
•
Use to display information about a specified Ethernet member link in an IEEE 802.3ad
link aggregation group (LAG) bundle.
•
Specify either the Fast Ethernet or Gigabit Ethernet interface type when issuing this
command:
host1#show interfaces interfaceType interfaceSpecifier lag
•
Field descriptions
•
interfaceSpecifier—Status of the hardware on this interface
•
Up—Hardware is operational
•
Down—Hardware is not operational
•
Administrative status—Operational state that you configured for this interface
•
Member—Membership status of the Ethernet link
•
LACP—Status of LACP configuration for the Ethernet link
•
•
•
active—Ethernet link participates in the protocol regardless of whether its Partner
member link is set to active or passive LACP PDU participation
•
passive—Ethernet link transmits LACP PDUs only when it receives LACP PDUs
from its Partner member link
mux state—Status of collecting and distributing at the Mux state machine
•
collecting/distributing—Ethernet link is actively collecting incoming frames and
distributing outgoing frames
•
detached—Ethernet link is detached from the LAG bundle due to protocol changes
or system constraints
•
waiting—Ethernet link is waiting to attach to a LAG bundle
LACP state
•
active—Actor link actively particulates in LACP
•
passive—Actor link transmits LACP PDUs
•
timeout—Timeout control value; this value is not configurable and is set to long
timeout (30 seconds)
•
aggregatable—Actor link can be aggregated
•
individual—Actor link cannot be aggregated; must operate as an individual link
•
in-sync—Actor link has joined the correct LAG bundle
•
out-of-sync—Actor link is unable to join the correct LAG bundle
•
collecting—Actor link is actively collecting incoming frames; if this field does not
appear, the Actor link is not actively collecting incoming frames
Copyright © 2010, Juniper Networks, Inc.
219
JunosE 11.3.x Link Layer Configuration Guide
220
•
distributing—Actor link is actively distributing outgoing frames; if this field does
not appear, the Actor link is not actively distributing outgoing frames
•
defaulted—Actor link is using defaulted operational information about the Partner
link that was administratively configured for Partner; if this field does not appear,
the operational information about the Partner link has been received by the Actor
link in an LACP PDU
•
expired—Actor link’s receive machine is expired; if this field does not appear, the
Actor link’s receive machine is active
•
port—Port number assigned to the Ethernet link by the Actor link
•
priority—Priority assigned to this Ethernet link by the Actor link
•
Key—Operational key value assigned to the Ethernet link by the Actor link
•
System Priority—Priority assigned to the Ethernet link by the system
•
System MAC Address—MAC address assigned to the Actor link
•
Partner—Status of the Partner link
•
active— Partner link participates in the LACP
•
passive—Partner link transmits LACP PDUs
•
timeout—Timeout control value; short timeout or long timeout
•
aggregatable—Partner link can be aggregated
•
individual—Partner link cannot be aggregated
•
in-sync—Partner link has joined the correct LAG bundle
•
out-of-sync—Partner link has joined the incorrect LAG bundle
•
collecting—Partner link is actively collecting incoming frames; if this field does not
appear, the Partner link is not actively collecting incoming frames
•
distributing—Partner link is actively distributing outgoing frames; if this field does
not appear, the Partner link is not actively distributing outgoing frames
•
defaulted—Partner link is using defaulted operational information about the Partner
link that was administratively configured for Partner; if this field does not appear,
the operational information about the Partner link has been received by the Actor
link in an LACP PDU
•
expired—Partner link’s receive machine is expired; if this field does not appear, the
Partner link’s receive machine is active
•
port—Port number assigned to the Ethernet link by the Partner link
•
priority—Priority assigned to the Ethernet link by the Partner link
Copyright © 2010, Juniper Networks, Inc.
Chapter 6: Configuring 802.3ad Link Aggregation and Link Redundancy
•
•
key—Operational key value assigned to the Ethernet link by the Partner link
•
age—Number of seconds since last LACP was received
•
System Priority—Priority assigned to the Ethernet link by the Partner link’s system
•
System MAC Address—MAC address assigned to the Partner link by the system
•
LACP packets—Number of transmitted and received LACP packets
•
Marker Protocol request packets—Number of Marker Protocol packets requested
to verify transmissions
•
Marker Protocol response packets—Number of Marker Protocol response packets
that verified transmissions
•
Discarded—Number of invalid LACP packets
Example
host1#show interfaces fastEthernet 4/0 lag
FastEthernet4/0 is Up, Administrative status is Up
Member of Lag boston
LACP passive, mux state collecting/distributing
LACP state (0x3c) passive, long timeout, aggregatable, in-sync,
collecting, distributing
port 0 priority 32768 key 8
System Priority 32768 System MAC Address is 0090.1a40.2043
Partner: state (0x3d) active, short timeout, aggregatable, in-sync,
collecting, distributing
port 0 priority 32768 key 8 age 25
System Priority 32768 System MAC Address is 0090.1a40.2043
LACP packets: received 8, transmitted 7
Marker Protocol request packets: received 0, transmitted 0
Marker Protocol response packets: received 0, transmitted 0
Discarded 0, unknown protocol received 0
•
See show interfaces lag.
show interfaces lag members
•
Use to display information about the Ethernet member links in all IEEE 802.3ad link
aggregation group (LAG) bundles configured on the router, or about the member links
in a specified IEEE 802.3ad LAG bundle.
•
Field descriptions
•
Lag—Name of the LAG bundle
•
Administrative status—Operational state that you configured for the LAG
•
Configured MinimumLinks—Minimum number of member links are configured for
the LAG bundle
•
Member-interface—Status of the member interface in the bundle
Copyright © 2010, Juniper Networks, Inc.
221
JunosE 11.3.x Link Layer Configuration Guide
•
•
Interface Specifier—Status of the hardware on this interface (up or down)
•
LACP active—Ethernet link participates in the protocol regardless of whether its
Partner member link is set to active or passive LACP PDU participation
•
LACP passive—Ethernet link transmits LACP PDUs only when it receives LACP
PDUs from its Partner link
•
collecting/distributing—Ethernet link is actively collecting incoming frames and
distributing outgoing frames
•
detached—Ethernet link is detached from the LAG bundle due to protocol changes
or system constraints
•
waiting—Ethernet link is waiting to attach to a LAG bundle
Example
host1#show interfaces lag members
Lag bostonBundle is Up, Administrative status is Up
Configured MinimumLinks 2
Member-interface FastEthernet0/0 is Up
(LACP active, state collecting/distributing)
Member-interface FastEthernet0/5 is Up
(LACP active, state collecting/distributing)
Lag actonBundle is Up, Administrative status is Up
Member-interface FastEthernet4/0 is Up
(LACP passive, state collecting/distributing)
Member-interface FastEthernet4/6 is Up
(LACP passive, state collecting/distributing)
2 lag interfaces found
•
222
See show interfaces lag members.
Copyright © 2010, Juniper Networks, Inc.
CHAPTER 7
Configuring IEEE 802.3ah OAM Link-Fault
Management
This chapter describes how to configure IEEE 802.3ah Operation, Administration, and
Maintenance (OAM) link-fault management on your E Series router, and contains the
following sections:
•
Ethernet OAM Link-Fault Management Overview on page 224
•
Ethernet OAM Link-Fault Management Platform Considerations on page 225
•
Ethernet OAM Link-Fault Management References on page 226
•
OAM Messages on page 226
•
OAM Elements Overview on page 227
•
OAM Client on page 228
•
OAM Sublayer on page 228
•
OAM Feature Overview on page 230
•
OAM Discovery Feature on page 230
•
OAM Link Monitoring Feature on page 232
•
OAM Remote Fault Detection Feature on page 234
•
OAM Remote and Local Loopback Feature on page 235
•
Interrelationship of OAM Link-Fault Management with Ethernet Subsystems on page 236
•
Guidelines for Configuring 802.3ah OAM Link-Fault Management on page 237
•
Configuring 802.3ah OAM Link-Fault Management on page 238
•
Example: Configuring 802.3ah OAM Link-Fault Management and Enabling Remote
Failure Monitoring on an Interface on page 244
•
Example: Enabling Remote Loopback Support on the Local Interface on page 245
•
Monitoring OAM Link-Fault Management Discovery Settings for an Interface on page 245
•
Monitoring OAM Link-Fault Management Statistics for an Interface on page 248
•
Monitoring OAM Link-Fault Management Configuration for an Interface on page 250
•
Monitoring OAM Link-Fault Management Sessions on All Configured
Interfaces on page 253
Copyright © 2010, Juniper Networks, Inc.
223
JunosE 11.3.x Link Layer Configuration Guide
Ethernet OAM Link-Fault Management Overview
The growth of Ethernet as a large-scale networking technology has propelled the necessity
for a new set of Operation, Administration, and Maintenance (OAM) protocols. Service
provider networks are large and expansive, with the need for different communication
operators to work in a combined way to deliver end-to-end services to enterprise users.
With the constant growth in the demands of enterprise end users, the need to enhance
the features and reliability of service provider Ethernet networks, especially in the areas
of availability and mean time to repair (MTTR), is steadily increasing. Ethernet OAM is
an enhancement that caters to tracking and resolving connectivity problems in circuits,
thereby improving the competitiveness of the service provider.
As DSL access infrastructure in networks worldwide migrates from ATM to Ethernet-based
connections, a requirement has evolved to enable Ethernet systems to offer the same
set of capabilities as their ATM counterparts in the fields of scalability, provisioning,
security, reliability, and manageability. A large difference exists between the ATM and
Ethernet networks in the field of OAM. Currently, a comprehensive set of OAM mechanisms
exist for ATM topologies to enable proactive monitoring of network health and
troubleshooting of network errors. In the recent past, both the Metro Ethernet Forum
(MEF) and the IEEE groups have developed OAM standards for Ethernet at both the MAC
(802.3) and High Level Interface (802.1) layers.
Ethernet MAC-layer OAM defined in IEEE Standard 802.3ah describes link-based OAM
mechanisms. These mechanisms improve the ability of a connected network element
to monitor the health of the link and the peer system. This improved ability enables the
connected network element to more quickly, proactively, and decisively react to
deteriorating or failing conditions of the link. A primary advantage of 802.3ah OAM is to
improve the member-link failover time of 802.3ad link aggregation groups (LAGs) that
are supported on all E Series router models.
NOTE: Ethernet running on top of a layer 2 protocol, such as Ethernet over
ATM, is not supported in OAM configurations.
The Ethernet OAM link fault management feature on routers running JunosE Software
interoperates with Junos platforms that implement 802.3ah, such as M Series and MX
Series routers (except M5 and M10 routers). Also, the OAM functionality integrates with
physical-level redundancy hardware available on certain IOAs, and with 802.3ad link
aggregation and link redundancy policies. The Ethernet OAM link fault management
functionality enables internal signaling about OAM link fault mechanisms to other internal
entities, such as the Ethernet application or the LAG bundle. The 802.3ah OAM capability
enables any failure in the member links of a LAG bundle to be detected and notified.
SNMP link up/down traps are generated for link up/down events that are triggered by
OAM. OAM PDUs are assigned a higher priority than regular data packets.
Related
Documentation
224
•
OAM Feature Overview on page 230
•
Ethernet OAM Link-Fault Management Platform Considerations on page 225
Copyright © 2010, Juniper Networks, Inc.
Chapter 7: Configuring IEEE 802.3ah OAM Link-Fault Management
•
Ethernet OAM Link-Fault Management References on page 226
Ethernet OAM Link-Fault Management Platform Considerations
You can configure 802.3ah link-fault management on the following E Series routers:
•
E120 router
•
E320 router
•
ERX1440 router
•
ERX1410 router
•
ERX710 router
•
ERX705 router
•
ERX310 router
Module Requirements
For information about the modules that support 802.3ah link-fault management on
ERX14xx models, ERX7xx models, and the ERX310 router:
•
See ERX Module Guide, Table 1, Module Combinations for detailed module specifications.
•
See ERX Module Guide, Appendix A, Module Protocol Support for information about the
modules that support 802.3ah link-fault management.
For information about the modules that support 802.3ah link-fault management on the
E120 and E320 routers:
•
See E120 and E320 Module Guide, Table 1, Modules and IOAs for detailed module
specifications.
•
See E120 and E320 Module Guide, Appendix A, IOA Protocol Support for information
about the modules that support 802.3ah link-fault management.
Interface Specifiers
The configuration task examples in this chapter use the format for ERX7xx models,
ERX14xx models, and the ERX310 router to specify 802.3ah link-fault management
For example, the following command specifies a Gigabit Ethernet interface on port 0 of
an I/O module in slot 4.
host1(config)#interface gigabitEthernet 4/0
When you configure a Gigabit Ethernet interface or a 10-Gigabit Ethernet interface on
E120 or E320 routers, you must include the adapter identifier as part of the interface
specifier. For example, the following command specifies a Gigabit Ethernet interface on
port 0 of the IOA installed in the upper adapter bay of slot 3.
host1(config)#interface gigabitEthernet 3/0/0
Copyright © 2010, Juniper Networks, Inc.
225
JunosE 11.3.x Link Layer Configuration Guide
For more information about interface types and specifiers on E Series models, see Interface
Types and Specifiers in JunosE Command Reference Guide.
Related
Documentation
•
Interface Types and Specifiers
Ethernet OAM Link-Fault Management References
For more information about 802.3ah link-fault management implementations, consult
the following resources:
•
IEEE 802.3ah-2004 (Clause 57, Operations, Administration, and Maintenance
[OAM])—Media Access Control Parameters, Physical Layers, and Management
Parameters for Subscriber Access Networks
•
IEEE 802.3ah-2000—Part 3: Carrier Sense multiple access with collision detection
(CSMA/CD) access methods and physical layer specifications
OAM Messages
Because 802.3ah is an optional component and not all functionalities of OAM might be
supported on a particular system, discovery mechanisms are used to ascertain the
presence and capabilities of the remote peer.
Transmitted Ethernet OAM messages or OAM PDUs are of standard length, untagged
Ethernet frames within the normal frame length limits in the range 64–1518 bytes. The
maximum OAM PDU frame size exchanged between two peers is determined during the
discovery phase. OAM PDUs contain the destination MAC address of the slow protocols
multicast (0180.c200.0002) and an Ethertype of 8809. In a slow protocol environment,
the bandwidth required is minimal and the frame transmission rate is limited to a
maximum of 10 frames per second. The first octet of the frame payload is the slow
protocol subtype field and is set to 0x03. OAM PDUs do not travel beyond a single hop
and are transmitted at a rate limited to a maximum of 10 OAM messages per second.
Certain OAM PDU types might be transmitted multiple times to improve the probability
of their successful receipt on degrading, lossy links. Figure 30 on page 226 shows the OAM
PDU format.
Figure 30: OAM PDU Format
Slow protocol subtype = 0x03
Source Address
Flags
Code
Ethertype = 8809
OAM Data / Pad
Payload
Frame Check Sequence
g016519
Destination Address =
01-80-c2-00-00-02
The Flags field is used to inform the local state to the peer. This state is used in discovery
and in remote failure detection. The Code field denotes the type of OAM packet. The
format of the OAM Data/Pad field consists of TLV elements.
Four types of OAM messages are supported:
226
Copyright © 2010, Juniper Networks, Inc.
Chapter 7: Configuring IEEE 802.3ah OAM Link-Fault Management
Related
Documentation
•
Information OAM PDU—A variable-length OAM PDU that is used for the discovery
process. This OAM PDU contains local, remote, and organization-specific information.
•
Event notification OAM PDU—A variable-length OAM PDU that is used for link
monitoring. This type of OAM PDU might be transmitted multiple times to improve the
probability of a successful receipt, such as in environments that result in high-bit errors.
Event notification OAM PDUs also include a timestamp to signify the time at which
they are triggered.
•
Loopback control OAM PDU—An OAM PDU predefined with a length of 64 bytes to
enable or disable the remote loopback command.
•
Vendor-specific OAM PDU—A variable-length OAM PDU that enables the addition of
vendor-specific extensions to OAM.
•
OAM Feature Overview on page 230
•
Configuring 802.3ah OAM Link-Fault Management on page 238
•
ethernet oam lfm
•
ethernet oam lfm remote-loopback
•
ethernet oam lfm remote-loopback supported
OAM Elements Overview
IEEE 802.3ah defines OAM procedures for a single point-to-point Ethernet link. Ethernet
OAM is a slow protocol with limited bandwidth requirements. The frame transmission
rate is limited to a maximum of 10 frames per second. As a result, the impact of OAM on
normal operations is negligible. However, when link monitoring is enabled, the CPU must
poll error counters frequently. In this case, the required processor memory and usage are
proportional to the number of interfaces that have to be polled.
Two major elements, the OAM client and the OAM sublayer, make up the Ethernet OAM.
The OAM sublayer resides above the MAC layer and below the logical link control (LLC)
layer. The OAM sublayer presents a MAC data interface to MAC clients and an OAM client
interface to OAM clients. Figure 31 on page 228 shows the OAM sublayer interfaces. For
effective interoperation and enhanced collaboration with 802.3ad link aggregation, the
OAM sublayer exists below the LAG bundle. The LAG bundle is present between the OAM
sublayer and the MAC client.
Copyright © 2010, Juniper Networks, Inc.
227
JunosE 11.3.x Link Layer Configuration Guide
Figure 31: OAM Sublayer Interfaces
OAM Client
OAM_CTL.req
MAC Client
OAMPDU.req
MAC:MA_DATA.req
802.3 OAM Client
service interface
802.3 MAC data
service interface
OAM_CTL.ind
OAMPDU.ind
MAC:MA_DATA.ind
OAM Sublayer
MAC:MA_DATA.req
MAC:MA_DATA.ind
802.3 MAC data
service interface
MAC
PHY
g016520
MAC control
The following sections describe the OAM elements:
Related
Documentation
•
OAM Client on page 228
•
OAM Sublayer on page 228
•
OAM Feature Overview on page 230
•
OAM Messages on page 226
OAM Client
The OAM client establishes and manages Ethernet OAM on a link. The OAM client also
enables and configures the OAM sublayer. During the OAM discovery stage, the OAM
client monitors OAM PDUs received from the remote peer and enables OAM functionality
on the link, depending on the local and remote states, and configuration settings. Outside
of the discovery stage, the OAM client manages the rules of response to OAM PDUs and
the OAM remote loopback mode.
Related
Documentation
•
OAM Sublayer on page 228
•
OAM Elements Overview on page 227
OAM Sublayer
The OAM sublayer presents two standard IEEE 802.3 MAC service interfaces: one pointed
toward the superior sublayers, which include the MAC client (or link aggregation), and
the other interface pointed toward the subordinate MAC control sublayer. The OAM
sublayer provides a dedicated interface for transmission of OAM control information and
OAM PDUs to and from a client.
The OAM sublayer is made up of three entities: control block, multiplexer, and packet
parser. The following sections describe each of the entities. Figure 32 on page 229 shows
228
Copyright © 2010, Juniper Networks, Inc.
Chapter 7: Configuring IEEE 802.3ah OAM Link-Fault Management
the entities of the OAM sublayer and the traversal of OAM PDUs among the different
entities.
Figure 32: OAM Sublayer Entities
OAM_CTL.req
OAMPDU.req
OAM_CTL.ind
MCF:MA_DATA.req
MCF:MA_DATA.ind
OAMPDU.ind
802.3 MAC data service interface
Control
Mux
Parser
OAM Sublayer
MAC:MA_DATA.ind
g016521
802.3 MAC data service interface
MAC:MA_DATA.req
Control Block
The control block functions as the interface between the OAM client and other blocks
internal to the OAM sublayer. The control block implements the discovery process, which
detects the existence and capabilities of remote OAM peers. It also includes the transmit
process that administers the transmission of OAM PDUs to the multiplexer and a set of
rules that manage the receipt of OAM PDUs from the packet parser.
Multiplexer
The multiplexer manages frames generated or forwarded from the MAC client, control
block, and packet parser. The multiplexer passes through frames generated by the MAC
client untouched. It sends OAM PDUs generated by the control block to the subordinate
sublayer; for example, the MAC sublayer. The multiplexer also forwards loopback frames
from the packet parser to the same subordinate sublayer when the interface is in OAM
remote loopback mode.
Parser
The parser categorizes frames as OAM PDUs, MAC client frames, or loopback frames
and then transfers each class to the appropriate entity. OAM PDUs are delivered to the
control block. MAC client frames are transmitted to the superior sublayer. Loopback
frames are distributed to the multiplexer.
Related
Documentation
•
OAM Client on page 228
•
OAM Elements Overview on page 227
Copyright © 2010, Juniper Networks, Inc.
229
JunosE 11.3.x Link Layer Configuration Guide
OAM Feature Overview
An important behavior of a carrier-class network element is the implementation of OAM
capabilities. These capabilities relate to operational fields, such as link monitoring, fault
signaling, and remote loopback across multi-vendor equipment, administrative boundaries,
and diversified physical locations. OAM capabilities currently exist in ATM and SONET
infrastructures. With the continued upgrade to Ethernet-based infrastructures, comparable
OAM functions at the MAC (802.3) level are essential. The IEEE 802.3 CSMA/CD Working
Group, using its Ethernet in First Mile (802.3ah) task force, defined a set of OAM
enhancements for Ethernet links in the 802.3ah standard. These enhancements gracefully
ensure backward compatibility with existing Ethernet implementations, while also
providing advanced monitoring functionality required in public networks.
JunosE Software supports the following OAM features:
Related
Documentation
•
OAM Discovery Feature on page 230
•
OAM Link Monitoring Feature on page 232
•
OAM Remote Fault Detection Feature on page 234
•
OAM Remote and Local Loopback Feature on page 235
•
Ethernet OAM Link-Fault Management Overview on page 224
•
Configuring 802.3ah OAM Link-Fault Management on page 238
•
Guidelines for Configuring 802.3ah OAM Link-Fault Management on page 237
OAM Discovery Feature
Discovery is the first phase of Ethernet OAM and it is used to detect the devices in the
network and their OAM capabilities. The discovery process is triggered automatically
when OAM is enabled on the interface. The discovery phase uses Information OAM PDUs.
The discovery process permits Ethernet interfaces to discover and monitor the peer on
the link if it also supports the IEEE 802.3ah standard. You can specify the discovery mode
used for IEEE 802.3ah OAM support as active or passive.
•
In active mode, the interface discovers and monitors the peer on the link if the peer
also supports IEEE 802.3ah OAM functionality. In active mode, the peer initiates the
discovery process. After the discovery process has been initiated, both sides participate
in discovery.
•
In passive mode, an OAM entity does not initiate the discovery process. Therefore, the
OAM exchange cannot be performed if you configure both the endpoints, the local and
the peer entities, for passive mode operation.
The discovery mode that you set up for an OAM entity also determines certain other
attributes that can be initiated by an OAM entity. For example, a passive mode OAM
entity cannot initiate a variable request or a loopback procedure. In a carrier environment,
230
Copyright © 2010, Juniper Networks, Inc.
Chapter 7: Configuring IEEE 802.3ah OAM Link-Fault Management
the customer edge (CE) devices are normally configured for passive mode operation,
whereas the provider edge (PE) equipment is configured for active mode operation.
Information OAM PDU Components
An OAM entity in active mode initiates the discovery process by sending an Information
OAM PDU to the slow protocols multicast address (destination MAC address of the
remote entity) at a configured rate. The transmitted Information OAM PDU contains a
local-information type-length-value (TLV). This TLV contains the following fields:
•
State—Transmission or receiving state for forwarded packets. The mode can be either
active or passive and can be used to determine device functionality.
•
Capabilities of the OAM sublayer—Advertises the capabilities of the local OAM entity.
With this information a peer can determine what functions are supported and
accessible, such as loopback or unidirectional operation. This field also specifies the
maximum OAM PDU size for receipt and delivery. This information, together with the
rate limiting value of 10 frames per second, can be used to specify the bandwidth
allocated to OAM traffic.
•
Vendor OUI—Organization unique identifier (OUI), which is controlled by the IEEE and
is typically the first three bytes of a MAC address.
•
Vendor-specific information—A 32-bit identifier, which is used to distinguish the type
of platform in conjunction with the vendor OUI field.
After a local entity sends an Information OAM PDU, the remote OAM entity waits to
receive the local information of the peer. After receipt of the Information OAM PDU, the
OAM entity applies a policy to determine whether an OAM relationship can be established.
For example, loopback mode might be required for the OAM association to be completed.
If the remote entity does not support loopback, the local entity might disable the OAM
association.
Transmission Settings for Information OAM PDUs
After an OAM association is established, Information OAM PDUs are sent at a configured
rate. If no OAM PDUs other than Information OAM PDUs are available to be sent from
the local peer to the remote peer, the local entity sends Information OAM PDUs that
contain both the local and remote information TLVs. This constant bidirectional transfer
of Information OAM PDUs serves as a keepalive mechanism for the OAM association. If
no Information OAM PDUs are received within 5 seconds, the discovery process restarts
and a link-fault event is generated that might cause a transition in the operational status
of the Ethernet interface to the down state. If the OAM association with the peer is
reestablished, OAM clears the link-fault event to cause a transition of the interface to
the operational up state. The operational status of an interface does not depend only
on the OAM status. Other factors, such as the administrative state of the interface, also
impact the operational state.
You can configure the OAM discovery function in JunosE Software per Ethernet major
interface as either active or passive mode. The OAM state machine labels a port to be in
the operational down state until the discovery process is completed successfully. You
can configure the PDU timer, which is the rate at which Information OAM PDUs are sent
to the remote peer to keep the OAM association active, in the range of milliseconds with
Copyright © 2010, Juniper Networks, Inc.
231
JunosE 11.3.x Link Layer Configuration Guide
a maximum value of 1000 (the default value) and a minimum value of 100. Also, you
can configure the local OAM function with a packet loss threshold, which specifies the
number of Information OAM PDUs that an interface can miss before the link between
peers is considered down. When the PDU loss threshold is exceeded, a link fault event
is triggered. The product of the PDU timer and the PDU loss threshold equals the lost-link
timer value, which is used to reset the discovery state diagram that maintains the states
of the OAM entities and determines the condition of the link based on various stored
values.
When the PDU loss threshold is exceeded, the OAM function signals a problem with the
link and the link is immediately transitioned to the down state. When the OAM association
with the peer is rediscovered after a successful discovery operation, the link transitions
to the up state.
NOTE: The operational status displayed in the output of the show commands
related to interface settings will be down if the OAM session is down owing
to loss of association.
Related
Documentation
•
OAM Feature Overview on page 230
•
OAM Messages on page 226
•
Configuring 802.3ah OAM Link-Fault Management on page 238
•
Monitoring OAM Link-Fault Management Discovery Settings for an Interface on page 245
•
ethernet oam lfm
•
ethernet oam lfm mode
•
ethernet oam lfm pdu-lost-threshold
•
ethernet oam lfm pdu-transmit-interval
•
show ethernet oam lfm discovery
OAM Link Monitoring Feature
The router performs link monitoring by sending periodic Information OAM PDUs to
advertise OAM mode, configuration, and capabilities. Link monitoring uses the Event
Notification OAM PDU and sends events to the remote OAM entity when problems are
observed on the link. You can configure the OAM application to track frame and symbol
errors on the link to analyze the overall health and quality of the link. Frame errors include
frameTooLong, lengthError (runts), alignmentError, and frameCheckSequence errors.
You can monitor frame and symbol errors by setting up a monitoring period or window
and a threshold value. If the number of errors observed during the window meets or
exceeds the configured low threshold, an Event Notification PDU (in the appropriate
TLVs) is generated and sent to the peer. Alternatively, if you configure a high threshold
value on the local OAM peer, the OAM function attempts to alter the operational state
of the link whenever the high threshold value is exceeded. The monitoring of the link
232
Copyright © 2010, Juniper Networks, Inc.
Chapter 7: Configuring IEEE 802.3ah OAM Link-Fault Management
continues with a new window or period as long as the operational state of the link is up.
When the number of errors observed during the window equals or goes below the
configured low threshold value, the OAM application attempts to reverse the operational
state of the link to up.
Supported Error Events for Tracking Link Faults
The OAM application maintains an updated cumulative count of frame and symbol errors
and also an updated summation of events generated as a result of a threshold exception.
Both these sums are displayed in the appropriate link event TLVs and in the output of
the show ethernet oam commands.
Because certain MAC devices on the IOAs might not support a symbol error statistic,
enabling the monitoring of symbol errors is benign and no events are raised for that link.
The following error events are supported for configuration on Ethernet interfaces:
•
Error Symbol Period (error symbols per second)—The number of symbol errors that
occurred during a specified period exceeded a threshold. These errors are coding symbol
errors.
•
Error Frame (error frames per second)—The number of frame errors observed during
a specified period exceeded a threshold.
•
Error Frame Seconds Summary (error seconds per n seconds)—The number of error
seconds (1-second intervals with at least one frame error) within the last n seconds
has exceeded a threshold.
Because IEEE 802.3ah OAM does not provide a guaranteed delivery of any OAM PDU,
the event notification OAM PDU might be sent multiple times to reduce the probability
of a lost notification. A sequence number is used to distinguish among duplicate events.
Actions Performed on Exceeding Threshold Values
You can configure the OAM application to influence the operational state of the link,
when a link quality threshold is exceeded or a critical event PDU is received from the peer,
or both. You can configure either of the following actions to be taken when a high threshold
value is exceeded or when a failure condition is communicated by the remote peer:
•
Disable—OAM unconditionally attempts to influence the operational state of the
interface to down. If the interface is a member link of a LAG bundle and at least one
other viable link (redundant member or another active/up link) is present, OAM
attempts to influence the operational state of the link to down. Otherwise, no action
is taken.
•
Failover—On GE-2 and GE-HDE line modules that are paired with GE-2 SFP I/O modules
with physical link redundancy, this action attempts to transition the link from active to
redundant.
By default, no action is performed on the link. The operational status displayed in the
output of the show commands for interfaces is down if the OAM session is marked as
down/nonfunctional after the configured action is taken on the link.
Copyright © 2010, Juniper Networks, Inc.
233
JunosE 11.3.x Link Layer Configuration Guide
Related
Documentation
•
OAM Feature Overview on page 230
•
Guidelines for Configuring 802.3ah OAM Link-Fault Management on page 237
•
OAM Messages on page 226
•
Monitoring OAM Link-Fault Management Configuration for an Interface on page 250
•
Monitoring OAM Link-Fault Management Statistics for an Interface on page 248
•
ethernet oam lfm high-threshold
•
ethernet oam lfm link-monitor frame-seconds
•
ethernet oam lfm link-monitor frame-seconds-summary
•
ethernet oam lfm link-monitor symbol-period
•
show ethernet oam lfm status
•
show ethernet oam lfm statistics
OAM Remote Fault Detection Feature
Failures in Ethernet connectivity that are caused by slowly degrading quality are difficult
to notice. JunosE Software enables you to configure the OAM application to monitor the
receive path of the link for quality and generate Event Notification PDUs to the remote
peer. The following failure conditions can be communicated by the remote entity to its
peer using the Flags field of an Information OAM PDU (Figure 30 on page 226):
Link Fault
This event type signifies that a loss of signal is detected by the receiver; for example, the
peer's laser is not operating correctly. A link fault is sent once per second in the Information
OAM PDU. Link fault is applicable only when the physical sublayer is capable of
independent transmit and receive operations. If you configure this option, the local OAM
entity detects loss-of-signal conditions that occurred in the receive path of the link. The
local entity influences the state of the link based on an Information OAM PDU with the
Link Fault bit set in the Flags field that it receives from the remote peer.
Dying Gasp
This event type denotes that an unrecoverable condition, such as a power failure, has
taken place. This type of condition is vendor specific. A notification about the condition
might be sent immediately and continuously. If you configure this option, the local OAM
entity detects unrecoverable error conditions that occurred in the receive path of the link.
The local entity influences the state of the link based on an Information OAM PDU with
the Dying Gasp bit set in the Flags field that it receives from the remote peer.
Critical Event
This event type indicates that an unspecified vendor-specific critical event has occurred.
A critical event might be sent immediately and continuously. If you configure this option,
the local OAM entity detects critical event error conditions that occurred in the receive
path of the link. The local entity influences the state of the link based on an Information
234
Copyright © 2010, Juniper Networks, Inc.
Chapter 7: Configuring IEEE 802.3ah OAM Link-Fault Management
OAM PDU with the Critical Event bit set in the Flags field that it receives from the remote
peer.
You can specify the action to be taken by the system when the configured link-fault event
occurs, such as disabling the interface or failing over to the secondary port on GE-2 and
GE-HDE line modules that are paired with GE-2 SFP I/O modules with physical link
redundancy. You can also configure the OAM application to react to event notifications
received from the peer.
If a link fault is detected, any Information OAM PDUs sent with the Link Fault bit set do
not contain any TLV data. Any OAM PDU received with these flags set are processed
with priority by the router. Other link events, such as Errored Symbol Period Event and
Errored Frame Event, which result in threshold values being exceeded are notified using
TLVs in Event Notification PDUs.
In JunosE Software, you can configure the OAM application to monitor the receive path
of the link for quality and generate Event Notification PDUs to the remote peer. You can
also configure the OAM application to respond to event notifications received from the
peer.
Related
Documentation
•
OAM Feature Overview on page 230
•
OAM Messages on page 226
•
Configuring 802.3ah OAM Link-Fault Management on page 238
•
Monitoring OAM Link-Fault Management Sessions on All Configured Interfaces on
page 253
•
ethernet oam lfm remote-failure
•
show ethernet oam lfm summary
OAM Remote and Local Loopback Feature
Remote loopback mode ensures link quality between the router and a remote peer during
installation or troubleshooting. JunosE Software can place a remote entity into loopback
mode (if remote loopback mode is supported by the remote entity). When you place a
remote entity into loopback mode, the interface receives the remote loopback request
and puts the interface into remote loopback mode. When the interface is in remote
loopback mode, all frames except OAM PDUs are looped back without any changes
made to the frames. OAM PDUs continue to be sent and processed.
A local OAM entity in active mode can start a remote loopback of its peer through a
Loopback Control OAM PDU that contains the option to enable loopback. During the
initiation phase, the local OAM entity discards any locally sourced non-OAM PDUs. When
the peer receives a loopback request, and assuming that it supports the service, it sets
the forwarding state to loop any received non-OAM PDUs; any locally generated non-OAM
PDUs are discarded while in loopback (Figure 32 on page 229). This forwarding state is
conveyed to the peer using an Information OAM PDU. When the Information OAM PDU
is received after loopback is disabled, the local OAM entity resumes transmission of
locally sourced non-OAM PDUs, in addition to OAM PDUs. You can prevent two active
Copyright © 2010, Juniper Networks, Inc.
235
JunosE 11.3.x Link Layer Configuration Guide
mode OAM entities from simultaneously placing each other into loopback mode by
making sure that the lower valued source address is the entity that is placed in loopback
mode (Figure 32 on page 229).
Because OAM PDUs are processed during remote loopback, variables can be retrieved
to measure the link performance. The initiating OAM entity stops the remote loopback
process by sending another Loopback Control OAM PDU with the option to disable the
looping of any non-OAM PDUs. When the loopback feature is enabled, the forwarding
process counts the number of packets and bytes transmitted to the peer, and the number
of packets and bytes received from the peer.
NOTE: The peer in loopback mode might intentionally discard data frames
to accommodate OAM traffic. OAM PDUs are assigned a higher priority than
regular data packets when oversubscription of the allocated bandwidth
occurs.
Related
Documentation
•
OAM Messages on page 226
•
Configuring 802.3ah OAM Link-Fault Management on page 238
•
Example: Enabling Remote Loopback Support on the Local Interface on page 245
•
ethernet oam lfm remote-loopback supported
•
ethernet oam lfm remote-loopback
Interrelationship of OAM Link-Fault Management with Ethernet Subsystems
802.3ah OAM assists the monitoring of individual Ethernet links. Link aggregation
mechanisms, such as 802.3ad, operate above the 802.3ah sublayer. Figure 33 on page 236
shows the interconnection between OAM and LAG bundles. You can use the results of
OAM link monitoring to configure the LAG sublayer accordingly to improve failover and
recovery times.
Figure 33: Interrelationship Between 802.3ah OAM and 802.3ad LAG
MAC Client
MAC data
OAM Client
.3ad LAG
236
802.3ah OAM
802.3ah OAM
802.3ah OAM
MAC Control
MAC Control
MAC Control
MAC
MAC
MAC
PHY
PHY
PHY
g016522
OAM Service Interface
MAC data
Copyright © 2010, Juniper Networks, Inc.
Chapter 7: Configuring IEEE 802.3ah OAM Link-Fault Management
Link events can be generated locally using the health monitoring of an Ethernet link.
These link events can be supplied to the link aggregation multiplexing logic, in addition
to the logic generated by the LAC protocol. For example, if the configured symbol-period
threshold is exceeded, you can configure the link aggregator to remove the member link
from the bundle and rebalance the bundle. Where a LAG member link is designated as
a redundant member, you can use the link monitor functionality to trigger the failover
and the reversal of the link.
Certain line module and IOA combinations support physical level redundancy. The
redundancy feature enables a primary Gigabit Ethernet link to fail over to the secondary
link without signaling higher-layer protocols and by maintaining the same MAC address
on the link. The preservation of the same MAC address on the link also retains bindings
to the MAC address (for example, ARP entries). When the OAM entity signals that a
health monitoring threshold is exceeded, the event can trigger the failover to the secondary
link.
JunosE Software implements the Marker Responder segment of the Marker protocol. If
the OAM entity signals a link event, such as the exceeding of a high threshold value, using
the health monitoring system, then Marker Response PDUs are not sent in such
circumstances.
Related
Documentation
•
OAM Feature Overview on page 230
•
OAM Elements Overview on page 227
•
Configuring 802.3ah OAM Link-Fault Management on page 238
•
Guidelines for Configuring 802.3ah OAM Link-Fault Management on page 237
Guidelines for Configuring 802.3ah OAM Link-Fault Management
Keep the following points in mind when you configure OAM link-fault management on
Ethernet interfaces:
•
The OAM application transmits and receives an OAM PDU at a maximum frequency
of every 100 milliseconds (10 OAM PDUs/sec) on every port on the set of IOAs for a
line module. The most impact on performance might occur on ES2 4G LMs with two
GE-8 I/O modules (16 ports) that cause 160 OAM PDUs to be transmitted per second.
Also, the OAM application must query MAC-layer statistics (up to 6-8 for frame errors)
every 10 seconds and errored symbol statistics per second.
•
Because the outage time of the forwarding controller can last up to about 15 seconds
or longer, the 802.3ah OAM feature does not support unified ISSU. The link-fault
management of Ethernet interfaces is halted during a unified ISSU operation. Monitoring
resumes immediately after the unified ISSU operation is completed.
•
Although OAM configurations on an interface are preserved during a stateful SRP
switchover procedure, the retention of such OAM settings depends on the time that
the stateful SRP switchover process takes to complete. If the stateful SRP switchover
operation causes a traffic disruption of more than two seconds, the previously
configured OAM settings are affected. We recommend that you configure the number
of PDUs that are failed to be received by an OAM entity before it generates a link
Copyright © 2010, Juniper Networks, Inc.
237
JunosE 11.3.x Link Layer Configuration Guide
fault/down event to be greater than two, and the high and low thresholds for an error
to be exceeded on an Ethernet OAM interface to be more than two seconds.
Related
Documentation
•
802.3ah OAM functionality is not supported on SRP Ethernet interfaces. Also, JunosE
Software does not support unidirectional operation of Ethernet OAM links, which enable
the OAM entities to send Link Fault Information OAM PDUs to the peer whenever a
receive path failure is detected. In addition, an active mode OAM entity can retrieve
and respond to the performance variables that it receives from its peer entity. However,
the local OAM entity does not send a list of such performance variables that it can
process from the peer.
•
OAM Feature Overview on page 230
•
Interrelationship of OAM Link-Fault Management with Ethernet Subsystems on page 236
•
Configuring 802.3ah OAM Link-Fault Management on page 238
Configuring 802.3ah OAM Link-Fault Management
Ethernet OAM link-fault management can be used for physical link-level fault detection
and management. It uses a new, optional sublayer in the data link layer of the OSI model.
Ethernet OAM can be implemented on any full-duplex point-to-point or emulated
point-to-point Ethernet link. A system-wide implementation is not required; OAM can
be deployed on particular interfaces of a router. Transmitted Ethernet OAM messages
or OAM PDUs are of standard length, untagged Ethernet frames within the normal frame
length limits in the range 64–1518 bytes.
To configure OAM link-fault management on an Ethernet interface:
1.
Specify a Fast Ethernet, Gigabit Ethernet, or 10-Gigabit Ethernet interface, and enable
IEEE 802.3ah OAM support on the interface. When the IEEE 802.3ah OAM protocol
is enabled on a physical interface, the discovery process is automatically triggered.
The default discovery mode of a local interface is active.
host1(config)#interface GigabitEthernet 6/0
host1(config-if)#ethernet oam lfm
NOTE: You must enable the OAM link-fault management feature to be
able to configure parameters that govern the link monitoring and
management process.
All of the following steps are optional. You can choose which of the OAM
configurations you want to set up on the interface to enable link-fault
administration. If you enable OAM support on the interface without
specifying any of the other parameters, such as discovery mode and
threshold settings, default values are assumed for those attributes.
2. Specify whether the interface or the peer initiates the discovery process by configuring
the link discovery mode to active or passive.
host1(config-if)#ethernet oam lfm mode active
238
Copyright © 2010, Juniper Networks, Inc.
Chapter 7: Configuring IEEE 802.3ah OAM Link-Fault Management
In this case, the discovery mode of the interface is set as active. In active mode, the
interface discovers and monitors the peer on the link if the peer also supports IEEE
802.3ah OAM functionality. An OAM entity in active mode initiates the discovery
process by sending an Information OAM PDU to the multicast address of the slow
protocol (0180.c200.0002) at a configured rate. In a carrier environment, the customer
edge (CE) devices are normally configured for passive mode operation, whereas the
provider edge (PE) equipment is configured for active mode operation.
3. Specify the frequency, in milliseconds, at which OAM PDUs are sent to the peer to
keep the OAM association alive.
host1(config-if)#ethernet oam lfm pdu-transmit-interval 200
In this example, the local interface is configured to send Information OAM PDUs every
200 milliseconds to the remote peer. This OAM PDU includes local, remote, and
organization-specific information, and contains a local-information TLV.
The rate of transmission of OAM PDUs can be a number in the range 100–1000
milliseconds; the default value is 1000 milliseconds.
4. Specify the number of OAM PDUs that a local OAM client can fail to receive from a
remote peer before a link-fault event is triggered. The product of the PDU timer and
the PDU loss threshold equals the lost-link timer value, which is used to reset the
Discovery state diagram that maintains the states of the OAM entities and determines
the condition of the link based on various stored values.
host1(config-if)#ethernet oam lfm pdu-lost-threshold 4
In this example, the local interface is set to wait for 4 OAM PDUs to be missed from
the remote peer before it generates a link-fault event. You can configure the local
interface to wait for a larger number of OAM PDUs to be missed from the remote peer
in networks that are prone to high losses and fluctuating performances, such as jitter,
higher latency, and poor transmission of packets.
The number of OAM PDUs that can fail to be received from a remote peer before the
local OAM entity triggers a link-fault event can be in the range 3–10; the default period
is 5 PDUs.
5. Configure the interface to detect local link faults and send events to the remote OAM
entity when problems are noticed on the link. When link monitoring is enabled, the
interface sends event OAM protocol data units (PDUs) when errors occur and interprets
event OAM PDUs from the remote peer. Link monitoring can be effective only if both
the local client and remote peer agree to support it.
You can specify the event threshold values on an interface for the local errors that
occur or a period of time during which such local errors are detected. The following
are the error events that you can track using the OAM functionality:
•
Error frame events
•
Symbol error events
•
Error frame second events
a. Configure a low threshold value for sending frame error events, which when
exceeded causes an Errored Frame Event TLV to be sent to the remote OAM entity.
Copyright © 2010, Juniper Networks, Inc.
239
JunosE 11.3.x Link Layer Configuration Guide
The Errored Frame Event TLV counts the number of errored frames detected during
the specified period.
host1(config-if)#ethernet oam lfm link-monitor frame-seconds threshold high 600
In this case, a low error frame threshold of 600 frames is set. When this threshold
is exceeded, an Errored Frame Event TLV is sent to the remote peer.
b. Configure a high threshold value for frame errors, which when exceeded triggers
an action.
host1(config-if)#ethernet oam lfm link-monitor frame-seconds threshold high 60
In this case, a high error frame threshold of 60 frames is set. When this threshold
is exceeded, the action configured on the interface using the ethernet oam lfm
high-threshold action command is taken.
c. Configure a period of time during which error frames are counted for both high and
low threshold settings. The time duration is specified in hundred millisecond units.
host1(config-if)#ethernet oam lfm link-monitor frame-seconds window 10
In this case, the window during which error frames are counted is set as 10 hundred
millisecond units. The configured window is valid for both high and low threshold
settings. The high and low threshold settings are reset whenever a new window,
during which errors are counted, commences.
d. Configure a low threshold value for errored frame seconds, which causes an Errored
Frame Seconds Summary Event TLV to be sent to the OAM entity when the
threshold is exceeded. The Errored Frame Seconds Summary Event TLV counts
the number of errored frame seconds that occurred during the specified period.
An errored frame second is any 1-second period that has at least one errored frame.
host1(config-if)#ethernet oam lfm link-monitor frame-seconds-summary threshold
low 60
In this case, a low errored frame seconds threshold of 60 frame seconds is set.
When this threshold is exceeded, an Errored Frame Seconds Summary Event TLV
in an Event Notification OAM PDU is sent from the local OAM entity to the remote
peer.
e. Configure a high threshold value for errored frame seconds, which when exceeded
triggers an action.
host1(config-if)#ethernet oam lfm link-monitor frame-seconds-summary threshold
high 6
In this case, a high threshold of 6 errored frame seconds is set. When this threshold
is exceeded, the action configured on the interface using the ethernet oam lfm
high-threshold action command is taken.
f. Specify a period of time in which frame seconds summary error events are counted
for both high and low threshold settings. The time period used for counting events
is specified in seconds.
host1(config-if)#ethernet oam lfm link-monitor frame-seconds-summary window
10
240
Copyright © 2010, Juniper Networks, Inc.
Chapter 7: Configuring IEEE 802.3ah OAM Link-Fault Management
In this case, frame seconds summary events are detected during a period of 10
seconds. The configured window is valid for both high and low threshold settings.
The high and low threshold settings are reset whenever a new window, during
which errors are counted, commences.
g. Configure a low threshold value for symbol error events that causes an Errored
Symbol Period Event TLV to be sent to the OAM entity when it is exceeded. The
Errored Symbol Period Event TLV counts the number of symbol error events that
occurred during the specified period.
host1(config-if)#ethernet oam lfm link-monitor symbol-period threshold low 60
In this case, a low symbol errors threshold of 60 symbols is set. When this threshold
is exceeded, an Errored Symbol Period Event TLV in an Event Notification OAM
PDU is sent from the local OAM entity to the remote peer. This event is generated
if the symbol error count is equal to or greater than the specified threshold for that
period.
h. Configure a high threshold value for symbol errors, which when exceeded, triggers
an action.
host1(config-if)#ethernet oam lfm link-monitor symbol-period threshold low 10
In this case, a low symbol errors threshold of 10 symbols is set. When this threshold
is exceeded, the action configured on the interface using the ethernet oam lfm
high-threshold action command is taken.
i.
Specify a period of time in which symbol error events are counted for both high
and low threshold settings. The time period is specified in seconds.
host1(config-if)#ethernet oam lfm link-monitor symbol-period window 10
In this case, symbol error events are counted over a period of 10 seconds. The
configured window is valid for both high and low threshold settings. The high and
low threshold settings are reset whenever a new window, during which errors are
counted, commences.
NOTE: We recommend that you do not use a multiple of the number
of symbols because the window size varies greatly, depending on the
speed of the link. For example, a 10 Gigabit Ethernet link generates
10.3x10M symbols per second. If the window has a lower bound of 1M
symbols, sampling the symbol error statistic occurs every 97
microseconds.
Some of the interfaces do not support statistics for errored symbol
events. If you configure a monitor for symbol errors on such interfaces,
the setting does not have any effect.
6. Configure a specific action to occur when a high threshold for an error is exceeded on
an Ethernet OAM interface. You can configure the OAM application to influence the
operational state of the link, when a link quality threshold is exceeded or a critical
event PDU is received from the peer, or both. If you configured the action for an OAM
Copyright © 2010, Juniper Networks, Inc.
241
JunosE 11.3.x Link Layer Configuration Guide
event to disable an Ethernet OAM interface when a high threshold for an error is
exceeded, the link moves to the operational down status.
host1(config-if)#ethernet oam lfm high-threshold action failover
In this case, when the high threshold is exceeded for a local link error, a failover occurs
to the secondary link of the redundant port on GE-2 and GE-HDE line modules that
are paired with GE-2 SFP I/O modules.
7. Configure the Ethernet OAM link-fault management functionality to detect failure
conditions that occurred at a remote peer and influence the state of the link based
on an Event Notification PDU received from the remote peer. You can also set the
action to be performed when a failure condition is observed in the link. If you enable
detection of faults that occurred at the remote peer, the local OAM entity monitors
unspecified critical event, unrecoverable error, and loss-of-signal conditions that the
remote peer notifies it using an Information OAM PDU with the Critical Event, Dying
Gasp, and Link Fault bits set in the Flags field.
host1(config-if)#ethernet oam lfm remote-failure critical-event action disable-interface
host1(config-if)#ethernet oam lfm remote-failure dying-gasp action disable-interface
host1(config-if)#ethernet oam lfm remote-failure link-fault action disable-interface
The operational status of the interface is set to down when an OAM PDU is received
from the remote peer by the local OAM entity to signal fault conditions at the remote
entity.
8. Set an interface into loopback mode to enable the current Ethernet OAM configuration
for the interface of the local OAM entity to allow initiation of remote loopback operation
or to respond to a remote loopback request from a peer.
host1(config-if)#ethernet oam lfm remote-loopback supported
NOTE: You must configure the interface of the local OAM entity to be
placed in remote loopback mode and respond to loopback requests from
the remote peer by using the ethernet oam lfm remote-loopback
supported command before you enable the remote peer to loop back
PDUs by using the start or stop keywords with the ethernet oam lfm
remote-loopback command in Privileged Exec mode. Otherwise, a warning
message is displayed prompting you to configure the interface of the local
OAM entity to be placed in remote loopback mode.
Also, the remote peer can place the local OAM entity in loopback mode
only if you configured the ethernet oam lfm remote-loopback supported
command on the local entity to enable remote loopback functionality on
the local entity.
9. Configure the local OAM entity to instruct the remote peer at the specified interface
to start looping back the non-OAM PDUs that it receives from the local OAM entity
or to stop the resending of such received non-OAM PDUs from the local entity.
a. Enable the remote loopback operation on a remote OAM entity, which causes the
remote entity at the specified Gigabit Ethernet interface to loop any received
non-OAM PDUs back to the local entity.
242
Copyright © 2010, Juniper Networks, Inc.
Chapter 7: Configuring IEEE 802.3ah OAM Link-Fault Management
host1#ethernet oam lfm remote-loopback start interface gigabitEthernet 1/0
This configuration setting is not preserved across a reboot. The setting that you
configured on the local OAM entity to start or stop the loopback operation on the
remote peer is not available after a warm or cold restart of the router, because the
router does not store the secure logs in NVS.
NOTE: If you attempt to enable the loopback operation on a remote
OAM entity by entering the ethernet oam lfm remote-loopback start
command, an error message is displayed if the remote entity is not
configured for loopback behavior and if the interface of the local entity
is not placed into loopback mode (to send and receive loopback PDUs).
b. Alternatively, you can disable the remote loopback operation on the remote OAM
entity by instructing it to not loop back any received non-OAM PDUs from the local
OAM entity.
host1#ethernet oam lfm remote-loopback stop interface gigabitEthernet 1/0
When you halt the remote loopback operation to cause the remote peer to not
loop back any PDUs that it receives from the local entity by using the ethernet oam
lfm remote-loopback stop command, the number of frames and bytes that are
transmitted from the local entity to the remote peer when the local interface is in
loopback mode, and the number of frames and bytes that are received from the
remote peer when the remote peer is in loopback mode are displayed using
appropriate field labels at the CLI prompt. You can also view the calculated
loopback parameter values later from the Remote Loopback section in the output
of the show ethernet oam lfm status command.
Related
Documentation
•
Guidelines for Configuring 802.3ah OAM Link-Fault Management on page 237
•
Monitoring OAM Link-Fault Management Configuration for an Interface on page 250
•
Monitoring OAM Link-Fault Management Discovery Settings for an Interface on page 245
•
Monitoring OAM Link-Fault Management Statistics for an Interface on page 248
•
Monitoring OAM Link-Fault Management Sessions on All Configured Interfaces on
page 253
•
ethernet oam lfm
•
ethernet oam lfm mode
•
ethernet oam lfm high-threshold
•
ethernet oam lfm link-monitor frame-seconds
•
ethernet oam lfm link-monitor frame-seconds-summary
•
ethernet oam lfm link-monitor symbol-period
•
ethernet oam lfm pdu-lost-threshold
•
ethernet oam lfm pdu-transmit-interval
Copyright © 2010, Juniper Networks, Inc.
243
JunosE 11.3.x Link Layer Configuration Guide
•
ethernet oam lfm remote-failure
•
ethernet oam lfm remote-loopback
•
ethernet oam lfm remote-loopback supported
Example: Configuring 802.3ah OAM Link-Fault Management and Enabling Remote
Failure Monitoring on an Interface
The following example shows how to enable the OAM link-fault management feature
on an interface and configure a link monitoring operation for frame seconds events on
the interface.
1.
Specify the Gigabit Ethernet interface on which OAM link-fault management needs
to be enabled, and configure the link discovery mode as active. When OAM functionality
is enabled on the interface, the discovery mode of the local OAM entity is set to active
by default. An OAM entity in active mode initiates the discovery process by sending
an Information OAM PDU to the multicast address of the slow protocol
(0180.c200.0002) at a configured rate.
host1(config)#interface gigabitEthernet 4/1
host1(config-if)#ethernet oam lfm mode active
2. Configure the Ethernet OAM link-fault management functionality to detect link-fault
and dying-gasp conditions that occurred in the receive path of the link and influence
the state of the link based on an Event Notification PDU received from the remote
peer. Link Fault means a loss of signal, Dying Gasp means an unrecoverable condition
such as a power failure.
host1(config-if)#ethernet oam lfm remote-failure dying-gasp action disable-interface
host1(config-if)#ethernet oam lfm remote-failure link-fault action disable-interface
3. Configure the local interface to be disabled when the high threshold for an error
condition is exceeded. The OAM functionality unconditionally attempts to influence
the operational state of the interface to down.
host1(config-if)#ethernet oam lfm high-threshold action disable-interface
4. Configure link monitoring operations for frame error events on the interface. Specify
the high threshold in number of frames for frame error events as 200, which when
exceeded causes an action to be triggered. Specify a low threshold for frame error
events, which when exceeded causes an Errored Frame Seconds Summary Event TLV
to be sent to the peer, as 20 frames. Also, set the window during which frame error
events are counted as 300 hundred millisecond units or 30 seconds.
host1(config-if)#ethernet oam lfm link-monitor frame-seconds threshold high 200
host1(config-if)#ethernet oam lfm link-monitor frame-seconds threshold low 20
host1(config-if)#ethernet oam lfm link-monitor frame-seconds window 300
Related
Documentation
244
•
Configuring 802.3ah OAM Link-Fault Management on page 238
•
ethernet oam lfm mode
•
ethernet oam lfm high-threshold
Copyright © 2010, Juniper Networks, Inc.
Chapter 7: Configuring IEEE 802.3ah OAM Link-Fault Management
•
ethernet oam lfm link-monitor frame-seconds
•
ethernet oam lfm link-monitor frame-seconds-summary
•
ethernet oam lfm link-monitor symbol-period
•
ethernet oam lfm remote-failure
Example: Enabling Remote Loopback Support on the Local Interface
You can allow a remote entity to set a local interface into remote loopback mode on all
Ethernet interfaces on the E Series routers in which OAM link-fault management support
is present. When a remote-loopback request is sent by a remote entity, the JunosE
Software places the local interface into loopback mode. When an interface is in loopback
mode, all frames except OAM PDUs are looped back without any changes to the frames.
OAM PDUs continue to be sent to the management plane and processed. By default, the
remote loopback feature is not enabled.
The following example configures the Gigabit Ethernet interface for OAM link-fault
management and enables it to be placed in remote loopback mode to respond to
loopback requests from the peer.
host1(config)#interface gigabitEthernet 4/1
host1(config-if)#ethernet oam lfm
host1(config-if)#ethernet oam lfm remote-loopback supported
Related
Documentation
•
OAM Remote and Local Loopback Feature on page 235
•
ethernet oam lfm
•
ethernet oam lfm remote-loopback supported
Monitoring OAM Link-Fault Management Discovery Settings for an Interface
Purpose
Action
Display the results of the Ethernet OAM link-fault management discovery process for a
particular interface, such as the hardware status of the interface, operational status of
the interface, status of the established link discovery mode of the local and remote OAM
entities, states of the multiplier and parser functions of the OAM sublayer for the local
and remote OAM entities, and functionalities and configuration of the local and remote
OAM entities.
To display information regarding the OAM discovery process for a specific interface:
host1#show ethernet oam lfm discovery GigabitEthernet 4/1
GigabitEthernet 4/1 is Up, Administrative status is Up
OAM status is Down
Local(0090.1A03.0063):
Mode
: active
Capabilities : link events
Mux Action
: Forwarding
Parser Action : Forwarding
Remote(0090.690a.0202):
Mode
: passive
Capabilities : link events, loopback, variable retrieval
Copyright © 2010, Juniper Networks, Inc.
245
JunosE 11.3.x Link Layer Configuration Guide
Mux Action
: Forwarding
Parser Action : Forwarding
Meaning
Table 11 on page 246 lists the show ethernet oam lfm discovery command output fields.
Table 11: show ethernet oam lfm discovery Output Fields
Field Name
Field Description
Interface type/name
interfaceSpecifier
Status of the hardware on this interface:
Administrative status
OAM status
246
•
Up—Hardware is operational
•
Down—Hardware is not operational
Operational state that you configured for this interface:
•
Up—Interface is enabled
•
Down—Interface is disabled
Status of link-fault management functionality on the interface.
The operational status of an interface does not depend only on
the OAM status. Other factors, such as the administrative state
of the interface, also impact the operational state
•
Up—Link-fault management feature is activated on the
interface
•
Down—Link-fault management feature is disabled on the
interface, either because it was not activated or because it was
turned off as a result of error conditions
Local (address)
MAC address of the interface of the local entity
Mode
Discovery mode of the interface of the local OAM entity:
•
active—The interface discovers and monitors the peer on the
link if the peer also supports IEEE 802.3ah OAM functionality.
An OAM entity in active mode initiates the discovery process
by sending an Information OAM PDU to the multicast address
of the slow protocol (0180.c200.0002) at a configured rate.
The default discovery mode of the OAM client is active
•
passive—An OAM entity does not initiate the discovery process.
You cannot perform link-fault management if you configure
both the local client and the remote peer for passive mode
operation
Copyright © 2010, Juniper Networks, Inc.
Chapter 7: Configuring IEEE 802.3ah OAM Link-Fault Management
Table 11: show ethernet oam lfm discovery Output Fields (continued)
Field Name
Field Description
Capabilities
Functions that the interface of the local entity can perform, such
as link monitoring or responding to remote loopback requests.
With this information a peer can determine what functions are
supported and accessible; for example, loopback capability. All
the configured settings on the local interface for OAM tasks are
displayed in this field
Displays one or more of the following values:
•
unidirectional—Indicates the ability to operate a link in a
unidirectional mode for diagnostic purposes
•
loopback—Indicates whether remote loopback is supported or
unsupported
•
link events—Indicates whether interpreting link events is
supported or unsupported on the remote peer
•
variable retrieval—Indicates whether the local OAM entity
supports receipt of performance MIB variables from its peer
entity variable requests using Variable Request OAM PDUs
Mux Action
State of the multiplexer functions of the OAM sublayer for the
local OAM entity. Device is forwarding non-OAM PDUs to the
lower sublayer or discarding non-OAM PDUs
Parser Action
State of the parser functions of the OAM sublayer for the local
OAM entity. Device is forwarding non-OAM PDUs to higher
sublayer, looping back non-OAM PDUs to the lower sublayer, or
discarding non-OAM PDUs
Remote (address)
MAC address of the interface of the remote peer
Mode
Discovery mode of the interface of the remote peer:
Copyright © 2010, Juniper Networks, Inc.
•
active—The interface discovers and monitors the entity on the
other side of the link if that entity also supports IEEE 802.3ah
OAM functionality.
•
passive—An OAM entity does not initiate the discovery process.
You cannot perform link-fault management if you configure
both the local client and the remote peer for passive mode
operation
247
JunosE 11.3.x Link Layer Configuration Guide
Table 11: show ethernet oam lfm discovery Output Fields (continued)
Field Name
Field Description
Capabilities
Functions that the interface of the remote peer can perform, such
as link monitoring or responding to remote loopback requests.
With this information a peer can determine what functions are
supported and accessible; for example, loopback capability. All
the configured settings on the local interface for OAM tasks are
displayed in this field
Displays one or more of the following values:
Related
Documentation
•
unidirectional—Indicates the ability to operate a link in a
unidirectional mode for diagnostic purposes
•
loopback—Indicates whether remote loopback is supported or
unsupported
•
link events—Indicates whether interpreting link events is
supported or unsupported on the remote peer
•
variable retrieval—Indicates whether the local OAM entity
supports receipt of performance MIB variables from its peer
entity variable requests using Variable Request OAM PDUs
Mux Action
State of the multiplexer functions of the OAM sublayer for the
remote peer. Device is forwarding non-OAM PDUs to the lower
sublayer or discarding non-OAM PDUs
Parser Action
State of the parser functions of the OAM sublayer for the remote
peer. Device is forwarding non-OAM PDUs to higher sublayer,
looping back non-OAM PDUs to the lower sublayer, or discarding
non-OAM PDUs
•
Configuring 802.3ah OAM Link-Fault Management on page 238
•
show ethernet oam lfm discovery
Monitoring OAM Link-Fault Management Statistics for an Interface
Purpose
Action
Display detailed information about the Ethernet OAM link-fault management packets
that are processed by a particular interface, such as the number of Information OAM
PDUs transmitted and received, the number of Event Notification PDUs transmitted and
received, Duplicate Event Notification PDUs transmitted and received, and Loopback
Control PDUs transmitted and received.
To display details about the Ethernet OAM link-fault management packets that are
analyzed by a specific interface:
host1#show ethernet oam lfm statistics GigabitEthernet 4/1
GigabitEthernet 4/1
In:
Information OAMPDUs
:291
Event Notification OAMPDUs
:1
Errored Frame
:1
Errored Symbol
:0
Duplicate Event Notification OAMPDUs
:0
248
Copyright © 2010, Juniper Networks, Inc.
Chapter 7: Configuring IEEE 802.3ah OAM Link-Fault Management
Meaning
Loopback Control OAMPDUs
Unsupported OAMPDUs
:0
:0
Out:
Information OAMPDUs
Event Notification OAMPDUs
Errored Frame
Errored Symbol
Loopback Control OAMPDUs
Duplicate Event Notification OAMPDUs
:291
:0
:0
:0
:0
:0
Table 12 on page 249 lists the show ethernet oam lfm statistics command output fields.
Table 12: show ethernet oam lfm statistics Output Fields
Field Name
Field Description
Interface type/name
interfaceSpecifier
Name and type of the Ethernet interface, in the interface specifier
format, for which link-fault management packet details are
displayed
In
Details about the types of PDUs that are sent from the interface
Information OAMPDUs
Number of Information OAM PDUs transmitted from the interface
to the remote peer
Event Notification OAMPDUs
Number of unique Event Notification PDUs transmitted from the
interface, when the number of errors equals or exceeds the
configured low threshold for a specified time period. A breakdown
of the types of errors that resulted in the generation of an Event
Notification PDU is also displayed
Errored Frame
Number of errored frame event TLVs that have been transmitted
since the OAM sublayer was reset
Errored Symbol
Number of symbols error event TLVs that have been transmitted
since the OAM sublayer was reset
Errored Frame Seconds
Summary
Number of framed seconds error event TLVs that have been
transmitted since the OAM sublayer was reset
Loopback Control OAMPDUs
Total number of loopback control PDUs transmitted
Duplicate Event Notification
OAMPDUs
Number of duplicate event notification OAM PDUs transmitted
Unsupported OAMPDUs
Number of unsupported OAM PDUs sent
Out
Details about the types of PDUs that are received on the interface
Information OAMPDUs
Number of Information OAM PDUs received on the interface from
the remote peer
Copyright © 2010, Juniper Networks, Inc.
249
JunosE 11.3.x Link Layer Configuration Guide
Table 12: show ethernet oam lfm statistics Output Fields (continued)
Field Name
Field Description
Event Notification OAMPDUs
Number of unique Event Notification PDUs received on the
interface, when the number of errors equals or exceeds the
configured low threshold for a specified time period. A breakdown
of the types of errors that resulted in the generation of an Event
Notification PDU is also displayed
Errored Frame
Number of errored frame event TLVs that have been received
since the OAM sublayer was reset
Errored Symbol
Number of symbols error event TLVs that have been received
since the OAM sublayer was reset
Errored Frame Seconds
Summary
Number of framed seconds error event TLVs that have been
received since the OAM sublayer was reset
Loopback Control OAMPDUs
Total number of loopback control PDUs received
Duplicate Event Notification
OAMPDUs
Number of duplicate event notification OAM PDUs received
Unsupported OAMPDUs
Number of unsupported OAM PDUs received
Based on the counts displayed for the supported OAM PDUs in
the corresponding fields, you can determine additional details,
such as the number of Variable Request PDUs, by viewing the
value displayed in the Unsupported OAM PDUs field and
comparing it against the total number of all supported OAM PDUs
Related
Documentation
•
Configuring 802.3ah OAM Link-Fault Management on page 238
•
show ethernet oam lfm statistics
Monitoring OAM Link-Fault Management Configuration for an Interface
Purpose
Action
Display the current Ethernet OAM link-fault management configuration for a particular
interface, such as the discovery mode of the interface, the interval at which OAM PDUs
are transmitted to the remote peer, the number of OAM PDUs that can be missed from
the remote peer before a link-fault event is generated, actions that are taken when the
high threshold for an error is exceeded or when an OAM PDU from a remote peer signifies
a fault condition, link monitoring attributes, and remote loopback settings.
To display the runtime settings of link-monitoring and general OAM operations for a
particular interface:
host1#show ethernet oam lfm status GigabitEthernet 4/0
GigabitEthernet 4/0
Mode:
Passive
Transmit-interval:
1000 ms
Loss-threshold:
5 packets
250
Copyright © 2010, Juniper Networks, Inc.
Chapter 7: Configuring IEEE 802.3ah OAM Link-Fault Management
Event Action:
High Threshold Action:
Remote-loopback:
disable
disable
supported
Frame-seconds Error Monitor
Window:
30 (100 millisecond units)
Low threshold:
20 errored frames
High threshold:
none
Remote-loopback:
Frames sent:
Bytes sent:
Frames received:
Bytes received:
Meaning
104437
16167885
104437
16167885
Table 13 on page 251 lists the show ethernet oam lfm status command output fields.
Table 13: show ethernet oam lfm status Output Fields
Field Name
Field Description
Interface type/name
interfaceSpecifier
Name and type of the Ethernet interface, in the interface specifier
format, for which link-fault management packet details are
displayed
Mode
Discovery mode of the interface:
•
Active—The interface discovers and monitors the peer on the
link if the peer also supports IEEE 802.3ah OAM functionality.
An OAM entity in active mode initiates the discovery process
by sending an Information OAM PDU to the multicast address
of the slow protocol (0180.c200.0002) at a configured rate.
The default discovery mode of the OAM client is active
•
Passive—An OAM entity does not initiate the discovery process.
You cannot perform link-fault management if you configure
both the local client and the remote peer for passive mode
operation
Transmit-interval
Number of milliseconds, after which Information OAM PDUs are
sent from the local OAM entity to the remote peer to maintain
the OAM association in an active state
Loss-threshold
Number of Information OAM PDUs that can be missed from the
remote peer before a link fault event is triggered
Event Action
Action to be performed on an interface when an Information OAM
PDU is received from the remote peer by the local OAM entity to
signal a fault condition at the remote entity. Possible values are:
Copyright © 2010, Juniper Networks, Inc.
•
disable—Sets the OAM functionality to unconditionally attempt
to influence the operational state of the interface to down
•
failover—On GE-2 and GE-HDE line modules that are paired
with GE-2 SFP I/O modules with physical link redundancy,
causes the transition of the link from active to redundant
251
JunosE 11.3.x Link Layer Configuration Guide
Table 13: show ethernet oam lfm status Output Fields (continued)
Field Name
Field Description
High Threshold Action
Action that occurs when the high threshold for an error is
exceeded:
Remote-loopback
•
disable—Sets the OAM functionality to unconditionally attempt
to influence the operational state of the interface to down. If
the interface is a member link of a LAG bundle and at least one
other viable link (redundant member or another active/up link)
is present, OAM attempts to influence the operational state of
the link to down. Otherwise, no action is taken
•
failover—On GE-2 and GE-HDE line modules that are paired
with GE-2 SFP I/O modules with physical link redundancy,
causes the transition of the link from active to redundant
Indicates whether the local interface is enabled for remote
loopback functionality and whether it can respond to remote
loopback requests from peers: supported or unsupported.
An OAM entity can put its remote peer into loopback mode using
the Loopback control OAM PDU. In loopback mode, every frame
received is transmitted back on the same port (except for OAM
PDUs, which are needed to maintain the OAM session) to the
local entity
252
Frame-seconds Error Monitor
Displays a detailed classification of frame seconds errors event
TLVs since the OAM sublayer was reset
Window
Specified amount of time in milliseconds during which frame
seconds error events are counted
Low threshold
Lowest value for frame second error events in number of frames,
which when exceeded causes an Errored Frame Seconds
Summary Event TLV to be sent to the peer
High threshold
Highest value for frame second error events in number of frames,
which when exceeded causes an action to be triggered
Frame-errors Error Monitor
Displays a detailed classification of frame errors event TLVs since
the OAM sublayer was reset
Window
Specified amount of time in hundred-millisecond units during
which frame error events are counted
Low threshold
Lowest value for frame error events in number of frames, which
when exceeded causes an Errored Frame Event TLV to be sent
to the peer
High threshold
Highest value for frame error events in number of frames, which
when exceeded causes an action to be triggered
Symbol-errors Error Monitor
Displays a detailed classification of symbol errors event TLVs
since the OAM sublayer was reset
Copyright © 2010, Juniper Networks, Inc.
Chapter 7: Configuring IEEE 802.3ah OAM Link-Fault Management
Table 13: show ethernet oam lfm status Output Fields (continued)
Related
Documentation
Field Name
Field Description
Window
Specified amount of time in seconds during which symbol error
events are counted
Low threshold
Lowest value for frame second error events in number of error
symbols, which when exceeded causes an Error Symbol Period
TLV to be sent to the peer
High threshold
Highest value for symbol error events in number of error symbols,
which when exceeded causes an action to be triggered
Remote-loopback
Displays details on the non-OAM PDUs that are sent and received
when the interface is in remote loopback mode
Frames sent
Number of frames sent to the remote peer that are transmitted
back or looped to the local interface
Bytes sent
Number of bytes sent to the remote peer that are transmitted
back or looped to the local interface
Frames received
Number of frames received from the remote peer when the local
entity is in loopback mode
Bytes received
Number of bytes received from the remote peer when the local
entity is in loopback mode
•
Configuring 802.3ah OAM Link-Fault Management on page 238
•
show ethernet oam lfm status
Monitoring OAM Link-Fault Management Sessions on All Configured Interfaces
Purpose
Display a summary of the MAC-layer OAM status of all Ethernet links on which OAM
link-fault management is enabled. This command displays the state of each of the links,
with a brief synopsis about the OAM configurations of each of the links, such as the
discovery mode of the OAM entity, state of the discovery mechanism, MAC address of
the remote peer, the Link Flag details that contain information about the interface, and
loopback configuration.
Action
To display Ethernet OAM link-fault management settings for all interfaces on which OAM
is enabled:
host1#show ethernet oam lfm summary
FastEthernet4/0 is Up, Administrative status is Up
Ethernet OAM (ver 1)
Mode: Active, Discovery State: Send any
Remote address: 0090.0a38.0208
Flags: Remote-Stable Remote-State-Valid Local-Stable
Loopback: Supported, Remote enabled
Copyright © 2010, Juniper Networks, Inc.
253
JunosE 11.3.x Link Layer Configuration Guide
FastEthernet4/1 is Down, Administrative status is Up
Ethernet OAM (ver 1)
Mode: Active, Discovery State: Fault
Remote address: 0090.0b92.032a
Flags: Local Evaluating
Loopback: Supported, Local enabled
Meaning
Table 14 on page 254 lists the show ethernet oam lfm summary command output fields.
Table 14: show ethernet oam lfm summary Output Fields
Field Name
Field Description
Interface type/name
interfaceSpecifier
Status of the hardware on this interface:
Administrative status
Up—Hardware is operational
•
Down—Hardware is not operational
Operational state that you configured for this interface:
•
Up—Interface is enabled
•
Down—Interface is disabled
Ethernet OAM (ver 1)
Revision of the OAM configuration. A new revision results from
each change to the configuration.
Mode
Discovery mode of the interface:
Remote address
254
•
•
Active—The interface discovers and monitors the peer on the
link if the peer also supports IEEE 802.3ah OAM functionality.
An OAM entity in active mode initiates the discovery process
by sending an Information OAM PDU to the multicast address
of the slow protocol (0180.c200.0002) at a configured rate.
The default discovery mode of the OAM client is active
•
Passive—An OAM entity does not initiate the discovery process.
You cannot perform link-fault management if you configure
both the local client and the remote peer for passive mode
operation
MAC Address of the remote peer
Copyright © 2010, Juniper Networks, Inc.
Chapter 7: Configuring IEEE 802.3ah OAM Link-Fault Management
Table 14: show ethernet oam lfm summary Output Fields (continued)
Field Name
Field Description
Discovery State
State of the discovery mechanism:
Copyright © 2010, Juniper Networks, Inc.
•
Fault—When the discovery process enters the Fault state, the
local PDU value is set based on the value of local link status
field. While the local link status is set to Fail, the local OAM
entity remains in this state indicating to the remote peer there
is link fault. This condition is accomplished by sending
Information OAM PDUs once per second with the Link Fault bit
of the Flags field set and no Information TLVs in the Data field
•
Active send local—A local entity configured in Active mode
sends Information OAM PDUs that only contain the Local
Information TLV. This state is referred to as Active Send Local.
While in this state, the local entity waits for Information OAM
PDUs received from the remote entity
•
Passive wait—An entity configured in passive mode waits until
receiving Information OAM PDUs with Local Information TLVs
before sending any Information OAM PDUs with Local
Information TLVs. This state is called Passive Wait. By waiting
until first receiving an Information OAM PDU with the Local
Information TLV, a passive entity cannot complete the OAM
Discovery process when connected to another entity in passive
mode
•
Send any—After an OAM PDU has been received indicating the
remote device is satisfied with the respective settings, the local
device enters the SEND_ANY state. This is the expected normal
operating state for OAM on fully operational links
•
Send local remote—After the local entity has received an
Information OAM PDU with the Local Information TLV from
the remote entity, the local entity begins sending Information
OAM PDUs that contain both the Local and Remote Information
TLVs. This state is called Send Local Remote. If at any time the
settings on either the local or remote entity change resulting
in the local OAM client becoming unsatisfied with the settings,
the discovery process returns to the Send Local Remote state
•
Send local remote ok—If the local OAM client deems the
settings on both the local and remote entities are appropriate,
it enters the Send Local Remote Ok state. If at any time the
settings on the local OAM client change resulting in the remote
OAM client becoming unsatisfied with the settings, the OAM
discovery process returns to the Send Local Remote Ok state
255
JunosE 11.3.x Link Layer Configuration Guide
Table 14: show ethernet oam lfm summary Output Fields (continued)
Field Name
Field Description
Flags
Provides information about the physical link; displays one or more
of the following values:
Loopback
Related
Documentation
256
•
•
Remote-Stable—Indicates remote OAM client acknowledgment
and acceptance of local OAM state information. False indicates
that remote entity either has not received or remote state
settings do no match local state information. True indicates
that remote entity has received and remote state settings
match local state information
•
Local-Stable—Indicates local OAM client acknowledgment
and acceptance of remote OAM state information. False
indicates that local entity either has not received or local state
settings do not match remote state information. True indicates
that local entity has received and local state settings match
remote state information
•
Local-Evaluating—The Local Stable and Local Evaluating bits
of the Flags field communicate the status of the local discovery
process to the peer. When the OAM discovery process is started,
the local entity sets the Local Stable to 0 and Local Evaluating
bits to 1 indicating OAM discovery has not completed. When
Local Stable is set to 1 and Local Evaluating is set to 0 and
Remote Stable is set to 1 and Remote Evaluating is set to 0
indicating that the settings of both the local and remote OAM
clients match, the OAM Discovery process has successfully
completed
•
Remote-State-Valid—Indicates the OAM client has received
remote state information found within Local Information TLVs
of received Information OAM PDUs. False indicates that OAM
client has not seen remote state information. True indicates
that the OAM client has seen remote state information
State of the loopback functionality of the local and remote OAM
entities; displays one or more of the following values:
•
Supported—Indicates that the Ethernet OAM configuration on
the interface is configured to initiate remote loopback or
respond to a remote loopback request it receives from a peer.
When you place a remote entity into loopback mode, the
interface receives the remote-loopback request and puts the
interface into remote-loopback mode. When a
remote-loopback request is sent by a remote entity, the local
interface is placed into loopback mode
•
Local enabled—Indicates that the loopback operation is
enabled on the specified interface of the local OAM entity,
which causes the local entity to loop back the received frames
other than OAM PDUs to the remote peer
•
Remote enabled—Indicates that the loopback operation is
enabled on the specified interface of the remote peer, which
causes the remote peer to loop back all received frames other
than OAM PDUs to the local OAM entity
Configuring 802.3ah OAM Link-Fault Management on page 238
Copyright © 2010, Juniper Networks, Inc.
Chapter 7: Configuring IEEE 802.3ah OAM Link-Fault Management
•
show ethernet oam lfm summary
Copyright © 2010, Juniper Networks, Inc.
257
JunosE 11.3.x Link Layer Configuration Guide
258
Copyright © 2010, Juniper Networks, Inc.
CHAPTER 8
Configuring Point-to-Point Protocol
This chapter describes how to configure a Point-to-Point Protocol (PPP) interface on
E Series routers.
This chapter contains the following sections:
•
Overview on page 259
•
Platform Considerations on page 269
•
References on page 270
•
Before You Configure PPP on page 271
•
Configuration Tasks on page 271
•
Optional Configuration Tasks on page 274
•
PPP Accounting Statistics on page 281
•
Monitoring PPP Interfaces on page 282
•
Troubleshooting on page 296
Overview
PPP provides a standard method for transporting multiprotocol datagrams over a
point-to-point link. PPP uses the High-Speed Data Link Control (HDLC) protocol for its
physical interface and provides a packet-oriented interface for the network-layer
protocols.
Internet Protocol Control Protocol (IPCP) (which negotiates for transport of IP version
4 datagrams), IPv6CP (which negotiates for transport of IP version 6 datagrams), the
OSI Network Layer Control Protocols (OSINLCPs), and Multiprotocol Label Switching
(MPLS) run within PPP.
The router supports dynamic PPP interfaces. For details, see “Configuring Dynamic
Interfaces” on page 511.
Framing
The software restricts the use of the general HDLC protocol (RFC 1662) to unnumbered
mode:
•
HDLC address field is 0xFF (all stations)
Copyright © 2010, Juniper Networks, Inc.
259
JunosE 11.3.x Link Layer Configuration Guide
•
HDLC control field is 0x03 (to indicate unnumbered mode)
The router does not support the following framing features:
•
Numbered mode (RFC 1663)
•
Autodetection of encapsulation
Error Frames
The router relies on higher-layer protocols to recover from PPP data loss. All unrecognized
protocol data units (PDUs) are discarded; however, statistics are maintained for packets
dropped.
Link Control Protocol
PPP’s Link Control Protocol (LCP) establishes a PPP link by negotiating with the PPP
peer at the other end of a proposed connection. When two routers initialize a PPP dialogue,
each router sends control packets to the peer. The control packets contain a list of LCP
options and corresponding values that the sending peer uses to define its end of the link,
such as the maximum receive unit (MRU).
LCP negotiations continue until the peers either converge (that is, reach an agreement
about values for connection parameters) or abandon attempts to establish a connection.
If you configure a PPP interface without an IP interface or profile, the router negotiates
LCP, but then terminates LCP after 2 to 3 minutes. Previously, the behavior in such a
circumstance was to negotiate LCP and then leave LCP open.
For static PPP interfaces, whenever LCP achieves a stopped state because of termination,
negotiation failure, or some other cause, it goes into passive mode and waits for the other
side of the connection to restart the negotiation process. Once in passive mode, the
router periodically attempts to negotiate with the other side according to an exponential
timeout algorithm.
For static PPP interfaces, the router waits 15 seconds, attempts negotiation, waits 30
seconds if it fails, attempts negotiation, waits 60 seconds if it fails, and so on. The timeout
periods are 15 seconds, 30 seconds, 60 seconds, 2 minutes, 4 minutes, 8 minutes, and
15 minutes. Once it reaches the 15-minute timeout, the router attempts negotiation every
15 minutes until successful. When LCP reaches the open state, the timer resets to 15
seconds.
Dynamic PPP interfaces are always torn down when LCP achieves a stopped state. For
more information, see “Configuring Dynamic Interfaces” on page 511.
LCP Negotiation Parameters
LCP can negotiate many PPP options, as follows:
260
•
MRU size—Maximum receive unit size (always accepted).
•
Magic number—Randomly generated number used to identify one end of a
point-to-point connection. Each side negotiates its magic number, taking note of each
other’s magic number. If both sides discover that the magic numbers they are
Copyright © 2010, Juniper Networks, Inc.
Chapter 8: Configuring Point-to-Point Protocol
negotiating are the same, each side attempts to change its magic number. If they are
not successful, and the magic numbers remain the same, the session terminates
because of the loopback that is detected. Magic numbers are always accepted.
By default, the router always attempts to negotiate a local magic number. The peer
can also determine whether to negotiate its magic number—the peer magic number.
The router always accepts a peer’s attempt to negotiate its magic number.
If the peer does not attempt to negotiate its magic number, you can configure the
router to ignore a mismatch of the peer magic number and retain the PPP connection.
For details, see “Validation of LCP Peer Magic Number” on page 261.
•
Authentication—Requested if configured.
•
Protocol-Field-Compression (PFC) and Address-and-Control-Field-Compression
(ACFC)—Accepted, but never requested.
•
Multilink PPP—Additional options can be negotiated when Multilink PPP is configured.
See “Configuring Multilink PPP” on page 299.
•
Async-Control-Character-Map (ACCM—Supported by PPP when used with an L2TP
Network Server (LNS). ACCM allows PPP to indirectly support asynchronous PPP
connections tunneled via a third-party L2TP Access Concentrator (LAC). PPP on the
router uses the ACCM configuration data as supplied by the LAC via proxy LCP. The
router does not directly support asynchronous PPP connections and will not negotiate
an ACCM option unless directed to do so by a third-party LAC.
PPP can also detect a loopback that occurs after LCP is negotiated, provided that:
•
No loopback occurs during LCP negotiations.
•
A loopback is introduced after LCP negotiation without forcing LCP renegotiation. (LCP
is renegotiated if the lower layer goes down or if an LCP confReq is received from the
other end.)
Validation of LCP Peer Magic Number
If the peer has not negotiated an LCP magic number, you can configure the router to
ignore a mismatch of the LCP peer magic number and retain the PPP connection.
Previously, the router terminated a PPP connection with a non-conforming peer when it
received LCP echo request packets or LCP echo reply packets from the peer with a magic
number that did not match the LCP peer magic number on the router. This is still the
current default behavior if you do not explicitly configure the router to ignore the LCP
peer magic number mismatch if the peer has not negotiated the magic number and retain
the PPP connection.
Configuring the router to ignore the peer magic number mismatch and retain the PPP
connection is useful if your network includes peers that send a non-null or invalid magic
number in the LCP echo request and reply packets despite having not negotiated the
magic number. In this situation, the router expects to receive a null magic number from
the peer, and terminates the PPP connection unless you configure it to ignore the peer
magic number mismatch and retain the connection.
Copyright © 2010, Juniper Networks, Inc.
261
JunosE 11.3.x Link Layer Configuration Guide
To configure the router to ignore the LCP peer magic number mismatch and retain the
PPP connection, use the ppp magic-number ignore-mismatch command from Interface
Configuration mode or Subinterface Configuration mode. For more information, see “ppp
magic-number ignore-mismatch” on page 276.
To verify configuration of LCP peer magic number validation on the router, you can use
the show ppp interface command. For more information, see “show ppp interface” on
page 283.
Keep the following points in mind when configuring the router to ignore the peer magic
number mismatch and retain the PPP connection:
•
If the peer negotiates the magic number but sends the router an LCP echo request or
reply packet that contains a null or invalid magic number, the router strictly terminates
the PPP connection. The router can ignore a mismatch of the LCP peer magic number
only when the peer has not negotiated the magic number.
•
Using the ppp magic-number disable command to disable negotiation of the magic
number on the router does not affect validation of the peer magic number. When you
issue the ppp magic-number disable command, the router sets only the local magic
number to null, but does not change or validate the peer magic number. (For more
information, see “ppp magic-number disable” on page 276.)
You can also configure validation of the LCP peer magic number for static MLPPP
interfaces, dynamic PPP interfaces, and dynamic MLPPP interfaces. For more information
about configuring static MLPPP interfaces, see “Configuring Multilink PPP” on page 299.
For more information about using profiles to configure dynamic PPP and dynamic MLPPP
interfaces, see “Configuring a Dynamic Interface from a Profile” on page 559 in “Configuring
Dynamic Interfaces” on page 511.
B-RAS Support
Broadband Remote Access Server (B-RAS) is an application that aggregates the output
from digital subscriber line access multiplexers (DSLAMs). B-RAS provides user PPP
sessions and PPP session termination and routes traffic onto the backbone. See JunosE
Broadband Access Configuration Guide for details on B-RAS.
The router provides an enhanced version of PPP to accommodate B-RAS with the
following features:
262
•
Internet Protocol Control Protocol (IPCP) extensions for Windows Internet Name
Service (WINS) and Domain Name System (DNS) name server addresses
•
Password Authentication Protocol (PAP)
•
Challenge Handshake Authentication Protocol (CHAP)
•
Keepalive timeout
•
Session timeout
•
Inactivity timeout
•
Accounting
Copyright © 2010, Juniper Networks, Inc.
Chapter 8: Configuring Point-to-Point Protocol
Authentication
The router acts as an authenticator. It demands authentication from a remote PPP peer
but refuses to authenticate itself.
Rate Limiting for PPP Control Packets
The router implements rate limiting for PPP control packets to protect the corresponding
PPP interface from denial-of-service (DoS) attacks. The interface discards control
packets when the rate of control packets received exceeds the rate limit for PPP
interfaces.
A PPP interface has a rate limit control that is non-configurable and always in effect; the
rate limit is the same for all PPP interfaces. In addition, each interface instance maintains
its own state and statistics counters for tracking the rate. The rate limit for PPP control
packets is approximately 10 packets per second.
For a PPP interface, the router increments the discards counter in the show ppp interface
command display to track the number of PPP control packets discarded on receipt (in)
or discarded before they were transmitted (out) on this interface.
For examples of the show ppp interface command display, see “show ppp interface” on
page 283.
Extensible Authentication Protocol
The JunosE Software supports Extensible Authentication Protocol (EAP) for
authenticating a peer before allowing network layer protocols to transmit over the link.
EAP supports multiple authentication methods, including EAP-TLS and
EAP-MD5-Challenge. The EAP server and the peer negotiate the specific authentication
method to be used. Figure 34 on page 263 illustrates the three components required for
EAP: an EAP authenticator, an EAP server, and an EAP client.
Figure 34: Authentication with EAP
After LCP negotiation, JunosE starts the EAP negotiation process by initiating an identity
exchange with the EAP client on the peer. The router sends an EAP identity request packet
to the peer, which replies with an EAP identity response packet. After this exchange, the
E Series router acts only as a pass-through device, enabling the EAP server residing on
the backend authentication server to select and negotiate the particular EAP
authentication method directly with the EAP client on the peer.
The JunosE Software forwards or discards packets received from the backend
authentication router and the peer depending on the identifying code contained in the
packet.
The E Series router forwards:
Copyright © 2010, Juniper Networks, Inc.
263
JunosE 11.3.x Link Layer Configuration Guide
•
Packets received from the peer with a Response code
•
Packets received from the backend authentication server with a Request, Success, or
Failure code
The E Series router discards:
•
Packets received from the peer with a Request, Success, or Failure code
•
Packets received from the backend authentication server with a Response code
The JunosE Software determines the outcome of the authentication based only on the
Accept or Reject indication sent by the RADIUS server
EAP Types
The JunosE Software has been qualified to work with the EAP authentication
methods—known as EAP types—described in Table 15 on page 264. Other EAP
authentication methods have not been qualified with the JunosE Software
Table 15: Supported EAP Types
EAP Type
Behavior
1—Identity
When LCP negotiation completes, PPP sends an initial EAP identity
request packet to the peer. The EAP identity response packet received
from the peer is forwarded to AAA. AAA forwards the response as an
Access-Request to the RADIUS server hosted on the backend
authentication server.
2—Notification
The JunosE Software forwards Notification requests from the backend
authentication server to the peer and Notification responses from the
peer to the server. The JunosE Software does not initiate any Notification
requests or responses.
3—NAK
The JunosE Software forwards the NAKs received from the peer to the
backend authentication server.
4—MD5-Challenge
The JunosE Software acts as a pass-through for the EAP-MD5-Challenge
negotiated between the peer and backend authentication server.
13—TLS
The JunosE Software acts as a pass-through for the EAP-TLS negotiated
between the peer and backend authentication server.
EAP Packet Retransmission
PPP retransmits the EAP request packets to the peer. The RADIUS client retransmits the
EAP response packets to the RADIUS Server. The request packets to the peer are governed
by nonconfigurable values for retransmission attempts and interval. The configuration
of the RADIUS client determines retransmission values for response packets to the
RADIUS server. The retransmission values are as follows:
•
264
PPP makes five attempts to retransmit an EAP request before the authentication
attempt is terminated. You cannot configure the number of retransmission attempts.
Copyright © 2010, Juniper Networks, Inc.
Chapter 8: Configuring Point-to-Point Protocol
•
When an EAP request is transmitted, a timer is started with a nonconfigurable
retransmission interval value of 3 seconds. When the timer expires, the EAP request is
retransmitted.
In some cases, you might want a longer retransmission interval. For example, you might
need to accommodate the additional time required by a user to enter information or scan
a fingerprint or retina. RADIUS can instruct the JunosE Software to wait longer by passing
an appropriate Session-Timeout attribute in the RADIUS Access-Challenge packet. This
retransmission interval value applies only to the EAP request packet present in the RADIUS
Access-Challenge packet.
The Session-Timeout attribute value overrides the default retransmission interval value,
up to a maximum of 30 seconds. If RADIUS recommends a greater value, then PPP resets
it back to 30 seconds in order to avoid longer or infinite delays.
EAP Behavior in an L2TP Environment
EAP behavior in an L2TP environment varies depending on whether the router acts as a
LAC or an LNS,
When the E Series Router Acts as a LAC
When PPP forwards an EAP identity response packet to AAA, AAA might be configured
to return a tunnel response upon successful validation of the packet. You can use AAA
domain maps, a AAA profile, or both to force such tunneling.
On an LAC, PPP forwards the PPP EAP authentication information to the LNS during the
establishment of the L2TP session. This authentication information consists of the EAP
type, the data appropriate to the type (such as a username) contained in the EAP identity
response packet, and the identifier of the EAP identity response packet. If the LNS trusts
the LAC, then the LNS uses this authentication information to resume the EAP negotiation
where the LAC left off.
L2TP on an LAC forwards the PPP EAP authentication information in the Proxy Authen
AVPs as described in L2TP Proxy Authenticate Extensions for
EAP—draft-ietf-l2tpext-proxy-authen-ext-eap-01.txt (December 2006 expiration).
When the E Series Router Acts as an LNS
PPP on an LNS resumes the EAP negotiation operation by detecting the presence of EAP
information in the proxy authentication data supplied by L2TP. PPP reconstructs the EAP
identity response packet from the proxy authentication data and forwards it to AAA.
L2TP on an LNS processes the received Proxy Authen AVPs as described in L2TP Proxy
Authenticate Extensions for EAP—draft-ietf-l2tpext-proxy-authen-ext-eap-01.txt
(December 2006 expiration).
Limitations
EAP is subject to internal limits. When the E Series router acts as a pass-through between
the backend authentication server and the peer, EAP packets traverse the controllers
within the router. The size of EAP packets and fragments tends to be larger than the
buffer exchange limit—1450 bytes—between the controllers. This intercontroller buffer
exchange limit is tuned for the optimal system performance and scalability; also, when
Copyright © 2010, Juniper Networks, Inc.
265
JunosE 11.3.x Link Layer Configuration Guide
stacked over L2TP on LNS, it prevents PPP control packets from causing IP fragmentation
and reassembly on the Ethernet downlink. Hence, if EAP is configured as a PPP
authentication protocol, then EAP packet or fragment size is affected by the intercontroller
buffer exchange limit as follows:
•
•
The MRU value advertised by JunosE in the LCP request packet takes the lowest of
the following values:
•
the lower layer MRU minus the PPP overhead
•
the configured MRU
•
1450 bytes
The MTU value is initialized by JunosE to the lowest of the following values:
•
the lower layer MTU minus the PPP overhead
•
the peer MRU
•
1450 bytes
The MTU value is passed to RADIUS in an Access-Request packet by means of the
Framed-Mtu attribute.
Performance
When EAP is configured on the router, it affects the performance and scalability of PPP
in terms of round-trip packet exchanges, negotiations, EAP server requirements, and EAP
client requirements. For information on the number of PPP interfaces supported with
EAP, see the Link Layer Maximums tables in Appendix A, System Maximums, of the current
JunosE Release Notes.
•
Performance depends on the number of packets exchanged during the negotiation.
When the number of packets exchanged increases—that is, when the number of
round-trips increases—it takes longer to finish the interface negotiation. System
resources are locked for a longer duration. As a result it takes longer to bring up all the
interfaces.
The number of round-trip message exchanges varies with the EAP authentication
method. When no retransmission of packets takes place and there is no fragmentation,
PAP and CHAP require one round-trip, EAP-MD5-Challenge requires two round-trips,
and EAP-TLS requires four round-trips.
Retransmission increases the number of round-trips. When the negotiated EAP
authentication method requires fragmentation, such as for the exchange of large
certificate chains, then the number of round-trips increases.
266
•
The number of simultaneous EAP negotiations is limited to 50 because of resource
limitations. Consequently, the time required to bring up interfaces when you configure
EAP authentication is longer than when you specify PAP or CHAP authentication.
•
EAP authentication methods fragment packets when the EAP packet size is greater
than the link MTU. The EAP server must fragment the EAP packet to the size of the
Framed-Mtu attribute contained in the RADIUS Access-Request packet.
Copyright © 2010, Juniper Networks, Inc.
Chapter 8: Configuring Point-to-Point Protocol
If the server fragments the packet to a larger size than specified by the attribute, then
JunosE drops the packet, because the E Series router acts as a pass-through device
and is not involved in the authentication method's fragmentation and reassembly
mechanisms.
On the other hand, if the EAP server fragments the EAP packet to a smaller size than
specified by the attribute, then performance decreases because of the increased
number of smaller packets that must be exchanged.
•
The EAP client on the peer must fragment the EAP packets to the size of the link MTU
on the E Series router. When it does not do so, performance can be affected.
Remote Peer Scenarios During Negotiation of PPP Options
During a PPP configuration request, if any of the primary or secondary DNS option is
rejected, or if they are unacceptable, the CPE (Customer Premises Equipment) is
prompted to negotiate the IPCP primary and secondary DNS options that are locally
available with the B-RAS (Broadband Remote Access Server). This provision is controlled
by CLI and SNMP configuration options.
The following describes the peer negotiations in different scenarios:
•
•
•
The CPE does not send the prompted options in the subsequent configure request
•
If B-RAS sends another NAK, it prompts the options again, until max configure-nak
is exceeded
•
If B-RAS sends an ACK, it ignores the options and brings up the link
The CPE negotiates a different option from the prompted options
•
If B-RAS sends another NAK, it prompts the options again, until max configure-nak
is exceeded
•
If B-RAS sends an ACK, it ignores the options and brings up the link
The CPE negotiates the prompted options but the option values are not acceptable
•
•
The CPE negotiates the prompted options but some option values are not acceptable
•
•
B-RAS negotiation timer expires and the link is terminated
The CPE negotiates the prompted option after the link comes up
•
•
B-RAS sends a NAK for unacceptable options, until max configure-nak is exceeded
The CPE stops responding on receiving the prompted options
•
•
B-RAS sends another NAK with the prompted options, until max configure-nak is
exceeded
This is treated as a renegotiation request and B-RAS sends an ACK/NAK until max
renegotiation and max configure-nak counters are exceeded, respectively
The CPE starts renegotiation without the prompted options
•
B-RAS renegotiates, until max renegotiation is exceeded
Copyright © 2010, Juniper Networks, Inc.
267
JunosE 11.3.x Link Layer Configuration Guide
•
•
If B-RAS sends a NAK, it prompts the options, until max configure-nak is exceeded
•
If B-RAS sends an ACK, it ignores the options and brings up this link
The CPE NAKs or rejects the prompted options
•
This behavior is non-compliant with RFC because a configure-rej or a configure-nak
must be sent only in response to a configure-req
IPCP Lockout and Local IP Address Pool Restoration
You can configure the router to terminate invalid IPv4 subscribers and return the unused
IPv4 addresses to the local address pool. When Internet Protocol version 6 Control
Protocol (IPv6CP) is negotiated, the router waits for 10 seconds for Internet Protocol
Control Protocol (IPCP) negotiation. If IPCP is not negotiated in 10 seconds, the interface
blocks IPv4 over Network Control Protocol (NCP) packets and the IP address is returned
to the local address pool. The subscribers must then reconnect to negotiate IPCP again.
The router assigns IPv4 and IPv6 addresses for a PPP subscriber after authentication in
the following ways:
•
RADIUS returns a valid IP address or a IPv6 prefix
•
The configured local address pool returns a valid IP address
The subscriber can negotiate IPv4 addresses, IPv6 addresses, or both. After an IPv6
address is negotiated for an IPCP service, the PPP application waits for the negotiation
of IPv4 address and then returns the assigned unused addresses to the local pool. By
default, this feature is disabled. To enable the feature, issue the ppp ipcp lockout
command from Interface Configuration, Subinterface Configuration, or Profile
Configuration modes. This command terminates the invalid subscriber entry and prevents
additional IPCP negotiations. When IPv6CP is active and if the IPCP must close, the router
does not terminate PPP and Link Control Protocol (LCP) and does not return the address
to the pool. In this case, AAA uses the assigned IP address and reassigns the same address
when IPCP is negotiated again.
IPCP Negotiation with Optional Peer IP Address
During normal operation for an IPCP negotiation, if the client does not request a specific
IP address, the server sends an IP address obtained from RADIUS or from the local address
pool.
If the client seeks a specific IP address, on receiving a NAK from the server, it sends a
confReq message without specifying the IP address option. In this case, even though the
server sends an IPCP confAck message , the server terminates the client because the
server requires an IP address from the client.
You can use the ppp peer-ip-address-optional command in Global Configuration mode
to specify that the peer IP address is optional. By default, this command is disabled. This
feature also supports high availability (HA) and unified in-service software upgrade
(Unified ISSU).
268
Copyright © 2010, Juniper Networks, Inc.
Chapter 8: Configuring Point-to-Point Protocol
NOTE: Even though the ppp peer-ip-address-optional command is
configured, on receiving a NAK from the server, if the client sends an IPCP
confReq message with specific IP address, IPCP is terminated after a
maximum of five attempts.
When the IPCP negotiation succeeds by configuring the ppp peer-ip-address-optional
command, the server does not have the client IP address. An IP address from RADIUS or
from the local pool is allocated to the client and the route towards this is added on the
server even though the client is not assigned with this address. If you want the server to
have the route to the client-requested IP address, use the framed-route RADIUS attribute
or configure statics routes. The client adds or configures static routes towards the server
for proper forwarding.
Platform Considerations
You can configure PPP interfaces on the following E Series Broadband Services Routers:
•
E120 router
•
E320 router
•
ERX1440 router
•
ERX1410 router
•
ERX710 router
•
ERX705 router
•
ERX310 router
Module Requirements
For information about the modules that support PPP interfaces on ERX14xx models,
ERX7xx models, and the ERX310 router:
•
See ERX Module Guide, Table 1, Module Combinations for detailed module specifications.
•
See ERX Module Guide, Appendix A, Module Protocol Support for information about the
modules that support PPP.
For information about the modules that support PPP interfaces on the E120 and E320
routers:
•
See E120 and E320 Module Guide, Table 1, Modules and IOAs for detailed module
specifications.
•
See E120 and E320 Module Guide, Appendix A, IOA Protocol Support for information
about the modules that support PPP.
Copyright © 2010, Juniper Networks, Inc.
269
JunosE 11.3.x Link Layer Configuration Guide
Interface Specifiers
Some of the configuration task examples in this chapter use the slot/port[.subinterface
] format to specify the physical interface on which you want to configure PPP. However,
the interface specifier format that you use depends on the router that you are using.
For ERX7xx models, ERX14xx models, and ERX310 router, use the slot/port[.subinterface
] format. For example, the following command specifies ATM 1483 subinterface 10 on
slot 0, port 1 of an ERX7xx model, ERX14xx model, or ERX310 router.
host1(config)#interface atm 0/1.10
For E120 and E320 routers, use the slot/adapter/port[.subinterface ] format, which includes
an identifier for the bay in which the I/O adapter (IOA) resides. In the software, adapter
0 identifies the right IOA bay (E120 router) and the upper IOA bay (E320 router); adapter
1 identifies the left IOA bay (E120 router) and the lower IOA bay (E320 router). For
example, the following command specifies ATM 1483 subinterface 20 on slot 5, adapter
0, port 0 of an E320 router.
host1(config)#interface atm 5/0/0.20
For more information about supported interface types and specifiers on E Series routers,
see Interface Types and Specifiers in JunosE Command Reference Guide.
References
For more information about the PPP protocol, consult the following resources:
270
•
L2TP Proxy Authenticate Extensions for
EAP—draft-ietf-l2tpext-proxy-authen-ext-eap-01.txt (December 2006 expiration)
•
RFC 1332—The PPP Internet Protocol Control Protocol (IPCP) (May 1992)
•
RFC 1661—The Point-to-Point Protocol (PPP) (July 1994)
•
RFC 1662—PPP in HDLC-like Framing (July 1994)
•
RFC 1877—PPP Internet Protocol Control Protocol Extensions for Name Server
Addresses (December 1995)
•
RFC 1994—PPP Challenge Handshake Authentication Protocol (CHAP) (August 1996)
•
RFC 2153—PPP Vendor Extensions (May 1997)
•
RFC 2246—The TLS Protocol Version 1.0 (January 1999)
•
RFC 2615—PPP over SONET/SDH (June 1999)
•
RFC 2716—PPP EAP TLS Authentication Protocol (October 1999)
•
RFC 3032—MPLS Label Stack Encoding (January 2001)
•
RFC 3579—RADIUS EAP (September 2003)
•
RFC 3748—Extensible Authentication Protocol (EAP) (June 2004)
Copyright © 2010, Juniper Networks, Inc.
Chapter 8: Configuring Point-to-Point Protocol
NOTE: IETF drafts are valid for only 6 months from the date of issuance.
They must be considered as works in progress. Please refer to the IETF
Web site at http://www.ietf.org for the latest drafts.
Before You Configure PPP
Before you configure a PPP interface, configure the interface or tunnel over which PPP
traffic will flow. See the following chapters:
•
Configuring Channelized T3 Interfaces in JunosE Physical Layer Configuration Guide
•
Configuring T3 and E3 Interfaces in JunosE Physical Layer Configuration Guide
•
Configuring Unchannelized OCx/STMx Interfaces in JunosE Physical Layer Configuration
Guide
•
Managing Tunnel-Service and IPSec-Service Interfaces in JunosE Physical Layer
Configuration Guide
•
“Configuring ATM” on page 3
•
“Configuring Packet over SONET” on page 359
•
“Configuring Point-to-Point Protocol over Ethernet” on page 371
The procedures described in this chapter assume that a physical interface has been
configured.
Configuration Tasks
The following procedure is an example of a PPP configuration on a serial interface. These
steps are mandatory unless otherwise noted.
1.
From Global Configuration mode, specify the physical interface on which you want
to configure PPP.
host1(config)#interface serial 3/0:2/5
2. Specify PPP as the encapsulation method (data-link protocol) on the interface.
host1(config-if)#encapsulation ppp
3. Assign an IP address and subnet mask for the interface.
host1(config-if)#ip address 192.168.22.10 255.255.255.0
4. Verify that your configuration changes are correct.
host1#show ppp interface serial 3/0:2/5 config
encapsulation ppp
•
Use to configure PPP as the encapsulation method.
•
Example
Copyright © 2010, Juniper Networks, Inc.
271
JunosE 11.3.x Link Layer Configuration Guide
host1(config-if)#encapsulation ppp
•
Use the no version to disable PPP on an interface.
•
See encapsulation ppp.
•
Use to specify a previously configured ATM interface on which you want to configure
PPP.
•
To specify an ATM interface for ERX7xx models, ERX14xx models, and ERX310 router,
use the slot/port.[subinterface ] format.
interface atm
•
•
slot—Number of the chassis slot
•
port—Port number on the I/O module
•
subinterface—Number of the subinterface in the range 1–2147483647
To specify an ATM interface for E120 and E320 routers, use the
slot/adapter/port[.subinterface ] format.
•
slot—Number of the chassis slot
•
adapter—Identifier for the IOA within the E320 chassis, either 0 or 1, where:
•
0 indicates that the IOA is installed in the right IOA bay (E120 router) or the upper
IOA bay (E320 router).
•
1 indicates that the IOA is installed in the left IOA bay (E120 router) or the lower
IOA bay (E320 router).
•
port—Port number on the IOA
•
subinterface—Number of the subinterface in the range 1–2147483647
•
For more information, see “Creating a Basic Configuration” on page 21 in “Configuring
ATM” on page 3.
•
Examples
host1(config-if)#interface atm 9/1.1
host1(config-if)#interface atm 5/0/1.1
•
Use the no version to disable or remove the subinterface or the logical interface.
•
See interface atm.
•
Use to specify a previously configured packet over SONET (POS) interface on which
you want to configure PPP.
•
To specify a POS interface for ERX7xx models, ERX14xx models, and ERX310 router,
use the slot/port.[subinterface ] format.
interface pos
272
•
slot—Number of the chassis slot
•
port—Port number on the I/O module
Copyright © 2010, Juniper Networks, Inc.
Chapter 8: Configuring Point-to-Point Protocol
•
•
subinterface—Number of the subinterface
To specify a POS interface for E120 and E320 routers, use the slot/adapter/port format.
•
slot—Number of the chassis slot
•
adapter—Identifier for the IOA within the E320 chassis, either 0 or 1, where:
•
•
0 indicates that the IOA is installed in the right IOA bay (E120 router) or the upper
IOA bay (E320 router).
•
1 indicates that the IOA is installed in the left IOA bay (E120 router) or the lower
IOA bay (E320 router).
port—Port number on the IOA
•
For more information about modules that support POS interfaces, see chapter
Configuring Unchannelized OCx/STMx Interfaces in JunosE Physical Layer Configuration
Guide.
•
Examples
host1(config-if)#interface pos 0/1
host1(config-if)#interface pos 5/0/0
•
Use the no version to remove the POS interface.
•
See interface pos.
•
Use to specify a serial interface in the slot/port:channel/subchannel format by selecting
a previously configured physical interface on which you want to configure PPP.
interface serial
•
•
slot—Refers to a router chassis slot.
•
port—Refers to a CT3, T3, or E3 module I/O port.
•
channel—Refers to a T1 (DS1) channel.
•
subchannel—Represents a set of DS0 subchannels.
Example
host1(config)#interface serial 3/0:2/5
•
Use the no version to disable or remove the subinterface or the logical interface.
•
See interface serial.
•
Use to assign an IP address and subnet mask for a PPP interface.
•
Example
ip address
host1(config-if)#ip address 192.168.22.10 255.255.255.0
•
Use the no version to remove an IP address or disable IP processing.
•
See ip address.
Copyright © 2010, Juniper Networks, Inc.
273
JunosE 11.3.x Link Layer Configuration Guide
Optional Configuration Tasks
You can perform the following optional PPP configuration tasks:
•
Add a text description or alias to a PPP interface.
•
Configure the IPCP netmask option (option 0x90).
•
Specify the keepalive timeout value.
•
Disable magic numbers.
•
Control validation of the LCP peer magic number when the peer has not negotiated
an LCP magic number.
•
Configure the maximum number of LCP, IPCP, or IPv6CP renegotiation attempts that
the router accepts before terminating a PPP session.
•
Specify the maximum receive units.
•
Configure passive mode.
•
Specify that the peer IP address is optional for an IPCP negotiation.
•
Configure name server addressing.
•
Stop or restart a PPP session.
•
Configure PPP authentication.
•
Use to assign a text description or alias to a static PPP interface.
•
Example
ppp description
host1(config-if)#ppp description pah8999
•
Use the no version to remove the description.
•
See ppp description.
•
Use to terminate invalid IPv4 subscribers and prevent additional IPCP negotiations.
•
When Internet Protocol version 6 Control Protocol (IPv6CP) is active, this command
enables unused IPv4 addresses, which are allocated for the IPv6 subscribers, to be
available for the IPCP services for an internally defined time interval (10 seconds).
When the time interval elapses, the subscriber must connect again to negotiate IPCP.
•
Example
ppp ipcp lockout
host1(config-subif)#ppp ipcp lockout
•
Use the no version to disable the IPCP lockout option on the interface.
•
See ppp ipcp lockout.
ppp ipcp netmask
274
Copyright © 2010, Juniper Networks, Inc.
Chapter 8: Configuring Point-to-Point Protocol
•
Use to specify the IPCP netmask option (option 0x90) for each PPP interface. By
default, the IPCP netmask option is disabled on the interface.
•
The IPCP netmask option is a nonstandard option that enables a peer to request the
netmask associated with the assigned IP address.
•
The netmask can be specified via RADIUS attribute 9, Framed-Ip-Netmask. If the
netmask is 255.255.255.255, the option is not negotiated. See the radius ignore
framed-ip-netmask command.
•
You can enable the IPCP netmask option either in a profile or on a static interface.
•
Example
host1(config-subif)#ppp ipcp netmask
•
Use the no version to disable the IPCP netmask option on the interface.
•
See ppp ipcp netmask.
•
Use to specify the keepalive timeout value.
•
There are two keepalive modes of operation: high-density mode and low-density mode.
ppp keepalive
•
High-density keepalive mode is automatically selected if PPP is layered over ATM,
L2TP, or PPPoE.
•
Low-density keepalive mode is selected if PPP is layered over HDLC. Keepalive mode
selection is made per interface.
•
High-density mode—This mode is also known as smart keepalive. When the keepalive
timer expires, the interface first verifies whether any frames were received from the
peer in the prior keepalive timeout interval. If so, the interface does not send an LCP
echo request (keepalive). Keepalive packets are sent only if the peer is silent (that is,
no traffic was received from the peer during the previous keepalive timeout interval).
If both sides are configured with keepalive, receipt of an LCP echo request by one end
suppresses the transmission of an LCP echo request by that end. Smart keepalive is
disabled when the keepalive timeout value is at least 60 seconds, even when in
high-density mode. Smart keepalive is always disabled when in low-density mode.
This mode suppresses transmission of unnecessary LCP echo requests.
•
For high-density keepalive mode, the range is 30–64800 seconds. The default value
is 30 seconds.
•
Low-density mode—When the keepalive timer expires, the interface always sends an
LCP echo request, regardless of whether the peer is silent.
•
For low-density keepalive mode, the range is 1–64800 seconds for POS uplink
interfaces, and 10–64800 seconds for all other HDLC interfaces. The default value for
all interfaces is 30 seconds.
•
If the keepalive interval is 30 seconds, a failed link is detected between 90 and 120
seconds after failure.
•
Use ppp keepalive without a value to restore the default, 30 seconds.
Copyright © 2010, Juniper Networks, Inc.
275
JunosE 11.3.x Link Layer Configuration Guide
•
Example
host1(config-if)#ppp keepalive 50
•
Use the no version to disable keepalive.
•
See ppp keepalive.
ppp magic-number disable
•
Use to disable negotiation of the local magic number.
•
Issuing this command prevents the router from detecting loopback configurations.
•
Example
host1(config-if)#ppp magic-number disable
•
Use the no version to restore negotiation of the local magic number.
•
See ppp magic-number disable.
ppp magic-number ignore-mismatch
•
Use to cause the router to ignore a mismatch of the LCP peer magic number and retain
the PPP connection when the peer has not negotiated an LCP magic number.
•
For more information about using this command, see “Validation of LCP Peer Magic
Number” on page 261.
•
Example
host1(config-if)#ppp magic-number ignore-mismatch
•
Use the no version to restore the default behavior, in which the router terminates the
PPP connection if it detects an LCP peer magic number mismatch.
•
See ppp magic-number ignore-mismatch.
•
Use to configure the maximum number of LCP, IPCP, or IPv6CP renegotiation attempts,
in the range 1–65535, that the router accepts before terminating a PPP session.
•
Configuring the maximum number of renegotiation attempts helps avoid massive
renegotiation loops that can occur between the router and a noncompliant PPP client.
Such renegotiation loops can cause excessive CPU utilization and can prevent the PPP
client from coming up properly.
•
When a PPP client exceeds the configured maximum number of renegotation attempts,
the router sends a termination request to end the PPP session. When the PPP session
is terminated and LCP goes into a stopped (closed) state, static PPP or MLPPP
interfaces go into passive mode and wait for the other side of the connection to start
the LCP negotiation process.
•
If you do not specify the optional lcp, ipcp, or ipv6cp keyword, the ppp
max-negotiations command sets the maximum number of renegotiation attempts
for each of LCP, IPCP, and IPv6CP to the value you specify, or to the default value (30)
if you omit the optional value for maximum renegotiation attempts.
ppp max-negotiations
276
Copyright © 2010, Juniper Networks, Inc.
Chapter 8: Configuring Point-to-Point Protocol
•
When both IPv4 interface columns and IPv6 interface columns are configured over a
PPP link-layer interface, the router terminates the PPP session only when the PPP
client exceeds the configured maximum number of renegotiation attempts for both
the IPv4 interface and the IPv6 interface.
•
Example 1—Sets the maximum number of LCP renegotiation attempts to 5
host1(config-if)#ppp max-negotiations lcp 5
•
Example 2—Sets the maximum number of IPCP renegotiation attempts to 30 (the
default)
host1(config-if)#ppp max-negotiations ipcp
•
Example 3—Sets the maximum number of LCP, IPCP, and IPv6CP renegotiation
attempts to 15
host1(config-if)#ppp max-negotiations 15
•
Example 4—Restores the maximum number of LCP, IPCP, and IPv6CP renegotiation
attempts to the default value, 30
host1(config-if)#no ppp max-negotiations
•
Use the no version to restore the default value, 30 renegotiation attempts.
•
See ppp max-negotiations.
•
Use to control the negotiation of the maximum receive unit (MRU).
•
Specify the number of bytes, in the range 64–65535.
•
We recommend you coordinate this value with the network administrator on the other
end of the line.
•
If the value configured for the PPP MRU is greater than the value of the lower-layer
MRU minus the PPP header length, the router logs a warning message and uses the
lesser of the configured MRU value or the lower-layer MRU value minus the PPP header
length to negotiate the local MRU.
•
If the value configured for the PPP MRU conflicts with a similar value configured for
another protocol, such as the MTU value for PPPoE, the router uses the lesser of the
two values.
•
Example
ppp mru
host1(config-if)#ppp mru 576
•
Use the no version to restore the default value, which causes PPP to use the lower-layer
MRU minus the PPP header length as the MRU value.
•
See ppp mru.
ppp passive-mode
Copyright © 2010, Juniper Networks, Inc.
277
JunosE 11.3.x Link Layer Configuration Guide
•
Use to force a static or dynamic PPP interface into passive mode before LCP negotiation
begins, for a period of one second. This delay enables slow clients to start up and
initiate the LCP negotiation.
•
Example
host1(config-if)#ppp passive-mode
•
Use the no version to disable passive mode.
•
See ppp passive-mode.
•
Use to resolve conflicts when the router and the PPP peer have the primary and
secondary DNS and WINS name server addresses configured with different values.
•
By default, the DNS and WINS addresses configured on the router take precedence.
•
Use the dns keyword or the wins keyword to configure which PPP peer address takes
precedence. This command has no effect unless both routers have the address
configured and the address is in conflict. If the PPP peer has the address and the router
does not, the peer always supplies the address regardless of how you have configured
the PPP peer.
•
Example
ppp peer
host1(config-if)#ppp peer dns
•
Use the no version when you want the router to take precedence during setup
negotiations between the router and the peer. If the IP addresses that the peer sends
to the router differ from the ones configured on your router, the router returns the values
that you configured as the correct values to the peer.
•
See ppp peer.
ppp peer-ip-address-optional
•
Use to specify that the peer IP address is optional in an IPCP configuration request. By
default this command is disabled.
•
Example
host1(config)#ppp peer-ip-address-optional
•
Use the no version to restore the default behavior
•
See ppp peer-ip-address-optional.
ppp shutdown
ppp shutdown ip
ppp shutdown ipv6
ppp shutdown mpls
ppp shutdown osi
278
Copyright © 2010, Juniper Networks, Inc.
Chapter 8: Configuring Point-to-Point Protocol
•
Use to terminate a PPP session.
•
To administratively disable the interface, use the ppp shutdown command.
•
To administratively disable IPCP, use the ppp shutdown ip command.
•
To administratively disable IPv6CP, use the ppp shutdown ipv6 command.
•
To administratively disable MPLS, use the ppp shutdown mpls command.
•
To administratively disable OSINLCP, use the ppp shutdown osi command.
•
All PPP sessions are enabled by default.
•
Example
host1(config-if)#ppp shutdown
•
Use the no version to restart a disabled session.
•
See ppp shutdown.
Configuring PPP Authentication
Perform the following optional tasks to configure PPP authentication:
•
Specify one or more PPP authentication types, and select an authentication virtual
router context.
•
Specify the CHAP challenge length.
•
Specify the maximum number of retries.
NOTE: The JunosE Software’s PPP application accepts null usernames
during PAP and CHAP authentication. When the PPP application receives
an authentication request that includes a null username, PPP passes the
request to AAA. To take advantage of this feature, configure your
authentication server to support the use of null usernames.
ppp authentication
•
Use to request authentication from a PPP peer and set the authentication method.
•
To specify the name of a virtual router (VR) to be used as the authentication VR context,
use the virtual-router keyword. Keep the following points in mind when you use the
ppp authentication virtual-router command:
•
When you specify a VR in the ppp authentication command, AAA does not query
the domain map for the assigned VR context. Instead, AAA uses the VR specified in
the ppp authentication command as the authentication VR context and issues the
authentication request to the authentication server in the assigned VR context.
•
If you specify the default VR as the authentication VR context, AAA loosely binds
the user to the default VR. This means that RADIUS can override the default VR
context with a new VR context during the authentication process. When the ppp
Copyright © 2010, Juniper Networks, Inc.
279
JunosE 11.3.x Link Layer Configuration Guide
authentication virtual-router command specifies the default VR, AAA returns either
the default VR or the VR specified by RADIUS.
•
If you specify a VR other than the default VR as the authentication VR, AAA tightly
binds the user to the specified VR. This means that RADIUS cannot override the
specified VR context with a new VR context during the authentication process. When
the ppp authentication virtual-router command specifies a nondefault VR, AAA
returns the specified VR.
•
The router supports the MD5 authentication algorithm for CHAP authentication.
•
You can specify one or more authentication protocols in order of preference. If the peer
router refuses the first choice, then the local router requests the next authentication
protocol, if specified. If the peer refuses that protocol, then the local router requests
the third protocol, if specified. If the peer refuses all specified authentication protocols,
then the local router terminates the session.
•
Example 1—Specifies the order of preference for the primary authentication protocol
host1(config-if)#ppp authentication pap chap eap
The router requests the use of PAP as the authentication protocol (because it appears
first in the command line). If the peer refuses to use PAP, the router requests the CHAP
protocol. If the peer refuses to use CHAP, the router requests the EAP protocol. If the
peer refuses to negotiate authentication, the router terminates the PPP session.
•
Example 2—Specifies a virtual router for the authentication virtual router context
host1(config-if)#ppp authentication virtual-router boston pap chap
This command is available in static configurations and in profiles.
•
Example 3—Configures only EAP on a static PPP interface
host1(config)#interface atm 3/2.100
host1(config-subif)#ppp authentication eap
•
Example 4—Configures EAP or PAP on a static PPP interface
host1(config)#interface atm 3/2.100
host1(config-subif)#ppp authentication eap pap
EAP negotiation is attempted first. If PPP receives a NAK from the peer in response to
the EAP request, then PAP is attempted. If PAP is also rejected, then PPP terminates
the session.
•
Example 5—Configures only EAP on a dynamic PPP interface
host1(config)#profile ppptest
host1(config-profile)#ppp authentication eap
•
Example 6—Configures EAP or CHAP or PAP on a dynamic PPP interface
host1(config)#profile ppptest
host1(config-profile)#ppp authentication eap chap pap
In this example, the router first attempts EAP negotiation. If PPP receives a NAK from
the peer in response to the EAP request, then the router attempts CHAP negotiation.
280
Copyright © 2010, Juniper Networks, Inc.
Chapter 8: Configuring Point-to-Point Protocol
If PPP receives a NAK from the peer in response to the CHAP request, then the router
attempts PAP negotiation. If PAP is also rejected, then PPP terminates the session.
•
Use the no version to specify that the router does not require authentication.
•
See ppp authentication.
ppp chap-challenge-length
•
Use to modify the length of the CHAP challenge by specifying the allowable minimum
length and maximum length.
•
Specify the minimum and maximum lengths in bytes in the range 8–63.
CAUTION: Do not decrease the range. Increasing the range is acceptable,
provided that you do not lower the minimum to do so. The recommended
minimum is 16. A longer challenge and a more unpredictable challenge
length provide a higher level of security.
•
The maximum length must be greater than or equal to the minimum length.
•
Example
host1(config-if)#ppp chap-challenge-length 24 28
•
Use the no version to restore the default minimum (16 bytes) and default maximum
(32 bytes).
•
See ppp chap-challenge-length.
•
Use to specify the maximum number of authentication retries the router allows before
terminating a PPP session
•
This value applies to PAP and CHAP authentication.
•
The range is 0–7. The default is 0, which indicates that no retries are allowed.
•
Example
ppp max-bad-auth
host1(config-if)#ppp max-bad-auth 3
•
Use the no version to return the number of retries to the default, 0.
•
See ppp max-bad-auth.
PPP Accounting Statistics
The JunosE Software begins the collection of accounting statistics for terminated PPP
sessions following, but not including, authentication acknowledgement from the E Series
router. The acknowledgment is either a CHAP success or PAP acknowledgement packet.
Copyright © 2010, Juniper Networks, Inc.
281
JunosE 11.3.x Link Layer Configuration Guide
All subsequent traffic is counted up the point that PPP at the router terminates the
subscriber's session. The statistics are reported in the following RADIUS attributes:
Attribute Number
Attribute Name
42
Acct-Input-Octets
43
Acct-Output-Octets
47
Acct-Input-Packets
48
Acct-Output-Packets
PPP session termination can be initiated through a number of mechanisms: PPP shutdown
at the client or router interface, subscriber logout at the router (by means of the logout
subscriber command), lower layer down events, and silent client termination.
The following rules apply to all termination scenarios:
•
•
•
Accounting statistics reported in RADIUS octet counts (Acct-Input-Octets and
Acct-Output-Octets) for terminated PPP customers include the following data:
•
All upper layer control traffic, including IPCP, IPCPv6, OSICP, and MPLSNCP
•
All data traffic, including IP, IPv6, MPLS, and OSI
•
All PPP LCP echo requests and responses following authentication
•
Other PPP LCP packets following the PAP or CHAP acknowledgment
•
Retransmits of the PAP or CHAP traffic
PPP accounting statistics reported in RADIUS octet counts (Acct-Input-Octets and
Acct-Output-Octets) exclude the following data:
•
PPP traffic prior to completion of authentication
•
PPP LCP terminate-request or terminate-acknowledgement packets
•
PPPoE padding for PPP control and data packets
Accounting statistics reported in RADIUS packet counts (Acct-Input-Packets and
Acct-Output-Packets) for terminated PPP customers are based on packets delivered
to or received from the upper transport layer: IP, IPv6, MPLS, and OSI.
For information on accounting statistics for tunneled PPP sessions, see PPP Accounting
Statistics.
Monitoring PPP Interfaces
Use the following versions of the show ppp interface command to monitor PPP interfaces:
•
282
show ppp interface
Copyright © 2010, Juniper Networks, Inc.
Chapter 8: Configuring Point-to-Point Protocol
•
show ppp interface summary
You can set a statistics baseline for PPP interfaces using the baseline ppp commands.
Use the optional delta keyword with PPP show commands to show baselined statistics.
You can use the output filtering feature of the show command to include or exclude lines
of output based on a text string that you specify. Refer to the show Commands in JunosE
System Basics Configuration Guide, for details.
NOTE: The E120 and E320 routers output for monitor and show commands
is identical to output from other E Series routers, except that the E120 and
E320 routers output also includes information about the adapter identifier
in the interface specifier (slot/adapter/port).
baseline ppp interface
•
Use to establish a baseline for PPP statistics on an interface.
•
The router implements the baseline by reading and storing the statistics at the time
the baseline is set, then subtracting this baseline whenever baseline-related statistics
are retrieved.
•
Use the optional delta keyword with PPP show commands to show baselined statistics.
•
Examples
host1#baseline ppp interface atm 3/3.20
host1#baseline ppp interface atm 3/0/3.20
•
There is no no version.
•
See baseline ppp interface.
•
Use to display selective PPP interface information.
•
You can filter the command display for characteristics of particular interest, such as
interface type, data type, configured protocol, or interface state.
•
Field descriptions
show ppp interface
•
inactivity-timeout—Inactivity timeout, in seconds; session is terminated if it is not
active for specified timeout
•
monitor-ingress-only—Indicates whether the router monitors only ingress traffic for
the configured idle (inactivity) timeout period; true (router monitors only ingress
traffic) or false (router monitors both ingress traffic and egress traffic)
•
PPP interface—Interface type, interface specifier, and status (up, down, lowerDown,
not present, passive, or tunnel). For more information about specifying the physical
interface on which you want to configure PPP, see Interface Types and Specifiers in
JunosE Command Reference Guide.
Copyright © 2010, Juniper Networks, Inc.
283
JunosE 11.3.x Link Layer Configuration Guide
•
accounting-timeout—Accounting timeout in seconds; frequency of accounting
updates to the authentication server
•
Interface alias—Alias or description of the PPP interface
•
Interface administrative status—Indicates whether the interface is administratively
enabled (open), meaning that the no ppp shutdown command is operational; or
administratively disabled (closed), which means that the ppp shutdown command
is operational
•
Configured network protocol—Indicates the network protocol configured on the
interface
•
Baseline status—Indicates whether a statistics baseline is set
•
Interface statistics
•
284
•
packets—Number of packets received (in) or transmitted (out) on the interface
•
octets—Number of octets received (in) or transmitted (out) on the interface
•
errors—Number of errors received (in) or transmitted (out) on the interface
•
discards—Number of packets discarded on receipt (in) or discarded before they
were transmitted (out); for more information about the discards counter, see “Rate
Limiting for PPP Control Packets” on page 263
•
policed—Number of packets received (in) and marked as per the rates configured
for the interface; for more information, see “Rate Limiting for PPP Control Packets”
on page 263
IPCP protocol configuration
•
configured—IPCP is configured on this interface (true or false)
•
administrative-status—IPCP administrative status (open or closed)
•
ip-address—Address to be used for negotiation of the local IP address option
•
dns-precedence—Used to resolve conflicts during negotiation of DNS addresses;
“local” indicates that the local side takes precedence and the no ppp peer dns
command is operative; “peer” indicates that the remote side takes precedence
and the ppp peer dns command is operative
•
wins-precedence—Used to resolve conflicts during negotiation of WINS addresses;
“local” indicates that the local side takes precedence and the no ppp peer wins
command is operative; “peer” indicates that the remote side takes precedence
and the ppp peer wins command is operative
•
ipcp-netmask-option—Controls negotiation of the IPCP netmask option; disabled
= do not negotiate, enabled = negotiate
•
ipcp-lockout-option—Terminates an invalid subscriber entry and prevents
additional IPCP negotiations (enabled or disabled)
Copyright © 2010, Juniper Networks, Inc.
Chapter 8: Configuring Point-to-Point Protocol
•
•
•
•
•
max-negotiations—Maximum number of renegotiation attempts that the router
accepts before terminating a PPP session
•
ipcp prompt-option dns—Prompts the CPE (Customer Premises Equipment) to
negotiate the IPCP primary and secondary DNS options that are locally available
with the broadband remote access server (enabled or disabled)
IPV6CP protocol configuration
•
configured—IPv6CP is configured on this interface (true or false)
•
administrative-status—IPv6CP administrative status (open or closed)
•
ipv6-interfaceId—Address to be used for negotiation of local IPv6 address option
IPCP protocol status
•
operational-status—IPCP operational status (up, down, not present, or not present
no resources)
•
terminate-reason—Reason for termination of IPCP service
IPV6CP protocol status
•
operational-status—IPv6CP operational status (up, down, not present, or not
present no resources)
•
terminate-reason—Reason for termination of IPv6CP service
IPCP negotiated options—Shows the following negotiated addresses for the local
and remote (peer) side of the link
•
ip-address—IP address
•
ip-address-mask—IP address mask
•
primary-dns-address—Primary DNS address
•
secondary-dns-address—Secondary DNS address
•
primary-wins-address—Primary WINS address
•
secondary-wins-address—Secondary WINS address
NOTE: The command displays a value of “none” for any negotiated
option parameters if the option was not negotiated.
•
•
OSINLCP protocol configuration
•
configured—OSINLCP is configured on this interface (true or false)
•
administrative-status—OSINLCP administrative status (open or closed)
OSINLCP protocol status
Copyright © 2010, Juniper Networks, Inc.
285
JunosE 11.3.x Link Layer Configuration Guide
•
•
operational-status—OSINLCP operational status (up, down, not present, or not
present no resources)
•
terminate-reason—Reason for termination of OSINLCP service
OSINLCP negotiated options
•
npdu-alignment—Negotiated NPDU alignment for the local and remote (peer)
side of the link
NOTE: The command displays a value of “none” for any negotiated
option parameters if the option was not negotiated.
•
•
•
MPLSNLCP protocol configuration
•
configured—MPLSNLCP is configured on this interface (true or false)
•
administrative-status—MPLSNLCP administrative status (open or closed)
MPLSNLCP protocol status
•
operational-status—MPLSNLCP operational status (up, down, not present, or not
present no resources)
•
terminate-reason—Reason for termination of MPLSNLCP service
MPLSNLCP negotiated options
•
npdu-alignment—Negotiated NPDU alignment for the local and remote (peer)
side of the link
NOTE: The command displays a value of “none” for any negotiated
option parameters if the option was not negotiated.
•
286
LCP protocol configuration
•
max-receive-unit—Controls negotiation of the local MRU option; “use lower layer”
indicates that the MRU of the layer below PPP defines the MRU to be negotiated;
“disabled” indicates that the MRU option is not to be negotiated. A numeric value
indicates the MRU value to be negotiated
•
authentication—Controls the negotiation of the local authentication option; “none”
indicates do not negotiate; “chap” indicates negotiate chap; “pap” indicates
negotiate pap; “chap/pap” indicates negotiate chap and, if it is rejected, negotiate
pap; “pap/chap” indicates negotiate pap and, if it is rejected, negotiate chap.
•
magic-number—Controls whether the local magic number is negotiated: enabled
(negotiate), or disabled (do not negotiate)
Copyright © 2010, Juniper Networks, Inc.
Chapter 8: Configuring Point-to-Point Protocol
•
•
magic-number-mismatch—Indicates whether the router is configured to ignore
the LCP peer magic number and retain the PPP connection when the peer has not
negotiated an LCP magic number: ignore (ignore the peer magic number mismatch
and retain the PPP connection), or reject (router terminates the PPP connection
if it detects a peer magic number mismatch)
•
keepalive-timer—Rate of LCP echo requests
•
restart-timer—Retry frequency during LCP, IPCP, OSINLCP, and MPLS negotiations
•
max-terminate—Maximum number of terminate requests
•
max-configure—Maximum number of configure requests
•
max-failure—Maximum number of configure NAKs
•
passive-mode—Forces a PPP interface into a passive mode before LCP negotiation
begins; “disabled” means do not wait for peer; “enabled” means wait for peer to
initiate negotiation
LCP protocol status
•
•
link-status—Overall status of LCP negotiations, including the following states:
Initial (idle), Starting (ready to negotiate), Authenticate (authenticating), and
Network (LCP is up)
LCP negotiated options—Shows the following negotiated values for the local and
remote (peer) side of the link:
•
max-receive unit—Maximum receive unit, in octets
•
authentication—Authentication method (none, pap, or chap)
•
magic-number—Magic number
•
pfc—PFC (none or enabled)
•
acfc—ACFC (none or enabled)
NOTE: The command displays a value of “none” for any negotiated
option parameters if the option was not negotiated.
•
LCP Endpoint Discriminator options
•
local discriminator class—Endpoint discriminator type, format, and address space
for the local and remote (peer) router
•
local endpoint discriminator—Endpoint discriminator value for the local router
within the specified class
Copyright © 2010, Juniper Networks, Inc.
287
JunosE 11.3.x Link Layer Configuration Guide
•
•
•
peer discriminator class—Endpoint discriminator type, format, and address space
for the remote router
•
peer endpoint discriminator—Endpoint discriminator value for the remote router
within the specified class
LCP protocol statistics—Shows the following statistics for the life of the interface
(since system boot or interface creation, whichever is later)
•
in-keepalive-requests—Number of received keepalive requests (LCP Echo
Requests)
•
out-keepalive-requests—Number of transmitted keepalive requests
•
in-keepalive-replies—Number of received keepalive replies
•
out-keepalive-replies—Number of transmitted keepalive replies
•
keepalive-failures—Number of keepalive failures reported on the interface
•
max-renegotiation-terminates—Number of renegotiation terminations for the PPP
session
IP protocol statistics
•
•
IPv6 protocol statistics
•
•
•
288
max-renegotiation-terminates—Number of times the link has been terminated
since it was created, due to the peer exceeding the maximum renegotiation
attempts.
max-renegotiation-terminates—Number of times the link has been terminated
since it was created, due to the peer exceeding the maximum renegotiation
attempts.
Authentication configuration
•
authenticate-retry—Maximum number of authentication retries configured using
the ppp max-bad-auth command
•
authentication-router—Virtual router for the authentication virtual router context
Authentication status
•
grant—Authentication status (true = access granted, false = access not granted)
•
session-timeout—Session timeout, in seconds; session is terminated at expiration
•
inactivity-timeout—Inactivity timeout, in seconds; session is terminated if it is not
active for specified timeout
•
accounting-timeout—Accounting timeout in seconds; frequency of accounting
updates to the authentication server
•
peer-ip-address—IP address to be used in negotiation of peer IP address
Copyright © 2010, Juniper Networks, Inc.
Chapter 8: Configuring Point-to-Point Protocol
•
peer-ip-address-mask—IP address mask to be used in negotiation of the peer IP
address mask
•
peer-primary-dns-address—IP address to be used in negotiation of the peer primary
DNS address
•
peer-secondary-dns-address—IP address to be used in negotiation of the peer
secondary DNS address
•
peer-primary-wins-address—IP address to be used in negotiation of the peer
primary WINS address
•
peer-secondary-wins-address—IP address to be used in negotiation of the peer
secondary WINS address
NOTE: The command displays the authentication status as “none” for
any parameters not provided by the authentication server.
•
•
•
Authentication statistics—Shows statistics accumulated since the session was
established
•
up-time—Time the session has been up, in seconds
•
in-octets—Number of octets received on the interface
•
out-octets—Number of octets transmitted out the interface
•
in-packets—Number of packets received on the interface
•
out-packets—Number of packets transmitted out the interface
PAP protocol configuration
•
•
peer-ipv6–interface-id—IPv6 interface Identifier of the peer returned in an
authentication grant from the RADIUS server
request-timeout—Maximum time, in seconds, to wait for an authentication request
packet
CHAP protocol configuration
•
name—Name to be used in challenge packets
•
challenge-retry—Maximum number of challenge packets to be transmitted
•
challenge-timeout—Frequency, in seconds, of challenge packet retransmission
•
minimum-challenge-length—Minimum length of challenge packet
•
maximum-challenge-length—Maximum length of challenge packet; the size of
the challenge used for each challenge packet is a random number between
minimum-challenge-length and maximum-challenge-length
Copyright © 2010, Juniper Networks, Inc.
289
JunosE 11.3.x Link Layer Configuration Guide
•
•
290
•
minimum-rechallenge-timeout—Minimum time, in seconds, before initiating a
rechallenge to peer
•
maximum-rechallenge-timeout—Maximum time, in seconds, before initiating a
rechallenge to peer; the actual time before a rechallenge is a random number
between minimum-rechallenge-timeout and maximum-rechallenge-timeout
EAP protocol configuration
•
request-retry—Maximum number of authentication requests retried before returning
a deny
•
request-timeout—Maximum time, in seconds, to wait for an authentication request
packet
If the operational status is down for a specific interface, one of the following
termination reasons might appear in parentheses:
•
administrative disable—Interface has been administratively disabled, which means
that the ppp shutdown command is in effect. This applies to an interface, IPCP,
IPv6CP, OSINLCP, and MPLS.
•
administrative logout—Interface has been administratively logged out, which
means that the logout subscriber command has been issued. This applies to an
interface only.
•
no upper interface—No upper layer is configured. This applies to an interface only.
•
authentication failure—Authentication is required and has failed. This applies to
an interface only.
•
no local xxx—local option, xxx, is required and could not be negotiated (for example,
IP address). This applies to an interface, IPCP, IPv6CP, OSINLCP, and MPLS.
•
no peer xxx—Remote peer option, xxx, is required and could not be negotiated (for
example, authentication). This applies to an interface, IPCP, IPv6CP, OSINLCP,
and MPLS.
•
keepalive drop count exceeded—Keepalive drop count has been exceeded. This
applies to an interface only.
•
session timeout—Session timeout period has expired. This applies to an interface
only.
•
inactivity timeout—Inactivity timeout period has expired. This applies to an interface
only.
•
address lease expired—Address lease period has expired. This applies to an
interface only.
•
not configured—Protocol is not configured on the interface. This applies to IPCP,
IPv6CP, OSINLCP, and MPLS.
Copyright © 2010, Juniper Networks, Inc.
Chapter 8: Configuring Point-to-Point Protocol
•
•
link down—Link is down and the protocol is not operationally up. This applies to
IPCP, IPv6CP, OSINLCP, and MPLS.
•
lower layer down—Lower protocol layer is down. This applies to an interface only.
•
max configure exceeded—Maximum number of configure requests was exceeded
while negotiations were in progress. This means that there was no response from
the peer, or the peer refused to negotiate. This applies to an interface, IPCP, IPv6CP,
OSINLCP, and MPLS.
•
peer requested termination—Remote peer requested termination of the connection,
which means that a terminate request was received while the session was in an
open state. This applies to an interface, IPCP, IPv6CP, OSINLCP, and MPLS.
Example 1—Provides detailed output for a particular IP interface
host1#show ppp interface gig 2/1/7.1.1 full
PPP interface GigabitEthernet 2/1/7.1.1 is upp
Interface administrative status is open
Configured network protocol is IPCP
IPCP protocol configuration
configured
true
administrative-status
open
ip-address
6.6.6.6
dns-precedence
local
wins-precedence
local
ipcp-netmask-option
disabled
ipcp-lockout
disabled
max-negotiations
30
ipcp prompt-option dns
enabled
IPCP protocol status
operational-status
up
IPCP negotiated options
local
ip-address
11.1.1.1
ip-address-mask
none
primary-dns-address
none
secondary-dns-address
none
primary-wins-address
none
secondary-wins-address
none
IPV6CP Protocol Configuration
configured
false
administrative-status
open
ipv6-interfaceId
0.0.0.0
max-negotiations
30
IPV6CP protocol status
operational-status
not present
OSINLCP protocol configuration
configured
false
administrative-status
open
OSINLCP protocol status
operational-status
not present
Interface statistics
in
packets
0
octets
14515
errors
0
discards
0
policed
0
LCP protocol configuration
max-receive-unit
use lower layer
Copyright © 2010, Juniper Networks, Inc.
peer
11.1.1.2
none
none
none
none
none
out
0
11296
0
0
0
291
JunosE 11.3.x Link Layer Configuration Guide
authentication
magic-number
magic-number-mismatch
keepalive-timer
restart-timer
max-terminate
max-configure
max-failure
passive-mode
LCP protocol status
link-status
LCP negotiated options
max-receive-unit
authentication
magic-number
accm
pfc
acfc
LCP protocol statistics
in-keepalive-requests
out-keepalive-requests
in-keepalive-replies
out-keepalive-replies
keepalive-failures
max-renegotiation terminates
IP protocol statistics
max-renegotiation-terminates
IPv6 protocol statistics
max-renegotiation-terminates
Authentication configuration
authenticate-retry
authentication-router
aaa-profile
''
Authentication status
grant
session-timeout
inactivity-timeout
monitor—ingress-only
accounting-timeout
peer-ip-address
peer-ip-address-mask
peer-primary-dns-address
peer-secondary-dns-address
peer-primary-wins-address
peer-secondary-wins-address
peer-ipv6–interface-id
Authentication statistics
up-time
in-octets
out-octets
in-packets
out-packets
PAP protocol configuration
request-timeout
CHAP protocol configuration
name
challenge-retry
challenge-timeout
minimum-challenge-length
maximum-challenge-length
minimum-rechallenge-timeout
292
enabled
reject
30 seconds
3 seconds
2
10
5
disabled
network
local
1492
none
0x3e51ca08
none
none
none
peer
1492
chap
0x740bbf81
none
none
none
11
11
11
11
0
0
0
0
0
''
true
none
none
false
none
none
none
none
none
none
none
none
0 seconds
0
0
0
0
20 seconds
''
10
4 seconds
16
32
0 seconds
Copyright © 2010, Juniper Networks, Inc.
Chapter 8: Configuring Point-to-Point Protocol
maximum-rechallenge-timeout
EAP Protocol Configuration
request-retry
request-timeout
•
0 seconds
5
3 seconds
Example 2—Provides detailed output for a particular IPv6 interface
host1#show ppp interface fastEthernet 12/0.1.1 full
PPP interface FastEthernet 12/0.1.1 is lowerDown
Interface administrative status is open
Configured network protocol is IPV6CP
IPCP protocol configuration
configured
false
administrative-status
open
ip-address
0.0.0.0
dns-precedence
local
wins-precedence
local
ipcp-netmask-option
disabled
ipcp-lockout-option
enabled
max-negotiations
10
IPCP protocol status
operational-status
not present
IPV6CP protocol configuration
configured
administrative-status
ipv6-interfaceId
IPV6CP protocol status
operational-status
terminate-reason
OSINLCP protocol configuration
configured
administrative-status
OSINLCP protocol status
operational-status
Interface statistics
packets
octets
errors
discards
LCP protocol configuration
max-receive-unit
authentication
magic-number
magic-number-mismatch
keepalive-timer
restart-timer
max-terminate
max-configure
max-failure
passive-mode
LCP protocol status
link-status
LCP protocol statistics
in-keepalive-requests
Copyright © 2010, Juniper Networks, Inc.
true
open
90:1a00:140:4b39
down
link down
false
open
not present
in
0
1163
0
153482
out
0
706
0
0
use lower layer
none
enabled
reject
30 seconds
3 seconds
2
10
5
disabled
initial
11
293
JunosE 11.3.x Link Layer Configuration Guide
out-keepalive-requests
in-keepalive-replies
out-keepalive-replies
keepalive-failures
Authentication configuration
authenticate-retry
authentication-router
aaa-profile
Authentication status
grant
terminate-reason
PAP protocol configuration
request-timeout
CHAP protocol configuration
name
challenge-retry
challenge-timeout
minimum-challenge-length
maximum-challenge-length
minimum-rechallenge-timeout
maximum-rechallenge-timeout
•
11
11
11
0
0
''
''
false
lower layer down
20 seconds
''
10
4 seconds
16
32
0 seconds
0 seconds
Example 3—Displays a termination reason (administrative disable) when the operational
status of the interface is down
host1#show ppp interface
PPP interface pos 0/1:1 is lowerDown
PPP interface pos 4/0:1 is lowerDown
PPP interface pos 12/1:1 is lowerDown
3 ppp interfaces found
PPP interface serial 0/0:1/1 is Up
PPP interface serial 0/0:1/2 is Down (administrative disable)
•
Example 4—Displays information about the PPP interface statistics for IPCP
host1#show ppp interface fastEthernet 2/0.1 statistics ip
PPP interface FastEthernet 2/0.1 is up
LCP protocol statistics
in-keepalive-requests
833
out-keepalive-requests
830
in-keepalive-replies
830
out-keepalive-replies
833
keepalive-failures
0
max-renegotiation-terminates
10
•
See show ppp interface.
show ppp interface summary
•
Use to display a summary of all the multilinked and nonmultilinked PPP interfaces
configured on the router.
•
Field descriptions
•
PPP Status—Nonmultilinked PPP interfaces
•
Configuration status—Indicates the configuration state of the PPP interface, IPCP,
IPv6CP , OSINLCP, or MPLS
•
294
configured—Interface or protocol is configured
Copyright © 2010, Juniper Networks, Inc.
Chapter 8: Configuring Point-to-Point Protocol
•
•
•
•
•
•
notConfigured—Interface or protocol is not configured
Administrative status—Indicates the administrative state of the PPP interface, IPCP,
IPv6CP , OSINLCP, or MPLS
•
open—Interface or protocol is administratively enabled
•
closed—Interface or protocol is administratively disabled
Operational status (Interface)—Indicates the operational state of the PPP interface
•
up—Interface is operational
•
down—Interface is not operational because of a problem in the PPP layer
•
lowerDown—Interface is not operational because a lower layer in the protocol
stack is down
•
notPresent—Interface is not operational because the hardware is unavailable
•
passive—Interface is waiting for the peer to send an LCP confReq message
•
tunnel—Interface is being redirected through a tunnel
Operational status (Ip, Ipv6, Osi. Mpls)—Indicates the operational state of the IPCP,
IPv6CP, OSINLCP, or MPLS protocol
•
up—Protocol is operational
•
down—Protocol is not operational because of a problem in the PPP layer
•
notPresent—Protocol is not operational because it does not exist
•
noResources—Protocol is not operational because it does not exist due to a lack
of resources
PPP Multilink Status—Multilinked PPP interfaces
Example
host1#show ppp interface summary
PPP Status
Configuration status
configured
Interface
4000
Ip
4000
Ipv6
0
Osi
0
Mpls
0
Administrative status
open
Interface
4000
Ip
4000
Ipv6
4000
Osi
4000
Mpls
4000
Operational status
up
Interface
4000
Ip
4000
Ipv6
0
Copyright © 2010, Juniper Networks, Inc.
notConfigured
n/a
0
4000
4000
4000
closed
0
0
0
0
0
down
notPresent
0
0
0
0
0
4000
noResources
n/a
0
0
295
JunosE 11.3.x Link Layer Configuration Guide
•
Osi
Mpls
Operational status
Interface
0
0
lowerDown
0
0
0
passive
0
4000
4000
tunnel
0
PPP Multilink Status
Configuration status
Link Interface
Network Interface
Ip
Ipv6
Osi
Mpls
Administrative status
Link Interface
Network Interface
Ip
Ipv6
Osi
Mpls
Operational status
Link Interface
Network Interface
Ip
Ipv6
Osi
Mpls
Operational status
Link Interface
Network Interface
configured
8000
2000
2000
0
0
0
open
8000
2000
2000
2000
2000
2000
up
8000
2000
2000
0
0
0
lowerDown
0
0
notConfigured
n/a
n/a
0
2000
2000
2000
closed
0
0
0
0
0
0
down
notPresent
0
0
0
0
0
0
0
2000
0
2000
0
2000
passive
tunnel
0
0
0
0
0
0
noResources
n/a
n/a
0
0
0
0
See show ppp interface summary.
show ppp peer-ip-address-optional
•
Use to display whether an IP address is required in a client request for an IPCP
negotiation
•
Field descriptions
•
•
Ppp peer-ip-address-optional—Indicates whether the peer IP address is optional in
the IPCP configuration request.
Example
host1#show ppp peer-ip-address-optional
Ppp peer ip address optional: enabled
•
See show ppp peer-ip-address-optional.
Troubleshooting
Use the pppPacket log to diagnose problems on your PPP interfaces. On dynamic PPP
interfaces, you can use the ppp log command within the profile, as described in
“Configuring Dynamic Interfaces” on page 511.
log severity debug pppPacket
296
Copyright © 2010, Juniper Networks, Inc.
Chapter 8: Configuring Point-to-Point Protocol
•
Use to configure a trace log file for a PPP interface.
•
Specify one of the following interface types and an interface specifier. For example,
specify slot/port:channel/subchannel for a serial POS PPP interface.
•
serial—Serial interface
•
atm—ATM interface
•
pos—Packet over SONET interface
•
You also configure logging to direct the output to a specific destination. For information,
see Overview of System Logging.
•
Example
host1(config-if)#log severity debug pppPacket serial 0/0:1/1
DEBUG 01/01/1970 00:16:58 pppPacket (1000001,*): interface:0/0:1/11/0:1,
time: 0.00, tx lcp confReq, id = 226, length = 19, mru = 32759,
authentication = chap MD5,magicNumber = 0x5387f9a2
DEBUG 01/01/1970 00:16:58 pppPacket (1000001,*): interface: 0/0:1/11/0:1,
time: 0.01, rx lcp confReq, id = 156, length = 18, mru = 32759,
magicNumber = 0x2d8eac91, pfc, acfc
DEBUG 01/01/1970 00:16:58 pppPacket (1000001,*): interface: 0/0:1/11/0:1,
time: 0.01, tx lcp confAck, id = 156, length = 18, mru = 32759,
magicNumber = 0x2d8eac91, pfc, acfc
•
Use the no version to return the severity changes to their default setting or to the
systemwide setting.
•
See log severity.
•
Use to enable PPP packet or state machine logging on any dynamic interface that uses
the profile being configured. Specify one of the following keywords:
ppp log
•
•
pppPacket—Enables PPP packet logging
•
pppStateMachine—Enables PPP state machine logging
Example
host1(config-profile)#ppp log pppPacket
NOTE: This command is equivalent to the log severity debug pppPacket
and log severity debug pppStateMachine commands.
•
Use the no version to disable packet or state machine logging.
•
See ppp log.
Copyright © 2010, Juniper Networks, Inc.
297
JunosE 11.3.x Link Layer Configuration Guide
298
Copyright © 2010, Juniper Networks, Inc.
CHAPTER 9
Configuring Multilink PPP
This chapter describes how to configure a Multilink Point-to-Point Protocol (PPP)
interface on E Series routers.
This chapter contains the following sections:
•
Overview on page 299
•
Platform Considerations on page 302
•
References on page 303
•
Supported MLPPP Features on page 304
•
Unsupported MLPPP Features on page 308
•
Before You Configure Static MLPPP on page 308
•
Configuring Static MLPPP on page 308
•
Configuring Dynamic MLPPP on page 319
•
Configuring MLPPP Fragmentation and Reassembly on page 320
•
Configuring Multiclass MLPPP on page 328
•
Monitoring MLPPP on page 329
Overview
Multilink PPP (MLPPP; also referred to as PPP Multilink, MLP, and MP) aggregates multiple
physical links into a single logical bundle. More specifically, MLPPP bundles multiple
link-layer channels into a single network-layer channel. Peers negotiate MLPPP during
the initial phase of Link Control Protocol (LCP) option negotiation. Each router indicates
that it is multilink capable by sending the multilink option as part of its initial LCP
configuration request.
An MLPPP bundle can consist of multiple physical links of the same type—such as multiple
asynchronous lines—or can consist of physical links of different types—such as leased
synchronous lines and dial-up asynchronous lines.
The router acts on MLPPP like another PPP Network Control Protocol (NCP). Packets
received with an MLPPP header are subject to fragmentation, reassembly, and sequencing.
Packets received without the MLPPP header cannot be sequenced and can be delivered
only on a first-come, first-served basis.
Copyright © 2010, Juniper Networks, Inc.
299
JunosE 11.3.x Link Layer Configuration Guide
Application
Some users need more bandwidth than a T1 or an E1 channel can provide, but cannot
afford the expense or do not need the bandwidth of T3 or E3. Equal-cost multipath
(ECMP) is one way to achieve the desired bandwidth. MLPPP is commonly used as an
alternative to ECMP to deliver NxT1 service. NxT1 service provides bandwidth greater
than DS1 service without going up to the expense and infrastructure required for DS3
service. Cost-analysis of NxT1 versus DS3 service typically imposes a practical limit of
8xT1 service; that is, aggregation of no more than eight T1 or E1 connections into an MLPPP
bundle.
The NxT1 implementation of MLPPP logically aggregates up to eight T1 or E1 connections
into a single virtual connection, or bundle, to a given customer site, as shown in Figure
35 on page 300.
Figure 35: MLPPP Aggregation of T1 Lines into a Single Bundle
Because MLPPP aggregates multiple link-layer channels onto a single network-layer IP
interface, protocol layering within the router is different than for non-multilink PPP.
Figure 36 on page 300 illustrates interface stacking with MLPPP.
Figure 36: Structure of MLPPP
MLPPP LCP Extensions
Multilink PPP adds the following LCP negotiation options:
•
300
Multilink maximum received reconstructed unit (MRRU) option—The MRRU option
has two functions. First, it informs the other end of the link the maximum size of the
PPP packet payload that the router can receive. Second, it informs the other end that
the router supports MLPPP. When you enable multilink on your router, the router
includes the MRRU option in LCP negotiation with the value set to the maximum
received unit (MRU) value for PPP. If the remote system rejects this option, the local
Copyright © 2010, Juniper Networks, Inc.
Chapter 9: Configuring Multilink PPP
system determines that the remote system does not support multilink PPP and it
terminates the link without negotiation.
NOTE: The router does not bring up a link if the MRU value received from
a peer device differs from the MRRU value received from the peer.
•
Short sequence number (SSN) header format option (not currently supported)—The
SSN option indicates that the transmitting router wants to use a short sequence number
(12 bits) in the MLPPP header rather than a long sequence number (24 bits). The router
currently supports only long sequence numbers.
•
Endpoint discriminator option—The endpoint discriminator option identifies the router
transmitting the packet. If the receiving router determines that packets on another link
have the same endpoint discriminator option, this link must be joined to that bundle.
If the receiving router determines that no packets on other links have the same option,
the receiving router must create a new bundle from this link.
The endpoint discriminator is generated internally; you cannot configure it. The endpoint
discriminator option is the same for all links on one end of the bundle; at the other end,
all links also share a common endpoint discriminator. The two endpoint discriminators
are different if the MLPPP bundle is set up between two E Series routers.
MLPPP Link Selection
By default, E Series routers use a round-robin algorithm to select the link on which to
transmit data on an MLPPP interface. The round-robin link selection method applies to
both best-effort packets, such as data, and non-best-effort (high-priority) packets, such
as voice and video. Best-effort packets are encapsulated with an MLPPP header that
contains a sequence number, whereas non-best-effort packets are encapsulated with
a PPP header that does not contain a sequence number.
The member links in an MLPPP bundle can experience different queuing delays due to
the volume of traffic transmitted on the MLPPP interface. These delays can cause packets
to arrive out of order at the remote router. The effect of such delays differs for best-effort
packets and non-best effort packets, as follows:
•
For best-effort packets that arrive out of order from the E Series router, the remote
router can use the sequence number to reorder and forward the packets in the correct
order, regardless of the order in which the packets were received.
•
For non-best-effort packets that arrive out of order from the E Series router, the lack
of a sequence number prevents the remote router from being able to determine the
correct order in which to forward the packets. This can cause problems with applications
that require high-priority voice and video traffic transmitted on MLPPP interfaces to
be received in the same order transmitted by the peer applications.
To ensure that the E Series router maintains the proper packet order when transmitting
non-best-effort traffic, you can use the ppp hash-link-selection command to enable
use of a hash-based algorithm to select the link on which the router transmits high-priority
packets on an MLPPP interface.
Copyright © 2010, Juniper Networks, Inc.
301
JunosE 11.3.x Link Layer Configuration Guide
When you use hash-based link selection instead of the default round-robin link selection
for non-best-effort traffic, the router uses the IP source address (SA) and IP destination
address (DA) of the packet as a hash to select the MLPPP member link on which to
transmit the packet. Specifically, the router uses the hash algorithm to bind the
transmission of all traffic between this IP SA and IP DA to the same member link in the
MLPPP bundle.
If the member link selected to transmit high-priority packets becomes inoperable or is
removed from the MLPPP bundle, the router must select a different link on which to
transmit the packets. As a result, packets transmitted on this new link might sometimes
arrive at the remote destination before the traffic sent on the previously selected member
link.
You can configure hash-based MLPPP link selection in any of the following ways:
•
To configure hash-based link selection for a individual MLPPP member link, issue the
ppp hash-link-selection command from Interface Configuration mode or Subinterface
Configuration mode in the context of the individual link interface. For more information,
see “Configuring Static MLPPP” on page 308.
•
To configure hash-based link selection for all current member links in an MLPPP bundle,
issue the ppp hash-link-selection command from Interface Configuration mode in the
context of the MLPPP bundle. Doing this has the same effect as issuing the ppp
hash-link-selection command separately for each member link in the bundle. For more
information, see “Contextual Command Differences” on page 310.
•
To configure hash-based link selection for all dynamic MLPPP link interfaces created
by a profile, issue the ppp hash-link-selection command from Profile Configuration
mode. For more information, see “Configuring Dynamic MLPPP” on page 319.
For a detailed description and examples of using the ppp hash-link-selection command,
see “ppp hash-link-selection” on page 313.
Platform Considerations
You can configure MLPPP interfaces on the following E Series Broadband Services
Routers:
302
•
E120 router
•
E320 router
•
ERX1440 router
•
ERX1410 router
•
ERX710 router
•
ERX705 router
•
ERX310 router
Copyright © 2010, Juniper Networks, Inc.
Chapter 9: Configuring Multilink PPP
Module Requirements
For information about the modules that support MLPPP interfaces on ERX14xx models,
ERX7xx models, and the ERX310 router:
•
See ERX Module Guide, Table 1, Module Combinations for detailed module specifications.
•
See ERX Module Guide, Appendix A, Module Protocol Support for information about the
modules that support MLPPP.
For information about the modules that support MLPPP interfaces on the E120 and E320
routers:
•
See E120 and E320 Module Guide, Table 1, Modules and IOAs for detailed module
specifications.
•
See E120 and E320 Module Guide, Appendix A, IOA Protocol Support for information
about the modules that support MLPPP.
Interface Specifiers
Some of the configuration task examples in this chapter use the slot/port format to
specify the physical interface on which you want to configure MLPPP. However, the
interface specifier format that you use depends on the type of physical interface on which
you want to configure MLPPP and on the router that you are using.
For ERX7xx models, ERX14xx models, and ERX310 router, use the slot/port format. For
example, the following command specifies an ATM interface on slot 5, port 1 of an ERX7xx
model, ERX14xx model, or ERX310 router.
host1(config)#interface atm 5/1
For E120 and E320 routers, use the slot/adapter/port format, which includes an identifier
for the bay in which the I/O adapter (IOA) resides. In the software, adapter 0 identifies
the right IOA bay (E120 router) and the upper IOA bay (E320 router); adapter 1 identifies
the left IOA bay (E120 router) and the lower IOA bay (E320 router). For example, the
following command specifies a tunnel-server port on slot 3, adapter 0, port 0 of an E320
router.
host1(config)#tunnel-server 3/0/0
For more information about supported interface types and specifiers on E Series routers,
see Interface Types and Specifiers in JunosE Command Reference Guide.
References
For more information about the MLPPP protocol and MLPPP fragmentation and
reassembly, consult the following resources:
•
RFC 1661—The Point-to-Point Protocol (PPP) (July 1994)
•
RFC 1990—The PPP Multilink Protocol (MP) (August 1996)
•
RFC 2233—The Interfaces Group MIB using SMIv2 (November 1997)
Copyright © 2010, Juniper Networks, Inc.
303
JunosE 11.3.x Link Layer Configuration Guide
Supported MLPPP Features
The router currently supports both the static configuration of the links participating in a
multilink bundle and the dynamic creation of MLPPP bundles over L2TP (only on the
LNS) when the LNS detects multilink LCP option negotiation in LCP proxy data.
The following MLPPP features are available for both static and dynamic MLPPP:
•
Logical aggregation of up to eight links in a bundle
•
Long sequence numbers
•
Authentication for interfaces with MLPPP encapsulation or for MLPPP bundles
•
Monotonically increasing sequence numbers
All packets distributed across the member links have monotonically increasing sequence
numbers. This feature enables the remote system on the customer premises to perform
resequencing (if the system is configured to do so).
•
Round-robin packet distribution or hash-based packet distribution
By default, E Series routers use a round-robin algorithm to handle packet distribution
across the member links in a bundle for both best-effort traffic and non-best-effort
traffic. The round-robin approach is used even when the member links have different
line rates.
As an alternative to round-robin packet distribution for non-best-effort traffic, you can
enable use of a hash-based algorithm for distribution of non-best-effort (high-priority)
packets, such as voice or video. Using a hash-based packet distribution mechanism
instead of the default round-robin packet distribution mechanism for non-best-effort
traffic ensures that the router maintains the proper packet order when transmitting
high-priority packets. For details, see “MLPPP Link Selection” on page 301.
•
Forwarding of multilink traffic to L2TP tunnels
E Series routers support dynamic MLPPP over L2TP configurations (on the L2TP network
server, or LNS).
•
Fragmentation and reassembly
For details, see “Configuring MLPPP Fragmentation and Reassembly” on page 320.
•
Packet resequencing for best-effort traffic, for non-best-effort traffic, and when MLPPP
reassembly is enabled
For details on how the router supports packet resequencing for best-effort traffic and
non-best-effort traffic, see “MLPPP Link Selection” on page 301.
For details on enabling MLPPP reassembly, see “Configuring MLPPP Fragmentation
and Reassembly” on page 320.
•
Multiclass MLPPP
For information about multiclass MLPPP, see “Configuring Multiclass Multilink PPP”
on page 345.
304
Copyright © 2010, Juniper Networks, Inc.
Chapter 9: Configuring Multilink PPP
You can configure bundles as follows:
•
On a COCX-F3 line module and its corresponding I/O modules, you can configure:
•
Up to 8 member links from different ports in the same bundle, with the following
restriction for MLPPP reassembly:
•
For a COCX-F3 line module with either a 12-port E3-12 FRAME I/O module or a
12-port CT3/T3 12 I/O module, the restriction is based on the ports on which
member links in the same bundle are configured.
A 12-port E3-12 FRAME I/O module and a 12-port CT3/T3 12 I/O module each
contain 12 ports numbered 0 through 11. When MLPPP reassembly is enabled, you
can configure a bundle with member links on the same port; on ports 0, 1, and 2;
on ports 3, 4, and 5; on ports 6, 7, and 8; or on ports 9, 10, and 11. However, the
router cannot properly reassemble fragments if you configure a bundle with member
links that span ports in different bundles; for example, on ports 0, 1, and 4.
When MLPPP reassembly is disabled, this restriction is not in effect; that is, member
links can span ports in different bundles.
•
•
Up to 12 bundles
On a cOCx/STMx line module and its corresponding I/O module, you can configure:
•
Member links from different OC3/STM1 ports in the same bundle, with the following
restrictions for MLPPP reassembly:
•
For a cOCx/STMx line module with a 4-port cOC3/STM1 I/O module, the restriction
is based on the ports on which member links in the same bundle are configured.
A 4-port cOC3/STM1 I/O module contains four ports numbered 0 through 3. When
MLPPP reassembly is enabled, you can configure a bundle with member links on
the same port, on ports 0 and 1, or on ports 2 and 3. However, the router cannot
properly reassemble fragments if you configure a bundle with member links that
span ports in different bundles; for example, on ports 1 and 2.
When MLPPP reassembly is disabled, this restriction is not in effect; that is, member
links can span ports in different bundles.
•
For a cOCx/STMx line module with a 1-port cOC12/STM4 I/O module, the restriction
is based on the STM1 (OC3) paths on which member links in the same bundle are
configured.
A 1-port cOC12/STM4 I/O module has four logical paths numbered 1 through 4.
When MLPPP reassembly is enabled, you can configure a bundle with member
links on the same path, on paths 1 and 2, or on paths 3 and 4. However, the router
cannot properly reassemble fragments if you configure a bundle with member
links that span paths in different bundles; that is, on paths 2 and 3.
When MLPPP reassembly is disabled, this restriction is not in effect; for example,
member links can span paths in different bundles.
•
Any combination of bundles that does not exceed the 336 available T1 channels (for
example, 336 single-link T1 bundles, 42 eight-link bundles, or 41 eight-link bundles
and 8 single-link bundles)
Copyright © 2010, Juniper Networks, Inc.
305
JunosE 11.3.x Link Layer Configuration Guide
•
•
•
•
•
•
•
On a CT3/T3-F0 line module with a CT3/T3 12 I/O module, you can configure:
•
Member links from different T3 ports in the same bundle
•
Any combination of bundles that does not exceed the 336 available T1 channels (for
example, 336 single-link T1 bundles, 42 eight-link bundles, or 41 eight-link bundles
and 8 single-link bundles)
On an ES2-S1 Service IOA, you can configure:
•
Up to 16,000 member links per line module, not to exceed a total of 12,000 MLPPP
bundles per chassis
•
Any combination of bundles that does not exceed either of these maximums (for
example, 4000 single-link bundles, 4000 two-link bundles, 4000 four-link bundles,
and 2000 eight-link bundles)
On an OCx/STMx ATM line module and its corresponding line modules, you can
configure:
•
Up to 8000 member links per line module, not to exceed a total of 8000 MLPPP
bundles per chassis
•
Any combination of bundles that does not exceed either of these maximums (for
example, 4000 single-link bundles, 4000 two-link bundles, 2000 four-link bundles,
and 1000 eight-link bundles)
On a Service line module (SM), you can configure:
•
Up to 16,000 member links per line module, not to exceed a total of 12,000 MLPPP
bundles per chassis
•
Any combination of bundles that does not exceed either of these maximums (for
example, 4000 single-link bundles, 4000 two-link bundles, 4000 four-link bundles,
and 2000 eight-link bundles)
On a shared tunnel-server port configured on a GE-2 or GE-HDE line module and
corresponding line modules, you can configure:
•
Up to 8000 member links per line module, not to exceed a total of 8000 MLPPP
bundles per chassis
•
Any combination of bundles that does not exceed either of these maximums (for
example, 4000 single-link bundles, 4000 two-link bundles, 2000 four-link bundles,
and 1000 eight-link bundles)
On an ES2-S1 GE-4 IOA, ES2-S1 GE-8 IOA, ES2-S1 OC3-8 STM1 ATM IOA, and ES2-S1
OC12-2 STM4 ATM IOA modules that pair with an ES2 4G LM on E120 and E320 routers,
you can configure:
•
306
Any combination of bundles that does not exceed the 252 available E1 channels (for
example, 252 single-link T1 bundles, 34 eight-link bundles, or 33 eight-link bundles
and 8 single-link bundles)
MLPPP bundles with one or more links per bundle for dynamic
MLPPP-over-PPPoE-over-Ethernet configurations.
Copyright © 2010, Juniper Networks, Inc.
Chapter 9: Configuring Multilink PPP
•
•
MLPPP bundles with only one link per bundle when configuring static
MLPPP-over-PPPoE-over-Ethernet. When you create multilink bundles in a static
MLPPP-over-PPPoE-over-Ethernet configuration, PPPoE is unable to direct the
PPPoE Active Discovery Initiation (PADI) packets received from the MLPPP bundle
links on the client to the appropriate (matching) links in the MLPPP bundle on the
server. As a result, the connections between bundle links become crossed, and the
bundle does not come up as expected. Creating MLPPP bundles with only a single
link for this configuration ensures a one-to-one correspondence between a PPPoE
subscriber and its associated link, and guarantees that the MLPPP bundle comes
up properly.
•
MLPPP bundles with only a single link per bundle are not required for static
MLPPP-over-PPPoE-over-Ethernet with VLAN configurations if all of the links in a
bundle have the same VLAN ID that is unique across all MLPPP bundles configured
on the line module.
On all E Series ATM module combinations that support MLPPP, you can configure:
•
MLPPP bundles with one or more links per bundle for dynamic MLPPP-over-multiple
PPPoE subinterfaces-over-one PPPoE major interface-over-ATM 1483 subinterface
configurations.
•
MLPPP bundles with only one link per bundle when configuring static
MLPPP-over-multiple PPPoE subinterfaces-over-one PPPoE major interface-over-an
ATM 1483 subinterface. In this configuration, you can stack multiple PPPoE
subinterfaces over a single PPPoE major interface.
•
Typically when you create ATM PVCs on an ATM module, there is a one-to-one
correspondence between a PPPoE subscriber and the ATM PVC with which the
subscriber is associated. However, in configurations with multiple PPPoE
subinterfaces stacked over a single PPPoE major interface, crossed MLPPP bundle
link connections can occur, as is the case with the ES2-S1 GE-4 IOA, and the bundle
does not come up as expected. Creating MLPPP bundles with only a single link for
this configuration ensures a one-to-one correspondence between a PPPoE subscriber
and its associated link, and guarantees that the MLPPP bundle comes up properly.
•
MLPPP bundles with only a single link per bundle are not required for static
MLPPP-over-multiple PPPoE subinterfaces-over-one PPPoE major
interface-over-ATM 1483 subinterface configurations if all PPPoE subinterfaces
stacked over the same PPPoE major interface belong to the same bundle.
NOTE: For information about the modules that support MLPPP on
ERX14xx models, ERX7xx models, and the ERX310 router, see ERX Module
Guide, Appendix A, Module Protocol Support. For information about the
modules that support MLPPP on the E120 and E320 routers, see E120
and E320 Module Guide, Appendix A, IOA Protocol Support.
Copyright © 2010, Juniper Networks, Inc.
307
JunosE 11.3.x Link Layer Configuration Guide
Unsupported MLPPP Features
The router does not support the following MLPPP features:
•
Short sequence numbers
•
Resequencing out-of-order packets in the absence of fragmentation
Given the location in the network where the router resides, the NxT1 links to a customer
site represent one of many places across the IP network where packets might be
received out of order. For example, if the router has multiple uplinks to a core router,
packets might be received out of order across these links.
You can lose packets if you transmit layer 2 traffic on an MPLS LSP that passes over
an MLPPP link bundle.
Packets are passed along to the next protocol layer in the order that they are processed.
Packet resequencing is therefore performed at the end station rather than the
aggregation router. IP datagrams can be resequenced by the end station using the IP
identification field.
Layer 2 packets such as Ethernet/MPLS and ATM-AAL5/MPLS have no sequence
number information and are sent in the order received. The packets are dropped if their
out-of-order condition is detected by a downstream device.
Frame Relay/MPLS packets do have a native sequence number in the header and are
rejected at the end of the LSP if the MLPPP sequence number order is violated.
To ensure that the router maintains the proper packet order when transmitting
high-priority (non-best-effort) packets such as voice and video, you can use the ppp
hash-link-selection command to enable use of a hash-based algorithm to select the
link on which the router transmits high-priority packets on an MLPPP interface. For
details, see “MLPPP Link Selection” on page 301.
Before You Configure Static MLPPP
Before you begin configuring static MLPPP, you must configure the physical line interfaces
to be aggregated by MLPPP. See the following chapters:
•
Configuring Channelized T3 Interfaces in JunosE Physical Layer Configuration Guide
•
Configuring T3 and E3 Interfaces in JunosE Physical Layer Configuration Guide
•
Configuring Channelized OCx/STMx Interfaces in JunosE Physical Layer Configuration
Guide
The procedures described in “Configuring Static MLPPP” on page 308 assume that a
physical line interface has been configured.
Configuring Static MLPPP
Static MLPPP configuration consists of two general tasks, each with several subtasks.
308
Copyright © 2010, Juniper Networks, Inc.
Chapter 9: Configuring Multilink PPP
To configure static MLPPP:
1.
Create the member links to be aggregated into a multilink bundle.
a. From Global Configuration mode, specify the individual interface on which you
want to configure MLPPP.
host1(config)#interface serial 2/0:1/1
b. Specify MLPPP as the encapsulation method on the interface.
host1(config-if)#encapsulation mlppp
c. (Optional) Specify the keepalive timeout value for the member link interface.
host1(config-if)#ppp keepalive 50
d. (Optional) Specify the authentication method for the member link interface.
host1(config-if)#ppp authentication pap chap
e. (Optional) Enable hash-based link selection instead of the default round-robin
link selection for the member link interface.
host1(config-if)#ppp hash-link-selection
2. Add member links to a multilink bundle.
a. Define the MLPPP bundle.
host1(config)#interface mlppp group1
b. Add each member link.
host1(config-if)#member-interface serial 2/0:1/1
c. Assign an IP address to the MLPPP bundle.
host1(config-if)#ip address 10.10.100.1 255.255.255.0
d. (Optional) Specify the keepalive timeout value for the MLPPP network interface
(the entire MLPPP bundle).
host1(config-if)#ppp keepalive 50
e. (Optional) Specify the authentication method for the MLPPP network interface
(the entire MLPPP bundle).
host1(config-if)#ppp authentication pap chap
f. (Optional) Enable hash-based link selection instead of the default round-robin
link selection for the MLPPP network interface (the entire MLPPP bundle).
host1(config-if)#ppp hash-link-selection
Configuration Example
The following commands configure three T1 lines and aggregate them into a multilink
bundle named group1.
host1(config)#interface serial 2/0:1/1
Copyright © 2010, Juniper Networks, Inc.
309
JunosE 11.3.x Link Layer Configuration Guide
host1(config-if)#encapsulation mlppp
host1(config-if)#exit
host1(config)#interface serial 2/0:2/1
host1(config-if)#encapsulation mlppp
host1(config-if)#exit
host1(config)#interface serial 2/0:3/1
host1(config-if)#encapsulation mlppp
host1(config-if)#ppp keepalive 50
host1(config-if)#exit
host1(config)#interface mlppp group1
host1(config-if)#member-interface serial 2/0:1/1
host1(config-if)#member-interface serial 2/0:2/1
host1(config-if)#member-interface serial 2/0:3/1
host1(config-if)#ppp authentication pap chap
host1(config-if)#ppp hash-link-selection
host1(config-if)#ip address 10.10.100.1 255.255.255.0
Contextual Command Differences
The MLPPP configuration commands have different effects depending on the interface
context. If you issue an MLPPP configuration command in the context of an individual
interface, the command affects only the MLPPP link interface associated with that
individual interface.
For example, the following commands disable negotiation of the local magic number
only for serial interface 2/0:1/1.
host1(config-if)#member-interface serial 2/0:1/1
host1(config-if)#encapsulation mlppp
host1(config-if)#ppp magic-number disable
If you issue an MLPPP configuration command in the context of an MLPPP bundle—the
MLPPP network interface—the command affects all the member links of the bundle.
This feature prevents you from having to issue MLPPP configuration commands for each
member link interface.
For example, the following commands disable negotiation of the local magic number
for the entire bundle, group1.
host1(config)#interface mlppp group1
host1(config-if)#member-interface serial 2/0:1/1
host1(config-if)#ip address 10.10.100.1 255.255.255.0
host1(config-if)#ppp magic-number disable
Any member links added to the bundle after issuing an MLPPP configuration command
are not affected by the command. For example, if you add serial interface 2/0:4/1 to the
group1 bundle after you issue the ppp magic-number disable command, negotiation of
the local magic number for this link and any member links subsequently added to the
bundle is not disabled.
Configuring Authentication
Perform the following optional tasks to configure authentication on interfaces with
MLPPP encapsulation or MLPPP bundles.
•
310
Specify one or more PPP authentication types.
Copyright © 2010, Juniper Networks, Inc.
Chapter 9: Configuring Multilink PPP
•
Modify the length of the CHAP challenge.
•
Specify the maximum number of retries.
NOTE: The JunosE Software’s PPP application accepts null usernames
during PAP and CHAP authentication. When the PPP application receives
an authentication request that includes a null username, PPP passes the
request to AAA. To take advantage of this feature, configure your
authentication server to support the use of null usernames.
ppp authentication
•
Use to require authentication from the PPP peer.
•
To specify the name of a virtual router (VR) to be used as the authentication VR context,
use the virtual-router keyword. Keep the following points in mind when you use the
ppp authentication virtual-router command:
•
When you specify a VR in the ppp authentication command, AAA does not query
the domain map for the assigned VR context. Instead, AAA uses the VR specified in
the ppp authentication command as the authentication VR context and issues the
authentication request to the authentication server in the assigned VR context.
•
If you specify the default VR as the authentication VR context, AAA loosely binds
the user to the default VR. This means that RADIUS can override the default VR
context with a new VR context during the authentication process. When the ppp
authentication virtual-router command specifies the default VR, AAA returns either
the default VR or the VR specified by RADIUS.
•
If you specify a VR other than the default VR as the authentication VR, AAA tightly
binds the user to the specified VR. This means that RADIUS cannot override the
specified VR context with a new VR context during the authentication process. When
the ppp authentication virtual-router command specifies a nondefault VR, AAA
returns the specified VR.
•
The router supports the MD5 authentication algorithm for CHAP authentication.
•
Example 1—Specify PAP or CHAP as the primary authentication protocol, and the other
authentication protocol as the alternative. For example, the following command
specifies pap as the primary authentication protocol and chap as the alternate.
host1(config-if)#ppp authentication pap chap
The router requests the use of PAP as the authentication protocol (because it appears
first in the command line). If the peer refuses to use PAP, the router requests the CHAP
protocol. If the peer refuses to negotiate authentication, the router terminates the PPP
session.
•
Example 2—Specify a virtual router for the authentication virtual router context. This
command is available in static configurations and in profiles.
host1(config-if)#ppp authentication virtual-router boston pap chap
Copyright © 2010, Juniper Networks, Inc.
311
JunosE 11.3.x Link Layer Configuration Guide
•
Use the no version to specify that the router does not require authentication.
•
See ppp authentication.
ppp chap-challenge-length
•
Use to modify the length of the CHAP challenge by specifying the allowable minimum
length and maximum length.
CAUTION: Do not use the ppp chap-challenge-length command; increasing
the minimum length (from the default 16 bytes) or decreasing the maximum
length (from the default 32 bytes) reduces the security of your router.
•
Specify the minimum and maximum lengths in bytes in the range 8–63.
•
The maximum length must be greater than or equal to the minimum length.
•
Example
host1(config-if)#ppp chap-challenge-length 24 28
•
Use the no version to restore the default minimum (16 bytes) and default maximum
(32 bytes).
•
See ppp chap-challenge-length.
•
Use to specify the maximum number of authentication retries the router allows before
terminating a PPP session
•
This value applies to PAP and CHAP authentication.
•
The range is 0–7. The default is 0, which indicates that no retries are allowed.
•
Example
ppp max-bad-auth
host1(config-if)#ppp max-bad-auth 3
•
Use the no version to return the number of retries to the default, 0.
•
See ppp max-bad-auth.
Configuring Other PPP Attributes
The available ppp command options are the same for interfaces whether they are
configured with PPP or MLPPP.
encapsulation mlppp
312
•
Use to configure MLPPP as the encapsulation method on an individual interface.
•
Use this command only within the context of an individual interface. Issuing this
command creates an MLPPP link interface, also referred to as an MLPPP bundle
member.
Copyright © 2010, Juniper Networks, Inc.
Chapter 9: Configuring Multilink PPP
•
Example
host1(config)#interface serial 2/0:1/1
host1(config-if)#encapsulation mlppp
•
Use the no version to disable MLPPP on an interface.
•
See encapsulation mlppp.
•
Use to create an MLPPP network interface, also known as the MLPPP bundle.
•
Example
interface mlppp
host1(config-if)#interface mlppp group2
•
Use the no version to delete the MLPPP bundle. You must first delete the IP interface,
followed by deleting the bundle members (link interfaces); then you can delete the
MLPPP bundle.
NOTE: RADIUS supports the inclusion of the MLPPP Bundle Name VSA
[26-62] in Access-Request, Acct-Start, Acct-Stop, and Interim-Acct
messages. For more information, see JunosE Broadband Access
Configuration Guide.
•
See interface mlppp.
•
Use to add an MLPPP link interface—also known as an MLPPP bundle member—to an
MLPPP bundle.
•
Example
member-interface
host1(config-if)#member-interface serial 2/0:1/1
•
Use the no version to remove the specified interface from the MLPPP bundle.
•
See member interface.
•
Use to enable use of a hash-based algorithm to select the link on which the router
transmits non-best-effort (high-priority) packets, such as voice or video, on an MLPPP
interface.
•
Hash-based MLPPP link selection is available only for non-best-effort traffic. For
best-effort traffic, the router uses a round-robin algorithm for link selection.
•
Using hash-based link selection instead of the default round-robin link selection for
non-best-effort traffic ensures that the router maintains the proper packet order when
transmitting high-priority packets.
ppp hash-link-selection
Copyright © 2010, Juniper Networks, Inc.
313
JunosE 11.3.x Link Layer Configuration Guide
•
When you configure hash-based link selection, the router uses the IP source address
and IP destination address of the packet as a hash to select the MLPPP member link
on which to transmit the packet.
•
You can configure hash-based MLPPP link selection in any of the following ways:
•
•
To configure hash-based link selection for an individual MLPPP member link interface,
issue the ppp hash-link-selection command from Interface Configuration mode or
Subinterface Configuration mode in the context of the link interface. (See Example
1.)
•
To configure hash-based link selection for all current member links in an MLPPP
bundle, issue the ppp hash-link-selection command from Interface Configuration
mode in the context of the MLPPP bundle. (See Example 2.)
•
To configure hash-based link selection for all dynamic MLPPP link interfaces created
by a profile, issue the ppp hash-link-selection command from Profile Configuration
mode. (See Example 3.)
Example 1—The following commands configure hash-based MLPPP link selection for
an individual MLPPP member link interface.
host1(config)#interface atm 2/0
host1(config-if)#interface atm 2/0.2
host1(config-subif)#atm pvc 42 0 42 aal5snap
host1(config-subif)#encapsulation mlppp
host1(config-subif)#ppp hash-link-selection
•
Example 2—The following commands configure hash-based MLPPP link selection for
all current member links in the MLPPP bundle (group1). Doing this has the same effect
as issuing the ppp hash-link-selection command separately for each member link in
the bundle.
host1(config)#interface mlppp group1
host1(config-if)#ppp hash-link-selection
•
Example 3—The following commands configure hash-based MLPPP link selection for
all dynamic MLPPP interfaces created by the profile named dynamicMlppp.
host1(config)#profile dynamicMlppp
host1(config-profile)#ppp multilink enable
host1(config-profile)#ppp hash-link-selection
•
Use the no version to restore the default round-robin algorithm for MLPPP link selection.
•
See ppp hash-link-selection.
•
Use to terminate invalid IPv4 subscribers and prevent additional IPCP negotiations.
•
When Internet Protocol version 6 Control Protocol (IPv6CP) is active, this command
enables unused IPv4 addresses, which are allocated for the IPv6 subscribers, to be
available for the IPCP services for an internally defined time interval (10 seconds).
When the time interval elapses, the subscriber must connect again to negotiate IPCP.
ppp ipcp lockout
For more information about how the IPv4 addresses are restored, see Chapter 7,
Configuring Point-to-Point Protocol.
314
Copyright © 2010, Juniper Networks, Inc.
Chapter 9: Configuring Multilink PPP
•
Example
host1(config-subif)#ppp ipcp lockout
•
Use the no version to disable the IPCP lockout option on the interface.
•
See ppp ipcp lockout.
•
Use to specify the keepalive timeout value in the range 10–64800 seconds. If issued
in the context of an individual interface, the command affects only that interface. If
issued in the context of an MLPPP bundle, the command affects all MLPPP link
interfaces that are member links of that bundle.
•
When the keepalive timer expires, the interface always sends an LCP echo request,
regardless of whether the peer is silent.
•
When the keepalive interval is 30 seconds (the default), a failed link is detected between
90 and 120 seconds after failure.
•
Use ppp keepalive without a value to restore the default, 30 seconds.
•
Example
ppp keepalive
host1(config-if)#ppp keepalive 50
•
Use the no version to disable keepalive.
•
See ppp keepalive.
•
Use to enable PPP packet or state machine logging on any dynamic interface that uses
the profile being configured. Specify one of the following keywords:
ppp log
•
•
pppPacket—Enables PPP packet logging
•
pppStateMachine—Enables PPP state machine logging
Example
host1(config-profile)#ppp log pppPacket
NOTE: This command is equivalent to the log severity debug pppPacket
and log severity debug pppStateMachine commands.
•
Use the no version to disable packet or state machine logging.
•
See ppp log.
ppp magic-number disable
Copyright © 2010, Juniper Networks, Inc.
315
JunosE 11.3.x Link Layer Configuration Guide
•
Use to disable negotiation of the local magic number. If issued in the context of an
individual interface, the command affects only that interface. If issued in the context
of an MLPPP bundle, the command affects all MLPPP link interfaces that are member
links of that bundle.
•
Issuing this command prevents the router from detecting loopback configurations.
•
Example
host1(config-if)#ppp magic-number disable
•
Use the no version to restore negotiation of the local magic number.
•
See ppp magic-number disable.
ppp magic-number ignore-mismatch
•
Use to cause the router to ignore a mismatch of the LCP peer magic number and retain
the PPP connection when the peer has not negotiated an LCP magic number.
•
For more information about using this command, see “Validation of LCP Peer Magic
Number” on page 261 in “Configuring Point-to-Point Protocol” on page 259.
•
To verify configuration of LCP peer magic number validation on the router, use the
show ppp interface mlppp command. For information, see “show ppp interface mlppp”
on page 332.
•
Example
host1(config-if)#ppp magic-number ignore-mismatch
•
Use the no version to restore the default behavior, in which the router terminates the
PPP connection if it detects an LCP peer magic number mismatch.
•
See ppp magic-number ignore-mismatch.
•
Use to configure the maximum number of LCP, IPCP, or IPv6CP renegotiation attempts,
in the range 1–65535, that the router accepts before terminating a PPP session.
•
Configuring the maximum number of renegotiation attempts helps avoid massive
renegotiation loops that can occur between the router and a noncompliant PPP client.
Such renegotiation loops can cause excessive CPU utilization and can prevent the PPP
client from coming up properly.
•
When a PPP client exceeds the configured maximum number of renegotation attempts,
the router sends a termination request to end the PPP session. When the PPP session
is terminated and LCP goes into a stopped (closed) state, static PPP or MLPPP
interfaces go into passive mode and wait for the other side of the connection to start
the LCP negotiation process.
•
If you do not specify the optional lcp, ipcp, or ipv6cp keyword, the ppp
max-negotiations command sets the maximum number of renegotiation attempts
for each of LCP, IPCP, and IPv6CP to the value you specify, or to the default value (30)
if you omit the optional value for maximum renegotiation attempts.
ppp max-negotiations
316
Copyright © 2010, Juniper Networks, Inc.
Chapter 9: Configuring Multilink PPP
•
When both IPv4 interface columns and IPv6 interface columns are configured over a
PPP link-layer interface, the router terminates the PPP session only when the PPP
client exceeds the configured maximum number of renegotiation attempts for both
the IPv4 interface and the IPv6 interface.
•
Example 1—Sets the maximum number of LCP renegotiation attempts to 5
host1(config-if)#ppp max-negotiations lcp 5
•
Example 2—Sets the maximum number of IPCP renegotiation attempts to 30 (the
default)
host1(config-if)#ppp max-negotiations ipcp
•
Example 3—Sets the maximum number of LCP, IPCP, and IPv6CP renegotiation
attempts to 15
host1(config-if)#ppp max-negotiations 15
•
Example 4—Restores the maximum number of LCP, IPCP, and IPv6CP renegotiation
attempts to the default value, 30
host1(config-if)#no ppp max-negotiations
•
Use the no version to restore the default value, 30 renegotiation attempts.
•
See ppp max-negotiations.
•
Use to control the negotiation of the maximum receive unit (MRU).
•
Specify the number of bytes, in the range 64–65535.
•
We recommend you coordinate this value with the network administrator on the other
end of the line.
•
If the value configured for the PPP MRU is greater than the value of the lower-layer
MRU minus the PPP header length, the router logs a warning message and uses the
lesser of the configured MRU value or the lower-layer MRU value minus the PPP header
length to negotiate the local MRU.
•
If the value configured for the PPP MRU conflicts with a similar value configured for
another protocol, such as the MTU value for PPPoE, the router uses the lesser of the
two values.
•
If you issue the command in the context of an encapsulated MLPPP interface, it affects
only that interface. If you issue the command in the context of an MLPPP bundle, it
affects all member links within that bundle.
•
Example
ppp mru
host1(config-if)#ppp mru 576
•
Use the no version to restore the default value, which causes PPP to use the lower-layer
MRU minus the PPP header length as the MRU value.
•
See ppp mru.
ppp passive-mode
Copyright © 2010, Juniper Networks, Inc.
317
JunosE 11.3.x Link Layer Configuration Guide
•
Use to force a static or dynamic PPP interface into passive mode, for a period of one
second, before LCP negotiation begins. This delay enables slow clients to start up and
initiate the LCP negotiation.
•
Example
host1(config-if)#ppp passive-mode
•
Use the no version to disable passive mode.
•
See ppp passive-mode.
•
Use to resolve conflicts when the system and the PPP peer system have primary and
secondary DNS and WINS addresses configured with different values.
•
By default, the DNS and WINS addresses configured on the system take precedence.
•
Use the ppp peer dns or the ppp peer wins commands to configure the PPP peer
system as the one that takes precedence. This command has no effect unless both
systems have the address configured and the address is in conflict. If the PPP peer
system has the address and the system does not, the peer always supplies the address
regardless of how you have configured the PPP peer.
•
Example
ppp peer
host1(config-profile)#ppp peer dns
•
Use the no ppp peer dns or the no ppp peer wins commands when you want the
system to take precedence during setup negotiations between the system and the
remote PC client. If the IP addresses passed to the system by the remote PC client
differ from the ones you have configured on your system, the system returns the values
that you configured as the correct values to the remote PC client.
•
See ppp peer.
•
Use to terminate an MLPPP session.
•
If you use the ip or osi keyword, disables the Internet Protocol Control Protocol (IPCP)
or OSI Network Layer Control Protocol (OSINLCP) service for the MLPPP network
interface (MLPPP bundle). Issue only in the context of a network interface.
•
If no keywords are issued, issuing this command has the following effect:
ppp shutdown
•
If issued in the context of an individual interface, the command affects only that
interface. The ip and osi keywords are not functional in this context.
•
If issued in the context of an MLPPP bundle, the command affects all MLPPP link
interfaces that are member links of that bundle. The ip and osi keywords are
functional only in this context.
•
The ppp shutdown command administratively disables the interface.
•
Example
host1(config-if)#ppp shutdown
318
Copyright © 2010, Juniper Networks, Inc.
Chapter 9: Configuring Multilink PPP
•
If you issue the ppp shutdown command in the context of an MLPPP bundle, you
cannot bring up an individual member link by subsequently issuing the no ppp
shutdown command in the context of that member. You can bring up only the entire
bundle; to do so, you must issue the no ppp shutdown command in the context of the
bundle. If you add new member links while a bundle is shut down, those new members
are also in the shut-down state until the entire bundle is brought up.
•
Use the no version to restart a disabled session.
•
See ppp shutdown.
Configuring Dynamic MLPPP
You can define a profile to dynamically create MLPPP bundles over L2TP on the LNS.
The profile consists of commands to define the bundle attributes, just as you would for
static configuration. For more information about profiles for dynamic interfaces, see
“Configuring Dynamic Interfaces” on page 511.
To configure a profile for dynamic MLPPP:
1.
Create a profile by assigning it a name.
host1(config)#profile dynmlppp
2. Enable creation of dynamic MLPPP interfaces.
host1(config-profile)#ppp multilink enable
3. Specify a virtual router to which dynamic IP interfaces created using this profile will
be assigned.
host1(config-profile)#ip virtual-router egypt
4. Specify an IP loopback interface with which dynamic IP interfaces created using this
profile will be associated.
host1(config-profile)#ip unnumbered loopback 0
5. (Optional) Set other desired PPP characteristics by using the ppp commands described
in “Configuring Authentication” on page 310 and “Configuring Other PPP Attributes”
on page 312.
ppp multilink enable
•
Use in a profile to enable the creation of dynamic MLPPP interfaces.
•
Example
host1(config-profile)#ppp multilink enable
•
Use the no version to cause the LNS to reject any incoming requests to create dynamic
MLPPP interfaces.
•
See ppp multilink enable.
profile
Copyright © 2010, Juniper Networks, Inc.
319
JunosE 11.3.x Link Layer Configuration Guide
•
Use to create a profile.
•
Specify a profile name with up to 80 characters.
•
Example
host1(config)#profile dynmlppp1
•
Use the no version to remove a profile.
•
See profile.
Configuring MLPPP Fragmentation and Reassembly
You can configure MLPPP fragmentation and reassembly on a static link interface before
adding the link to a bundle, or in a profile assigned to a dynamic MLPPP interface. You
can also configure fragmentation and reassembly for all current member links in an
MLPPP bundle.
Overview
E Series routers support fragmentation and reassembly as part of their MLPPP
implementation. Fragmentation is the process by which a large packet is broken up into
multiple smaller fragments for simultaneous transmission across multiple links of an
MLPPP bundle. Reassembly is the process by which the destination router reassembles
the fragments into the original packets.
Application
You can use MLPPP fragmentation and reassembly to reduce transmission latency. You
can also use the feature to implement a packet-prioritization scheme that allows smaller,
delay-sensitive packets (such as high-priority voice packets) to be interleaved with or
race ahead of larger, delay-insensitive packets (such as low-priority data packets) when
they are transmitted in the network.
Supported Configurations
Table 16 on page 320 lists the static and dynamic MLPPP configurations on E Series routers
that support fragmentation and reassembly.
Table 16: Supported Configurations for MLPPP Fragmentation and
Reassembly
320
Static MLPPP Configurations
Dynamic MLPPP Configurations
Static MLPPP over ATM 1483 subinterfaces
Dynamic MLPPP over ATM 1483 subinterfaces
Static MLPPP over PPPoE over ATM 1483
subinterfaces
Dynamic MLPPP over PPPoE over ATM 1483
subinterfaces
Static MLPPP over serial (HDLC) interfaces
Dynamic MLPPP over serial (HDLC) interfaces
–
Dynamic MLPPP over L2TP (on the L2TP network
server)
Copyright © 2010, Juniper Networks, Inc.
Chapter 9: Configuring Multilink PPP
Table 16: Supported Configurations for MLPPP Fragmentation and
Reassembly (continued)
Static MLPPP Configurations
Dynamic MLPPP Configurations
Static MLPPP over PPPoE over Ethernet
Dynamic MLPPP over PPPoE over Ethernet
Module Requirements
For a list of the line modules and corresponding I/O modules that support MLPPP
fragmentation and reassembly on ERX7xx models, ERX14xx models, and the ERX310
router, see ERX Module Guide, Appendix A, Module Protocol Support.
For a list of the line modules and corresponding IOAs that support MLPPP fragmentation
and reassembly on the E120 and E320 routers, see E120 and E320 Module Guide,
Appendix A, IOA Protocol Support.
Link Configuration Parameters
The parameters for MLPPP fragmentation and reassembly are configured on a per-link
basis for each link interface (also known as a member link) in an MLPPP bundle.
By default, fragmentation and reassembly are disabled for MLPPP links. You can enable
or disable fragmentation and reassembly for an individual link, or for all member links in
a bundle, by using the ppp fragmentation and ppp reassembly commands. However,
you must configure the same fragmentation setting and the same reassembly
setting—enabled or disabled—for all member links in a bundle.
When you use the ppp fragmentation command to enable fragmentation on a link, you
can optionally specify the maximum fragment size to be used on the link interface. When
you use the ppp reassembly command to enable reassembly on a link, you can optionally
specify the administrative multilink maximum received reconstructed unit (MRRU) value
for the link.
Bundle Validation and Configuration Guidelines
When you configure MLPPP, the router validates that each link interface attempting to
join a statically or dynamically created bundle has Link Control Protocol (LCP) parameters
that are compatible with the other member links already in the bundle. This validation
includes examining the parameters configured for fragmentation and reassembly on a
particular link interface and verifying that these parameters are compatible with the
other member links in the bundle.
To ensure that the bundle validation succeeds, make sure you observe the following
configuration guidelines for MLPPP fragmentation and reassembly.
Guidelines for MLPPP Fragmentation
Use the following guidelines when you configure MLPPP fragmentation on a link interface:
Copyright © 2010, Juniper Networks, Inc.
321
JunosE 11.3.x Link Layer Configuration Guide
•
Configure the same fragmentation setting—enabled or disabled—for all member links
in a bundle.
•
When fragmentation is enabled, configure the same fragment size for all member links
in a bundle.
•
Make sure a link’s fragment size does not exceed its maximum transmission unit (MTU)
size.
•
Do not configure both MLPPP fragmentation (with the ppp fragmentation command)
and IP fragmentation of L2TP packets (with the ip mtu command) on the same
interface. Instead, you must choose only one of the fragmentation configurations by
setting it to the necessary value and set the other fragmentation configuration to the
maximum allowable value.
Guidelines for MLPPP Reassembly
Use the following guidelines when you configure MLPPP reassembly on a link interface:
•
Configure the same reassembly setting—enabled or disabled—for all member links in
a bundle.
•
Make sure a link’s administrative MRRU is greater than or equal to the local maximum
receive unit (MRU) negotiated both on that link and on other member links in the
bundle.
•
The local MRRU negotiated on a link must be the same as the local MRRU negotiated
on the other member links in the bundle.
•
The peer MRRU negotiated on a link must be the same as the peer MRRU negotiated
on the other member links in the bundle.
•
When reassembly is enabled, member links belonging to the same bundle can have
different local MRU values.
•
When reassembly is disabled, member links belonging to the same bundle must
negotiate the same local MRU value.
Bundle Validation Failure
If an MLPPP link interface fails bundle validation because one or more of the preceding
configuration guidelines are not met, the router’s actions differ depending on whether
you are using a static MLPPP configuration or a dynamic MLPPP configuration, as follows:
•
For static MLPPP configurations, the router permits the failed link to join the bundle,
but forces the link into a down state.
•
For dynamic MLPPP configurations, the router prohibits the failed link from joining the
bundle, and subsequently tears down the link.
Recovering from Bundle Validation Failure
To recover from a bundle validation failure, you must reconfigure the link interface (for
static MLPPP configurations) or reconfigure the profile (for dynamic MLPPP
configurations) according to the guidelines described in “Bundle Validation and
Configuration Guidelines” on page 321.
322
Copyright © 2010, Juniper Networks, Inc.
Chapter 9: Configuring Multilink PPP
Configuring Fragmentation and Reassembly for Static MLPPP
To configure fragmentation and reassembly on a static MLPPP link interface:
1.
From Global Configuration mode, specify the individual link interface on which you
want to configure fragmentation and reassembly.
host1(config)#interface serial 4/0:1/1/1/1/1
2. Specify MLPPP as the encapsulation method on the link interface.
host1(config-if)#encapsulation mlppp
3. Enable fragmentation on the link interface, and optionally specify the maximum
allowable fragment size to use.
host1(config-if)#ppp fragmentation 128
NOTE: You can specify the maximum fragment size for a link only when
you use the ppp fragmentation command to enable fragmentation on
that link. You cannot specify the maximum fragment size for a link when
fragmentation is disabled.
4. Enable reassembly on the link interface, and optionally specify the administrative
MRRU value to use.
host1(config-if)#ppp reassembly 1590
NOTE: You can specify the administrative MRRU value for a link only when
you use the ppp reassembly command to enable reassembly on that link.
You cannot specify the administrative MRRU for a link when reassembly
is disabled.
5. Exit Interface Configuration mode.
host1(config-if)#exit
6. Repeat Steps 1 through 5 for each additional link interface on which you want to
configure fragmentation and reassembly. For example:
host1(config)#interface serial 4/0:1/1/1/1/2
host1(config-if)#encapsulation mlppp
host1(config-if)#ppp fragmentation 128
host1(config-if)#ppp reassembly 1590
host1(config-if)#exit
7. Define the MLPPP bundle.
host1(config)#interface mlppp group1
8. Add each member link to the bundle.
host1(config-if)#member-interface serial 4/0:1/1/1/1/1
host1(config-if)#member-interface serial 4/0:1/1/1/1/2
9. Assign an IP address to the MLPPP bundle.
Copyright © 2010, Juniper Networks, Inc.
323
JunosE 11.3.x Link Layer Configuration Guide
host1(config-if)#ip address 10.10.100.1 255.255.255.0
Static MLPPP over ATM 1483 Example
The following example configures MLPPP fragmentation and reassembly for two member
links in an MLPPP bundle over an ATM 1483 subinterface.
host1(config)#interface atm 2/0
host1(config-if)#interface atm 2/0.2
host1(config-subif)#atm pvc 42 0 42 aal5snap
host1(config-subif)#encapsulation mlppp
host1(config-subif)#ppp fragmentation
host1(config-subif)#ppp reassembly 1400
host1(config-subif)#ppp authentication pap chap
host1(config-subif)#exit
host1(config)#interface atm 2/0.3
host1(config-subif)#atm pvc 43 0 43 aal5snap
host1(config-subif)#encapsulation mlppp
host1(config-subif)#ppp fragmentation
host1(config-subif)#ppp reassembly 1600
host1(config-subif)#ppp authentication pap chap
host1(config-subif)#exit
host1(config)#interface mlppp client1
host1(config-if)#member-interface atm 2/0.2
host1(config-if)#member-interface atm 2/0.3
host1(config-if)#ip address 10.10.200.1 255.255.255.0
Configuring Fragmentation and Reassembly for Dynamic MLPPP
To configure fragmentation and reassembly for dynamic MLPPP, you must create a
profile that includes commands to define the link and bundle attributes, just as you do
for a static MLPPP configuration.
For more information, see:
•
“Configuring Dynamic Interfaces” on page 511
•
LAC Configuration Prerequisites
•
LNS Configuration Prerequisites
To define a profile that configures MLPPP fragmentation and reassembly for a dynamic
MLPPP interface:
1.
From Global Configuration mode, create a profile by assigning it a name, and access
Profile Configuration mode.
host1(config)#profile dynmlppp1
host1(config-profile)#
2. Enable the creation of dynamic MLPPP interfaces.
host1(config-profile)#ppp multilink enable
3. Enable fragmentation on the link interface, and optionally specify the maximum
allowable fragment size to use.
host1(config-profile)#ppp fragmentation 128
324
Copyright © 2010, Juniper Networks, Inc.
Chapter 9: Configuring Multilink PPP
NOTE: You can specify the maximum fragment size for a link only when
you use the ppp fragmentation command to enable fragmentation on
that link. You cannot specify the maximum fragment size for a link when
fragmentation is disabled.
4. Enable reassembly on the link interface, and optionally specify the administrative
MRRU value to use.
host1(config-profile)#ppp reassembly 1800
NOTE: You can specify the administrative MRRU value for a link only when
you use the ppp reassembly command to enable reassembly on that link.
You cannot specify the administrative MRRU for a link when reassembly
is disabled.
5. (Optional) Specify a virtual router to which dynamic IP interfaces created with this
profile will be assigned.
host1(config-profile)#ip virtual-router boston
6. (Optional) Specify an IP loopback interface with which dynamic IP interfaces created
with this profile will be associated.
host1(config-profile)#ip unnumbered loopback 0
7. (Optional) Set other PPP characteristics as needed by using the ppp commands
described in “Configuring Multilink PPP” on page 299.
Dynamic MLPPP over PPPoE Example
The following example configures MLPPP fragmentation and reassembly for a dynamic
MLPPP interface over dynamic PPPoE over an ATM 1483 subinterface.
host1(config)#profile dynmlppp2
host1(config-profile)#ppp multilink enable
host1(config-profile)#ppp fragmentation 128
host1(config-profile)#ppp reassembly 1800
host1(config-profile)#ip virtual-router westford
host1(config-profile)#ip unnumbered loopback 1
host1(config-profile)#pppoe sessions 9
host1(config-profile)#ppp authentication chap
host1(config-profile)#exit
host1(config)#interface atm 4/0
host1(config-if)#interface atm 4/0.1
host1(config-subif)#atm pvc 52 0 52 aal5autoconfig 0 0 0
host1(config-subif)#profile pppoe dynmlppp2
host1(config-subif)#auto-configure pppoe
Dynamic MLPPP over L2TP Example
The following example configures MLPPP fragmentation and reassembly for a dynamic
MLPPP interface over L2TP over a Gigabit Ethernet interface.
Copyright © 2010, Juniper Networks, Inc.
325
JunosE 11.3.x Link Layer Configuration Guide
host1(config)#ip router-id 193.1.1.1
host1(config)#interface loopback 0
host1(config-if)#ip address 193.1.1.1 255.255.255.0
host1(config-if)#interface gigabitEthernet 1/1
host1(config-if)#ip unnumbered loopback 0
host1(config-if)#exit
host1(config)#ip route 193.1.1.2 255.255.255.255 gigabitEthernet 1/1
host1(config)#profile l2tp-profile
host1(config-profile)#ip virtual-router default
host1(config-profile)#ip unnumbered loopback 0
host1(config-profile)#ip access-routes
host1(config-profile)#ppp authentication pap
host1(config-profile)#ppp keepalive
host1(config-profile)#ppp multilink enable
host1(config-profile)#ppp mru 1590
host1(config-profile)#ppp reassembly 1590
host1(config-profile)#ppp fragmentation 128
host1(config-profile)#pppoe session 8000
host1(config-profile)#exit
host1(config)#l2tp destination profile lac ip address 193.1.1.2
host1(config-l2tp-dest-profile)#remote host xxx.com
host1(config-l2tp-dest-profile-host)#enable proxy authenticate
host1(config-l2tp-dest-profile-host)#tunnel password welcome
host1(config-l2tp-dest-profile-host)#profile l2tp-profile
encapsulation mlppp
•
Use to configure MLPPP as the encapsulation method on an individual interface.
•
Use this command only within the context of an individual interface. Issuing this
command creates an MLPPP link interface, which can be configured as a member of
an MLPPP bundle.
•
Example
host1(config)#interface serial 2/0:1/1
host1(config-if)#encapsulation mlppp
•
Use the no version to disable MLPPP on an interface.
•
See encapsulation mlppp.
•
Use to create an MLPPP network interface, also known as an MLPPP bundle.
•
Example
interface mlppp
host1(config-if)#interface mlppp group2
•
Use the no version to delete the MLPPP bundle. To delete an MLPPP bundle you must
first delete the IP interface, then delete the bundle members (link interfaces), and
finally delete the MLPPP bundle itself.
•
See interface mlppp.
member-interface
326
Copyright © 2010, Juniper Networks, Inc.
Chapter 9: Configuring Multilink PPP
•
Use to add an MLPPP link interface—also known as an MLPPP bundle member—to an
MLPPP bundle.
•
Example
host1(config-if)#member-interface serial 2/0:1/1
•
Use the no version to remove the specified interface from the MLPPP bundle.
•
See member-interface.
•
Use to enable fragmentation on an MLPPP link interface.
•
If fragmentation is enabled on the link, you can optionally specify the maximum
fragment size to be used on that link, in the range 128–65535 octets.
•
A link’s maximum fragment size cannot exceed the MTU size on that link.
•
We recommend that all member links in an MLPPP bundle be assigned the same
fragment size.
•
Do not configure both MLPPP fragmentation and IP fragmentation of L2TP packets
(with the ip mtu command) on the same interface. Instead, you must choose only one
of the fragmentation configurations by setting it to the necessary value and set the
other fragmentation configuration to the maximum allowable value.
•
Example
ppp fragmentation
host1(config-if)#ppp fragmentation 128
•
Use the no version to disable fragmentation on the link and restore the default fragment
size, which is the link’s MTU.
•
See ppp fragmentation.
•
Use in a profile to enable the creation of dynamic MLPPP interfaces.
•
Example
ppp multilink enable
host1(config-profile)#ppp multilink enable
•
Use the no version to reject any incoming requests to create dynamic MLPPP interfaces.
•
See ppp multilink enable.
•
Use to enable reassembly on an MLPPP link interface.
•
If reassembly is enabled on the link, you can optionally specify the administrative MRRU
for the link, in the range 64–65535 octets. The administrative MRRU is the maximum
allowable size of the PPP packet payload that the router can receive.
•
A link’s MRRU must be greater than or equal to the local MRU on that link.
•
We recommend that all member links in an MLPPP bundle be assigned the same
reassembly setting: enabled or disabled.
ppp reassembly
Copyright © 2010, Juniper Networks, Inc.
327
JunosE 11.3.x Link Layer Configuration Guide
•
Example
host1(config-if)#ppp reassembly 1590
•
Use the no version to disable reassembly on the link and restore the default value,
which is the local MRU on the link.
•
See ppp reassembly.
•
Use to create a profile for a dynamic interface.
•
You specify a profile name of up to 80 characters.
•
Example
profile
host1(config)#profile dynmlppp1
•
Use the no version to remove a profile.
•
See profile.
Configuring Fragmentation and Reassembly for MLPPP Bundles
If you issue the ppp fragmentation command or the ppp reassembly command in the
context of an MLPPP bundle, the command affects all the current member links in the
bundle. This enables you to issue a single command for the entire bundle instead of
having to issue individual commands for each member link in the bundle.
For example, the following commands configure MLPPP fragmentation and reassembly
for all member links in the bundle group1.
host1(config)#interface mlppp group1
host1(config-if)#ppp fragmentation 128
host1(config-if)#ppp reassembly 1590
host1(config-if)#exit
host1(config)#
Any member links added to the bundle after you issue an MLPPP configuration command
in the bundle context are not affected by the command. For example, if you add a member
link to the group1 bundle after you issue the ppp fragmentation or ppp reassembly
command, MLPPP fragmentation and reassembly for this link and any member links
subsequently added to the bundle is not enabled.
Configuring Multiclass MLPPP
Multiclass MLPPP enables you to fragment data packets of different priorities into multiple
classes in an MLPPP bundle. It also enables you to send high-priority packets between
fragments of larger, lower priority packets. Multiclass MLPPP ensures that high-priority,
delay-sensitive traffic, such as voice and video, are received in the proper sequence.
For information about multiclass MLPPP, see “Configuring Multiclass Multilink PPP” on
page 345.
328
Copyright © 2010, Juniper Networks, Inc.
Chapter 9: Configuring Multilink PPP
Monitoring MLPPP
Use the commands in this section to display information about MLPPP interfaces.
You can set a statistics baseline for MLPPP serial (member link) or bundle (multilink)
interfaces using the baseline ppp command. Use the delta keyword with the show
commands described below to display statistics with the baseline values subtracted.
After you configure multilink PPP, you can use the show ppp interface commands to
display configuration and statistics information about MLPPP and MLPPP fragmentation
and reassembly.
You can use the output filtering feature of the show command to include or exclude lines
of output based on a text string you specify. For details, see section show Commands in
JunosE System Basics Configuration Guide.
NOTE: The E120 and E320 routers output for monitor and show commands
is identical to output from other E Series routers, except that the E120 and
E320 routers output also includes information about the adapter identifier
in the interface specifier (slot/adapter/port).
baseline ppp interface
•
Use to set a statistics baseline for PPP interfaces—including MLPPP interfaces, either
individual serial (member link) interfaces or multilink (bundle) interfaces.
•
Use only the serial or mlppp keywords.
•
For serial interfaces, specify the interface location in the format
slot/port:channel/subchannel for CT3 modules.
•
For MLPPP interfaces, specify the interface location as the name of the MLPPP bundle.
•
The router implements the baseline by reading and storing the statistics at the time
the baseline is set and then subtracting this baseline whenever baseline-relative
statistics are retrieved.
•
When baselining is requested, the time since the last baseline was set is displayed in
hours:minutes:seconds or days/hours format. If a baseline was not set, the following
message is displayed instead:
No baseline has been set
•
Use the optional delta keyword with MLPPP show commands to specify that baselined
statistics are to be shown.
•
Example
host1#baseline ppp interface serial 2/0:1/1
•
There is no no version.
•
See baseline ppp interface.
Copyright © 2010, Juniper Networks, Inc.
329
JunosE 11.3.x Link Layer Configuration Guide
Sample Display
Without Baseline
The following command displays PPP interface (including MLPPP interface) statistics
without baselining:
host1#show ppp interface statistics
PPP interface serial 2/0:4/1
No baseline has been set
Interface statistics
packets
octets
errors
discards
PPP interface serial 2/0:5/1
No baseline has been set
Interface statistics
packets
octets
errors
discards
PPP interface serial 2/1:4/1
No baseline has been set
Interface statistics
packets
octets
errors
discards
PPP interface serial 2/1:5/1
No baseline has been set
Interface statistics
packets
octets
errors
discards
4 ppp interfaces found
is up
in
0
572
0
0
out
0
684
0
0
is up
in
0
572
0
0
out
0
684
0
0
is up
in
0
572
0
0
out
0
684
0
0
is up
in
0
572
0
0
out
0
684
0
0
PPP interface mlppp group1 is up
PPP multilink member-interface serial 2/0:1/1 is up
No baseline has been set
Interface statistics
in
packets
0
octets
608
errors
0
discards
0
PPP multilink member-interface serial 2/0:2/1 is up
No baseline has been set
Interface statistics
in
packets
0
octets
608
errors
0
discards
0
PPP multilink member-interface serial 2/0:3/1 is up
No baseline has been set
Interface statistics
in
packets
0
octets
596
errors
0
discards
0
PPP interface mlppp group2 is up
PPP multilink member-interface serial 2/1:1/1 is up
No baseline has been set
Interface statistics
in
330
out
0
716
0
0
out
0
716
0
0
out
0
704
0
0
out
Copyright © 2010, Juniper Networks, Inc.
Chapter 9: Configuring Multilink PPP
packets
0
octets
628
errors
0
discards
0
PPP multilink member-interface serial 2/1:2/1 is up
No baseline has been set
Interface statistics
in
packets
0
octets
628
errors
0
discards
0
PPP multilink member-interface serial 2/1:3/1 is up
No baseline has been set
Interface statistics
in
packets
0
octets
616
errors
0
discards
0
2 mlppp interfaces found
Sample Display with
Baseline
0
740
0
0
out
0
740
0
0
out
0
728
0
0
The following command displays PPP interface (including MLPPP interface) statistics
with baselining:
host1#show ppp interface statistics delta
PPP interface serial 2/0:4/1 is up
Time since last baseline 00:00:35
Interface statistics
in
packets
0
octets
75
errors
0
discards
0
PPP interface serial 2/0:5/1 is up
Time since last baseline 00:00:37
Interface statistics
in
packets
0
octets
87
errors
0
discards
0
PPP interface serial 2/1:4/1 is up
Time since last baseline 00:00:39
Interface statistics
in
packets
0
octets
101
errors
0
discards
0
PPP interface serial 2/1:5/1 is up
Time since last baseline 00:00:43
Interface statistics
in
packets
0
octets
94
errors
0
discards
0
4 ppp interfaces found
PPP interface mlppp group1 is up
PPP multilink member-interface serial 2/0:1/1 is up
Time since last baseline 00:00:17
Interface statistics
in
packets
0
octets
28
errors
0
Copyright © 2010, Juniper Networks, Inc.
out
0
82
0
0
out
0
90
0
0
out
0
112
0
0
out
0
99
0
0
out
0
26
0
331
JunosE 11.3.x Link Layer Configuration Guide
discards
0
PPP multilink member-interface serial 2/0:2/1 is up
Time since last baseline 00:10:22
0
Interface statistics
in
packets
0
octets
102
errors
0
discards
0
PPP multilink member-interface serial 2/0:3/1 is up
Time since last baseline 00:00:19
Interface statistics
in
packets
0
octets
112
errors
0
discards
0
out
0
104
0
0
PPP interface mlppp group2 is up
PPP multilink member-interface serial 2/1:1/1 is up
Time since last baseline 00:00:23
Interface statistics
in
packets
0
octets
125
errors
0
discards
0
PPP multilink member-interface serial 2/1:2/1 is up
Time since last baseline 00:00:25
Interface statistics
in
packets
0
octets
135
errors
0
discards
0
PPP multilink member-interface serial 2/1:3/1 is up
Time since last baseline 00:00:30
Interface statistics
in
packets
0
octets
125
errors
0
discards
0
2 mlppp interfaces found
out
0
126
0
0
out
0
132
0
0
out
0
138
0
0
out
0
132
0
0
show ppp interface mlppp
332
•
Use to display information about MLPPP interfaces.
•
You can display a great variety of information with this complex command. See the
show ppp interface command in “Configuring Point-to-Point Protocol” on page 259,
for more detailed information about the display options.
•
Use the show ppp interface command to display information about all PPP interfaces,
including MLPPP interfaces.
•
Field descriptions
•
PPP interface mlppp—Name and administrative status (up or down) for an MLPPP
bundle
•
PPP multilink member-interface—Interface type, interface specifier, and
administrative status (up or down) for an MLPPP member link
Copyright © 2010, Juniper Networks, Inc.
Chapter 9: Configuring Multilink PPP
•
Network interface administrative status—Indicates whether the interface for the
MLPPP bundle is administratively enabled (open), meaning that the no ppp
shutdown command is operational, or administratively disabled (closed), meaning
that the ppp shutdown command is operational
•
Link interface administrative status—Indicates whether the interface for the member
link is administratively enabled (open), meaning that the no ppp shutdown command
is operational, or administratively disabled (closed), meaning that the ppp shutdown
command is operational
•
Configured network protocol—Network protocol configured on the interface
•
Fragmentation and reassembly configuration:
•
Link interface fragmentation—Indicates whether MLPPP fragmentation is enabled
or disabled on the link interface
•
Link interface fragment size—MLPPP fragment size, in octets, currently in use on
the link interface
•
Link interface reassembly—Indicates whether MLPPP reassembly is enabled or
disabled on the link interface
•
Link interface administrative MRRU—Administrative MRRU value, in octets, currently
in use on the link interface
•
Baseline status—Indicates whether a statistics baseline has been set
•
Interface statistics:
•
packets—Number of packets received (in) and sent (out) on the interface
•
octets—Number of octets received (in) and sent (out) on the interface
•
errors—Number of errors received (in) and sent (out) on the interface
•
discards—Number of packets discarded on receipt (in) or discarded before they
were transmitted (out)
NOTE: For the LCP, IPCP, and OSINLCP negotiated options, the
command displays a value of “none” if the option was not negotiated.
•
LCP protocol configuration:
•
max-receive-unit—Controls negotiation of the local MRU option; value can be one
of the following:
•
use lower layer—MRU of the layer below PPP defines the MRU to be negotiated
•
disabled—MRU option is not to be negotiated
Copyright © 2010, Juniper Networks, Inc.
333
JunosE 11.3.x Link Layer Configuration Guide
•
•
•
334
authentication—Controls negotiation of the local authentication option; value can
be one of the following:
•
none—Do not negotiate
•
chap—Negotiate CHAP
•
pap—Negotiate PAP
•
chap/pap—Negotiate CHAP, and if it is rejected, negotiate PAP
•
pap/chap—Negotiate PAP, and if it is rejected, negotiate CHAP
•
magic-number—Controls whether the local magic number is negotiated: enabled
(negotiate), or disabled (do not negotiate)
•
magic-number-mismatch—Indicates whether the router is configured to ignore
the LCP peer magic number and retain the PPP connection when the peer has not
negotiated an LCP magic number: ignore (ignore the peer magic number mismatch
and retain the PPP connection), or reject (router terminates the PPP connection
if it detects a peer magic number mismatch)
•
keepalive-timer—Rate of LCP echo requests, in seconds
•
restart-timer—Retry frequency during LCP, IPCP, and OSINLCP negotiations, in
seconds
•
max-terminate—Maximum number of terminate requests
•
max-configure—Maximum number of configure requests
•
max-failure—Maximum number of configure NAKs
LCP protocol status:
•
•
a numeric value—MRU value to be negotiated
link-status—Indicates the overall status of LCP negotiations, including the following
states: initial (idle), starting (ready to negotiate), authenticate (authenticating),
and network (LCP is up)
LCP negotiated options:
•
max-receive-unit—Negotiated maximum receive unit, in octets, for the local and
remote (peer) side of the link
•
max-receive-reconstructed-unit—Negotiated maximum receive reconstructed
unit, in octets, for the local and remote (peer) side of the link
•
authentication—Negotiated authentication method (none, pap, or chap) for the
local and remote (peer) side of the link
•
magic-number—Negotiated magic number for the local and remote (peer) side
of the link
Copyright © 2010, Juniper Networks, Inc.
Chapter 9: Configuring Multilink PPP
•
pfc—Negotiated pfc (none or enabled) for the local and remote (peer) side of the
link
•
acfc—Negotiated acfc (none or enabled) for the local and remote (peer) side of
the link
NOTE: The command displays a value of “none” for any negotiated
option parameters if the option was not negotiated.
•
•
•
LCP Endpoint Discriminator options:
•
local discriminator class—Endpoint discriminator type, format, and address space
for the local system
•
local endpoint discriminator—Endpoint discriminator value for the local system
within the specified class
•
peer discriminator class—Endpoint discriminator type, format, and address space
for the remote system
•
peer endpoint discriminator—Endpoint discriminator value for the remote system
within the specified class
LCP protocol statistics:
•
in-keepalive-requests—Number of received keepalive requests (LCP Echo Request)
for the life of the interface (since either system boot or interface creation, whichever
is later)
•
out-keepalive-requests—Number of transmitted keepalive requests for the life of
interface
•
in-keepalive-replies—Number of received keepalive replies for the life of the
interface
•
out-keepalive-replies—Number of transmitted keepalive replies for the life of the
interface
•
keepalive-failures—Number of keepalive failures reported on the interface
•
max-renegotiation-terminates—Number of renegotiation terminations for the PPP
session
IPCP protocol configuration:
•
configured—IPCP is configured on this interface (true or false)
•
administrative-status—IPCP administrative status (open or closed)
•
ip-address—Address to be used for negotiation of local IP address option
•
dns-precedence—Used to resolve conflicts during DNS address negotiation
Copyright © 2010, Juniper Networks, Inc.
335
JunosE 11.3.x Link Layer Configuration Guide
•
•
local—Local side takes precedence, and the no ppp peer dns command is operative
•
peer—Remote side takes precedence, and the ppp peer dns command is operative
•
wins-precedence—Used to resolve conflicts during WINS address negotiation
•
ipcp-lockout—Terminates an invalid subscriber entry and prevents additional IPCP
negotiations (enabled or disabled)
•
max-negotiations—Maximum number of renegotiation attempts that the router
accepts before terminating a PPP session
IPCP protocol status:
•
•
operational-status—IPCP operational status (up, down, not present, or not present
no resources)
IPCP negotiated options:
•
ip-address—Negotiated IP address for the local and remote (peer) side of the link
•
primary-dns-address—Negotiated primary DNS address for the local and remote
(peer) side of the link
•
secondary-dns-address—Negotiated secondary DNS address for the local and
remote (peer) side of the link
•
primary-wins-address—Negotiated primary WINS address for the local and remote
(peer) side of the link
•
secondary-wins-address—Negotiated secondary WINS address for the local and
remote (peer) side of the link
NOTE: The command displays a value of “none” for any negotiated
option parameters if the option was not negotiated.
•
•
•
336
OSINLCP protocol configuration:
•
configured—OSINLCP is configured on this interface (true or false)
•
administrative-status—OSINLCP administrative status (open or closed)
OSINLCP protocol status:
•
operational-status—OSINLCP operational status (up, down, not present, or not
present no resources)
•
terminate-reason—Reason for termination of OSINLCP service
OSINLCP negotiated options
Copyright © 2010, Juniper Networks, Inc.
Chapter 9: Configuring Multilink PPP
•
•
npdu-alignment—Negotiated NPDU alignment for the local and remote (peer)
side of the link
Example 1—Displays information about the MLPPP member links configured in bundle
group1
host1#show ppp interface mlppp group1 members
PPP interface mlppp group1 is up
PPP multilink member-interface serial 2/0:1/1 is up
PPP multilink member-interface serial 2/0:2/1 is up
PPP multilink member-interface serial 2/0:3/1 is up
•
Example 2—Displays information about all MLPPP member links configured for all
bundles
host1#show ppp interface mlppp members
PPP interface mlppp group1 is up
PPP multilink member-interface serial
PPP multilink member-interface serial
PPP multilink member-interface serial
PPP interface mlppp group2 is up
PPP multilink member-interface serial
PPP multilink member-interface serial
PPP multilink member-interface serial
PPP interface mlppp group3
No member-interfaces found
•
2/1:1/1 is up
2/1:2/1 is up
2/1:3/1 is up
Example 3—Displays information about all MLPPP encapsulated links, regardless of
whether the links are members of an MLPPP bundle
host1#show ppp interface mlppp links
PPP multilink interface serial 2/0:1/1
PPP multilink interface serial 2/0:2/1
PPP multilink interface serial 2/0:3/1
PPP multilink interface serial 2/1:1/1
PPP multilink interface serial 2/1:2/1
PPP multilink interface serial 2/1:3/1
•
2/0:1/1 is up
2/0:2/1 is up
2/0:3/1 is up
is
is
is
is
is
is
up
up
up
up
up
up
Example 4—Displays configuration information about MLPPP member links configured
in bundle group1
host1#show ppp interface mlppp group1 config
PPP interface mlppp group1 is up
Network interface administrative status is open
Configured network protocol is IPCP
PPP multilink member-interface ATM 10/0.10 is up
Link interface administrative status is open
Link interface fragmentation is enabled
Link interface fragment size is 128
Link interface reassembly is enabled
Link interface administrative MRRU is 2000
PPP multilink member-interface ATM 10/0.11 is down (lower layer down)
Link interface administrative status is closed
Link interface fragmentation is enabled
Link interface fragment size is 128
Link interface reassembly is enabled
Link interface administrative MRRU is 2000
PPP multilink member-interface ATM 10/0.12 is down (lower layer down)
Link interface administrative status is closed
Link interface fragmentation is enabled
Copyright © 2010, Juniper Networks, Inc.
337
JunosE 11.3.x Link Layer Configuration Guide
Link interface fragment size is 128
Link interface reassembly is enabled
Link interface administrative MRRU is 2000
PPP multilink member-interface ATM 10/0.13 is down (lower layer down)
Link interface administrative status is closed
Link interface fragmentation is enabled
Link interface fragment size is 128
Link interface reassembly is enabled
Link interface administrative MRRU is 2000
1 mlppp interfaces found
•
Example 5—Displays statistics about all configured MLPPP member links configured
in bundle group1
host1#show ppp interface mlppp group1 statistics
PPP interface mlppp group1 is up
PPP multilink member-interface ATM 10/0.10
No baseline has been set
Interface statistics
in
packets
0
octets
170
errors
0
discards
0
PPP multilink member-interface ATM 10/0.11
No baseline has been set
Interface statistics
in
packets
0
octets
50
errors
0
discards
0
PPP multilink member-interface ATM 10/0.12
No baseline has been set
Interface statistics
in
packets
0
octets
50
errors
0
discards
0
PPP multilink member-interface ATM 10/0.13
No baseline has been set
Interface statistics
in
packets
0
octets
50
errors
0
discards
0
1 mlppp interfaces found
•
is up
out
0
690
0
0
is down (lower layer down)
out
0
0
0
0
is down (lower layer down)
out
0
0
0
0
is down (lower layer down)
out
0
0
0
0
Example 6—Displays status information about the specified MLPPP bundle
host1#show ppp interface mlppp group1 status
PPP interface mlppp group1 is up
1 mlppp interfaces found
•
Example 7—Shows complete configuration, statistics, and status information about
the specified MLPPP bundle
host1#show ppp interface mlppp group1 full
PPP interface mlppp group1 is up
Network interface administrative status is open
Configured network protocol is IPCP
IPCP protocol configuration
configured
true
338
Copyright © 2010, Juniper Networks, Inc.
Chapter 9: Configuring Multilink PPP
administrative-status
ip-address
dns-precedence
wins-precedence
max-negotiations
IPCP protocol status
operational-status
IPCP negotiated options
ip-address
primary-dns-address
secondary-dns-address
primary-wins-address
secondary-wins-address
OSINLCP protocol configuration
configured
administrative-status
OSINLCP protocol status
operational-status
open
1.2.3.4
local
local
10
up
local
1.2.3.4
none
none
none
none
peer
6.7.8.9
none
none
none
none
false
open
not present
terminate-reason
not configured
PPP multilink member-interface serial 2/0:1/1 is up
Link interface administrative status is open
No baseline has been set
Interface statistics
in
packets
0
octets
1488
errors
0
discards
0
LCP protocol configuration
max-receive-unit
use lower layer
authentication
none
magic-number
enabled
magic-number-mismatch
ignore
keepalive-timer
30 seconds
restart-timer
3 seconds
max-terminate
2
max-configure
10
max-failure
5
LCP protocol status
link-status
network
out
0
1972
0
0
LCP negotiated options
local
peer
max-receive-unit
1590
1590
max-receive-reconstructed-unit 1590
1590
authentication
none
none
magic-number
0x6c079eb0
0x2c5a5798
pfc
none
none
acfc
none
none
LCP Endpoint Discriminator options
local discriminator class
Locally Assigned Address
local endpoint discriminator
0x31393933313030303800001b000001
peer discriminator class
Locally Assigned Address
peer endpoint discriminator
0x31393933313030303800001b000002
LCP protocol statistics
in-keepalive-requests
70
out-keepalive-requests
70
in-keepalive-replies
70
out-keepalive-replies
70
keepalive-failures
0
max-renegotiation-terminates
10
PPP multilink member-interface serial 2/0:2/1 is up
Copyright © 2010, Juniper Networks, Inc.
339
JunosE 11.3.x Link Layer Configuration Guide
Link interface administrative status is open
No baseline has been set
Interface statistics
in
packets
0
octets
1508
errors
0
discards
0
LCP protocol configuration
max-receive-unit
use lower layer
authentication
none
magic-number
enabled
magic-number-mismatch
ignore
keepalive-timer
30 seconds
restart-timer
3 seconds
max-terminate
2
max-configure
10
max-failure
5
LCP protocol status
link-status
network
LCP negotiated options
local
max-receive-unit
1590
max-receive-reconstructed-unit 1590
authentication
none
magic-number
0x7ada4a05
pfc
none
acfc
none
out
0
1996
0
0
peer
1590
1590
none
0x1bb178cd
none
none
LCP Endpoint Discriminator options
local discriminator class
Locally Assigned Address
local endpoint discriminator
0x31393933313030303800001b000001
peer discriminator class
Locally Assigned Address
peer endpoint discriminator
0x31393933313030303800001b000002
LCP protocol statistics
in-keepalive-requests
71
out-keepalive-requests
71
in-keepalive-replies
71
out-keepalive-replies
71
keepalive-failures
0
PPP multilink member-interface serial 2/0:3/1 is up
Link interface administrative status is open
No baseline has been set
Interface statistics
in
out
packets
0
0
octets
1568
2068
errors
0
0
discards
0
0
LCP protocol configuration
max-receive-unit
use lower layer
authentication
none
magic-number
enabled
magic-number-mismatch
ignore
keepalive-timer
30 seconds
restart-timer
3 seconds
max-terminate
2
max-configure
10
max-failure
5
LCP protocol status
link-status
network
LCP negotiated options
local
peer
max-receive-unit
1590
1590
max-receive-reconstructed-unit 1590
1590
340
Copyright © 2010, Juniper Networks, Inc.
Chapter 9: Configuring Multilink PPP
authentication
none
none
magic-number
0x31cc52e0
0x32ebdec6
pfc
none
none
acfc
none
none
LCP Endpoint Discriminator options
local discriminator class
Locally Assigned Address
local endpoint discriminator
0x31393933313030303800001b000001
peer discriminator class
Locally Assigned Address
peer endpoint discriminator
0x31393933313030303800001b000002
LCP protocol statistics
in-keepalive-requests
74
out-keepalive-requests
74
in-keepalive-replies
74
out-keepalive-replies
74
keepalive-failures
0
1 mlppp interfaces found
•
Example 8—Displays information about the MLPPP interface
host1#show ppp interface mlppp 0/0-1 full
PPP interface mlppp 0/0-1 is up
Network interface administrative status is open
Configured network protocols are IPCP, IPV6CP
IPCP protocol configuration
configured
true
administrative-status
open
ip-address
192.168.1.1
dns-precedence
local
wins-precedence
local
ipcp-netmask-option
disabled
ipcp-lockout
enabled
IPCP protocol status
operational-status
up
IPCP negotiated options
local
ip-address
192.168.1.1
ip-address-mask
none
primary-dns-address
none
secondary-dns-address
none
primary-wins-address
none
secondary-wins-address
none
IPV6CP protocol configuration
configured
true
...
peer
100.100.100.17
none
none
none
none
none
PPP multilink member-interface ATM 0/0.10 is up
Link interface administrative status is open
Link interface fragmentation is enabled
Link interface fragment size is (use MTU)
Link interface reassembly is enabled
Link interface administrative MRRU is (use MRU)
Link interface hash-link-selection is disabled
No baseline has been set
...
Authentication status
grant
true
session-timeout
31622400 seconds
inactivity-timeout
none
monitor-ingress-only
false
accounting-timeout
none
peer-ip-address
100.100.100.17
peer-ip-address-mask
none
Copyright © 2010, Juniper Networks, Inc.
341
JunosE 11.3.x Link Layer Configuration Guide
peer-primary-dns-address
peer-secondary-dns-address
peer-primary-wins-address
peer-secondary-wins-address
peer-ipv6-interface-id
•
none
none
none
none
none
See show ppp interface.
show ppp interface summary
•
Use to display a summary of all the multilinked and nonmultilinked PPP interfaces
configured on the router.
•
Field descriptions
•
PPP Status—Non-multilinked PPP interfaces
•
Configuration status—Indicates the configuration state of the PPP interface, IPCP,
IPv6CP , OSINLCP, or MPLS
•
•
•
342
•
configured—Interface or protocol is configured
•
notConfigured—Interface or protocol is not configured
Administrative status—Indicates the administrative state of the PPP interface, IPCP,
IPv6CP , OSINLCP, or MPLS
•
open—Interface or protocol is administratively enabled
•
closed—Interface or protocol is administratively disabled
Operational status (Interface)—Indicates the operational state of the PPP interface
•
up—Interface is operational
•
down—Interface is not operational because of a problem in the PPP layer
•
lowerDown—Interface is not operational because a lower layer in the protocol
stack is down
•
notPresent—Interface is not operational because the hardware is unavailable
•
passive—Interface is waiting for the peer to send an LCP confReq message
•
tunnel—Interface is being redirected through a tunnel
Operational status (Ip, Ipv6, Osi, Mpls)—Indicates the operational state of the IPCP,
IPv6CP, OSINLCP, or MPLS protocol
•
up—Protocol is operational
•
down—Protocol is not operational because of a problem in the PPP layer
Copyright © 2010, Juniper Networks, Inc.
Chapter 9: Configuring Multilink PPP
•
•
•
•
notPresent—Protocol is not operational because it does not exist
•
noResources—Protocol is not operational because it does not exist due to a lack
of resources
PPP Multilink Status—Multilinked PPP interfaces
Example
host1#show ppp interface summary
PPP Status
Configuration status
configured
Interface
4000
Ip
4000
Ipv6
0
Osi
0
Mpls
0
Administrative status
open
Interface
4000
Ip
4000
Ipv6
4000
Osi
4000
Mpls
4000
Operational status
up
Interface
4000
Ip
4000
Ipv6
0
Osi
0
Mpls
0
Operational status
lowerDown
Interface
0
notConfigured
n/a
0
4000
4000
4000
closed
0
0
0
0
0
down
notPresent
0
0
0
0
0
4000
0
4000
0
4000
passive
tunnel
0
0
PPP Multilink Status
Configuration status
Link Interface
Network Interface
Ip
Ipv6
Osi
Mpls
Administrative status
Link Interface
Network Interface
Ip
Ipv6
Osi
Mpls
Operational status
Link Interface
Network Interface
Ip
Ipv6
Osi
Mpls
Operational status
Link Interface
Network Interface
notConfigured
n/a
n/a
0
2000
2000
2000
closed
0
0
0
0
0
0
down
notPresent
0
0
0
0
0
0
0
2000
0
2000
0
2000
passive
tunnel
0
0
0
0
configured
8000
2000
2000
0
0
0
open
8000
2000
2000
2000
2000
2000
up
8000
2000
2000
0
0
0
lowerDown
0
0
noResources
n/a
0
0
0
0
noResources
n/a
n/a
0
0
0
0
See show ppp interface summary.
Copyright © 2010, Juniper Networks, Inc.
343
JunosE 11.3.x Link Layer Configuration Guide
344
Copyright © 2010, Juniper Networks, Inc.
CHAPTER 10
Configuring Multiclass Multilink PPP
•
Multiclass MLPPP Overview on page 345
•
Multiclass MLPPP Traffic Classes Overview on page 346
•
Multiclass MLPPP LCP Extensions Overview on page 347
•
Multiclass MLPPP Platform Considerations on page 347
•
Multiclass MLPPP References on page 348
•
Configuring Multiclass MLPPP on page 348
•
Enabling Multiclass MLPPP on page 349
•
Configuring Traffic Classes on Multiclass MLPPP Interfaces on page 350
•
Configuring Fragmentation on Multiclass MLPPP Interfaces on page 350
•
Configuring Reassembly on Multiclass MLPPP Interfaces on page 351
•
Example: Configuring Multiclass MLPPP on a Dynamic Interface on page 352
•
Example: Configuring Multiclass MLPPP on a Static Interface on page 353
•
Monitoring Multiclass MLPPP on page 353
Multiclass MLPPP Overview
Multiclass MLPPP enables the fragmentation of data packets of different priorities into
multiple classes in an MLPPP bundle. It enables you to interleave data packets of higher
priority between packets of lower priority before transmission.
When the MLPPP bundle consists of more than one multilink interface, multiclass MLPPP
ensures the delivery of high-priority, delay-sensitive traffic, such as voice and video, in
the proper sequence. Multiclass MLPPP accomplishes this by creating separate transmit
and receive contexts for every multilink class in the MLPPP bundle. The transmit and
receive contexts contain the sequence numbers and all other statistics pertaining to the
multilink class
Multiclass MLPPP Fragmentation and Reassembly
You can configure fragmentation and reassembly on a multiclass MLPPP interface.
Fragmentation is the process by which a large packet is broken up into multiple smaller
fragments for simultaneous transmission across multiple links of an MLPPP bundle.
Reassembly is the process by which the destination router reassembles the fragments
into the original packets.
Copyright © 2010, Juniper Networks, Inc.
345
JunosE 11.3.x Link Layer Configuration Guide
On MLPPP bundles that consist of physical links of different types, MLPPP does not
guarantee the receipt of high-priority data packets in sequence. Multiclass MLPPP enables
you to fragment data packets of different priorities into multiple multilink classes. Because
every multilink class has its own transmit and receive context, data packets of each class
are received in the same sequence they were transmitted.
With multiclass MLPPP, data packets of each multilink class are encapsulated in an
MLPPP header. The sequence numbers of each class are also embedded within the
header before transmission. The receiving peer processes each class independently and
uses the sequence numbers in the MLPPP header to internally reorder and reassemble
packets in the desired sequence.
Multiclass MLPPP Configuration Guidelines
Use the following guidelines while configuring multiclass MLPPP:
Related
Documentation
•
Configure multiclass MLPPP on each link in the MLPPP bundle. If any link is not
configured, the receiving peer might prevent the mismatched link from joining the
bundle.
•
The first link to join a bundle determines whether multiclass MLPPP is configured on
the bundle. All subsequent links must also negotiate the same multiclass MLPPP
parameters as that of the first link. The configuration for each link in a bundle is identical.
•
Configuring Multiclass MLPPP on page 348
•
Chapter 9, Configuring Multilink PPP
Multiclass MLPPP Traffic Classes Overview
A traffic class is a system-wide collection of buffers, queues, and bandwidth that you
can allocate to provide a defined level of service to packets in the traffic class. With
multiclass MLPPP, high-priority and low-priority data packets are fragmented into their
respective QoS traffic classes before being transmitted. The QoS traffic classes are each
mapped to a separate multilink class.
The major benefits of mapping traffic classes to multilink classes are:
•
The multiclass MLPPP feature supports the mapping of up to eight traffic classes. You
can fragment data packets into a maximum of eight different priorities of traffic classes.
•
Classes of higher-priority can be interleaved between classes of lower priority, which
reduces transmission latency.
•
Every multilink class has its own transmit and receive context. These contexts ensure
that data packets of higher priority traffic classes are received in the order they were
transmitted.
The default traffic class is the best-effort traffic class. You can configure fragmentation
and reassembly on all traffic classes. Any packet without a traffic-class-to-multilink-class
mapping is transmitted without a multiclass MLPPP header.
346
Copyright © 2010, Juniper Networks, Inc.
Chapter 10: Configuring Multiclass Multilink PPP
Related
Documentation
•
Configuring Traffic Classes on Multiclass MLPPP Interfaces on page 350
•
Multiclass MLPPP Overview on page 345
•
Traffic Class and Traffic-Class Groups Overview
Multiclass MLPPP LCP Extensions Overview
Link Control Protocol (LCP) establishes an MLPPP link by negotiating LCP options with
the MLPPP peer at the receiving end of a proposed connection. Peers negotiate multiclass
MLPPP during the initial phase of the LCP option negotiation.
LCP uses the following new LCP configuration options for establishing a multiclass
MLPPP link:
•
Multilink header format—Multilink header format has three functions:
•
It informs the receiving peer that the multiclass MLPPP feature is supported.
•
It informs the peer of the multilink header format that will be used.
•
It informs the peer of the number of multilink classes configured.
The router currently supports only the multilink header format option. The two number
formats that are negotiated for the multilink header format option are:
Related
Documentation
•
Short sequence number
•
Long sequence number—The router currently supports only long sequence numbers
•
Prefix elision—Prefix elision informs the receiving peer that only packets with a certain
prefix must be accepted. This prefix is not transmitted as part of the information in the
fragments of a multilink class. When the prefix is negotiated, all multilink packets must
be transmitted with the negotiated prefix removed from the start of the packet. The
prefix is empty for all classes, by default. The router currently does not support the
prefix elision option.
•
Multiclass MLPPP Overview on page 345
•
Configuring Multiclass MLPPP on page 348
•
Link Control Protocol in Chapter 8, Point-to-Point Protocol
Multiclass MLPPP Platform Considerations
You can configure multiclass MLPPP on the following E Series Broadband Services
Routers:
•
E120 router
•
E320 router
Copyright © 2010, Juniper Networks, Inc.
347
JunosE 11.3.x Link Layer Configuration Guide
Module Requirements
For information about modules that support multiclass MLPPP on the E120 and E320
Broadband Services Routers:
•
See E120 and E320 Module Guide, Table 1, Module and IOAs for detailed module
specifications.
•
See E120 and E320 Module Guide, Appendix A, IOA Protocol Support for information
about the modules that support multiclass MLPPP.
Interface Specifiers
For E120 and E320 routers, use the slot/adapter/port format, which includes an identifier
for the bay in which the I/O adapter (IOA) resides. In the software, adapter 0 identifies
the right IOA bay (E120 router) and the upper IOA bay (E320 router); adapter 1 identifies
the left IOA bay (E120 router) and the lower IOA bay (E320 router). For example, the
following command specifies a gigabitEthernet interface on slot 3, adapter 0, port 0 of
an E320 router.
host1(config)#interface gigabitEthernet 3/0/0
Related
Documentation
•
Configuring Multiclass MLPPP on page 348
•
Multiclass MLPPP Overview on page 345
•
Interface Types and Specifiers in JunosE Command Reference Guide
Multiclass MLPPP References
For more information about multiclass MLPPP, see the following resources:
Related
Documentation
•
RFC 1990—The PPP Multilink Protocol (MP) (August 1996)
•
RFC 2686—The Multi-Class Extension to Multi-Link PPP (September 1999)
•
Configuring Multiclass MLPPP on page 348
•
Multiclass MLPPP Overview on page 345
Configuring Multiclass MLPPP
When you configure multiclass MLPPP, you enable the creation of multilink classes on
the MLPPP interface and assign QoS traffic classes to the multilink classes. You can
configure multiclass MLPPP on a static MLPPP interface or in a dynamic profile for a
dynamic MLPPP interface.
To configure multiclass MLPPP:
348
Copyright © 2010, Juniper Networks, Inc.
Chapter 10: Configuring Multiclass Multilink PPP
1.
Enable multiclass MLPPP.
See “Enabling Multiclass MLPPP” on page 349.
2. Configure traffic classes on the multiclass MLPPP interface.
See “Configuring Traffic Classes on Multiclass MLPPP Interfaces” on page 350.
3. (Optional) Configure fragmentation on the multiclass MLPPP interface.
See “Configuring Fragmentation on Multiclass MLPPP Interfaces” on page 350.
4. (Optional) Configure reassembly on the multiclass MLPPP interface.
See “Configuring Reassembly on Multiclass MLPPP Interfaces” on page 351.
Related
Documentation
•
Multiclass MLPPP Overview on page 345
•
Example: Configuring Multiclass MLPPP on a Dynamic Interface on page 352
•
Example: Configuring Multiclass MLPPP on a Static Interface on page 353
Enabling Multiclass MLPPP
You can enable multiclass MLPPP on an MLPPP interface and create a specified number
of multilink classes on it. A maximum number of eight multilink classes are supported
per MLPPP interface.
Before you enable multiclass MLPPP:
•
Define the QoS traffic classes
See Configuring Traffic Classes That Define Service Levels.
To enable multiclass MLPPP and create a specified number of multilink classes on a
dynamic MLPPP interface:
1.
From Global Configuration mode, create an MLPPP dynamic profile by assigning it a
name.
host1(config)#profile ppp-multilink-profile
2. Enable multiclass MLPPP and specify the number of multilink classes to create.
host1(config-profile)#ppp multilink multiclass multilink-classes 8
To enable multiclass MLPPP and create a specified number of multilink classes on a
static MLPPP interface:
1.
From Global Configuration mode, specify the individual interface on which you want
to configure multiclass MLPPP.
host1(config)#interface gigabitEthernet 3/0/0
2. Specify PPPoE as the encapsulation method on the interface.
host1(config-if)#encapsulation pppoe
3. Create a PPPoE subinterface.
Copyright © 2010, Juniper Networks, Inc.
349
JunosE 11.3.x Link Layer Configuration Guide
host1(config)#interface gigabitEthernet 3/0/0.10
4. Specify MLPPP as the encapsulation method on the subinterface.
host1(config-if)#encapsulation mlppp
5. Enable multiclass MLPPP and specify the number of miltilink classes to create.
host1(config-if)#ppp multilink multiclass multilink-classes 8
Related
Documentation
•
Configuring a Dynamic Interface from a Profile in Chapter 17, Configuring Dynamic
Interfaces
•
ppp multilink multiclass
Configuring Traffic Classes on Multiclass MLPPP Interfaces
You can configure mapping of QoS traffic classes to multilink classes. The best-effort
QoS traffic class is mapped to multilink class 0 by default.
To configure mapping of QoS traffic classes to multilink classes:
•
Specify the QoS traffic classes to be mapped to the multilink classes.
To map QoS traffic classes to multilink classes in a dynamic profile:
host1(config-profile)#ppp multilink multiclass traffic-class best-effort voice
otherData video
To map QoS traffic classes to multilink classes in a static MLPPP interface:
host1(config-if)#ppp multilink multiclass traffic-class best-effort voice otherData
video
NOTE: You must include the best-effort traffic class in the ppp multilink
multiclass traffic-class command, or the command fails.
Related
Documentation
•
Chapter 17, Configuring Dynamic Interfaces
•
ppp multilink multiclass traffic-class
Configuring Fragmentation on Multiclass MLPPP Interfaces
You can configure fragmentation on a multiclass MLPPP interface with the same fragment
size as that of the MLPPP interface.
Before you configure fragmentation on the multiclass MLPPP interface:
350
Copyright © 2010, Juniper Networks, Inc.
Chapter 10: Configuring Multiclass Multilink PPP
•
Ensure that fragmentation is enabled on the MLPPP interface.
See Configuring MLPPP Fragmentation and Reassembly in Chapter 8, Configuring Multilink
PPP.
To configure fragmentation on a multiclass MLPPP interface:
•
Specify the QoS traffic classes to be fragmented.
To configure fragmentation on multilink classes in a dynamic profile:
host1(config-profile)#ppp multilink multiclass fragmentation best-effort voice
otherData video
To configure fragmentation on multilink classes in a static MLPPP interface:
host1(config-if)#ppp multilink multiclass fragmentation best-effort voice otherData
video
The order of the QoS traffic classes does not affect the execution of the command.
NOTE: You must include the best-effort traffic class in the ppp multilink
multiclass fragmentation command, or the command fails.
Related
Documentation
•
Chapter 17, Configuring Dynamic Interfaces
•
ppp multilink multiclass fragmentation
Configuring Reassembly on Multiclass MLPPP Interfaces
You can configure reassembly on a multiclass MLPPP interface with the same maximum
received reconstructed unit (MRRU) value as that of the MLPPP interface.
Before you configure reassembly on the multiclass MLPPP interface:
•
Ensure that reassembly is enabled on the MLPPP interface.
See Configuring MLPPP Fragmentation and Reassembly in Chapter 8, Configuring Multilink
PPP.
To configure reassembly on a multiclass MLPPP interface:
•
Specify the QoS traffic classes to be reassembled.
To configure reassembly on multilink classes in a dynamic profile:
host1(config-profile)#ppp multilink multiclass reassembly best-effort voice
otherData video
To configure reassembly on multilink classes in a static MLPPP interface:
host1(config-if)#ppp multilink multiclass reassembly best-effort voice otherData
video
The order of the QoS traffic classes does not affect the execution of the command.
Copyright © 2010, Juniper Networks, Inc.
351
JunosE 11.3.x Link Layer Configuration Guide
NOTE: You must include the best-effort traffic class in the ppp multilink
multiclass reassembly command, or the command fails.
Related
Documentation
•
Chapter 17, Configuring Dynamic Interfaces
•
ppp multilink multiclass reassembly
Example: Configuring Multiclass MLPPP on a Dynamic Interface
The following example shows how to configure multiclass MLPPP on a dynamic MLPPP
interface. To configure multiclass MLPPP you first define the traffic classes that need to
be mapped to the multilink classes. You configure multiclass MLPPP in the dynamic
profile and optionally configure fragmentation and reassembly on the multiclass MLPPP
interface.
1.
Define the QoS traffic classes.
host1 (config)#traffic-class voice
host1 (config-traffic-class)#fabric-strict-priority
host1 (config)#traffic-class low-loss
host1 (config-traffic-class)#fabric-strict-priority
host1 (config)#traffic-class low-latency
host1 (config-traffic-class)#fabric-strict-priority
For more information about defining QoS traffic classes, see Traffic Class and
Traffic-Class Groups Overview.
2. Create a dynamic profile.
host1(config)#profile ppp-multilink-dynamic-profile
3. Configure multiclass MLPPP in the dynamic profile.
host1 (config-profile)#ppp multilink multiclass multilink-classes 4
host1(config-profile)#ppp multilink multiclass traffic-class best-effort voice low-loss
low-latency
For more information about configuring a dynamic profile for multiclass MLPPP, see
Configuring a Profile in Chapter 17, Configuring Dynamic Interfaces.
4. Configure fragmentation and reassembly on the multiclass MLPPP interface.
host1(config-profile)#ppp multilink multiclass fragmentation best-effort voice low-loss
low-latency
host1(config-profile)#ppp multilink multiclass reassembly best-effort voice low-loss
low-latency
Related
Documentation
352
•
Configuring Multiclass MLPPP on page 348
Copyright © 2010, Juniper Networks, Inc.
Chapter 10: Configuring Multiclass Multilink PPP
Example: Configuring Multiclass MLPPP on a Static Interface
The following example shows how to configure multiclass MLPPP on a static MLPPP
interface. To configure multiclass MLPPP you first define the traffic classes that need to
be mapped to the multilink classes. You configure multiclass MLPPP on the static MLPPP
interface and optionally configure fragmentation and reassembly on the interface.
1.
Define the QoS traffic classes.
host1 (config)#traffic-class video
host1 (config-traffic-class)#fabric-strict-priority
host1 (config)#traffic-class low-loss
host1 (config-traffic-class)#fabric-strict-priority
For more information about QoS traffic classes, see Traffic Class and Traffic-Class
Groups Overview.
2. Specify the interface and the encapsulation method on which you want to configure
MLPPP
host1(config)#interface gigabitEthernet 3/0/0
host1(config-if)#encapsulation pppoe
host1(config)#interface gigabitEthernet 3/0/0.10
host1(config-if)#encapsulation mlppp
3. Configure multiclass MLPPP on the static interface.
host1(config-if)#ppp multilink multiclass multilink-classes 3
host1(config-if)#ppp multilink multiclass traffic-class best-effort video low-loss
4. Configure fragmentation and reassembly on the multiclass MLPPP interface.
host1(config-if)#ppp multilink multiclass fragmentation best-effort video low-loss
host1(config-if)#ppp multilink multiclass reassembly best-effort video low-loss
Related
Documentation
•
Configuring Multiclass MLPPP on page 348
Monitoring Multiclass MLPPP
Purpose
Action
Display information about the status and configuration of multilink classes on an MLPPP
Interface.
To display configuration information about multiclass MLPPP member links configured
in the specified MLPPP bundle:
host1#show ppp interface mlppp bundle1 config
PPP interface mlppp mlppp1 is up
...
PPP multilink member-interface gigabitEthernet 3/0.1.1 is up
Link interface administrative status is open
PPP multilink multiclass is enabled
PPP multilink multiclass classes 4
PPP multilink multiclass fragmentation is enabled on “voice”, otherData”
PPP multilink multiclass reassembly is enabled on “voice”, ”otherData”
...
Copyright © 2010, Juniper Networks, Inc.
353
JunosE 11.3.x Link Layer Configuration Guide
PPP multilink member-interface gigabitEthernet 3/0.1.2 is up
Link interface administrative status is open
PPP multilink multiclass is enabled
PPP multilink multiclass classes 4
PPP multilink multiclass fragmentation is enabled on “voice”,”otherData”
PPP multilink multiclass reassembly is enabled on “voice”, ”otherData”
...
1 mlppp interfaces found
To display the statistics of the multiclass MLPPP member links configured in the specified
MLPPP bundle:
host1#show ppp interface mlppp bundle1 statistics
PPP interface mlppp bundle1 is up
Time since last baseline 2 days, 18 hours
2 receive classes, 2 transmit classes
Interface statistics
in
packets
0
octets
0
errors
0
discards
0
fragments
0
out
0
0
0
0
0
Receive Class 0:
0 fragments in reassembly list
0 reordered, 0/0 discarded fragments/bytes,
0x0 last received sequence number
Receive Class 1:
0 fragments in reassembly list
0 reordered, 0/0 discarded fragments/bytes,
0x0 last received sequence number
Transmit Class 0:
0 fragments, 0x8 last sent sequence number
Transmit Class 1:
0 fragments, 0x0 last sent sequence number
...
1 mlppp interfaces found
To display complete configuration, statistics, and status information of multiclass MLPPP
member links configured in the specified MLPPP bundle:
host1#show ppp interface mlppp bundle1 full
Bundle name: bundle1
MLPPP interface gigabitEthernet 3/0.1.1 is up
Link interface administrative status is open
PPP multilink multiclass is enabled
PPP multilink multiclass classes 4
PPP multilink multiclass fragmentation is enabled on “voice”, otherData”
PPP multilink multiclass reassembly is enabled on “voice”, ”otherData”
...
LCP negotiated options
local
peer
max-receive-unit
1590
1590
max-receive-reconstructed-unit 1590
1590
authentication
none
none
magic-number
0x78b5606f
0x5aa2de54
pfc
none
none
acfc
none
none
354
Copyright © 2010, Juniper Networks, Inc.
Chapter 10: Configuring Multiclass Multilink PPP
multiclass-classes
multiclass-sequence-format
4
long
4
long
...
1 mlppp interfaces found
Meaning
Table 17 on page 355 lists the show ppp interface mlppp command output fields.
Table 17: show ppp interface mlppp Output Fields
Field Name
Field Description
PPP interface mlppp bundleName
Name and state (up or down) of the MLPPP interface
PPP multilink member-interface
interfaceName
Name and state (up or down) of the MLPPP member
link interface
Link interface administrative
status
Administrative state of the member link interface:
open (enabled) or closed (disabled)
PPP multilink multiclass
Configuration of multiclass MLPPP on the MLPPP
interface: enabled or disabled
PPP multilink multiclass classes
Number of multilink classes created on the MLPPP
interface: 1 through 8
PPP multilink multiclass
fragmentation
Configuration of fragmentation of the multiclass
MLPPP interface: enabled or disabled. If
fragmentation is enabled then the command also
lists the QoS traffic classes on which fragmentation
is enabled.
PPP multilink multiclass
reassembly
Configuration of reassembly of the multiclass MLPPP
interface: enabled or disabled. If reassembly is
enabled then it also lists the QoS traffic classes on
which reassembly is enabled.
mlppp interfaces found
Number of MLPPP interfaces configured
Time since last baseline
When baselining is configured, the time since the last
baseline was set is displayed in hours:minutes:seconds
or days/hours format
receive class, transmit class
Number of multilink classes configured on the MLPPP
bundle
Copyright © 2010, Juniper Networks, Inc.
355
JunosE 11.3.x Link Layer Configuration Guide
Table 17: show ppp interface mlppp Output Fields (continued)
356
Field Name
Field Description
Interface statistics
Statistics for data received by (in) and transmitted
(out) on the MLPPP interface:
•
packets—Number of packets received and
transmitted on the interface
•
octets—Number of octets received and transmitted
on the interface
•
errors—Number of errors received and transmitted
on the interface
•
discards—Number of packets discarded on receipt
or discarded before they were transmitted
•
fragments—Number of fragments received and
transmitted on the interface
Receive Class number
Information about the packets of the specified
multilink class received by the router
fragments in reassembly list
Number of buffered fragments reassembled
reordered
Number of fragments reordered
discarded fragments/bytes
Number of fragments and bytes that have been
discarded.
last received sequence number
Sequence number of the last multiclass MLPPP
packet received
Transmit Class number
Information about the packets of the specified
multilink class transmitted by the router
fragments
Number of fragments that are sent by the router
last sent sequence number
Sequence number of the last multiclass MLPPP
packet sent
Bundle name
Name of the MLPPP bundle
MLPPP interface interfaceName
Name and state (up or down) of the configured
MLPPP interface
Copyright © 2010, Juniper Networks, Inc.
Chapter 10: Configuring Multiclass Multilink PPP
Table 17: show ppp interface mlppp Output Fields (continued)
Related
Documentation
Field Name
Field Description
LCP negotiated options
Negotiated LCP options for the local and peer
systems:
•
max-receive-unit—Negotiated maximum receive
unit, in octets, for the local and remote (peer) side
of the link
•
max-receive-reconstructed-unit—Negotiated
maximum receive reconstructed unit, in octets, for
the local and remote (peer) side of the link
•
authentication—Negotiated authentication method
(none, pap, or chap) for the local and remote (peer)
side of the link
•
magic-number—Negotiated magic number for the
local and remote (peer) side of the link
•
pfc—Negotiated protocol field compression (none
or enabled) for the local and remote (peer) side of
the link
•
acfc—Negotiated address and control field
compression (none or enabled) for the local and
remote (peer) side of the link
•
multiclass-classes—Number of multilink classes
negotiated
•
multiclass-sequence-format—Format of the
negotiated sequence number: long or short
•
Configuring Multiclass MLPPP on page 348
•
show ppp interface
Copyright © 2010, Juniper Networks, Inc.
357
JunosE 11.3.x Link Layer Configuration Guide
358
Copyright © 2010, Juniper Networks, Inc.
CHAPTER 11
Configuring Packet over SONET
Use the procedures described in this chapter to configure packet over SONET (POS) on
E Series routers.
This chapter contains the following sections:
•
Overview on page 359
•
Platform Considerations on page 360
•
References on page 361
•
Before You Configure POS on page 362
•
Configuration Tasks on page 362
•
Monitoring POS on page 366
Overview
Packet over SONET (Synchronous Optical Network)/SDH (Synchronous Digital Hierarchy)
is the serial transmission of data over SONET frames through the use of a protocol such
as Point-to-Point Protocol (PPP).
Packet over SONET/SDH is an ideal feature for networks that are built for providing
Internet or IP data. It provides superior bandwidth utilization and efficiency compared
with other transport methods. For expensive WAN links, packet over SONET can provide
as much as 25 to 30 percent higher throughput than networks based on Asynchronous
Transfer Mode (ATM). By transporting frames directly into the SONET/SDH payload, the
overhead required in an ATM cell header for IP over ATM encapsulation is eliminated.
The router supports PPP, Cisco High-Level Data Link Control (HDLC), and Frame Relay
over SONET/SDH.
POS Features
POS supports the following features:
•
Payload scrambling
•
Clock source configuration
•
Maximum transmission unit (MTU) size configuration
•
Maximum receive unit (MRU) size configuration
Copyright © 2010, Juniper Networks, Inc.
359
JunosE 11.3.x Link Layer Configuration Guide
•
POS framing
•
Cyclic redundancy check (CRC) checking
•
Loopback configuration
SONET/SDH
SONET is an ANSI standard for transmitting bits over fiber-optic cable. SDH is the
international standard defined by the International Telecommunication Union (ITU).
SONET/SDH is the physical infrastructure of choice for carrier ATM networks operating
at speeds above 50 Mbps.
SONET/SDH allows carriers to build high-speed international links without requiring
conversion from one transmission protocol to another (for example, T1 to T3 or T1 to E3
conversion).
SONET transmission speeds start at 51.84 Mbps and are referred to as OC1. SDH
transmission speeds start at 155.52 Mbps and are referred to as STM1. All other speeds
are multiples of these base numbers. Table 18 on page 360 shows the speeds of the most
common SONET/SDH implementations.
Table 18: Most Common SONET/SDH Implementations
SONET
SDH
Transmission Speed
OC1
—
51.84 Mbps
OC3
STM1
155.52 Mbps
OC12
STM4
622.08 Mbps
OC48
STM16
2.4 Gbps
OC96
STM32
4.876640 Gbps
OC192
STM64
9.953280 Gbps
Platform Considerations
You can configure POS interfaces on the following E Series Broadband Services Routers:
360
•
E120 router
•
E320 router
•
ERX1440 router
•
ERX1410 router
•
ERX710 router
•
ERX705 router
•
ERX310 router
Copyright © 2010, Juniper Networks, Inc.
Chapter 11: Configuring Packet over SONET
Module Requirements
For information about the modules that support POS interfaces on ERX14xx models,
ERX7xx models, and the ERX310 router:
•
See ERX Module Guide, Table 1, Module Combinations for detailed module specifications.
•
See ERX Module Guide, Appendix A, Module Protocol Support for information about the
modules that support POS.
For information about the modules that support POS interfaces on the E120 and E320
routers:
•
See E120 and E320 Module Guide, Table 1, Modules and IOAs for detailed module
specifications.
•
See E120 and E320 Module Guide, Appendix A, IOA Protocol Support for information
about the modules that support POS.
Interface Specifiers
The configuration task examples in this chapter use the slot/port[.subinterface ] format
to specify a POS interface. However, the interface specifier format that you use depends
on the router that you are using.
For ERX7xx models, ERX14xx models, and ERX310 router, use the slot/port[.subinterface
] format. For example, the following command specifies a POS interface on slot 0, port
1 of an ERX7xx model, ERX14xx model, or ERX310 router.
host1(config)#interface pos 0/1
For E120 and E320 routers, use the slot/adapter/port format, which includes an identifier
for the bay in which the I/O adapter (IOA) resides. In the software, adapter 0 identifies
the right IOA bay (E120 router) and the upper IOA bay (E320 router); adapter 1 identifies
the left IOA bay (E120 router) and the lower IOA bay (E320 router). For example, the
following command specifies a POS interface on slot 5, adapter 0, port 0 of an E320
router.
host1(config)#interface pos 5/0/0
For more information about supported interface types and specifiers on E Series routers,
see Interface Types and Specifiers in JunosE Command Reference Guide.
References
For more information about POS interfaces, consult the following resources:
•
RFC 1662—PPP in HDLC-like Framing (July 1994)
•
RFC 2615—PPP over SONET/SDH (June 1999
•
RFC 2427—Multiprotocol Interconnect over Frame Relay (September 1998)
Copyright © 2010, Juniper Networks, Inc.
361
JunosE 11.3.x Link Layer Configuration Guide
Before You Configure POS
Before you configure a POS interface, verify that you have correctly installed the required
module. For information about installing modules in ERX7xx models, ERX14xx models,
and ERX310 router, see ERX Hardware Guide, Chapter 4, Installing Modules. For information
about installing modules in the E120 and E320 routers, see E120 and E320 Hardware
Guide, Chapter 4, Installing Modules. Then verify that no ATM interfaces are defined on
the physical port.
Also have the following information available:
•
Interfaces specifiers for the POS interfaces that you want to create
For more information about specifying POS interfaces on E Series routers, see Interface
Types and Specifiers in JunosE Command Reference Guide.
•
IP addresses and subnet mask assignments for IP interfaces
Configuration Tasks
To configure a POS interface:
1.
Configure a physical interface.
host1(config)#interface pos 0/1
2. (Optional) Assign a text description or an alias to the interface.
host1(config-if)#pos description austin01 pos interface
3. Configure the encapsulation method.
host1(config-if)#encapsulation ppp
4. (Optional) Configure the internal clock source.
host1(config-if)#clock source internal module
5. (Optional) Set the size of the CRC.
host1(config-if)#crc 32
6. (Optional) Set the time interval at which the router calculates bit and packet rate
counters.
host1(config-if)#load-interval 90
7. (Optional) Set the type of loopback mode.
host1(config-if)#loopback line
8. (Optional) Set the MRU size.
host1(config-if)#mru 1000
9. (Optional) Set the MTU size.
host1(config-if)#mtu 1000
10. (Optional) Set the type of framing.
362
Copyright © 2010, Juniper Networks, Inc.
Chapter 11: Configuring Packet over SONET
host1(config-if)#pos framing sdh
11. Disable payload scrambling.
host1(config-if)#no pos scramble-atm
12. (Optional) Disable an interface.
host1(config-if)#shutdown
clock source
•
Use to set the clock source.
•
You can set internal or line clocking.
•
Internal clocking has two options:
•
•
module—Uses internal clock from the line module
•
chassis—Uses the configured router clock
Example
host1(config-if)#clock source internal module
•
Use the no version to restore the default value, line.
•
See clock source.
•
Use to set the number of bits used for CRC checking.
•
CRC is an error-checking technique that uses a calculated numeric value to detect
errors in transmitted data; 16 and 32 indicate the number of check digits per frame that
are used to calculate the frame check sequence (FCS). Both the sender and receiver
must use the same setting.
•
Example
crc
host1(config-if)#crc 32
•
Use the no version to restore the default value, 16.
•
See crc.
encapsulation frame-relay ietf
•
Use to specify Frame Relay as the encapsulation method for the interface.
•
The router uses IETF format (RFC 2427 encapsulation).
•
Example
host1(config-if)#encapsulation frame-relay ietf
•
Use the no version to remove the Frame Relay configuration from an interface.
•
See encapsulation frame-relay ietf
encapsulation ppp
Copyright © 2010, Juniper Networks, Inc.
363
JunosE 11.3.x Link Layer Configuration Guide
•
Use to specify PPP as the encapsulation method for the interface.
•
Example
host1(config-if)#encapsulation ppp
•
Use the no version to remove the PPP configuration from an interface.
•
See encapsulation ppp.
•
Use to configure a POS interface.
•
To specify a POS interface for ERX7xx models, ERX14xx models, and ERX310 router,
use the slot/port[.subinterface ] format.
interface pos
•
•
slot—Number of the chassis slot
•
port—Port number on the I/O module
•
subinterface—Number of the subinterface
To specify a POS interface for E120 and E320 routers, use the slot/adapter/port format.
•
slot—Number of the chassis slot
•
adapter—Identifier for the IOA within the E320 chassis, either 0 or 1, where:
•
•
0 indicates that the IOA is installed in the right IOA bay (E120 router) or the upper
IOA bay (E320 router).
•
1 indicates that the IOA is installed in the left IOA bay (E120 router) or the lower
IOA bay (E320 router).
port—Port number on the IOA
•
For more information about modules that support POS interfaces, see chapter
Configuring Unchannelized OCx/STMx Interfaces in JunosE Physical Layer Configuration
Guide.
•
Examples
host1(config-if)#interface pos 0/1
host1(config-if)#interface pos 5/0/0
•
Use the no version to remove the POS interface.
•
See interface pos.
•
Use to set the time interval at which the router calculates bit and packet rate counters.
•
You can choose a multiple of 30 seconds, in the range 30–300 seconds.
•
Example
load-interval
host1(config-if)#load-interval 90
364
Copyright © 2010, Juniper Networks, Inc.
Chapter 11: Configuring Packet over SONET
•
Use the no version to restore the default value, 300.
•
See load-interval.
•
Use to specify the type of loopback for a POS interface.
loopback
•
•
internal—Connects the local transmitted signal to the local received signal.
•
line—Connects the received network signal directly to the transmit network signal.
When configured in line loopback mode, the router never receives data from the
network.
Example
host1(config-if)#loopback line
•
Use the no version to clear the loopback.
•
See loopback.
•
Use to set the maximum allowable size of the MRU.
•
Specify a value in the range 1–9996 bytes.
•
Example
mru
host1(config-if)#mru 1000
•
Use the no version to restore the default value, 4470.
•
See mru.
•
Use to set the maximum allowable size of the MTU.
•
Specify a value in the range 1–9996 bytes.
•
Example
mtu
host1(config-if)#mtu 1000
•
Use the no version to restore the default value, 4470.
•
See mtu.
•
Use to assign a text description or an alias to a POS HDLC interface.
•
You can use this command to help you identify the interface and keep track of interface
connections.
•
The description or alias can be a maximum of 80 characters.
•
Use “show interfaces pos” on page 367 to display the text description.
•
Example
pos description
Copyright © 2010, Juniper Networks, Inc.
365
JunosE 11.3.x Link Layer Configuration Guide
host1(config-if)#pos description austin01 pos interface
•
Use the no version to remove the text description or alias.
•
See pos description.
•
Use to set the type of framing for a POS interface.
pos framing
•
•
sdh—Uses SDH framing format
•
sonet—Uses SONET framing format (the default)
Example
host1(config-if)#pos framing sdh
•
Use the no version to restore the default value, sonet.
•
See pos framing.
•
Use to enable payload scrambling on a POS interface.
•
Payload scrambling is enabled by default. When enabled, both sides of the connection
must be using the scrambling algorithm. The router uses a 43rd-order synchronous
scrambler to scramble the output data.
•
Example
pos scramble-atm
host1(config-if)#pos scramble-atm
•
Use the no version to disable scrambling on the POS interface.
•
See pos scramble-atm.
•
Use to disable a POS interface.
•
Example
shutdown
host1(config-if)#shutdown
•
Use the no version to restart a disabled interface.
•
See shutdown.
Monitoring POS
Use the show interfaces pos command to display information about the POS interface.
You can set a statistics baseline for POS interfaces using the baseline interface pos
command.
You can use the output filtering feature of the show command to include or exclude lines
of output based on a text string you specify. See show Commands in JunosE System Basics
Configuration Guide, for details.
366
Copyright © 2010, Juniper Networks, Inc.
Chapter 11: Configuring Packet over SONET
NOTE: The E120 and E320 routers output for monitor and show commands
is identical to output from other E Series routers, except that the E120 and
E320 router output also includes information about the adapter identifier in
the interface specifier (slot/adapter/port).
baseline interface pos
•
Use to set a statistics baseline for POS interfaces. The router implements the baseline
by reading and storing the statistics at the time the baseline is set and then subtracting
this baseline whenever baseline-relative statistics are retrieved.
•
Example
host1#baseline interface pos 8/0
•
There is no no version.
•
See baseline interface.
•
Use to display the configuration, state, and statistics for a POS interface.
•
To specify a POS interface for ERX7xx models, ERX14xx models, and ERX310 router,
use the slot/port[.subinterface ] format.
show interfaces pos
•
•
slot—Number of the chassis slot
•
port—Port number on the I/O module
•
subinterface—Number of the subinterface
To specify a POS interface for E120 and E320 routers, use the slot/adapter/port format.
•
slot—Number of the chassis slot
•
adapter—Identifier for the IOA within the E320 chassis, either 0 or 1, where:
•
•
•
•
0 indicates that the IOA is installed in the right IOA bay (E120 router) or the upper
IOA bay (E320 router).
•
1 indicates that the IOA is installed in the left IOA bay (E120 router) or the lower
IOA bay (E320 router).
port—Port number on the IOA
You can include the following keywords:
•
delta—Specifies that baselined statistics are to be shown
•
brief—Displays the operational status of all configured interfaces
Field descriptions
•
POS interface status—State of the physical interface: up, down
•
Description—Text description or alias if configured for the interface
Copyright © 2010, Juniper Networks, Inc.
367
JunosE 11.3.x Link Layer Configuration Guide
•
•
snmp trap link-status—SNMP trap status: disabled: up, down
•
Encapsulation—Layer 2 encapsulation display; options: ppp, frame-relay ietf, mlppp,
mlframe-relay ietf, hdlc
•
SONET path operational status—State of the SONET path: up, down,
lowerLayerDown
•
time since last status change—Last reported change to the SONET path operational
status
•
SONET operational status—State of SONET operation: up, down, lowerLayerDown
•
time since last status change—Last reported change to the SONET operational
status
•
loopback—Loopback status for the physical interface: enabled, disabled
•
timing source—Clocking source for the physical interface
•
framing type—Framing type for the physical interface
•
Crc type checking—Number of bits used for CRC checking: crc16, crc32, none
•
Hdlc mru—MRU size allowed on the interface
•
Hdlc mtu—MTU size allowed on the interface
•
Hdlc interface speed—Line speed of the interface
•
Hdlc scrambling—Status of payload scrambling on the interface: on, off
•
5 minute input rate—Data rates based on the traffic received in the last five minutes
•
5 minute output rate—Data rates based on the traffic sent in the last five minutes
•
Packets received—Number of incoming packets received on this interface
•
Bytes received—Number of incoming bytes received on this interface
•
Errored packets received—Number of incoming errors received on this interface
•
Packets sent—Number of outgoing packets transmitted on this interface
•
Bytes sent—Number of outgoing bytes transmitted on this interface
•
Errored packets sent—Number of outgoing errors on this interface
Example
host1#show interfaces pos 8/0
Packet over SONET interface 8/0 is ifOperUp
Description: houston80 pos interface
snmp trap link-status = disabled
Encapsulation ppp
SONET path operational status: up
time since last status change: 00:20:37
368
Copyright © 2010, Juniper Networks, Inc.
Chapter 11: Configuring Packet over SONET
SONET operational status:
up
time since last status change: 00:20:37
loopback not set
timing source is loop timing
framing type is SONET
Crc type checking - CRC32
Hdlc mru = 4470
Hdlc mtu = 4470
Hdlc interface speed = 155520000
Hdlc scrambling is off
5 minute input rate 24910848 bits/sec, 1023242 packets/sec
5 minute output rate 24905728 bits/sec, 1023233 packets/sec
Interface statistics
Packets received
Bytes received
Errored packets received
Packets sent
Bytes send
Errored packets sent
•
1066995954
3836558195
0
1055275550
3039550548
0
See show interfaces.
Copyright © 2010, Juniper Networks, Inc.
369
JunosE 11.3.x Link Layer Configuration Guide
370
Copyright © 2010, Juniper Networks, Inc.
CHAPTER 12
Configuring Point-to-Point Protocol over
Ethernet
This chapter describes how to configure the Point-to-Point Protocol (PPP) over Ethernet
interfaces on E Series routers.
This chapter contains the following sections:
•
Overview on page 371
•
Platform Considerations on page 380
•
References on page 381
•
Access Nodes in Ethernet Aggregation Networks Overview on page 382
•
ATM-to-Ethernet Interworking Overview on page 382
•
Before You Configure PPPoE on page 384
•
Configuring PPPoE over ATM on page 384
•
Processing of IWF PPPoE Sessions with Duplicate MAC Addresses on page 391
•
Guidelines for Configuring Duplicate Protection for IWF PPPoE Sessions on page 391
•
Configuration Examples for ATM-to-Ethernet Interworking Functions on page 392
•
Configuring PPPoE for Ethernet Modules on page 394
•
Configuring PADM Messages on page 402
•
Configuring PADN Messages on page 404
•
Configuring PPPoE Service Name Tables on page 405
•
Configuring PADS Packet Content on page 413
•
Configuring PPPoE Remote Circuit ID Capture on page 414
•
Monitoring PPPoE on page 419
•
Troubleshooting on page 435
Overview
E Series routers use PPP over Ethernet (PPPoE) to enable multiple hosts to open PPP
sessions to the router using one or more bridging modems. When service providers want
to maintain the session abstraction associated with PPP, PPPoE is used with Broadband
Copyright © 2010, Juniper Networks, Inc.
371
JunosE 11.3.x Link Layer Configuration Guide
Remote Access Server (B-RAS) technologies that provide a bridged Ethernet topology.
PPPoE can be configured over ATM or on Ethernet modules with or without VLANs.
Figure 37 on page 372 shows how PPPoE allows the router to handle multiple PPP sessions
originating on an Ethernet module to be multiplexed over one PVC on an ATM interface.
PPP, as described in “Configuring Point-to-Point Protocol” on page 259, runs above the
PPPoE layer.
Figure 37: PPPoE over ATM
The router handles the server part of PPPoE session management and never initiates a
setup of a PPPoE session. The router only responds to session requests that are sent to
it by the remote PPP client. After the sessions are set up, the router demultiplexes the
sessions based on session identifiers assigned to a specific connection.
PPPoE Stages
PPPoE has two distinct stages: Discovery and Session.
Discovery
PPPoE includes a Discovery protocol that allows each PPP session to learn the Ethernet
address of the remote peer, as well as establish a unique session identifier. When a host
wants to initiate a PPPoE session, it must first perform Discovery to identify the Ethernet
MAC address of the peer and establish a PPPoE session ID.
Although PPP defines a peer-to-peer relationship, Discovery is inherently a client-server
relationship. In the Discovery process, a host acting as a client discovers a remote access
concentrator (AC), which acts as the server.
Based on the network topology, there may be more than one remote AC with whom the
host can communicate. The Discovery stage allows the host to discover all remote ACs
and then select the one to which it wants to connect.
In summary, the Discovery stage consists of the following four steps:
1.
The host (PPPoE client) broadcasts a PPPoE Active Discovery Initiation (PADI) packet
to all remote ACs in the network.
2. One or more remote ACs respond to the PADI packet by sending a PPPoE Active
Discovery Offer (PADO) packet, indicating that they can serve the client request. The
PADO packet includes the name of the AC from which it was sent.
372
Copyright © 2010, Juniper Networks, Inc.
Chapter 12: Configuring Point-to-Point Protocol over Ethernet
3. The host sends a unicast PPPoE Active Discovery Request (PADR) packet to the AC
to which it wants to connect.
4. The selected AC sends a PPPoE Active Discovery Session (PADS) packet to confirm
the session.
Session
When Discovery is successfully completed, both the host and the selected remote AC
have the information they need to build their point-to-point connection over Ethernet.
The only parameter that you can configure is the number of PPPoE sessions.
NOTE: The router supports dynamic PPPoE interfaces. Also, profiles support
PPPoE interfaces. See “Configuring Dynamic Interfaces” on page 511 and
“Configuring Dynamic Interfaces Using Bulk Configuration” on page 619, for
more information.
PPPoE Service Name Tables
PPPoE clients use service name tags, as defined in RFC 2516, to request that an AC
support certain services. The client includes a custom service name tag in the PADI packet
that it broadcasts to remote ACs. Alternatively, the client can include an empty service
name tag of zero length to indicate that any service is acceptable, or an unknown service
name tag to represent a service not yet configured in the PPPoE service name table.
On receipt of a PADI packet that it can serve, the AC responds with a PADO packet. The
PADO packet contains a service name tag that is identical to the one in the PADI, as well
as one or more additional service name tags indicating other services that the AC offers.
A PPPoE service name table consists of one or more service name entries and their
associated action. The PPPoE service name table can include three types of service name
tags:
•
Custom service name tag (serviceName) — A service entry that represents a specific
client service that an AC can support. The length of the custom service name tag can
be up to 31 alphanumeric characters; for example, myQoSClass or my ISPService. You
can optionally associate an action (drop or terminate) with a custom service. The
default action for a custom service is terminate.
•
Empty service name tag (empty-service-name) — A service entry of zero length that
is used to represent any service. The router either responds with a PADO packet to all
PADI requests containing an empty service name tag, or denies (drops) all PADI requests
based on the action configured for the service.
•
Unknown service name tag (unknown-service-name) — A service entry that has not
been configured in the PPPoE service name table. When a PPPoE client includes an
unknown service name tag in the PPPoE service name table, the router responds based
on the action (drop or terminate) associated with the unknown service name entry.
Copyright © 2010, Juniper Networks, Inc.
373
JunosE 11.3.x Link Layer Configuration Guide
The default action associated with the unknown service name tag depends on the
PPPoE service name table configuration. If all the services in the table are configured
to drop, the default action for the unknown service name tag is terminate. If all the
services in the table are configured to terminate, the default action for the unknown
service name tag is drop. If both terminate and drop are configured for services in the
table, all unknown service name tags are dropped by default.
Features
PPPoE service name tables enable an AC, such as an E Series router, to support multiple
service name tags in addition to the empty service name tag and the unknown service
name tag. You can configure up to 16 PPPoE service name tables per E Series router to:
•
Define the set of service name tags (empty service name, custom service name, and
unknown service name) that the router advertises in the PADO packets sent to PPPoE
clients.
•
Control whether the router responds to (terminate) or denies (drop) PADI requests
based on the action associated with the service name tags.
Table Structure
Each entry, or row, in a PPPoE service name table consists of the following components:
•
Service name tag—Service name tags specify the client services that an AC supports.
You can add three types of service name tags to the PPPoE service name table: empty
service name, custom service name (serviceName), and unknown service name. Every
PPPoE service name table includes one empty service name tag and one unknown
service name service tag. An empty service name tag is a service tag of zero length
that is used to represent any service. An unknown service name service tag is used to
represent a service tag that has not been configured in the service name table. In
addition to these two tags, you can configure up to 16 custom service name tags per
table.
•
Action—Each service name tag has an associated action: terminate (the default action)
or drop. For empty service name and unknown service name entries, you can use the
action keyword with the service command to modify the default action associated
with the service. For custom service name (serviceName) entries, using the action
keyword with the service command is optional. The default action for a custom service
tag entry is terminate.
For example, Table 19 on page 374 shows a PPPoE service name table containing five
entries: three custom service name tags, two associated with the terminate action and
one associated with the drop action; an empty service name tag (“ ” ) associated with
the drop action; and an unknown service name tag associated with the drop action.
Table 19: Sample PPPoE Service Name Table
374
Service Name
Action
“myISPService”
Terminate
“myQOSClass1”
Terminate
Copyright © 2010, Juniper Networks, Inc.
Chapter 12: Configuring Point-to-Point Protocol over Ethernet
Table 19: Sample PPPoE Service Name Table (continued)
Service Name
Action
“myQOSClass2”
Drop
“ ”
(empty-service-name)
Drop
unknown-service-name
Drop
NOTE: You can associate the drop action with a maximum of eight service
tags in a PPPoE service name table.
Enabling the Service Name Table for Use
After you create a PPPoE service name table and populate it with entries, you must
enable it for use with a static or dynamic PPPoE interface. To enable a PPPoE service
name table for use with a static interface, you assign the table to the PPPoE major
interface. To enable a PPPoE service name table for use with a dynamic interface, you
add the table to a profile that is dynamically assigned to a PPPoE interface column. For
details about configuring and using PPPoE service name tables, see “Configuring PPPoE
Service Name Tables” on page 405.
Using the PPPoE Remote Circuit ID to Identify Subscribers
You can enable the router to capture and format a vendor-specific tag containing a
PPPoE remote circuit ID transmitted from a digital subscriber line access multiplexer
(DSLAM) device. The router can then send this value to a Remote Authentication Dial-In
User Service (RADIUS) server or to a Layer 2 Tunneling Protocol (L2TP) network server
(LNS) to uniquely identify subscriber locations.
This feature is supported on all modules on which you can configure PPPoE interfaces.
The feature is particularly useful in Ethernet-based Broadband Remote Access Server
(B-RAS) configurations as a means of uniquely identifying subscribers connected to the
router on a single Ethernet link.
For detailed configuration instructions, see “Configuring PPPoE Remote Circuit ID Capture”
on page 414.
Application
When a connection between an E Series router and a DSLAM is on an ATM interface,
subscribers are typically assigned an ATM PVC to communicate with the router. Each
ATM PVC is created on a different ATM 1483 subinterface. When a RADIUS server in this
configuration sends messages to the router containing the NAS-Port-Id [87] RADIUS
attribute, each ATM 1483 subinterface produces a unique NAS-Port-Id that can
differentiate subscribers on the ATM link.
By contrast, when the connection between the router and the DSLAM is on an Ethernet
interface that does not use either virtual LANs (VLANs) or stacked VLANs (S-VLANs),
Copyright © 2010, Juniper Networks, Inc.
375
JunosE 11.3.x Link Layer Configuration Guide
the NAS-Port-Id value is the same for all subscribers on the Ethernet link. Enabling the
router to capture the remote circuit ID sent from the DSLAM and use it as a RADIUS or
L2TP attribute facilitates the process of identifying individual subscribers on an Ethernet
link.
PPPoE Remote Circuit ID Capture
When you enable capture of the PPPoE remote circuit ID by issuing the pppoe
remote-circuit-id command, the E Series router captures the remote circuit ID value if it
is sent from the DSLAM. The PPPoE intermediate agent on the DSLAM appends a
vendor-specific tag containing the remote circuit ID to the existing PPPoE PADI or PADR
packet and sends this packet to the E Series router. The PPPoE remote circuit ID value
can be a maximum of 64 characters. The router stores this value on the line module on
which the PPPoE interface is configured.
PPPoE Remote Circuit ID Format
By default, the router formats the captured PPPoE remote circuit ID to include only the
agent-circuit-id suboption (suboption 1) of the PPPoE intermediate agent tags sent from
the DSLAM. To configure a nondefault format for the captured PPPoE remote circuit ID,
you can use one of the radius remote-circuit-id-format commands listed in Table 20
on page 376.
Table 20: Configuring Nondefault Formats for the PPPoE Remote Circuit
ID
To Configure This Nondefault Format
Use This Command
Include only the agent-remote-id suboption
(suboption 2) of the tags supplied by the PPPoE
intermediate agent
host1(config)#radius remote-circuit-id-format
agent-remote-id
Include both the agent-circuit-id suboption
(suboption 1) and the agent-remote-id
suboption (suboption 2) of the tags supplied
by the PPPoE intermediate agent
host1(config)#radius remote-circuit-id-format
agent-circuit-id agent-remote-id
Include the NAS-Identifier [32] RADIUS attribute
with either or both of the agent-circuit-id and
agent-remote-id suboptions of the tags
supplied by the PPPoE intermediate agent
host1(config)#radius remote-circuit-id-format
nas-identifier agent-circuit-id
or
host1(config)#radius remote-circuit-id-format
nas-identifier agent-remote-id
or
host1(config)#radius remote-circuit-id-format
nas-identifier agent-circuit-id
agent-remote-id
376
Copyright © 2010, Juniper Networks, Inc.
Chapter 12: Configuring Point-to-Point Protocol over Ethernet
Table 20: Configuring Nondefault Formats for the PPPoE Remote Circuit
ID (continued)
To Configure This Nondefault Format
Use This Command
Append the agent-circuit-id suboption to an
interface specifier that is consistent with the
recommended format in the DSL Forum
Technical Report (TR)-101—Migration to
Ethernet-Based DSL Aggregation (April 2006).
host1(config)#radius remote-circuit-id-format
dsl-forum-1
For details about how the router implements
this format, see “Format for dsl-forum-1
Keyword” on page 377.
For more information about configuring the format of the PPPoE remote circuit ID value,
see “radius remote-circuit-id-format” on page 418.
Remote Circuit ID Delimiter
If the format of the PPPoE remote circuit ID consists of two or more components, the
router uses a # character by default to delimit the components. Optionally, you can use
the radius remote-circuit-id-delimiter command to configure a nondefault delimiter
character (for example, ! or %) to separate multiple components in the PPPoE remote
circuit ID value. For information about how to use this command, see “radius
remote-circuit-id-delimiter” on page 418.
Format for dsl-forum-1 Keyword
When you specify the radius remote-circuit-id-format command with the dsl-forum-1
keyword, the router appends the agent-circuit-id suboption value to an interface specifier
that is consistent with the recommended format in the DSL Forum Technical Report
(TR)-101—Migration to Ethernet-Based DSL Aggregation (April 2006).
The format of the PPPoE remote circuit ID when you use the dsl-forum-1 keyword is as
follows:
dslForum1InterfaceSpecifier#agent-circuit-id
where:
•
dslForum1InterfaceSpecifier is the interface specifier in dsl-forum-1 format
•
# is the default delimiter character
•
agent-circuit-id is the agent-circuit-id suboption (suboption 1) of the PPPoE intermediate
agent tags sent from the DSLAM
If the DSLAM transmits empty data for agent-circuit-id, the router appends the value
0/0/0/0/0/0 to dslForum1InterfaceSpecifier.
To obtain the value for dslForum1InterfaceSpecifier, the router translates an internally
generated interface specifier into the format for the dsl-forum-1 keyword, using the
following conventions:
Copyright © 2010, Juniper Networks, Inc.
377
JunosE 11.3.x Link Layer Configuration Guide
•
The dsl-forum-1 format for ATM interfaces is atm slot/adapter/port:vpi.vci
•
The dsl-forum-1 format for Ethernet interfaces is eth slot/adapter/port:svlanId.vlanId
•
For the E120 or the E320 routers, the router uses the actual adapter value (0 or 1) in
the dsl-forum-1 format. For ERX14xx models, ERX7xx models, and the ERX310 router,
which do not support an adapter value, the router sets the adapter value to 0 (zero).
•
For Ethernet interfaces that use VLANs but do not use S-VLANs, the router sets the
svlanId value to 4096 and uses the actual vlanId value in the dsl-forum-1 format.
•
For Ethernet interfaces that use neither S-VLANs nor VLANs, the router sets both the
svlanId value and the vlanId value to 4096 in the dsl-forum-1 format.
•
The router ignores subinterface values for ATM and Ethernet interfaces in the translated
dsl-forum-1 format.
NOTE: The format of the interface specifier that the router generates
internally is different from the interface specifier format that you use to
configure interfaces on the router. For information about the interface types
and specifiers to use when configuring interfaces on E Series routers, see
Interface Types and Specifiers in JunosE Command Reference Guide.
Format Examples for dsl-forum-1 Keyword
Table 21 on page 378 provides several examples of how the router uses the conventions
described in “Format for dsl-forum-1 Keyword” on page 377 to translate internally generated
interface specifiers into the format of the dslForum1InterfaceSpecifier value. The examples
in the table use adapter 1 for interfaces on an E120 or E320 router, and adapter 0 (no
adapter value) for interfaces on ERX14xx models, ERX7xx models, and the ERX310 router.
Table 21: Interface Specifier Format Examples for dsl-forum-1 Keyword
Interface Example
Internal Router Format
How Router Translates
Format of
dslForum1InterfaceSpecifier
ATM 1483 subinterface on
slot 2, port 0, subinterface 1
with VPI 100 and VCI 101
atm 2/0.1:100.101
•
Sets adapter to 0
atm 2/0/0:100.101
•
Ignores subinterface 1
•
Uses other values as
supplied
ATM 1483 subinterface on
slot 3, adapter 1, port 7,
subinterface 6 with VPI 200
and VCI 201
atm 3/1/7.6:200.201
•
Ignores subinterface 6
•
Uses other values as
supplied
Gigabit Ethernet interface on
slot 2, port 0 with no VLAN
or S-VLAN subinterfaces
gigabitEthernet 2/0
•
Sets adapter to 0
•
Sets both svlanId and
vlanId to 4096
•
Uses other values as
supplied
378
atm 3/1/7:200.201
eth 2/0/0:4096.4096
Copyright © 2010, Juniper Networks, Inc.
Chapter 12: Configuring Point-to-Point Protocol over Ethernet
Table 21: Interface Specifier Format Examples for dsl-forum-1 Keyword
(continued)
Interface Example
Internal Router Format
How Router Translates
Format of
dslForum1InterfaceSpecifier
Gigabit Ethernet interface on
slot 4, adapter 1, port 1 with
no VLAN or S-VLAN
subinterfaces
gigabitEthernet 4/1/1
•
Sets both svlanId and
vlanId to 4096
eth 4/1/1:4096.4096
•
Uses other values as
supplied
Gigabit Ethernet interface on
slot 2, port 0, subinterface 1
with VLAN ID 5
gigabitEthernet 2/0.1:5
•
Sets adapter to 0
•
Ignores subinterface 1
•
Sets svlanId to 4096
•
Uses other values as
supplied
•
Ignores subinterface 3
•
Sets svlanId to 4096
•
Uses other values as
supplied
•
Sets adapter to 0
•
Ignores subinterface 1
•
Replaces - (hyphen)
between svlanId and
vlanID with . (period)
•
Uses other values as
supplied
•
Ignores subinterface 3
•
Replaces - (hyphen)
between svlanId and
vlanID with . (period)
•
Uses other values as
supplied
Gigabit Ethernet interface on
slot 4, adapter 1, port 1,
subinterface 3 with VLAN
ID 10
gigabitEthernet 4/1/1.3:10
Gigabit Ethernet interface on
slot 2, port 0, subinterface 1
with S-VLAN ID 5 and VLAN
ID 6
gigabitEthernet 2/0.1:5-6
Gigabit Ethernet interface on
slot 4, adapter 1, port 1,
subinterface 3 with S-VLAN
ID 10 and VLAN ID 20
gigabitEthernet 4/1/1.3:10-20
eth 2/0/0:4096.5
eth 4/1/1:4096.10
eth 2/0/0:5.6
eth 4/1/1:10.20
Use by RADIUS or L2TP
Enabling the router to capture and format the PPPoE remote circuit ID sent from the
DSLAM has no effect by itself. To use the PPPoE remote circuit ID value, you must send
it to a RADIUS server, to an L2TP network server (LNS), or to both by doing one or more
of the following:
•
Issue the radius override calling-station-id remote-circuit-id command to substitute
the remote circuit ID value for the standard Calling-Station-Id [31] RADIUS attribute.
•
Issue the radius override nas-port-id remote-circuit-id command to substitute the
remote circuit ID value for the standard NAS-Port-Id [87] RADIUS attribute.
•
Issue the aaa tunnel calling-number-format command to generate L2TP Calling
Number attribute value pair (AVP) 22 in a descriptive format that includes either or
both of the agent-circuit-id (suboption 1) and agent-remote-id (suboption 2) suboptions
of the PPPoE intermediate agent tags.
Copyright © 2010, Juniper Networks, Inc.
379
JunosE 11.3.x Link Layer Configuration Guide
For more information about configuring RADIUS and L2TP on E Series routers, see the
JunosE Broadband Access Configuration Guide.
System Event Log
You can use the radiusSendAttributes system event log category to troubleshoot
applications that use PPPoE remote circuit ID capture. The radiusSendAttributes event
category logs RADIUS attributes added to outbound RADIUS requests.
You can also use the log severity debug pppoeControlPacket command to configure a
packet trace log for a PPPoE interface that includes the PPPoE remote circuit ID value
captured on that interface. For information about how to use the log severity debug
pppoeControlPacket command, see “Troubleshooting” on page 435.
For information about how to log system events, see Overview of System Logging.
PPPoE MTU Configuration
To avoid fragmentation and reassembly, Ethernet access networks require larger MTU
sizes for PPP traffic. With JunosE PPPoE MTU, you can control the deployment of larger
packet sizes. You can configure PPPoE MTU directly on the PPPoE interface or use a
dynamic configuration profile. When you use the PPPoE MTU tag, each PPPoE
subinterface can have a unique MTU value. Operational MTU is the lesser of the PPPoE
MTU or the lower layer MTU minus the PPPoE overhead.
You can use the pppoe mtu command to set the MTU using a combination of lower layer
restrictions and controls:
•
Greater MTU than the current maximum permitted by RFC 2516, with the default equal
to the current maximum setting (1494 octets)
•
Optional setting for absolute maximum PPPoE MTU
•
Optional use of a larger lower layer MTU
•
Optional use of the PPPoE-Max-Mtu tag transmitted from the client
Platform Considerations
You can configure PPPoE interfaces on the following E Series Broadband Services Routers:
380
•
E120 router
•
E320 router
•
ERX1440 router
•
ERX1410 router
•
ERX710 router
•
ERX705 router
•
ERX310 router
Copyright © 2010, Juniper Networks, Inc.
Chapter 12: Configuring Point-to-Point Protocol over Ethernet
Module Requirements
For information about the modules that support PPPoE interfaces on ERX14xx models,
ERX7xx models, and the ERX310 router:
•
See ERX Module Guide, Table 1, Module Combinations for detailed module specifications.
•
See ERX Module Guide, Appendix A, Module Protocol Support for information about the
modules that support PPPoE.
For information about the modules that support PPPoE interfaces on the E120 and E320
routers:
•
See E120 and E320 Module Guide, Table 1, Modules and IOAs for detailed module
specifications.
•
See E120 and E320 Module Guide, Appendix A, IOA Protocol Support for information
about the modules that support PPPoE.
Interface Specifiers
The configuration task examples in this chapter use the slot/port[.subinterface ] format
to specify the physical interface on which you want to configure PPPoE. However, the
interface specifier format that you use depends on the router that you are using.
For ERX7xx models, ERX14xx models, and ERX310 router, use the slot/port[.subinterface
] format. For example, the following command specifies ATM 1483 subinterface 10 on
slot 0, port 1 of an ERX7xx model, ERX14xx model, or ERX310 router.
host1(config)#interface atm 0/1.10
For E120 and E320 routers, use the slot/adapter/port[.subinterface ] format, which includes
an identifier for the bay in which the I/O adapter (IOA) resides. In the software, adapter
0 identifies the right IOA bay (E120 router) and the upper IOA bay (E320 router); adapter
1 identifies the left IOA bay (E120 router) and the lower IOA bay (E320 router). For
example, the following command specifies ATM 1483 subinterface 20 on slot 5, adapter
0, port 0 of an E320 router.
host1(config)#interface atm 5/0/0.20
For more information about supported interface types and specifiers on E Series routers,
see Interface Types and Specifiers in JunosE Command Reference Guide.
References
For more information about PPPoE, consult the following resources:
•
DSL Forum Technical Report (TR)-101—Migration to Ethernet-Based DSL Aggregation
(April 2006)
•
Extensions to a Method for Transmitting PPP over Ethernet
(PPPoE)—draft-carrel-info-pppoe-ext-00.txt (November 2000 expiration)
Copyright © 2010, Juniper Networks, Inc.
381
JunosE 11.3.x Link Layer Configuration Guide
•
IEEE 802.1q (Virtual LANs)
•
RFC 2516—Method for Transmitting PPP over Ethernet (PPPoE) (February 1998)
NOTE: IETF drafts are valid for only 6 months from the date of issuance.
They must be considered as works in progress. Please refer to the IETF
Web site at http://www.ietf.org for the latest drafts.
Access Nodes in Ethernet Aggregation Networks Overview
The access node is the first aggregation point in the digital subscriber line (DSL) access
network and apart from terminating the DSL physical layer signals, it also terminates the
user ATM layer. The access node contains an Ethernet uplink to provide connectivity to
the aggregation network. When ATM is supported on the DSL line, the access node
provisions an interworking function between the ATM layer on the user side and the
Ethernet layer on the network side, encompassing protocol translation, access loop
identification, QoS, security, and OAM attributes. This functionality might require the
access node to snoop, modify, or terminate protocols in layers above the ATM Adaptation
Layer 5 (AAL5) encapsulation. The access node operates as an Ethernet switch, while
it also offers enhanced functionality for protocol interworking, multicast support, and
customization for support of access networks (such as ARP and IGMP processing, and
user identification and isolation).
The subscriber's access node indicates to the B-RAS application running on the router
whenever a PPPoE session carries interworked PPPoA or PPPoE over ATM traffic. This
indication enables the B-RAS application to modify its behavior for interworked PPPoE
sessions. To denote that a PPPoE session contains interworked traffic, the PPPoE client
or the host includes the IWF-Session DSL Forum VSA (26-254) in the unicast PPPoE
Active Discovery Request (PADR) packet that it transmits to the PPPoE access
concentrator to which it wants to connect.
ATM-to-Ethernet Interworking Overview
In the ATM-to-Ethernet IWF topology, each ATM virtual path identifier (VPI) or virtual
circuit identifier (VCI) is mapped to a corresponding stacked Ethernet Virtual Local Area
Network (VLAN). When this feature is used, the ATM packets are translated into Ethernet
packets through mapping between an ATM link and an Ethernet link. The VPI of ATM
packets is mapped to the external stacked VLAN (S-VLAN) tag, and the VCI of ATM
packets is mapped to the internal customer VLAN (C-VLAN) tag, thereby enabling the
transmission of ATM packets over Ethernet links. VPI and VCI are mapped to double tags.
The inner and outer SVLAN tags identify ATM digital subscriber line access multiplexer
(DSLAM) device information and user information, respectively. After the PPPoE
authentication packet reaches B-RAS, B-RAS can authenticate based on user account,
device information (the outer tag), and user information (the inner tag). In this way,
account hacking can be avoided in terms of security.
The DSL Forum defined the IWF to devise the process for conversion of PPP over ATM
(PPPoA) and PPPoE over ATM sessions to PPPoE sessions at the DSLAM to the B-RAS
382
Copyright © 2010, Juniper Networks, Inc.
Chapter 12: Configuring Point-to-Point Protocol over Ethernet
application running on routers. This functionality was defined to enable DSL access
infrastructure in networks worldwide to migrate from ATM to Ethernet-based connections.
IWF is a set of mechanisms required to interlink two networks of different technologies.
IWF is used to describe the PPPoA conversion to PPPoE sessions at the DSLAM. These
mechanisms include conversion of PDU framing, addressing policies, priority mapping,
security mechanisms, and OAM flows. In ATM-to-Ethernet interworking circuits, the
PPPoA session that arrives at the DSLAM over ATM from a customer premises equipment
(CPE) or access loop is converted to a PPPoE session at the DSLAM. This PPPoE session
is then continued to be transmitted to the PPPoE access concentrator to B-RAS as a
PPPoE session. Every PPPoA session is associated with a corresponding PPPoE session.
A PPPoE session from the DSLAM to the B-RAS that is actually a PPPoA session from
the end user to the DSLAM is referred to as an IWF PPPoE session. The B-RAS application
is configured to limit PPPoE sessions that originate from the same MAC address to protect
itself from a denial of service (DoS) attack. This restriction on maximum number of
PPPoE client sessions poses a problem for IWF PPPoE sessions because all PPPoE
sessions contain the same MAC address of the DSLAM.
To avoid this problem, the PPPoE client inserts the IWF PPPoE tag in the PADR packet
to the PPPoE access concentrator to which it wants to connect. The B-RAS application
uses the IWF PPPoE tag to distinguish between an IWF PPPoE session and a regular,
non-IWF PPPoE session during the PPPoE discovery stage. The IWF PPPoE tag enables
the B-RAS application running on E Series routers to distinguish the IWF PPPoE session
from the regular PPPoE sessions to overcome the limit on the B-RAS the maximum
number of PPPoE sessions per MAC address as a protection from DoS attacks sourced
from the same MAC address. For more information about ATM-to-Ethernet interworking
functions, see the DSL Forum Technical Report 101: Migration to Ethernet-Based DSL
Aggregation.
These ATM-to-Ethernet interworking circuits can be mapped to individual logical
interfaces configured on an ATM, Gigabit Ethernet, or 10-Gigabit Ethernet physical
interface. The ATM-to-Ethernet interworking cross-connect essentially provides Layer
2 switching, and statistics are reported at the logical interface level.
During the conversion from ATM to Ethernet, the least significant 12 bits of the ATM cell
VCI are copied to the Ethernet frame inner VLAN tag. Cells received on an ATM logical
interface configured with the ATM-to-Ethernet interworking encapsulation type and
falling within the configured VCI range are reassembled into packets. These packets are
forwarded to a designated Ethernet logical interface that is configured with the
ATM-to-Ethernet interworking encapsulation type.
During the conversion from Ethernet to ATM, the Ethernet frame inner VLAN tags that
fall within the configured range are copied to the least significant 12 bits of the ATM cell
VCI. The ATM logical interface uses its configured VPI when segmenting the Ethernet
packets into cells. ATM-to-Ethernet interworking is supported on E Series routers with
aggregated Ethernet, Gigabit Ethernet, and 10-Gigabit Ethernet interfaces.
Copyright © 2010, Juniper Networks, Inc.
383
JunosE 11.3.x Link Layer Configuration Guide
Before You Configure PPPoE
Before you attempt to configure a PPPoE interface, configure the physical interface over
which PPPoE traffic will flow. The procedures described in this chapter assume that a
physical interface has been configured.
Configuring PPPoE over ATM
This section provides an example of a common PPPoE over ATM configuration.
See the following resources for additional information:
•
“Configuring ATM” on page 3—Provides detailed information about ATM technology
and line interface module capabilities.
•
“Configuring Bridged Ethernet” on page 443—Provides configuration information about
Bridged Ethernet, which allows multiple upper-layer interface types (IP and PPPoE)
to be simultaneously multiplexed over the same interface.
•
“Configuring Dynamic Interfaces” on page 511—Provides detailed information about
configuring ATM to support dynamic interfaces.
•
Configuring Upper-Layer Protocols over Static Ethernet Interfaces on page 151
To configure PPPoE over ATM:
1.
Configure a physical interface.
host1(config)#interface atm 0/1
2. Configure the ATM 1483 subinterface.
host1(config-if)#interface atm 0/1.20
3. Configure a PVC by specifying the vcd (virtual circuit descriptor), the vpi (virtual path
identifier), the vci (virtual channel identifier), and the encapsulation type.
host1(config-if)#atm pvc 10 22 100 aal5snap
4. Select PPPoE as the encapsulation method.
host1(config-subif)#encapsulation pppoe
5. Do one of the following to configure the maximum number of PPPoE sessions
(subinterfaces) supported on the interface:
•
Configure the maximum number of PPPoE sessions on a per-interface basis.
host1(config-if)#pppoe sessions 128
•
Configure the maximum number of PPPoE sessions on a per-subscriber basis by
overriding the current PPPoE maximum session value with the PPPoE maximum
session value returned by the RADIUS server in the Max-Clients-Per-Interface
vendor-specific attribute (VSA) [26-143] in Access-Accept messages.
host1(config-if)#pppoe max-session-vsa override
6. Create a PPPoE subinterface.
384
Copyright © 2010, Juniper Networks, Inc.
Chapter 12: Configuring Point-to-Point Protocol over Ethernet
host1(config-subif)#interface atm 0/1.20.1
7. Select PPP as the encapsulation method.
host1(config-subif)#encapsulation ppp
8. (Optional) Configure maximum transfer unit (MTU) parameters.
host1(config-if)#pppoe mtu 1380
9. (Optional) Configure an access concentrator (AC) name on the PPPoE interface.
host1(config-subif)#pppoe acname CYM9876
10. (Optional) Set up the router to prevent a client from establishing more than one
session using the same MAC address.
When the duplicate protection feature is enabled, multiple IWF PPPoE sessions that
contain the same MAC address are still processed and can access network services
until the maximum number of PPPoE sessions configured per major interface
(configured using the pppoe sessions command) is reached. For more information
about how IWF PPPoE sessions with duplicate addresses are handled, see “Processing
of IWF PPPoE Sessions with Duplicate MAC Addresses” on page 391.
host1(config-subif)#pppoe duplicate-protection
11. Assign an IP address and subnet mask to the PVC.
host1(config-subif)#ip address 192.32.10.20 255.255.255.0
12. (Optional) Configure additional PPPoE subinterfaces by completing Steps 6 through
11 using unique numbering.
host1(config-subif)#interface atm 0/1.20.2
pppoe max-session-vsa
•
Use to override the current PPPoE maximum session value set with the pppoe sessions
command with the PPPoE maximum session value returned by the RADIUS server in
the Max-Clients-Per-Interface VSA [26-143].
•
RADIUS returns the Max-Clients-Per-Interface VSA value in Access-Accept messages
for each subscriber during PPP authentication.
•
By default, the router ignores the PPPoE maximum session value returned by RADIUS.
•
The router never overrides the maximum number of PPPoE subinterfaces supported
per line module with a value from RADIUS that is either 0 (zero) or greater than the
maximum number of supported PPPoE subinterfaces. For example, if the maximum
number of PPPoE subinterfaces supported for a particular line module is 8000 and
the PPPoE maximum session value returned by RADIUS is 0 (zero) or greater than
8000, the RADIUS value in this case is ignored.
See JunosE Release Notes, Appendix A, System Maximums corresponding to your
software release for information about the maximum number of PPPoE subinterfaces
supported for each line module.
Copyright © 2010, Juniper Networks, Inc.
385
JunosE 11.3.x Link Layer Configuration Guide
•
The following rules apply if you configure the router to override the current PPPoE
maximum session value for the interface with the PPPoE maximum session value
returned by RADIUS in the Max-Clients-Per-Interface VSA:
•
If the current PPPoE maximum session value is less than the PPPoE maximum session
value returned by RADIUS, the PPPoE application overrides the current maximum
session value with the value returned by RADIUS and proceeds with creation of the
PPPoE interface.
•
If the current number of active PPPoE sessions, including the current session, is
greater than the PPPoE maximum session value returned by RADIUS, PPPoE ignores
(drops) the new session.
•
If the current number of active PPPoE sessions is less than or equal to the PPPoE
maximum session value returned by RADIUS, PPPoE proceeds with creation of the
PPPoE interface.
The following table shows examples of the PPPoE maximum session value when a
new subscriber logs in, and indicates the status of the current session.
•
PPPoE
Maximum
Session
Value from
RADIUS
Current
PPPoE
Maximum
Session
Value
Existing
Number of
PPPoE
Sessions
New PPPoE
Maximum
Session
Value
New
Number of
PPPoE
Sessions
10
5
4
10
5
PPP session
up
3
5
4
3
5
PPP/PPPoE
session down
5
5
4
5
5
PPP session
up
Status of
Session
Example
host1(config-if)#pppoe max-session-vsa override
•
Use the no version to restore the default behavior, ignore.
•
See pppoe max-session-vsa.
Figure 38 on page 387 illustrates the interface stack for this configuration.
386
Copyright © 2010, Juniper Networks, Inc.
Chapter 12: Configuring Point-to-Point Protocol over Ethernet
Figure 38: Example of PPPoE over ATM Stacking
atm pvc
•
Use to configure a PVC on an ATM interface.
•
The following parameters are mandatory:
•
•
vcd —Virtual circuit descriptor, which identifies a virtual circuit in the range
1–2147483647. The vcd is a unique number that you assign, which identifies a virtual
circuit. The vcd value has no relationship to the vpi and vci values and has meaning
only to the E Series router.
•
vpi—Virtual path identifier of the PVC. The VPI is an 8-bit field in the ATM cell header.
The VPI value is unique on a single link, not throughout the ATM network, because
it has meaning only to the E Series router. The VPI value must match the value on
the switch. The parameters vpi and vci cannot be both set to 0; if one is 0, the other
cannot be 0.
•
vci —Virtual channel identifier. The VCI is a 16-bit field in the ATM cell header. The
VCI value is unique on a single link, not throughout the ATM network, because it has
meaning only to the E Series router. The parameters vpi and vci cannot be both set
to 0; if one is 0, the other cannot be 0.
•
encapsulation type:
•
aal5snap—Specifies a logical link control (LLC) encapsulated circuit. An
LLC/Subnetwork Access Protocol (LLC/SNAP) header precedes the protocol
datagram.
•
aal5mux ip—Specifies a multiplexed circuit used for IP only.
•
aal5autoconfig—Enables the autodetection of a 1483 encapsulation (LLC/SNAP
or VC multiplexed).
Example
Copyright © 2010, Juniper Networks, Inc.
387
JunosE 11.3.x Link Layer Configuration Guide
host1(config-if)#atm pvc 10 100 22 aal5autoconfig
•
Use the no version to remove the specified PVC.
•
See atm pvc.
•
Use to specify PPP as the encapsulation method for the interface.
•
Example
encapsulation ppp
host1(config-subif)#encapsulation ppp
•
Use the no version to disable PPP on an interface.
•
See encapsulation ppp.
•
Use to specify PPPoE as the encapsulation method for the interface.
•
Example
encapsulation pppoe
host1(config-subif)#encapsulation pppoe
•
Use the no version to disable PPPoE on an interface.
•
See encapsulation pppoe.
•
Use to configure an ATM interface.
•
To specify an ATM interface for ERX7xx models, ERX14xx models, and ERX310 router,
use the slot/port.[subinterface ] format.
interface atm
•
388
•
slot—Number of the chassis slot
•
port—Port number on the I/O module
•
subinterface—Number of the subinterface in the range 1–2147483647
To specify an ATM interface for E120 and E320 routers, use the
slot/adapter/port[.subinterface ] format.
•
slot—Number of the chassis slot
•
adapter—Identifier for the IOA within the E320 chassis, either 0 or 1, where:
•
0 indicates that the IOA is installed in the right IOA bay (E120 router) or the upper
IOA bay (E320 router).
•
1 indicates that the IOA is installed in the left IOA bay (E120 router) or the lower
IOA bay (E320 router).
•
port—Port number on the IOA
•
subinterface—Number of the subinterface in the range 1–2147483647
Copyright © 2010, Juniper Networks, Inc.
Chapter 12: Configuring Point-to-Point Protocol over Ethernet
•
For more information, see “Creating a Basic Configuration” on page 21 in “Configuring
ATM” on page 3.
•
Examples
host1(config)#interface atm 0/1.19
host1(config)#interface atm 0/0/1.19
•
Use the no version to remove the interface or subinterface.
•
See interface atm.
•
Use to assign an IP address and subnet mask to a subinterface.
•
Example
ip address
host1(config-if)#ip address 192.1.1.1 255.255.255.0
•
Use the no version to remove an IP address or disable IP processing.
•
See ip address.
•
Use to configure an access concentrator (AC) name on the PPPoE interface. When
the AC (the server) receives a PPPoE Active Discovery Initiation (PADI) packet that it
can serve, it replies by sending a PPPoE Active Discovery Offer (PADO) packet. The
PADO packet contains the AC name configured using this command.
•
If the AC name is not configured, the router name is used.
•
The AC name can be a maximum of 64 characters.
•
Example
pppoe acName
host1(config-subif)#pppoe acName CYM9876
•
Use the no version to remove the AC name.
•
See pppoe acName.
pppoe duplicate-protection
•
Use to prevent a client from establishing more than one session using the same MAC
address.
•
This feature is disabled by default.
•
For PPPoE sessions that contain the IWF-Session DSL Forum VSA (26-254) in the
PADR packets sent from the client to the PPPoE access concentrator, multiple
subscriber sessions with the same MAC address can originate. This behavior occurs
because the interworking functionality (IWF) causes a PPPoE over ATM or PPP over
ATM (PPPoA) session to be converted by the digital subscriber line access multiplexer
(DSLAM) into a PPPoE session. As a result of this conversion, the MAC addresses of
all IWF PPPoE sessions contain the MAC address of the DSLAM device.
For PPPoE sessions with the IWF-Session VSA, duplication of MAC addresses is
permitted by default. Regardless of whether the duplicate protection feature is enabled,
Copyright © 2010, Juniper Networks, Inc.
389
JunosE 11.3.x Link Layer Configuration Guide
multiple IWF PPPoE sessions with the same MAC address (the address of the DSLAM
device) are not terminated until the limit on the maximum number of PPPoE sessions
configured on the major interface is reached.
See “Guidelines for Configuring Duplicate Protection for IWF PPPoE Sessions” on
page 391 for a list of considerations to be observed when you use the duplicate protection
feature for IWF PPPoE sessions.
•
Example
host1(config-subif)#pppoe duplicate-protection
•
Use the no version to disable duplicate protection.
•
See pppoe duplicate-protection.
•
Use to set the MTU using a combination of lower layer restrictions and controls.
•
You can specify an MTU greater than the current maximum permitted by RFC 2516, in
the range 66–65535.
•
You can use the use-lower-layer keyword to use the lower layer interface value minus
any PPPoE overhead. You can use the use-mtu-tag keyword to use the provided PPPoE
mtu tag value.
•
Example
pppoe mtu
host1(config-profile)#pppoe mtu 1380
•
Use the no version to restore the default value, 1494.
•
See pppoe mtu.
•
Use to specify the maximum number of PPPoE subinterfaces permitted on an interface,
in the range 1–8000 (ERX routers) or 1–32,000 (E120 and E320 router). On the ES2
10G ADV LM (E120 and E320 router), you can have PPPoE subinterfaces in the range
1–32000. The default value is 8000 (ERX routers) or 16,000 (E120 and E320 router)
or 32,000 (ES2 10G ADV LM).
•
The pppoe sessions command affects only those subinterfaces that you create after
issuing this command. Previously created interfaces remain, even if their number
exceeds the new value for pppoe sessions.
pppoe sessions
NOTE: The number of subinterfaces permitted on the interface for E120
and E320 routers is in the range 1–32,000 irrespective of the type of line
module. However, if you specify a value greater than the number of
subinterfaces supported by a line module, the number of subinterfaces
created is the default maximum value for that line module. For example,
if you specify the number of subinterfaces for the ES2 4G LM as 32,000
interfaces, the number of subinterfaces created is 16,000 which is the
default maximum value for the ES2 4G LM.
390
Copyright © 2010, Juniper Networks, Inc.
Chapter 12: Configuring Point-to-Point Protocol over Ethernet
•
Example
host1(config-if)#pppoe sessions 128
•
Use the no version to restore the default value, 8000 (ERX routers) or 16,000 (E120
and E320 routers) or 32,000 (ES2 10G ADV LM).
•
See pppoe sessions.
Processing of IWF PPPoE Sessions with Duplicate MAC Addresses
JunosE Software supports detection of PPPoE sessions with duplicate MAC addresses
that contain interworking function (IWF) tags. The IWF feature performs a set of
operations on a subscriber’s session to enable the transport of PPPoE over ATM traffic
on a PPPoE interface.
PPPoE supports duplicate detection based on MAC addresses to prevent spoofed MAC
addresses and to avoid unauthorized users from attempting to use the MAC address of
another valid user. When duplicate protection is configured for the underlying interface,
a dynamic PPPoE logical interface cannot be activated when an existing active logical
interface is present for the same PPPoE client. This mechanism prevents an unauthorized
user to deny or disrupt service to a legitimate user.
Although duplicate protection of PPPoE sessions with the same MAC address enables
prevention of unauthorized access to resources, there might be scenarios in interworked
PPPoE sessions in which multiple sessions that originate from the same MAC address
are required for access to network services and applications. In this release, you can
enable multiple PPPoE sessions with the same MAC address that contain the IWF tag
to be established. This feature is useful for IWF PPPoE sessions because of a number of
such sessions contain the same MAC address of the DSLAM at which multiplexing and
conversion functions are performed.
Guidelines for Configuring Duplicate Protection for IWF PPPoE Sessions
Keep the following points in mind when you configure duplicate protection for IWF PPPoE
sessions:
•
In most environments, a 1:1 relationship between the DSLAM and PPPoE access
concentrator is present. In such situations, all IWF sessions demultiplexed at any PPPoE
access concentrator are required to contain the same source MAC address. In
deployments where IWF sessions originate from multiple MAC addresses (because of
multiple DSLAMs used to demultiplex subscriber sessions) and no VLAN grouping of
VLAN IDs is configured, IWF sessions are not limited per source MAC address.
•
If a user spoofs the IWF-Session VSA in a PPPoE PADR that originates from the PPPoE
client or access loop for a non-IWF session, this user might be able to bypass the
duplicate protection setting configured on the router. The PPPoE access concentrator
cannot detect such spoofing when the interworking functionality is activated.
•
Table 22 on page 392 describes the different scenarios in which duplicate MAC addresses
are supported for IWF PPPoE sessions and non-IWF PPPoE sessions, when duplicate
protection configuration is enabled or disabled on a router.
Copyright © 2010, Juniper Networks, Inc.
391
JunosE 11.3.x Link Layer Configuration Guide
Table 22: PPPoE Duplicate Protection Scenarios for IWF and non-IWF
PPPoE Sessions
Duplicate Protection
Disabled
Type of PPPoE Session
Duplicate Protection Enabled
IWF PPPoE session
(IWF-Session DSL VSA
contained in the PADR
packet)
Sessions with duplicate MAC
addresses are processed until the
maximum number of PPPoE
sessions configured per major
interface is reached.
Sessions with duplicate
MAC addresses are
processed.
Non-IWF PPPoE session
(IWF-Session DSL VSA not
contained in the PADR packet
)
Sessions with duplicate MAC
addresses are terminated and
cannot access network resources
Sessions with duplicate
MAC addresses are
processed.
Configuration Examples for ATM-to-Ethernet Interworking Functions
The following sections describe sample configuration cases to illustrate how the
interworking functions are performed when a 1:1 and an N:1 association exists between
DSLAMs and the PPPoE access concentrator (B-RAS application):
•
Single DSLAM Connected to a PPPoE Access Concentrator Example on page 392
•
Multiple DSLAMs Connected to a PPPoE Access Concentrator Example on page 393
Single DSLAM Connected to a PPPoE Access Concentrator Example
Consider a topology in which a DSLAM multiplexes multiple PPPoE over ATM sessions
over the Ethernet aggregate network using interworking functionality between PPPoE
over ATM and PPPoE. Figure 39 on page 393 shows a sample configuration scenario in
which one DSLAM is connected to one PPPoE access concentrator. The subscriber access
nodes are connected using ATM links to the DSLAMs. In this circuit, a 1:1 relationship exists
between the DSLAM and the PPPoE access concentrator (PPPoE major interface).
Because of the presence of a 1:1 association between the DSLAM and the access
concentrator, segregation of VLAN IDs is not required. A one-to-one mapping is configured
between the user port and VLAN. The access node is assigned a unique VLAN identification
to a port using either a unique S-VLAN ID or a unique (S-VLAN ID, C-VLAN ID) pair. The
uniqueness of the mapping is maintained in the access node and across the aggregation
network. The B-RAS PPPoE access concentrator demultiplexes the PPPoE sessions.
392
Copyright © 2010, Juniper Networks, Inc.
Chapter 12: Configuring Point-to-Point Protocol over Ethernet
Figure 39: Single DSLAM Connected to a PPPoE Access Concentrator
Fast Ethernet or
Gigabit Ethernet
ATM
Layer 2 switch
DSLAM
Gigabit Ethernet
Layer 3 switch
Layer 2 switch
g016524
Layer 2 switch
B-RAS
In such a case, the PPPoE access concentrator uses the maximum number of
subinterfaces configured on a PPPoE interface using the pppoe sessions command to
limit the maximum number of IWF PPPoE sessions. The B-RAS tracks the IWF flag in a
PPPoE PADR packet it receives from the access concentrator, which the PPPoE client
forwarded to the access concentrator during the discovery stage. The presence of the
IWF tag causes the PPPoE access concentrator to accept duplicate PPPoE sessions with
the same MAC address of the DSLAM are permitted by default. The suboption for the
IWF-Session DSL Forum VSA (26-254) contains the field code of 0xFE in PADR packet
and its length field is set to 0x00.
Multiple DSLAMs Connected to a PPPoE Access Concentrator Example
Consider another scenario in which the access node assigns the same S-VLAN ID to a
group of ports. Figure 40 on page 394 shows a sample configuration scenario in which
multiple DSLAMs are connected to a single PPPoE access concentrator. This configuration
pattern is denoted as N:1 VLAN to indicate many-to-one mapping between ports and
VLAN. Sample criteria for grouping multiple ports with the same S-VLAN ID comprise
the same originating virtual path, same service, or same destination service provider. In
this topology, multiple DSLAMs, which aggregate sessions from multiple PPPoE clients,
are connected to one access concentrator.
Copyright © 2010, Juniper Networks, Inc.
393
JunosE 11.3.x Link Layer Configuration Guide
Figure 40: Multiple DSLAMs Connected to a PPPoE Access Concentrator
Layer 2 switch
VLAN ID = 1
ATM
DSLAM
VLAN ID = 1, 2, 3
Fast Ethernet or
Gigabit Ethernet
Gigabit Ethernet
Layer 2 switch
ATM
B-RAS
Layer 3 switch
VLAN ID = 2
DSLAM
Layer 2 switch
DSLAM
g016523
VLAN ID = 3
ATM
Although in such a scenario, in which a N:1 DSLAM and PPPoE access concentrator
relationship is exhibited, normally a VLAN grouping is performed to segregate the traffic
from each DSLAM. Such a grouping of VLAN IDs is a regular network administration
practice. If such a grouping of VLAN IDs is made, a 1:1 relationship between DSLAM and
the PPPoE access concentrator is created that enables each access concentrator to
serve a VLAN group.
Configuring PPPoE for Ethernet Modules
You can configure PPPoE on Fast Ethernet (FE), Gigabit Ethernet (GE), and 10-Gigabit
Ethernet (10GE) modules. You can configure Ethernet interfaces with IP only, with PPPoE
only, with both IP and PPPoE, and with or without VLANs.
This section provides information about configuring PPPoE without VLANs. If you want
to configure PPPoE with VLANs, see “Configuring VLAN and S-VLAN Subinterfaces” on
page 167, which shows common VLAN configurations such as:
•
PPPoE over VLAN
•
IP over VLAN and PPPoE over VLAN
NOTE: “Configuring VLAN and S-VLAN Subinterfaces” on page 167 provides
other non-VLAN configuration examples, such as configurations using
MPLS.
For more information about specific Ethernet modules and the protocols and applications
they support, see:
•
394
ERX Module Guide, Appendix A, Module Protocol Support (for ERX7xx models, ERX14xx
models, and ERX310 router)
Copyright © 2010, Juniper Networks, Inc.
Chapter 12: Configuring Point-to-Point Protocol over Ethernet
•
E120 and E320 Module Guide, Appendix A, IOA Protocol Support (for E120 and E320
routers)
PPPoE Interface and Subinterface Limits
PPPoE subinterfaces can be distributed in any way across I/O module ports. For example,
you can configure the maximum supported number of PPPoE subinterfaces on one port
of an FE-2 I/O module and no PPPoE subinterfaces on the other port.
For information about current system maximums supported for PPPoE interfaces and
subinterfaces, see JunosE Release Notes, Appendix A, System Maximums.
Configuring IPv4 and IPv6 over PPPoE with VLAN
You can configure IPv4 and IPv6 interface columns over static PPPoE, as shown in Figure
41 on page 395.
Figure 41: Example of Configuring IPv4 and IPv6 over PPPoE
IPv4
IPv4
IPv6
PPP interface
PPP interface
PPPoE subinterface
PPPoE subinterface
PPPoE interface
Gigabit Ethernet
g016516
VLAN
To configure IPv4 and IPv6 interface columns over static PPPoE:
1.
Specify a Fast Ethernet, Gigabit Ethernet, or 10-Gigabit Ethernet interface.
host1(config)#interface gigabitEthernet 2/0/1
2. Specify VLAN as the encapsulation method.
host1(config-if)#encapsulation vlan
The VLAN major interface is added.
3. Create a VLAN subinterface by adding a subinterface number to the interface
identification command.
host1(config-if)#interface gigabitEthernet 2/0/1.1
4. Assign a VLAN ID for the subinterface.
host1(config-if)#vlan id 1
5. Create a PPPoE subinterface.
Copyright © 2010, Juniper Networks, Inc.
395
JunosE 11.3.x Link Layer Configuration Guide
host1(config-if)#pppoe
6. Specify PPPoE as the encapsulation method on the interface.
host1(config-if)#pppoe subinterface gigabitEthernet 2/0/1.1.1
host1(config-if)#encapsulation ppp
7. Specify the order of preference for the primary authentication protocol.
host1(config-if)#ppp authentication pap chap eap
8. Enable IPv6 processing on an interface without assigning an explicit IPv6 address to
that interface.
host1(config-if)#ipv6 unnumbered loopback 0
9. Enable the IPv6 Neighbor Discovery process on an interface.
host1(config-if)#ipv6 nd
10. Specify which IPv6 prefixes the system includes in IPv6 router advertisements.
host1(config-if)#ipv6 nd prefix-advertisement 2002:1::/64 60000 45000 onlink
autoconfig
11. (Optional) Configure additional VLAN subinterfaces by completing Steps 3 through
10.
encapsulation ppp
•
Use to specify PPP as the encapsulation method for the interface.
•
Example
host1(config-if)#encapsulation ppp
•
Use the no version to disable PPP on an interface.
•
See encapsulation ppp.
•
Use to configure VLAN as the encapsulation method for the interface.
•
Example
encapsulation vlan
host1(config-if)#encapsulation vlan
•
Use the no version to disable VLAN on an interface.
•
See encapsulation vlan.
•
Use to add an IPv6 address to an interface or a subinterface.
•
Example
ipv6 address
host1(config)#interface gigabitEthernet 1/0.25
host1(config-if)#ipv6 address 1::1/64
396
•
Use the no version to remove an IPv6 address.
•
See ipv6 address
Copyright © 2010, Juniper Networks, Inc.
Chapter 12: Configuring Point-to-Point Protocol over Ethernet
ipv6 nd
•
Use to enable the IPv6 Neighbor Discovery process on an interface.
•
You can include the following commands in IPv6 profiles to configure Neighbor
Discovery route advertisement characteristics.
•
Command
Description
ipv6 nd
Enables Neighbor Discovery on an interface
ipv6 nd prefix-advertisement
Specifies IPv6 prefix included in IPv6 router advertisements
Example
host1(config)#profile ProfileIpv6South22
host1(config-profile)#ipv6 nd
•
Use the no version to disable the Neighbor Discovery process for the profile.
•
See ipv6 nd
•
Use to set up an unnumbered interface.
•
An unnumbered interface does not have an IPv6 address assigned to it. Unnumbered
interfaces are often used in point-to-point connections where an IPv6 address is not
required.
•
This command enables IPv6 processing on an interface without your having to assign
an explicit IPv6 address to the interface.
•
You supply an interface location that is the type and number of another interface on
which the router has an assigned IPv6 address. This interface cannot be another
unnumbered interface.
•
Example
ipv6 unnumbered
host1(config-if)#ipv6 unnumbered loopback 0
•
Use the no version to disable IPv6 processing on an interface.
•
See ipv6 unnumbered
•
Use to request authentication from a PPP peer and set the authentication method.
•
The router supports the MD5 authentication algorithm for CHAP authentication.
•
Example 1—Specifies the order of preference for the primary authentication protocol
ppp authentication
host1(config-if)#ppp authentication pap chap eap
The router requests the use of PAP as the authentication protocol (because it appears
first in the command line). If the peer refuses to use PAP, the router requests the CHAP
protocol. If the peer refuses to use CHAP, the router requests the EAP protocol. If the
peer refuses to negotiate authentication, the router terminates the PPP session.
Copyright © 2010, Juniper Networks, Inc.
397
JunosE 11.3.x Link Layer Configuration Guide
•
Example 2—Configures EAP or CHAP or PAP on a dynamic PPP interface
host1(config)#profile ppptest
host1(config-profile)#ppp authentication eap chap pap
In this example, the router first attempts EAP negotiation. If PPP receives a NAK from
the peer in response to the EAP request, then the router attempts CHAP negotiation.
If PPP receives a NAK from the peer in response to the CHAP request, then the router
attempts PAP negotiation. If PAP is also rejected, then PPP terminates the session.
•
Use the no version to specify that the router does not require authentication.
•
See ppp authentication.
•
Use to specify PPPoE as the encapsulation method for the interface.
•
This command creates a PPPoE major interface.
•
Example
pppoe
host1(config-if)#pppoe
•
Use the no version to remove the PPPoE major interface.
•
See pppoe.
•
Use to specify the VLAN ID.
•
Use a VLAN ID that is in the range 0–4095 and is unique within the Ethernet interface.
•
Examples
vlan id
host1(config-if)#vlan id 400
host1(config-if)#vlan id 4 255 mac-address 0090.1a01.1234
•
There is no no version.
•
See vlan id.
Configuring PPPoE Without VLANs
To configure PPPoE over an Ethernet interface without VLANs:
1.
Specify a Fast Ethernet, Gigabit Ethernet, or 10-Gigabit Ethernet interface.
host1(config)#interface fastEthernet 4/1
2. Specify PPPoE as the encapsulation method on the interface.
host1(config-if)#pppoe
3. Create a PPPoE subinterface.
host1(config-if)#pppoe subinterface fastEthernet 4/1.1
4. Specify PPP as the encapsulation method on the interface.
host1(config-subif)#encapsulation ppp
398
Copyright © 2010, Juniper Networks, Inc.
Chapter 12: Configuring Point-to-Point Protocol over Ethernet
5. (Optional) Configure an access concentrator (AC) name on the PPPoE interface.
host1(config-subif)#pppoe acname CYM9876
6. (Optional) Set up the router to prevent a client from establishing more than one
session using the same MAC address.
When the duplicate protection feature is enabled, multiple IWF PPPoE sessions (sent
from PPPoE clients to the PPPoE access concentrator) that contain the same MAC
address are still processed and can access network services until the maximum number
of PPPoE sessions configured per major interface (configured using the pppoe sessions
command) is reached.
host1(config-subif)#pppoe duplicate-protection
7. Assign an IP address and mask.
host1(config-if)#ip address 192.6.129.5 255.255.255.0
8. (Optional) Configure additional PPPoE subinterfaces by completing Steps 3 through
7 using unique numbering.
Figure 42 on page 399 illustrates the interface stack for this configuration.
Figure 42: Example of PPPoE Stacking
encapsulation ppp
•
Use to specify PPP as the encapsulation method for the interface.
•
Example
host1(config-if)#encapsulation ppp
•
Use the no version to disable PPP on an interface.
•
See encapsulation ppp.
•
Use to select a Fast Ethernet interface.
•
For more information, see chapter Configuring Ethernet Interfaces in JunosE Physical
Layer Configuration Guide.
•
Example
interface fastEthernet
Copyright © 2010, Juniper Networks, Inc.
399
JunosE 11.3.x Link Layer Configuration Guide
host1(config)#interface fastEthernet 1/0
•
Use the no version to remove IP from an interface or subinterface. You must issue the
no version from the highest level down; you cannot remove an interface or subinterface
if the one above it still exists.
•
See interface fastEthernet.
interface gigabitEthernet
interface tenGigabitEthernet
•
Use to select a Gigabit Ethernet interface or a 10-Gigabit Ethernet interface.
•
To specify a Gigabit Ethernet interface for ERX7xx models, ERX14xx models, and ERX310
router, use the slot/port[.subinterface ] format.
•
To specify a Gigabit Ethernet interface or 10-Gigabit Ethernet interface for E120 and
E320 routers, use the slot/adapter/port[.subinterface ] format.
•
For more information, see chapter Configuring Ethernet Interfaces in JunosE Physical
Layer Configuration Guide.
•
Examples
host1(config)#interface gigabitEthernet 1/0
host1(config)#interface gigabitEthernet 4/0/1 6.0.0FRS
host1(config)#interface tenGigabitEthernet 4/0/1
•
Use the no version to remove IP from an interface. You must issue the no version from
the highest level down; you cannot remove an interface or subinterface if the one above
it still exists.
•
See interface gigabitEthernet.
•
See interface tenGigabitEthernet.
•
Use to assign an IP address and subnet mask to an interface or subinterface.
•
Example
ip address
host1(config-if)#ip address 192.1.1.1 255.255.255.0
•
Use the no version to remove an IP address or disable IP processing.
•
See ip address.
•
Use to specify PPPoE as the encapsulation method for the interface.
•
This command creates a PPPoE major interface.
•
Example
pppoe
host1(config-if)#pppoe
400
Copyright © 2010, Juniper Networks, Inc.
Chapter 12: Configuring Point-to-Point Protocol over Ethernet
•
Use the no version to remove the PPPoE major interface.
•
See pppoe.
•
Use to configure an access concentrator (AC) name on the PPPoE interface. When
the AC (the server) receives a PPPoE Active Discovery Initiation (PADI) packet that it
can serve, it replies by sending a PPPoE Active Discovery Offer (PADO) packet. The
PADO packet contains the AC name configured using this command.
•
If the AC name is not configured, the router name is used.
•
The AC name can be a maximum of 64 characters.
•
Example
pppoe acName
host1(config-subif)#pppoe acName CYM9876
•
Use theno version to remove the AC name.
•
See pppoe acName.
pppoe duplicate-protection
•
Use to prevent a client from establishing more than one session using the same MAC
address.
•
This feature is disabled by default.
•
For PPPoE sessions that contain the IWF-Session DSL Forum VSA (26-254) in the
PADR packets sent from the client to the PPPoE access concentrator, multiple
subscriber sessions with the same MAC address can originate. This behavior occurs
because the interworking functionality (IWF) causes a PPPoE over ATM or PPP over
ATM (PPPoA) session to be converted by the digital subscriber line access multiplexer
(DSLAM) into a PPPoE session. As a result of this conversion, the MAC addresses of
all IWF PPPoE sessions contain the MAC address of the DSLAM device.
For PPPoE sessions with the IWF-Session VSA, duplication of MAC addresses is
configured by default. Regardless of whether the duplicate protection feature is enabled,
multiple IWF PPPoE sessions with the same MAC address (the address of the DSLAM
device) are not terminated until the limit on the maximum number of PPPoE sessions
configured on the major interface is reached.
See “Guidelines for Configuring Duplicate Protection for IWF PPPoE Sessions” on
page 391 for a list of considerations to be observed when you use the duplicate protection
feature for IWF PPPoE sessions.
•
Example
host1(config-subif)#pppoe duplicate-protection
•
Use the no version to disable duplicate protection.
•
See pppoe duplicate-protection.
pppoe subinterface fastEthernet
Copyright © 2010, Juniper Networks, Inc.
401
JunosE 11.3.x Link Layer Configuration Guide
•
Use to create a PPPoE subinterface on a Fast Ethernet module.
•
On ERX7xx models, ERX14xx models, and the ERX310 router, use the
slot/port/pppoeSubinterface format.
•
Example
host1(config)#pppoe subinterface fastEthernet 4/1.1
•
Use the no version to remove the PPPoE subinterface.
•
See pppoe subinterface.
Configuring PADM Messages
You can configure PPPoE to issue and display a PPPoE Active Discovery Message (PADM).
The PADM message is a control message that servers send to clients. The clients may
act on the control message, but are not required to do so. There are two types of PADM
messages:
•
Message of the minute (MOTM)—Informs clients of interesting system information
•
URL—Typically spawns an Internet browser with the specified URL as the initial page
You can configure the router to send PADM messages as follows:
•
Send MOTM messages to all clients connected to the router.
•
Send MOTM and URL messages to all clients connected to a subinterface.
•
Configure profiles to send MOTM and URL messages to new clients created when the
profile is dynamically attached to an IP interface.
NOTE: You can use the pppoe motm command at three different points
in the configuration process: Privileged Exec, Interface Configuration, and
Profile Configuration modes. You can use the pppoe url command at two
different points in the configuration process: Interface Configuration and
Profile Configuration modes. Note the differences described in guidelines
below.
pppoe motm
•
Use to cause the PPPoE application to send a PADM message of the minute (MOTM)
message to all PPPoE clients connected to the router. The MOTM string is passed with
no changes.
•
The message string is not saved in nonvolatile storage (NVS).
•
Use in Privileged Exec mode.
•
Example
host1#pppoe motm Router going down at 10:00 p.m.
402
Copyright © 2010, Juniper Networks, Inc.
Chapter 12: Configuring Point-to-Point Protocol over Ethernet
•
Use the no version to disable the message.
•
See pppoe motm.
•
Use in the context of a PPPoE subinterface to cause the PPPoE application to send
the specified PADM message to the client as it is configured (if connected).
•
The message is also sent whenever the subinterface transitions from down to up.
•
The message string is saved in nonvolatile storage (NVS).
•
Use in Interface Configuration mode.
•
Example
pppoe motm
host1(config-if)#interface fastEthernet 1/0.1.1
host1(config-if)#pppoe motm Router going down at 10:00 p.m.
•
Use the no version to disable the message.
•
See pppoe motm.
•
Use in a profile to cause the PPPoE application to send the string to the new client that
is created when the profile is dynamically attached to an IP interface.
•
The message string is saved in nonvolatile storage (NVS).
•
Use in Profile Configuration mode.
•
Example
pppoe motm
host1(config-profile)#pppoe motm Router going down now
•
Use the no version to disable the message.
•
See pppoe motm.
•
Use in the context of a PPPoE subinterface to cause the PPPoE application to send
the specified PADM message to the client as it is configured (if connected).
•
The message is also sent whenever the subinterface transitions from down to up.
•
The message string is saved in nonvolatile storage (NVS).
•
Use in Interface Configuration mode.
•
Example
pppoe url
host1(config-if)#interface fastEthernet 1/0.1.1
host1(config-if)#pppoe url http://www.relevanturl.com
•
Use the no version to disable the message.
•
See pppoe url.
pppoe url
Copyright © 2010, Juniper Networks, Inc.
403
JunosE 11.3.x Link Layer Configuration Guide
•
Use in a profile to cause the PPPoE application to send the string to the new client that
is created when the profile is dynamically attached to an IP interface.
•
The message string is saved in nonvolatile storage (NVS).
•
PPPoE substitutes the following characters for information in the specified URL string
before transmitting:
•
%U user and domain name
•
%u user name
•
%d domain name
•
%D profile name
•
%% % character
•
Use in Profile Configuration mode.
•
Example
host1(config-profile)#pppoe url http://www.relevanturl.com
•
Use the no version to disable the message.
•
See pppoe url.
Configuring PADN Messages
You can configure PPPoE to receive PPPoE Active Discovery Network (PADN) messages.
When a client connects to a PPPoE server, such as an E Series router, the client receives
configuration information from the server via the PADN message. This PADN information
associates the PPPoE sessions with a set of routes. The client can use this set of routes
to determine which session to use based on the destination IP address.
The PADN packet data is relevant only when the PPP network layer is “ up.” To reach an
up state, PPP alerts PPPoE after the Network Control Protocol (NCP) completes
negotiation.
The routes of interest can be maintained on the router in domain maps.
NOTE: For information about domain mapping, see JunosE Broadband Access
Configuration Guide.
aaa domain-map
•
Use to map a domain name between a PPP client’s domain name and a virtual router.
•
Example
host1(config)#aaa domain-map xyz.com
host1(config-domain-map)#padn 10.2.25.6 255.255.255.0 10
host1(config-domain-map)#padn 20.2.0.0 255.255.0.0 11
404
Copyright © 2010, Juniper Networks, Inc.
Chapter 12: Configuring Point-to-Point Protocol over Ethernet
•
Use the no version to delete the map entry.
•
See aaa domain-map.
•
Use to configure PADN parameters for a domain name.
•
You may send up to a maximum of 16 PADNs per domain name.
•
Example
padn
host1(config-domain-map)#padn 10.2.25.6 255.255.255.255 13
•
Use the no version to delete PADN parameters for the domain name.
•
See padn.
Configuring PPPoE Service Name Tables
To configure PPPoE service name tables on the router:
1.
Create the PPPoE service name table.
2. (Optional) Add entries to populate the PPPoE service name table.
You can:
•
Configure specific service names to represent custom values.
•
Specify a nondefault action for the empty service name entry.
•
Specify a nondefault action for the unknown service name entry.
3. Enable the PPPoE service name table for use with a static or dynamic interface.
The following sections describe how to perform these tasks.
Creating and Populating PPPoE Service Name Tables
To create and populate a PPPoE service name table on the router:
1.
From Global Configuration mode, create a PPPoE service name table by assigning it
a name.
host1(config)#pppoe-service-name-table myServiceTable1
This command accesses PPPoE Service Name Table Configuration mode and builds
a default PPPoE service name table named myServiceTable1. The table contains two
entries: an empty service name entry associated with the default action, terminate;
and an unknown service name entry associated with the default action, drop as shown
in Table 23 on page 406. This table directs the router to respond to all PADI requests
containing an empty service name tag; and denies requests that contain a service
name tag that has not been configured in the service name table.
Copyright © 2010, Juniper Networks, Inc.
405
JunosE 11.3.x Link Layer Configuration Guide
Table 23: Default PPPoE Service Name Table
Service Name
Action
“ ”
Terminate
unknown-service-name
Drop
2. (Optional) From PPPoE Service Name Table Configuration mode, create entries to
populate the PPPoE service name table.
You can configure up to 16 specific service name entries per table, in addition to the
empty and unknown service name tags.
host1(config-pppoe-service-name-table)#service myISPService action drop
host1(config-pppoe-service-name-table)#service myQOSClass1 action terminate
host1(config-pppoe-service-name-table)#service myQOSClass2 action drop
host1(config-pppoe-service-name-table)#service myQOSClass3
host1(config-pppoe-service-name-table)#service empty-service-name action drop
host1(config-pppoe-service-name-table)#service unknown-service-name action
terminate
These commands build the PPPoE service name table shown in Table 24 on page 406.
This table directs the router to send a PADO packet in response to all PADI requests
containing the myQOSClass1, myQOSClass3, empty service name tags, and unknown
service name tag. The router is directed to drop all PADI requests containing the
myISPService or myQOSClass2 or the empty service name tags.
Table 24: PPPoE Service Name Table with Entries
Service Name
Action
myISPService
Drop
myQOSClass1
Terminate
myQOSClass2
Drop
myQOSClass3
Terminate
“”
Drop
unknown-service-name
Terminate
3. Exit PPPoE Service Name Table Configuration mode.
host1(config-pppoe-service-name-table)#exit
4. (Optional) Use the appropriate show command to verify the creation of the PPPoE
service name table and entries.
host1(config)#show pppoe-service-name-table name myServiceTable1
5. (Optional) Repeat Steps 1 through 4 to configure additional PPPoE service name
tables on the router.
406
Copyright © 2010, Juniper Networks, Inc.
Chapter 12: Configuring Point-to-Point Protocol over Ethernet
pppoe-service-name-table
•
Use from Global Configuration mode to create a PPPoE service name table.
•
You can create a maximum of 16 PPPoE service name tables per E Series router.
•
Specify a table name of up to 31 alphanumeric characters.
•
This command accesses PPPoE Service Name Table Configuration mode, which
enables you to configure entries for the PPPoE service name table.
•
Example
host1(config)#pppoe-service-name-table myServiceTable1
•
Use the no version to remove the specified PPPoE service name table from the router.
•
See pppoe-service-name-table.
•
Use to add service name tags to the PPPoE service name table.
•
Each PPPoE service name table includes one empty service name tag, one unknown
service name tag, and can optionally include up to 16 additional custom service name
tags. An empty service name tag is used to represent any service. An unknown service
name tag is used to represent a service that has not been configured in the PPPoE
service name table. A custom service name tag is used to represent a specific service.
•
To modify the action associated with an empty service entry, use the
empty-service-name keyword with the action keyword. This directs the router to drop
PADI requests from the PPPoE client. The default action for an empty service name
entry is terminate.
•
To include a custom service entry, specify a serviceName of up to 31 alphanumeric
characters. Use the optional action keyword with the service command for a custom
service entry to specify that the router either drop or terminate PADI requests from
the PPPoE client. The default action for a custom service entry is terminate.
•
To modify the action associated with an unknown service entry, use the
unknown-service-name keyword with the action keyword. This directs the router to
terminate (allow) PADI requests from the PPPoE client. The default action for an
unknown service name entry is drop.
service
The default action for the unknown service name entry depends on the configuration
of the service name table. If all the services in the service name table are configured
to terminate, the default action of the unknown service name tag is drop. If all the
services in the service name table are configured to drop, the default action for the
unknown service name tag is terminate. If both terminate and drop are configured,
the default action for the unknown service name tag is drop.
•
Example 1– Includes a custom service entry in the PPPoE service name table. The
associated action for this service tag is terminate. This is the default action when you
add a custom service entry without using the optional action keyword.
host1(config-pppoe-service-name-table)#service myISPService
Copyright © 2010, Juniper Networks, Inc.
407
JunosE 11.3.x Link Layer Configuration Guide
•
Example 2 – Includes a custom service entry in the PPPoE service name table. The
associated action for this service tag is drop. Use the optional action keyword with the
service command to associate an action with the custom service entry.
host1(config-pppoe-service-name-table)# service myQOSClass2 action drop
•
Example 3 – Includes an unknown service name entry in the PPPoE service name table.
The associated action for this service tag is terminate. Use the action keyword with
the service command to associate an action with the unknown service name entry.
host1(config-pppoe-service-name-table)# service unknown-service-name action
terminate
•
Example 4 – Includes an empty service name entry in the PPPoE service name table.
The associated action for this service tag is drop. Use the action keyword with the
service command to associate an action with the empty service name entry.
host1(config-pppoe-service-name-table)#service empty-service-name action drop
•
Use the no version to remove the custom service name tags from the PPPoE service
name table or restore the default action for the empty and unknown service name
tags.
•
See service.
Enabling PPPoE Service Name Tables for Use with Static Interfaces
To enable a PPPoE service name table for use with a static interface, assign the service
name table to the PPPoE major interface.
PPPoE over ATM Configurations
To enable a PPPoE service name table for use with a static interface in PPPoE over ATM
configurations:
1.
Configure an ATM physical interface.
host1(config)#interface atm 3/0
2. Configure an ATM 1483 subinterface.
host1(config-if)#interface atm 3/0.1
3. Configure an ATM PVC by specifying the VCD, the VPI, the VCI, and the encapsulation
type.
host1(config-subif)#atm pvc 10 100 22 aal5snap
4. Select PPPoE as the encapsulation method on the interface. This command creates
the PPPoE major interface.
host1(config-subif)#encapsulation pppoe
5. Assign the PPPoE service name table to the PPPoE major interface.
host1(config-subif)#pppoe service-name-table myServiceTable1
atm pvc
408
Copyright © 2010, Juniper Networks, Inc.
Chapter 12: Configuring Point-to-Point Protocol over Ethernet
•
Use to configure a PVC on an ATM interface.
•
For details about specifying the mandatory VCD, VPI, VCI, and encapsulation type
parameters, see “atm pvc” on page 387.
•
Example
host1(config-if)#atm pvc 10 100 22 aal5snap
•
Use the no version to remove the specified PVC.
•
See atm pvc.
•
Use to specify PPPoE as the encapsulation method for the interface.
•
This command creates a PPPoE major interface.
•
Example
encapsulation pppoe
host1(config-subif)#encapsulation pppoe
•
Use the no version to disable PPPoE on an interface.
•
See encapsulation pppoe.
•
Use to configure an ATM interface.
•
For information about specifying the ATM interface or subinterface, see “interface atm”
on page 388.
•
Examples
interface atm
host1(config)#interface atm 3/1.19
host1(config)#interface atm 3/0/1.19
•
Use the no version to remove the interface or subinterface.
•
See interface atm.
pppoe service-name-table
•
Use from Subinterface Configuration mode to assign a PPPoE service name table to
a PPPoE major interface for use by a static ATM 1483 subinterface.
•
Specify the name of the PPPoE service name table configured with the
pppoe-service-name-table command from Global Configuration mode.
•
Example
host1(config-subif)#pppoe service-name-table myServiceTable1
•
Use the no version to remove the PPPoE service name table assignment.
•
See pppoe service-name-table.
Copyright © 2010, Juniper Networks, Inc.
409
JunosE 11.3.x Link Layer Configuration Guide
PPPoE over Ethernet Configurations
To enable a PPPoE service name table for use with a static interface in PPPoE over
Ethernet configurations:
Configure a Fast Ethernet, Gigabit Ethernet, or 10-Gigabit Ethernet physical interface.
1.
host1(config)#interface fastEthernet 4/1
2. Select PPPoE as the encapsulation method on the interface. This command creates
the PPPoE major interface.
host1(config-if)#pppoe
3. Assign the PPPoE service name table to the PPPoE major interface.
host1(config-if)#pppoe service-name-table myServiceTable1
interface fastEthernet
•
Use to select a Fast Ethernet interface.
•
Example
host1(config)#interface fastEthernet 4/1
•
Use the no version to remove IP from an interface or subinterface. You must issue the
no version from the highest level down; you cannot remove an interface or subinterface
if the one above it still exists.
•
See interface fastEthernet.
interface gigabitEthernet
interface tenGigabitEthernet
•
Use to select a Gigabit Ethernet interface or a 10-Gigabit Ethernet interface.
•
For information about specifying the Gigabit Ethernet or 10-Gigabit Ethernet interface
or subinterface, see “interface gigabitEthernet” on page 400 and “interface
tenGigabitEthernet” on page 400 on “interface tenGigabitEthernet” on page 667.
•
Examples
host1(config)#interface gigabitEthernet 1/0
host1(config)#interface gigabitEthernet 4/0/1 6.0.0FRS
host1(config)#interface tenGigabitEthernet 4/0/1
•
Use the no version to remove IP from an interface. You must issue the no version from
the highest level down; you cannot remove an interface or subinterface if the one above
it still exists.
•
See interface gigabitEthernet.
•
See interface tenGigabitEthernet.
pppoe
410
Copyright © 2010, Juniper Networks, Inc.
Chapter 12: Configuring Point-to-Point Protocol over Ethernet
•
Use to specify PPPoE as the encapsulation method for the interface.
•
This command creates a PPPoE major interface.
•
Example
host1(config-if)#pppoe
•
Use the no version to remove the PPPoE major interface.
•
See pppoe.
pppoe service-name-table
•
Use from Interface Configuration mode to assign a PPPoE service name table to a
PPPoE major interface for use by a static Fast Ethernet, Gigabit Ethernet, or 10-Gigabit
Ethernet interface.
•
Specify the name of the PPPoE service name table configured with the
pppoe-service-name-table command from Global Configuration mode.
•
Example
host1(config-if)#pppoe service-name-table myServiceTable1
•
Use the no version to remove the PPPoE service name table assignment.
•
See pppoe service-name-table.
Enabling PPPoE Service Name Tables for Use with Dynamic Interfaces
To enable a PPPoE service name table for use with a dynamic interface, add the service
name table to a profile that is dynamically assigned to the interface.
For complete details, see “Configuring a Dynamic Interface from a Profile” on page 559 in
“Configuring Dynamic Interfaces” on page 511.
To enable a PPPoE service name table for use with a dynamic interface:
1.
Create a profile by assigning it a name.
host1(config)#profile baseProfile
2. Assign the PPPoE service name table to the profile as a PPPoE characteristic.
host1(config-profile)#pppoe service-name-table myServiceTable1
3. Exit Profile Configuration mode.
host1(config-profile)#exit
4. Configure a physical interface.
On ERX7xx models, ERX14xx models, and the ERX310 router:
host1(config-if)#interface atm 3/0.1
5. Configure an ATM PVC by specifying the VCD, the VPI, the VCI, and the encapsulation
type.
host1(config-subif)#atm pvc 10 100 22 aal5snap
Copyright © 2010, Juniper Networks, Inc.
411
JunosE 11.3.x Link Layer Configuration Guide
6. Apply the profile to the interface.
host1(config-subif)#profile pppoe baseProfile
7. Enable the PPPoE dynamic encapsulation type.
host1(config-subif)#auto-configure pppoe
atm pvc
•
Use to configure a PVC on an ATM interface.
•
For details about specifying the mandatory VCD, VPI, VCI, and encapsulation type
parameters, see “atm pvc” on page 387.
•
Example
host1(config-if)#atm pvc 10 100 22 aal5snap
•
Use the no version to remove the specified PVC.
•
See atm pvc.
•
Use to configure an ATM 1483 subinterface to support a dynamic interface. Specifies
the type(s) of dynamic encapsulation that will be accepted/detected by the ATM 1483
subinterface.
•
This command causes the layers above ATM 1483 to become dynamic.
•
Select pppoe as the dynamic next upper interface type.
•
Example
auto-configure
host1(config-subif)#auto-configure pppoe
•
Use the no version to disable detection of the specified encapsulation.
•
See auto-configure.
•
Use to configure an ATM interface.
•
For information about specifying the ATM interface or subinterface, see “interface atm”
on page 388.
•
Examples
interface atm
host1(config)#interface atm 3/0.1
host1(config)#interface atm 3/0/0.1
•
Use the no version to remove the interface or subinterface.
•
See interface atm.
pppoe service-name-table
412
Copyright © 2010, Juniper Networks, Inc.
Chapter 12: Configuring Point-to-Point Protocol over Ethernet
•
Use from Profile Configuration mode to assign a PPPoE service name table to a profile
for use by the dynamic PPPoE interface column associated with the profile.
•
Specify the name of the PPPoE service name table configured with the
pppoe-service-name-table command from Global Configuration mode.
•
Example
host1(config-profile)#pppoe service-name-table myServiceTable1
•
Use the no version to remove the PPPoE service name table assignment.
•
See pppoe service-name-table.
•
Use from Global Configuration mode to create a profile name of up to 80 characters.
•
Use from Subinterface Configuration mode to assign a profile to an interface. Specify
pppoe as the encapsulation type to which the profile applies.
•
Examples
profile
host1(config)#profile myProfile
host1(config-subif)#profile pppoe myProfile
•
Use the no version to remove a profile (from Global Configuration mode) or to remove
the profile assignment (from Subinterface Configuration mode).
•
See profile.
Configuring PADS Packet Content
By default, an E Series router acting as an AC sends both the AC-Name and AC-Cookie
tags as part of the PADS packet when it confirms a session with a PPPoE client. These
tags are defined in RFC 2516 as follows:
•
AC-Name—String that uniquely identifies the particular AC
•
AC-Cookie—Tag used by the AC to help protect against denial of service (DoS) attacks
If necessary for compatibility with your network equipment, you can issue the pppoe
pads disable-ac-info command to prevent the router from sending the AC-Name and
AC-Cookie tags in the PADS packet.
pppoe pads disable-ac-info
•
Use to prevent the router from sending the AC-Name and AC-Cookie tags in the PADS
packet.
•
The pppoe pads disable-ac-info command affects PADS packets sent only on PPPoE
interfaces configured on the router after the command is issued. It has no effect on
PADS packets sent on previously created PPPoE interfaces.
•
Example
host1(config)#pppoe pads disable-ac-info
Copyright © 2010, Juniper Networks, Inc.
413
JunosE 11.3.x Link Layer Configuration Guide
•
Use the no version to restore the default behavior, which is to send the AC-Name and
AC-Cookie tags in the PADS packet.
•
See pppoe pads disable-ac-info.
Configuring PPPoE Remote Circuit ID Capture
To capture and use the PPPoE remote circuit ID:
1.
Configure a static or dynamic PPPoE interface.
For instructions on configuring a static PPPoE interface, see “Configuring PPPoE over
ATM” on page 384 or “Configuring PPPoE for Ethernet Modules” on page 394.
For instructions on configuring a dynamic PPPoE interface, see “Configuring Dynamic
Interfaces” on page 511.
2. Configure capture of the PPPoE remote circuit ID on this interface.
a. Enable the router to capture the PPPoE remote circuit ID transmitted from the
DSLAM by using one of the following methods:
•
For a static PPPoE interface, issue the pppoe remote-circuit-id command from
Interface Configuration mode or Subinterface Configuration mode.
host1(config-if)#pppoe remote-circuit-id
•
For a dynamic PPPoE interface, issue the pppoe remote-circuit-id command
from Profile Configuration mode as a characteristic of the profile assigned to
the dynamic PPPoE interface column.
host1(config)#profile pppoeTest
host1(config-profile)#pppoe remote-circuit-id
By default, the router formats the captured PPPoE remote circuit ID to include only
the agent-circuit-id suboption (suboption 1) of the PPPoE intermediate agent tags
sent from the DSLAM.
b. (Optional) Use the show pppoe interface command (for static PPPoE interfaces)
or the show profile command (for dynamic PPPoE interfaces) to verify that PPPoE
remote circuit capture is enabled.
host1#show pppoe interface fastEthernet 4/1.1
host1#show profile name pppoeTest
For information about how to use these commands, see “show pppoe interface”
on page 421 and “show profile” on page 430.
3. (Optional) Configure the format of the captured PPPoE remote circuit ID value.
a. Configure RADIUS to specify a nondefault format for the PPPoE remote circuit ID
value.
•
414
For example, the following command formats the PPPoE remote circuit ID to
include only the agent-remote-id suboption (suboption 2) of the tags supplied
by the PPPoE intermediate agent.
Copyright © 2010, Juniper Networks, Inc.
Chapter 12: Configuring Point-to-Point Protocol over Ethernet
host1(config)#radius remote-circuit-id-format agent-remote-id
The following command formats the PPPoE remote circuit ID to include the
NAS-Identifier [32] RADIUS attribute with both the agent-circuit-id and
agent-remote-id suboptions of the tags supplied by the PPPoE intermediate
agent.
•
host1(config)#radius remote-circuit-id-format nas-identifier agent-circuit-id
agent-remote-id
The following command formats the PPPoE remote circuit ID to append the
agent-circuit-ID suboption to an interface specifier that is consistent with the
recommended format in the DSL Forum Technical Report (TR)-101—Migration
to Ethernet-Based DSL Aggregation (April 2006). For details about how the
router implements this format, see “Format for dsl-forum-1 Keyword” on page 377.
•
host1(config)#radius remote-circuit-id-format dsl-forum-1
b. Configure RADIUS to specify a nondefault delimiter character to separate
components in the PPPoE remote circuit ID value. (The default delimiter character
is #.)
host1(config)#radius remote-circuit-id-delimiter %
c. Use the show radius remote-circuit-id format command and the show radius
remote-circuit-id-delimiter command to verify the format and delimiter settings
for the PPPoE remote circuit ID value.
host1#show radius remote-circuit-id-format
host1#show radius remote-circuit-id-delimiter
For information about how to use these commands, see “show radius
remote-circuit-id-format” on page 434 and “show radius remote-circuit-id-delimiter”
on page 434.
4. Send the PPPoE remote circuit ID value to a RADIUS server, to an LNS, or to both.
a. Configure RADIUS to use the PPPoE remote circuit ID captured from the DSLAM
in place of either (or both) of the Calling-Station-Id [31] and NAS-Port-Id [87]
RADIUS attributes.
host1(config)#radius override calling-station-id remote-circuit-id
host1(config)#radius override nas-port-id remote-circuit-id
b. Configure the E Series L2TP access controller (LAC) to generate L2TP Calling
Number AVP 22 in fixed format or one of several formats that includes either or
both of the agent-circuit-id (suboption 1) and agent-remote-id (suboption 2)
suboptions of the tags supplied by the PPPoE intermediate agent.
host1(config)#aaa tunnel calling-number-format fixed
or
host1(config)#aaa tunnel calling-number-format descriptive
include-agent-circuit-id include-agent-remote-id
or
host1(config)#aaa tunnel calling-number-format include-agent-circuit-id
Copyright © 2010, Juniper Networks, Inc.
415
JunosE 11.3.x Link Layer Configuration Guide
c. (Optional) Configure a fallback format for the L2TP Calling Number AVP 22. The
fallback format is used only when you have configured the calling number format
as anything other than fixed and the PPPoE agent ID is null or unavailable.
host1(config)#aaa tunnel calling-number-format fallback fixed
or
host1(config)#aaa tunnel calling-number-format fallback descriptive
d. (Optional) Use the show radius override command to verify the override settings
configured for RADIUS, and the show aaa tunnel-parameters command to verify
the parameters configured for L2TP tunnel definitions.
host1#show radius override
host1#show aaa tunnel-parameters
For information about how to use these commands, see “show radius override” on
page 433 and “show aaa tunnel-parameters” on page 420.
aaa tunnel calling-number-format
•
Use to configure the format used by the E Series LAC to generate the L2TP Calling
Number AVP 22.
•
The fixed format is similar to the fixed format of RADIUS attribute 31
(Calling-Station-Id). The LAC uses this format in ICRQ packets that it sends to the
LNS.
•
Several different descriptive formats include information about the interface and either
or both of the suboptions supplied by the PPPoE intermediate agent, agent-circuit-id
and agent-remote-id.
•
Several simpler formats include only either or both of the PPPoE suboptions,
agent-circuit-id and agent-remote-id.
•
Example 1
host1(config)#aaa tunnel calling-number-format descriptive include-agent-circuit-id
•
Example 2
host1(config)#aaa tunnel calling-number-format descriptive include-agent-circuit-id
include-agent-remote-id
•
Example 3
host1(config)#aaa tunnel calling-number-format include-agent-circuit-id
•
Use the no version to restore the default calling number format, descriptive.
•
See aaa tunnel calling-number-format.
aaa tunnel calling-number-format-fallback
416
•
Use to configure the fallback format that the E Series LAC uses to generate the L2TP
Calling Number AVP 22 in the event that the PPPoE agent ID is null or unavailable.
•
The fallback format is used only when the configured calling number format includes
either or both of the agent-circuit-id and agent-remote-id.
Copyright © 2010, Juniper Networks, Inc.
Chapter 12: Configuring Point-to-Point Protocol over Ethernet
•
The calling number format determines what element triggers use of the fallback format:
Calling Number Format
Fallback Trigger
agent-circuit-id
agent-circuit-id is empty
agent-circuit-id include-agent-remote-id
Both agent-circuit-id and agent-remote-id
are empty.
agent-remote-id
agent-remote-id is empty
descriptive include-agent-circuit-id
agent-circuit-id is empty
descriptive include-agent-circuit-id
include-agent-remote-id
Both agent-circuit-id and agent-remote-id
are empty.
descriptive include-agent-remote-id
agent-remote-id is empty
•
You can specify either descriptive format or fixed format.
•
Example
host1(config)#aaa tunnel calling-number-format-fallback fixed
•
Use the no version to restore the default format, descriptive.
•
See aaa tunnel calling-number-format-fallback.
•
Use to enable a static PPPoE interface (from Interface Configuration mode or
Subinterface Configuration mode) or a dynamic PPPoE interface (from Profile
Configuration mode) to capture and process a vendor-specific tag containing a remote
circuit ID transmitted from a DSLAM.
•
The router can then send this value to a RADIUS server or to an L2TP network server
(LNS) to uniquely identify subscriber locations.
•
Examples
pppoe remote-circuit-id
host1(config-if)#pppoe remote-circuit-id
host1(config-profile)#pppoe remote-circuit-id
•
Use the no version to restore the default behavior, which is not to capture and process
the PPPoE remote circuit ID.
•
See pppoe remote-circuit-id.
radius override calling-station-id remote-circuit-id
•
Use to configure RADIUS to override the standard use of the Calling-Station-Id [31]
RADIUS attribute and instead use the PPPoE remote circuit ID transmitted from a
DSLAM.
•
Example
host1(config)#radius override calling-station-id remote-circuit-id
Copyright © 2010, Juniper Networks, Inc.
417
JunosE 11.3.x Link Layer Configuration Guide
•
Use the no version to restore the default Calling-Station-Id value, which is the telephone
number from which the call originated.
•
See radius override calling-station-id remote-circuit-id.
radius override nas-port-id remote-circuit-id
•
Use to configure RADIUS to override the standard use of the NAS-Port-Id [87] RADIUS
attribute and instead use the PPPoE remote circuit ID transmitted from a DSLAM.
•
Example
host1(config)#radius override nas-port-id remote-circuit-id
•
Use the no version to restore the default NAS-Port-Id value, which is the physical
interface of the network access server (NAS) that is authenticating the user.
•
See radius override nas-port-id remote-circuit-id.
radius remote-circuit-id-delimiter
•
Use to configure the delimiter character that the router uses to set off multiple
components in the format of the PPPoE remote circuit ID value captured from a DSLAM.
•
Example
host1(config)#radius remote-circuit-id-delimiter !
•
Use the no version to restore the default delimiter character, #.
•
See radius remote-circuit-id-delimiter.
radius remote-circuit-id-format
418
•
Use to configure the format of the PPPoE remote circuit ID value captured from a
DSLAM.
•
By default, the router formats the PPPoE remote circuit ID to include only the
agent-circuit-id suboption (suboption 1) of the tags supplied by the PPPoE intermediate
agent.
•
You can use this command to configure one of the following nondefault formats for
the PPPoE remote circuit ID value:
•
To include the agent-circuit-id suboption, use the agent-circuit-id keyword.
•
To include the agent-remote-id suboption (suboption 2) of the tags supplied by the
PPPoE intermediate agent, use the agent-remote-id keyword.
•
To include the NAS-Identifier [32] RADIUS attribute, use the nas-identifier keyword.
If you include the nas-identifier keyword, you must also include either or both of the
agent-circuit-id and agent-remote-id keywords.
•
To append the agent-circuit-ID value to an interface specifier that is consistent with
the recommended format in DSL Forum Technical Report (TR)-101—Migration to
Ethernet-Based DSL Aggregation (April 2006)the , use the dsl-forum-1 keyword.
For details about how the router implements this format, see “Format for dsl-forum-1
Keyword” on page 377.
Copyright © 2010, Juniper Networks, Inc.
Chapter 12: Configuring Point-to-Point Protocol over Ethernet
•
RADIUS overrides the standard use of the Calling-Station-Id [31] or NAS-Port-Id [87]
attribute with the PPPoE remote circuit ID only if the DSLAM transmits non-empty
data for at least one of the agent-circuit-id or agent-remote-id values. If the DSLAM
transmits empty data, then RADIUS does not override the Calling-Station-Id [31] or
NAS-Port-Id [87] RADIUS attribute with the PPPoE remote circuit ID and instead uses
the standard value for the RADIUS attribute.
•
If a single component in a multi-component PPPoE remote circuit ID format is empty,
the router represents the empty component as two consecutive delimiter characters
(## by default).
•
Example 1—Formats the PPPoE remote circuit ID value to include only the
agent-remote-id suboption of the tags supplied by the PPPoE intermediate agent.
host1(config)#radius remote-circuit-id-format agent-remote-id
•
Example 2—Formats the PPPoE remote circuit ID value to include both the
agent-circuit-id and agent-remote-id suboptions of the tags supplied by the PPPoE
intermediate agent.
host1(config)#radius remote-circuit-id-format agent-circuit-id agent-remote-id
•
Example 3—Formats the PPPoE remote circuit ID value to include the NAS-Identifier
[32] RADIUS attribute with the agent-circuit-id suboption of the tags supplied by the
PPPoE intermediate agent.
host1(config)#radius remote-circuit-id-format nas-identifier agent-circuit-id
•
Example 4—Formats the PPPoE remote circuit ID value to include the NAS-Identifier
[32] RADIUS attribute with the agent-remote-id suboption of the tags supplied by the
PPPoE intermediate agent.
host1(config)#radius remote-circuit-id-format nas-identifier agent-remote-id
•
Example 5—Formats the PPPoE remote circuit ID value to include the NAS-Identifier
[32] RADIUS attribute with both the agent-circuit-id and agent-remote-id suboptions
of the tags supplied by the PPPoE intermediate agent.
host1(config)#radius remote-circuit-id-format nas-identifier agent-circuit-id
agent-remote-id
•
Example 6—Formats the PPPoE remote circuit ID value to use the format for the
dsl-forum-1 keyword. For details about how the router implements this format, see
“Format for dsl-forum-1 Keyword” on page 377.
host1(config)#radius remote-circuit-id-format dsl-forum-1
•
Use the no version to restore the default format, agent-circuit-id.
•
See radius remote-circuit-id-format.
Monitoring PPPoE
Use the commands described in this section to display information about PPPoE interfaces
and subinterfaces.
Copyright © 2010, Juniper Networks, Inc.
419
JunosE 11.3.x Link Layer Configuration Guide
You can set a statistics baseline for PPPoE interfaces, subinterfaces, and circuits using
the baseline pppoe interface command.
You can use the output filtering feature of the show command to include or exclude lines
of output based on a text string you specify. See chapter Command Line Interface in
JunosE System Basics Configuration Guide for details.
NOTE: The E120 and E320 routers output for monitor and show commands
is identical to output from other E Series routers, except that the E120 and
E320 routers output also includes information about the adapter identifier
in the interface specifier (slot/adapter/port).
baseline pppoe interface
•
Use to set a statistics baseline for PPPoE interfaces, subinterfaces, and circuits.
•
The router implements the baseline by reading and storing the statistics at the time
the baseline is set and then subtracting this baseline whenever baseline-relative
statistics are retrieved.
•
You cannot set a baseline for groups of interfaces, subinterfaces, or circuits. You must
set them one at a time.
•
When baselining is requested, the time since the last baseline was set is displayed in
hours:minutes:seconds or days/hours format. If a baseline has not been set, the message
“No baseline has been set” is displayed instead.
•
Use the optional delta keyword with PPPoE show commands to specify that baselined
statistics will be shown.
•
Examples
host1#baseline pppoe interface atm 2/0.1.1
host1#baseline pppoe interface atm 2/0/0.1.1
•
There is no no version.
•
See baseline pppoe interface.
show aaa tunnel-parameters
420
•
Use to display tunnel parameters that are configured for L2TP tunnel definitions,
including the calling number format.
•
Field descriptions
•
Tunnel password—Default tunnel password
•
Tunnel client-name—Hostname that the LAC sends to the LNS when communicating
about the tunnel
•
Tunnel nas-port-method—Default NAS port type
•
Tunnel nas-port ignore—Whether the router uses the tunnel peer’s NAS-Port [5]
attribute; enabled or disabled
Copyright © 2010, Juniper Networks, Inc.
Chapter 12: Configuring Point-to-Point Protocol over Ethernet
•
•
Tunnel nas-port-type ignore—Whether the router uses the tunnel peer’s
NAS-Port-Type [61] attribute; enabled or disabled
•
Tunnel assignmentID format—Value of the tunnel assignment ID that is passed to
PPP/L2TP
•
Tunnel calling number format—Format configured for L2TP Calling Number AVP 22
generated by the LAC
Example
host1#show aaa tunnel-parameters
Tunnel password is 3&92k5b#q4
Tunnel client-name is host1
Tunnel nas-port-method is none
Tunnel nas-port ignore disabled
Tunnel nas-port-type ignore disabled
Tunnel assignmentId format is assignmentId
Tunnel calling number format is descriptive, includes agent-circuit-id
and
agent-remote-id
•
See show aaa tunnel-parameters.
•
Use to display parameters on a PPPoE interface or a PPPoE subinterface.
•
If you do not specify an interface and subinterface, the router displays the PPPoE
interface and Status parameters for all configured interfaces.
•
If you specify an interface with no subinterface, the router displays the PPPoE interface
and Status parameters for that interface.
•
If you specify an interface and subinterface, the router displays detailed parameters
available for that subinterface.
•
Field descriptions
show pppoe interface
•
PPPoE interface—Interface identifier. For more information about specifying the
physical interface, see Interface Types and Specifiers in JunosE Command Reference
Guide.
•
Status—Operational status of the interface; possible values are:
•
operStatusUp—Interface or subinterface is operational
•
Down—Interface or subinterface is not operational
•
LowerLayerDown—Subinterface is not operational because an underlying interface
is down
•
full—Displays configuration, status, and statistics information
•
max sessions—Number of maximum allowable PPP sessions configured
•
mtu—Maximum transfer unit (MTU) value; when derived from the PPPoE MTU tag,
the value can only be determined from an active session.
Copyright © 2010, Juniper Networks, Inc.
421
JunosE 11.3.x Link Layer Configuration Guide
422
•
acName—Name of PPPoE access concentrator
•
will not send ac info in PADS packet—When the pppoe pads disable-ac-info
command is issued, indicates that the router does not send the AC-Name and
AC-Cookie tags in the PADS packet
•
duplicate-protection—Whether duplicate protection is enabled or disabled for the
interface
•
capture remote circuit id—Whether capture of the PPPoE remote circuit ID sent from
the DSLAM is enabled or disabled for the interface
•
active connections—Number of live PPP connections
•
configured subinterfaces—Number of PPPoE subinterfaces you configured on an
interface
•
Assigned profile—Name of profile assigned to dynamic PPPoE interface
•
PPPoE Statistics Counters
•
PADI received/PADI transmitted—Number of initiation control packets
received/transmitted
•
PADO received/PADO transmitted—Number of offer control packets
received/transmitted
•
PADR received/PADR transmitted—Number of request control packets
received/transmitted
•
PADS received/PADS transmitted—Number of session confirmation control packets
received/transmitted
•
PADT received/PADT transmitted—Number of termination control packets
received/transmitted
•
PADM received/PADM transmitted—Number of message control packets
received/transmitted
•
PADN received/PADN transmitted—Number of network control packets
received/transmitted
•
PAD packets received—Total number of control packets received on the interface
•
PAD packets transmitted—Total number of control packets transmitted on the
interface
•
Invalid PAD Packets
•
Invalid Version—Number of control packets received with an invalid version
•
Invalid PAD Code—Number of control packets received with an invalid code
•
Invalid PAD Tags—Number of control packets received with invalid tags
Copyright © 2010, Juniper Networks, Inc.
Chapter 12: Configuring Point-to-Point Protocol over Ethernet
•
•
Invalid PAD Tag length—Number of control packets received with an invalid tag
length
•
Invalid PAD Type—Number of control packets received with an invalid type
•
Invalid PADI Session—Number of invalid PPPoE Active Discovery Initiation sessions
•
Invalid PADR Session—Number of invalid PPPoE Active Discovery Request sessions
•
Invalid PAD packet length—Number of control packets received with an invalid
packet length
•
Invalid PAD packets—Number of invalid control packets received
•
Total Invalid PAD packets—Total number of invalid control packets received on the
interface
•
Insufficient Resources—Number of requests denied because of an inadequate number
of sessions; check the number of active clients
•
Lockout Configuration (seconds)—Encapsulation type lockout settings for the PPPoE
client associated with the dynamic PPPoE subinterface column; for more information
about these fields, see “Configuring Encapsulation Type Lockout for PPPoE Clients”
on page 544 in “Configuring Dynamic Interfaces” on page 511
•
Min—Minimum lockout time, in seconds
•
Max—Maximum lockout time, in seconds
•
Total clients in active lockouts—Number of PPPoE clients currently undergoing
dynamic encapsulation type lockout
•
Total clients in lockout grace period—Number of PPPoE clients currently in a
lockout grace period
Example 1
host1#show pppoe interface atm 1/0.1
PPPoE interface ATM 1/0.1 is operStatusUp (dynamic)
PPPoE interface ATM 1/0.1 has max sessions = 4000
PPPoE interface ATM 1/0.1 has acName of 111111111111111
PPPoE interface ATM 1/0.1 will not send ac info in PADS packet
PPPoE interface ATM 1/0.1 is in duplicate-protection
PPPoE interface ATM 1/0.1 will capture remote circuit ID
PPPoE interface ATM 1/0.1 has 1 active connections,
out of 1 configured subinterfaces
Assigned profile (any)
PPPoE Statistics
Counters:
PADI received
PADI transmitted
PADO received
PADO transmitted
PADR received
Copyright © 2010, Juniper Networks, Inc.
: baseProfile
0
1
1
0
0
423
JunosE 11.3.x Link Layer Configuration Guide
PADR transmitted
1
PADS received
1
PADS transmitted
0
PADT received
0
PADT transmitted
0
PADM received
1
PADM transmitted
0
PADN received
0
PADN transmitted
0
PAD packets received
PAD packets transmitted
Invalid PAD Packets:
Invalid Version
Invalid PAD Code
Invalid PAD Tags
Invalid PAD Tag length
Invalid PAD Type
Invalid PADI Session
Invalid PADR Session
Invalid PAD packet length
Invalid PAD packets
Total Invalid PAD packets
2
2
0
0
0
0
0
0
0
3
0
3
Insufficient Resources 0
Lockout Configuration (seconds): Min 5, Max 60
Total clients in active lockouts: 0
Total clients in lockout grace period: 0
•
Example2—Uses the Fast Ethernet interface
host1#show pppoe interface fastEthernet 9/4
PPPoE interface fastEthernet 9/4 is operStatusUp
PPPoE interface fastEthernet 9/4 has max sessions = 8000
PPPoE interface fastEthernet 9/4 has no acName set
PPPoE interface fastEthernet 9/4 is in test mode
PPPoE interface fastEthernet 9/4 has 16 active connections,
out of 16 configured subinterfaces
PPPoE Statistics
Counters:
PADI received
0
PADI transmitted
16
PADO received
16
PADO transmitted
0
PADR received
0
PADR transmitted
16
PADS received
16
PADS transmitted
0
PADT received
0
PADT transmitted
0
PADM received
16
PADM transmitted
0
PADN received
16
PADN transmitted
0
PAD packets received
32
PAD packets transmitted
32
Invalid PAD Packets:
Invalid Version
0
Invalid PAD Code
0
•
424
Example 3—Uses the default MTU value (1494)
Copyright © 2010, Juniper Networks, Inc.
Chapter 12: Configuring Point-to-Point Protocol over Ethernet
host1#show pppoe interface full
PPPoE interface FastEthernet 2/0 is operStatusUp
PPPoE interface FastEthernet 2/0 has max sessions = 8000
PPPoE interface FastEthernet 2/0 mtu 1494
PPPoE interface FastEthernet 2/0 has no acName set
PPPoE interface FastEthernet 2/0 autoconfigured subinterfaces
PPPoE interface FastEthernet 2/0 has 1 active connections,
out of 1 configured subinterfaces
Assigned profile (any)
: pppoetest
PPPoE Statistics
Counters:
PADI received
42
PADI transmitted
0
PADO received
0
PADO transmitted
8
PADR received
8
PADR transmitted
0
PADS received
0
PADS transmitted
8
PADT received
0
PADT transmitted
7
PADM received
0
PADM transmitted
0
PADN received
0
PADN transmitted
0
PAD packets received
50
PAD packets transmitted
23
Invalid PAD Packets:
Invalid Version
Invalid PAD Code
Invalid PAD Tags
Invalid PAD Tag length
Invalid PAD Type
Invalid PADI Session
Invalid PADR Session
Invalid PAD packet length
Invalid PAD packets
Total Invalid PAD packets
0
0
0
0
0
0
0
0
0
0
Insufficient Resources 0
Lockout Configuration (seconds): Min 10, Max 120
Total clients in active lockouts: 0
Total clients in lockout grace period: 0
•
Example 4—Uses the PPPoE MTU tag
host1#show pppoe interface full
PPPoE interface FastEthernet 2/0 is operStatusUp
PPPoE interface FastEthernet 2/0 has max sessions = 8000
PPPoE interface FastEthernet 2/0 will use tag value for mtu
PPPoE interface FastEthernet 2/0 has no acName set
PPPoE interface FastEthernet 2/0 autoconfigured subinterfaces
PPPoE interface FastEthernet 2/0 has 1 active connections,
out of 1 configured subinterfaces
Assigned profile (any)
: pppoetest
PPPoE Statistics
Counters:
PADI received
44
PADI transmitted
0
Copyright © 2010, Juniper Networks, Inc.
425
JunosE 11.3.x Link Layer Configuration Guide
PADO received
0
PADO transmitted
10
PADR received
10
PADR transmitted
0
PADS received
0
PADS transmitted
10
PADT received
0
PADT transmitted
9
PADM received
0
PADM transmitted
0
PADN received
0
PADN transmitted
0
PAD packets received
PAD packets transmitted
54
29
Invalid PAD Packets:
Invalid Version
Invalid PAD Code
Invalid PAD Tags
Invalid PAD Tag length
Invalid PAD Type
Invalid PADI Session
Invalid PADR Session
Invalid PAD packet length
Invalid PAD packets
Total Invalid PAD packets
0
0
0
0
0
0
0
0
0
0
Insufficient Resources 0
Lockout Configuration (seconds): Min 5, Max 60
Total clients in active lockouts: 0
Total clients in lockout grace period: 0
•
See show pppoe interface.
show pppoe interface summary
•
Use to display the operational and administrative status of all configured PPPoE
interfaces.
•
Field descriptions
•
Total PPPoE interfaces—Number of configured PPPoE interfaces included in summary
•
Administrative Status
•
426
•
Up—Number of interfaces not affected by manual administrative intervention
•
Down—Number of interfaces that cannot flow because of manual administrative
intervention
Operational Status
•
Up—Number of interfaces that are operational
•
Down—Number of interfaces that are not operational
Copyright © 2010, Juniper Networks, Inc.
Chapter 12: Configuring Point-to-Point Protocol over Ethernet
•
•
LowerLayerDown—Number of interfaces that are not operational because an
underlying interface is down
•
NotPresent—Number of interfaces that are not operational because hardware is
unavailable
Example
host1:01#show pppoe interface summary
Total PPPoE interfaces: 16
Administrative Status:
Up: 15
Down: 1
Operational Status:
Up:
Down:
LowerLayerDown:
NotPresent:
•
15
1
1
0
See show pppoe interface.
show pppoe-service-name-table
•
Use to display the contents of a PPPoE service name table configured on the router.
•
The command displays the table name, the name of all service name entries in the
table, and the action (terminate or drop) associated with the service name entries.
•
You must specify the name of the PPPoE service name table configured with the
pppoe-service-name-table command from Global Configuration mode.
•
To display the names of PPPoE service name tables that you can specify to complete
the command, issue the show pppoe-service-name-table name ? command.
•
Field descriptions
•
•
Service Name Table—Name of the PPPoE service name table configured with the
pppoe-service-name-table command
•
Empty service name action—terminate or drop
•
Service name—Name of the custom service name tag configured with the service
command
•
action—Action (terminate or drop) associated with the service name tags configured
using the action keyword with the service command.
•
Unknown service name action—terminate or drop.
Example 1—Displays the names of PPPoE service name tables that you can specify to
complete the command
host1#show pppoe-service-name-table name ?
myDefaultTable
myDefaultTable service-name-table
myServiceTable1 myServiceTable1 service-name-table
myServiceTable2 myServiceTable2 service-name-table
myServiceTable3 myServiceTable3 service-name-table
Copyright © 2010, Juniper Networks, Inc.
427
JunosE 11.3.x Link Layer Configuration Guide
•
Example 2—Displays the contents of a default PPPoE service name table with no
specific service name entries
host1#show pppoe-service-name-table name myDefaultTable
Service Name Table myDefaultTable
Empty service name action: terminate
Unknown service name action: drop
•
Example 3—Displays the contents of a PPPoE service name table that includes: empty
service name tag and associated action, terminate; two custom service tags and their
associated actions (terminate and drop); and the unknown service name tag and its
default action (terminate).
host1#show pppoe-service-name-table name myServiceTable1
Service Name Table myServiceTable1
Empty service name action: terminate
Service name: myISPService action: terminate
Service name: myQOSClass1 action: drop
Unknown service name action: terminate
•
Example 4—Displays the names of all PPPoE service name tables configured on the
router
host1#show pppoe-service-name-table brief
Service-Name Table:
myServiceTable1
myServiceTable2
•
See show pppoe-service-name-table.
•
Use to display parameters for PPPoE subinterfaces.
•
If you do not specify a subinterface, the router displays the configured PPPoE
subinterface number and status for all configured PPPoE subinterfaces.
•
If you specify an interface with no subinterface, the router displays the status for the
subinterfaces associated with the interface.
•
If you specify an interface and subinterface, the router displays detailed parameters
available for that subinterface.
•
To display configuration, status, and statistics information, use the full keyword.
•
Field descriptions
show pppoe subinterface
•
PPPoE subinterface—Interface specifier
•
Status—Operational status of the interface. Possible values are:
•
428
•
operStatusUp—Interface or subinterface is operational
•
Down—Interface or subinterface is not operational
•
LowerLayerDown—Subinterface is not operational because an underlying interface
or subinterface is down
URL String—URL string sent in the PADM message to PPPoE clients
Copyright © 2010, Juniper Networks, Inc.
Chapter 12: Configuring Point-to-Point Protocol over Ethernet
•
•
MOTM String—Message of the minute string sent in the PADM message to PPPoE
clients
•
session id—Session ID of the subinterface
•
source MAC address—MAC address of PPPoE client
•
MTU—Maximum transfer unit (MTU) value; when derived from the PPPoE MTU tag,
the value can only be determined from an active session.
•
In Octets—Number of octets received on the subinterface
•
Out Octets—Number of octets transmitted on the subinterface
•
In Packets—Number of packets received on the subinterface
•
Out Packets—Number of packets transmitted on the subinterface
Example 1
host1:v0#show pppoe subinterface fastEthernet 1/1.1.1
PPPoE subinterface fastEthernet 1/1.1.1 is operStatusUp
URL String: http://www.urlofinterest.com
MOTM String: a horse walks into a bar
PPPoE subinterface fastEthernet 1/1.1.1 has a session id of 1
PPPoE Statistics
In Octets: 480
Out Octets: 256
In Packets: 8
Out Packets: 8
•
Example 2
host1:v0#show pppoe subinterface full
show pppoe subinterface fullPPPoE subinterface
operStatusUp (dynamic)
PPPoE subinterface FastEthernet 2/0.11 has
PPPoE subinterface FastEthernet 2/0.11 has
0090.1a40.280a
PPPoE subinterface FastEthernet 2/0.11 has
PPPoE Statistics
In Octets: 165922
Out Octets: 108283
In Packets: 3607
Out Packets: 3608
•
FastEthernet 2/0.11 is
a session id of 8
source MAC address
a MTU of 1494
See show pppoe subinterface.
show pppoe subinterface summary
•
Use to display the operational and administrative status of all configured PPPoE
subinterfaces.
•
Field descriptions
•
Total PPPoE subinterfaces—Number of configured PPPoE subinterfaces included
in summary
•
Administrative Status
Copyright © 2010, Juniper Networks, Inc.
429
JunosE 11.3.x Link Layer Configuration Guide
•
•
•
Up—Number of subinterfaces not affected by manual administrative intervention
•
Down—Number of subinterfaces that cannot flow because of manual
administrative intervention
Operational Status
•
Up—Number of subinterfaces that are operational
•
Down—Number of subinterfaces that are not operational
•
LowerLayerDown—Number of subinterfaces that are not operational because an
underlying interface is down
•
NotPresent—Number of subinterfaces that are not operational because hardware
is unavailable
Example
host1:01#show pppoe subinterface summary
Total PPPoE subinterfaces: 116
Administrative Status:
Up: 115
Down: 1
Operational Status:
Up:
Down:
LowerLayerDown:
NotPresent:
115
1
1
0
•
See show pppoe subinterface.
•
Use to display information about profiles.
•
To display information about a specific profile, use the name keyword.
•
To display a list of profiles configured on the router, use the brief keyword.
•
Field descriptions
show profile
430
•
Profile—Name of the profile that is displayed
•
IP address—IP address and subnet mask of the interface, or none if the interface is
unnumbered
•
Unnumbered interface—Specifier for the unnumbered interface, or none if the
interface is numbered
•
Router—Name of the virtual router (VR) assigned to the profile; interfaces created
by the profile are attached to this VR
•
Directed Broadcast—Enabled or disabled
•
ICMP Redirects—Enabled or disabled
Copyright © 2010, Juniper Networks, Inc.
Chapter 12: Configuring Point-to-Point Protocol over Ethernet
•
Access Route Addition—Enabled or disabled
•
Network Address Translation—Enabled or disabled; domain location (inside or
outside)
•
Source-Address Validation—Enabled or disabled
•
Ignore DF Bit—Enabled or disabled
•
Filter Option Packets—Router filters out packets with IP options; enabled or disabled
•
Administrative MTU—MTU size configured on the profile
•
TCP MSS value—Maximum segment size for TCP SYN packets traveling through the
interface
•
Inactivity Timer—Inactivity timer setting; enabled or disabled
•
Route Map Name—Route map applied to the IP interface subscriber; enabled or
disabled
•
Auto Detect—Router automatically detects packets that do not match any entries
in the demultiplexer table; enabled or disabled
•
Auto Configure—Dynamic creation of subscriber interfaces on a primary IP interface;
enabled or disabled
•
IGMP—Enabled or disabled
•
static-groups—Displays address of any static groups configured for IGMP
•
Input policy—Name of input policy and whether statistics are enabled or disabled
•
Output policy—Name of output policy and whether statistics are enabled or disabled
•
PPP Keepalive—PPP keepalive period, in seconds
•
PPP Magic Number—Enabled or disabled
•
PPP Peer DNS Priority—Enabled or disabled
•
PPP Peer WINS Priority—Enabled or disabled
•
PPP Authentication—Type of authentication configured: PAP, CHAP, or none
•
PPP Authentication Router—Name of authentication virtual router
•
PPP Negotiate MRU—MRU configured for the profile
•
PPP Packet Log—Enabled or disabled
•
PPP State Log—Enabled or disabled
•
PPP Chap Challenge Length—Minimum and maximum Chap Challenge length
•
PPP Passive Mode—Enabled or disabled
Copyright © 2010, Juniper Networks, Inc.
431
JunosE 11.3.x Link Layer Configuration Guide
•
•
PPP Multilink—Enabled or disabled
•
PPP IPCP netmask option—Enabled or disabled
•
PPP AAA Profile—AAA profile associated with this PPP interface
•
PPP Multilink Fragmentation—Enabled or disabled
•
PPP Multilink Fragment Size—Multilink fragment size for this PPP interface
•
PPP Multilink Reassembly—Enabled or disabled
•
PPP Multilink Mrru—Multilink MRRU value for this PPP interface
•
PPP Initiate IP—Initiation of IPv4 over this PPP interface; enabled or disabled
•
PPP Initiate IPv6—Initiation of IPv6 over this PPP interface; enabled or disabled
•
PPPoE Max Sessions—Maximum number of PPPoE subinterfaces that can be on an
interface
•
PPPoE Always-offer—Router offers to set up a session for the client, even if the
router has insufficient resources to establish a session; enabled or disabled
•
PPPoE Remote-Circuit-Id—The router captures and processes a vendor-specific tag
containing a remote circuit ID transmitted from a digital subscriber line access
multiplexer (DSLAM); enabled or disabled
•
PPPoE Log PPPoeControlPacket—Enabled or disabled
•
PPPOE duplicate-protect—Enabled or disabled
•
PPPoE ACNAME—Access concentrator name
•
PPPoE URL—URL sent in PADM message to PPPoE clients
•
PPPoE MOTM—Message of the minute sent in the PADM message to PPPoE clients
•
PPPoE Service-Name Table—Name of the PPPoE service name table, if configured
for the specified profile
Example—Displays configuration information for a PPPoE profile assigned to a dynamic
interface
host1#show profile name pppoeProfile
Profile
: pppoeProfile
Unnumbered interface on
: loopback 1
Router
: default
Directed Broadcast
: Disabled
ICMP Redirects
: Disabled
Access Route Addition
: Enabled
Network Address Translation: Disabled
Source-Address Validation : Disabled
Ignore DF Bit
: Disabled
Filter Option Packets
: Disabled
Administrative MTU
: 1500
TCP MSS value
: 0
432
Copyright © 2010, Juniper Networks, Inc.
Chapter 12: Configuring Point-to-Point Protocol over Ethernet
Inactivity Timer
Route Map Name
Auto Detect
Auto Configure
:
:
:
:
Disabled
Disabled
Disabled
Disabled
IGMP
: Enabled
static-groups
:
Input policy: bobb statistics enabled
Output policy: bobb statistics enabled
PPP Keepalive
:
PPP Magic Number
:
PPP Peer DNS Priority
:
PPP Peer WINS Priority
:
PPP Authentication
:
PPP Authentication Router
:
PPP Negotiate MRU
:
PPP Packet Log
:
PPP State Log
:
PPP Chap Challenge Length
:
PPP Passive Mode
:
PPP Multilink
:
PPP IPCP Netmask Option
:
PPP AAA Profile
:
PPP Multilink Fragmentation :
PPP Multilink Fragment Size :
PPP Multilink Reassembly
:
PPP Multilink Mrru
:
PPP Initiate IP
PPP Initiate IPv6
PPPoE Max Sessions
:
PPPoE Always-offer
:
PPPoE Remote-Circuit-Id
:
PPPoE Log PPPoeControlPacket:
PPPoE duplicate-protect
:
PPPoE ACNAME
:
PPPoE URL
:
PPPoE MOTM
:
PPPoE Service-Name table
:
30
enabled
disabled
disabled
pap/chap
(use lower layer MRU)
disabled
disabled
16 - 32
disabled
disabled
disabled
disabled
(use MTU)
disabled
(use MRU)
: disabled
: disabled
2
Disabled
Enabled
Disabled
Enabled
CYM9876
http://www.urlofinterest.com
goodmorning
myServiceTable1
•
See show profile.
•
Use to display the current override settings configured on the RADIUS client (LNS) for
the NAS-IP-Address [4], NAS-Port-Id [87], Calling-Station-Id [31], and NAS-Identifier
[32] RADIUS attributes.
•
Field descriptions
show radius override
•
nas-ip-addr—Override setting for the NAS-IP-Address attribute
•
nas-port-id—Override setting for the NAS-Port-Id attribute; value is remote-circuit-id
if configured with radius override nas-port-id remote-circuit-id command
Copyright © 2010, Juniper Networks, Inc.
433
JunosE 11.3.x Link Layer Configuration Guide
•
•
calling-station-id—Override setting for the Calling-Station-Id attribute; value is
remote-circuit-id if configured with radius override calling-station-id
remote-circuit-id command
•
nas-info—Virtual router that generates the NAS-IP-Address and NAS-Identifier
attributes for AAA broadcast accounting packets; current virtual router or
authentication virtual router
Example
host1#show radius override
nas-ip-addr:
nas-ip-addr
nas-port-id:
remote-circuit-id
calling-station-id: remote-circuit-id
nas-info:
from current virtual router
•
See show radius override.
show radius remote-circuit-id-delimiter
•
Use to display the delimiter character configured to set off components in the PPPoE
remote circuit ID value captured from a DSLAM.
•
The default delimiter character is #.
•
Example
host1#show radius remote-circuit-id-delimiter
%
•
See show radius remote-circuit-id-delimiter.
show radius remote-circuit-id-format
•
Use to display the format configured for the PPPoE remote circuit ID value captured
from a DSLAM.
•
If the PPPoE remote circuit ID value is configured to include any or all of the
agent-circuit-id, agent-remote-id, and nas-identifier components, the display lists the
components included and the order in which they appear.
•
If the PPPoE remote circuit ID value is configured to use the format for the dsl-forum-1
keyword of “radius remote-circuit-id-format” on page 418 , the display indicates that
this format is in effect.
•
The default format is agent-circuit-ID.
•
Example
host1#show radius remote-circuit-id-format
nas-identifier agent-circuit-id agent-remote-id
•
434
See show radius remote-circuit-id-format.
Copyright © 2010, Juniper Networks, Inc.
Chapter 12: Configuring Point-to-Point Protocol over Ethernet
Troubleshooting
Use the pppoeControlPacket log to diagnose problems on your PPPoE interfaces.
log severity debug pppoeControlPacket
•
Use to configure a packet trace log for a PPPoE interface. You must specify a PPPoE
major interface.
•
Specify one of the following interface types and a corresponding interface specifier.
For more information, see Interface Types and Specifiers in JunosE Command Reference
Guide.
•
fastEthernet
•
gigabitEthernet
•
atm
•
tenGigabitEthernet
•
The packet trace log for a PPPoE interface displays only the first 256 bytes of packet
data. Data in excess of 256 bytes does not appear in the packet trace log.
•
You also configure logging to direct the output to a specific destination. For information,
see Overview of System Logging.
•
Example
host1(config-if)#ip address 164.10.6.71 255.255.255.0
host1(config-if)#log severity debug pppoeControlPacket atm 10/0.1
host1:v0#DEBUG 07/25/2000 15:13:19 pppoeControlPacket (interface atm
10/0.1): PADI rx from 00-09-01-a0-00-2e
DEBUG 07/25/2000 15:13:19 pppoeControlPacket (interface atm 10/0.1): PADO
tx to 00-09-01-a0-00-2e
DEBUG 07/25/2000 15:13:19 pppoeControlPacket (interface atm 10/0.1): PADR
rx from 00-09-01-a0-00-2e
DEBUG 07/25/2000 15:13:19 pppoeControlPacket (interface atm 10/0.1): PADS
tx to 00-09-01-a0-00-2e, connection made using session id 3 on sub
interface 1
RX-a0-00-2e:v0#
RX-a0-00-2e:v0#
RX-a0-00-2e:v0#
RX-a0-00-2e:v0#
RX-a0-00-2e:v0#
RX-a0-00-2e:v0#
RX-a0-00-2e:v0#config t
Enter configuration commands, one per line. End with CNTL/Z.
RX-a0-00-2e:v0(config)#interface atm 10/1.1.1
RX-a0-00-2e:v0(config-if)#ppp shut
RX-a0-00-2e:v0(config-if)#DEBUG 07/25/2000 15:13:38 pppoeControlPacket
(interface atm 10/0.1): PADT rx from 00-09-01-a0-00-2e
RX-a0-00-2e:v0(config-if)#
RX-a0-00-2e:v0(config-if)#no ppp shut
RX-a0-00-2e:v0(config-if)#pppoe test
RX-a0-00-2e:v0(config-if)#DEBUG 07/25/2000 15:13:49 pppoeControlPacket
(interface atm 10/0.1): PADI rx from 00-09-01-a0-00-2e
DEBUG 07/25/2000 15:13:49 pppoeControlPacket (interface atm 10/0.1): PADO
tx to 00-09-01-a0-00-2e
Copyright © 2010, Juniper Networks, Inc.
435
JunosE 11.3.x Link Layer Configuration Guide
DEBUG 07/25/2000 15:13:49 pppoeControlPacket (interface atm 10/0.1): PADR
rx from 00-09-01-a0-00-2e
DEBUG 07/25/2000 15:13:49 pppoeControlPacket (interface atm 10/0.1): PADS
tx to 00-09-01-a0-00-2e, connection made using session id 4 on sub
interface 1
RX-a0-00-2e:v0(config-if)#
RX-a0-00-2e:v0(config-if)#exit
•
436
See log severity.
Copyright © 2010, Juniper Networks, Inc.
CHAPTER 13
Configuring Bridged IP
E Series routers support bridged IP (1483) interfaces.
This chapter contains the following sections:
•
Overview on page 437
•
Platform Considerations on page 438
•
References on page 439
•
Before You Configure Bridged IP on page 439
•
Configuring Bridged IP on page 440
Overview
You can configure a bridged IP interface to manage IP packets that are encapsulated
inside an Ethernet frame running over a permanent virtual circuit (PVC).
When you configure a bridged IP interface, it automatically performs proxy Address
Resolution Protocol (ARP). You can also configure the router as a relay agent that
forwards Dynamic Host Configuration Protocol (DHCP) broadcasts.
Proxy ARP
Proxy ARP allows your router to respond to ARP requests on behalf of an Ethernet end
node.
The router performs proxy ARP for the ARP requests that come in over the bridged IP
interface when both of the following conditions are met:
•
The IP address in the ARP request matches an entry in the routing table.
•
The route is on a different interface than the one on which the router received the ARP
request.
If you specify that the bridged IP interface performs unrestricted proxy ARP, it also
performs proxy ARP when the route is on the interface that received the ARP request.
In most situations, do not configure the router to perform unrestricted proxy ARP. Do so
for special situations, such as when cable modems are used. When an IP client broadcasts
the ARP request across the Ethernet wire, the end node with the correct IP address
responds to the ARP request and provides the correct MAC address. If the unrestricted
Copyright © 2010, Juniper Networks, Inc.
437
JunosE 11.3.x Link Layer Configuration Guide
proxy ARP feature is enabled, the router response is redundant and might fool the IP
client into determining that the destination MAC address within its own subnet is the
same as the address of the router.
DHCP
DHCP provides a mechanism through which hosts using TCP/IP can obtain protocol
configuration parameters automatically from a DHCP server on the network.
The most important configuration parameter carried by DHCP is the IP address. A host
must be initially assigned a specific IP address that is appropriate to the network to which
the computer is attached, and that is not assigned to any other host on that network. If
you move a host to a new network, you must give it a new IP address.
DHCP also carries other important configuration parameters such as the subnet mask,
default router, and Domain Name System (DNS) server.
An IP client contacts a DHCP server for configuration parameters. The DHCP server is
typically centrally located and operated by the network administrator. Because a network
administrator manages the server, DHCP clients can obtain reliable parameters
appropriate to the current network architecture.
For information about DHCP, see DHCP Overview Information.
Platform Considerations
You can configure bridged IP interfaces on the following E Series Broadband Services
Routers:
•
E120 router
•
E320 router
•
ERX1440 router
•
ERX1410 router
•
ERX710 router
•
ERX705 router
•
ERX310 router
Module Requirements
For information about the modules that support bridged IP interfaces on ERX14xx models,
ERX7xx models, and the ERX310 router:
•
See ERX Module Guide, Table 1, Module Combinations for detailed module specifications.
•
See ERX Module Guide, Appendix A, Module Protocol Support for information about the
modules that support bridged IP.
For information about the modules that support bridged IP interfaces on the E120 and
E320 routers:
438
Copyright © 2010, Juniper Networks, Inc.
Chapter 13: Configuring Bridged IP
•
See E120 and E320 Module Guide, Table 1, Modules and IOAs for detailed module
specifications.
•
See E120 and E320 Module Guide, Appendix A, IOA Protocol Support for information
about the modules that support bridged IP.
Interface Specifiers
The configuration task examples in this chapter use the slot/port[.subinterface ] format
to specify the ATM physical interface on which you want to configure bridged IP. However,
the interface specifier format that you use depends on the router that you are using.
For ERX7xx models, ERX14xx models, and ERX310 router, use the slot/port[.subinterface
] format. For example, the following command specifies ATM 1483 subinterface 10 on
slot 0, port 1 of an ERX7xx model, ERX14xx model, or ERX310 router.
host1(config)#interface atm 0/1.10
For E120 and E320 routers, use the slot/adapter/port[.subinterface ] format, which includes
an identifier for the bay in which the I/O adapter (IOA) resides. In the software, adapter
0 identifies the right IOA bay (E120 router) and the upper IOA bay (E320 router); adapter
1 identifies the left IOA bay (E120 router) and the lower IOA bay (E320 router). For
example, the following command specifies ATM 1483 subinterface 20 on slot 5, adapter
0, port 0 of an E320 router.
host1(config)#interface atm 5/0/0.20
For more information about supported interface types and specifiers on E Series routers,
see Interface Types and Specifiers in JunosE Command Reference Guide.
References
For more information about bridged IP, consult RFC 2684—Multiprotocol Encapsulation
over ATM Adaptation Layer 5 (September 1999). Note that RFC 2684 obsoletes RFC
1483.
Before You Configure Bridged IP
Before you configure bridged IP on an ATM interface, verify that:
•
You have correctly installed a module that supports bridged IP. For information, see
ERX Module Guide, Appendix A, Module Protocol Support (on ERX7xx models, ERX14xx
models, and the ERX310 router) or E120 and E320 Module Guide, Appendix A, IOA
Protocol Support (on the E120 or the E320 router).
•
Each configured line can transmit data to and receive data from your switch
connections.
Table 25 on page 440 lists the prerequisite tasks for configuring bridged IP and the resources
that you can consult to learn how to perform these tasks.
Copyright © 2010, Juniper Networks, Inc.
439
JunosE 11.3.x Link Layer Configuration Guide
Table 25: Prerequisite Tasks for Configuring Bridged IP
To Learn About
See
Preconfiguration and hardware
diagnostic procedures
ERX Hardware Guide
E120 and E320 Hardware Guide
Configuring T3 and E3 line modules
Chapter Configuring T3 and E3 Interfaces in JunosE
Physical Layer Configuration Guide
Configuring OC3 line modules
Chapter Configuring Unchannelized OCx/STMx
Interfaces in JunosE Physical Layer Configuration Guide
Also have the following information available:
•
Interface specifiers for the ATM interfaces on which you want to configure bridged IP
For more information about specifying ATM interfaces and subinterfaces on E Series
routers, see Interface Types and Specifiers in JunosE Command Reference Guide.
•
Subinterface numbers for each logical interface that you want to create
•
Virtual path and channel numbers for each virtual circuit that you want to create
•
IP addresses and subnet mask assignments for IP interfaces
•
IP address of the DHCP server
Configuring Bridged IP
To configure an ATM interface using bridged IP encapsulation:
1.
Configure a physical interface.
host1(config)#interface atm 0/1
2. Configure the subinterface.
host1(config-if)#interface atm 0/1.20
3. Configure a PVC on the subinterface by specifying the virtual circuit descriptor (VCD),
the virtual path identifier (VPI), the virtual channel identifier (VCI), and the
encapsulation type.
host1(config-if)#atm pvc 10 22 100 aal5snap
4. Configure bridged IP encapsulation.
host1(config-if)#encapsulation bridge1483
5. Assign an IP address and subnet mask to the PVC.
host1(config-subif)#ip address 192.168.10.20 255.255.255.0
440
Copyright © 2010, Juniper Networks, Inc.
Chapter 13: Configuring Bridged IP
NOTE: You can also assign an IP template to the interface or create an
unnumbered interface instead of assigning an IP address. For details, see
chapter Configuring IP in JunosE IP, IPv6, and IGP Configuration Guide.
6. (Optional) Use the appropriate show commands to verify your configuration.
host1#show atm interface 0/1
host1#show atm vc 0/1 10
host1#show atm subinterface 0/1.20
For more information about using these commands, see “Monitoring ATM” on page 67
in “Configuring ATM” on page 3.
atm pvc
•
Use to configure a PVC on an ATM interface.
•
The following fields are mandatory:
•
vcd—Unique number that identifies a virtual circuit in the range 1–2147483647. The
VCD value has no relationship to the VPI and VCI values and has meaning only to
the E Series router.
•
vpi—8-bit field in the ATM cell header. The VPI value is unique on a single link, not
throughout the ATM network, because it has meaning only to the E Series router.
The VPI value must match the value on the ATM switch.
NOTE: Do not set both the VPI and VCI values to zero.
•
•
vci—16-bit field in the ATM cell header. The VCI value is unique on a single link, not
throughout the ATM network, because it has meaning only to the router. You cannot
set both the VPI and VCI to 0.
•
encapsulation type:
•
aal5snap—Specifies a logical link control (LLC) encapsulated circuit. An
LLC/Subnetwork Access Protocol (LLC/SNAP) header precedes the protocol
datagram.
•
aal5muxip—Specifies a multiplexed circuit used for IP only.
Example
host1(config-if)#atm pvc 10 22 100 aal5snap
•
Use the no version to remove the specified PVC.
•
See atm pvc.
encapsulation bridge1483
Copyright © 2010, Juniper Networks, Inc.
441
JunosE 11.3.x Link Layer Configuration Guide
•
Use to configure bridged IP as the encapsulation method on an interface.
•
Use the unrestrictedProxyArp keyword to allow the router to perform unrestricted
processing of ARP requests even if the route is on the same interface on which the
request is received. See “Proxy ARP” on page 437 for details.
•
Example
host1(config-if)#encapsulation bridge1483
•
Use the no version to remove bridged IP as the encapsulation method on the interface.
•
See encapsulation bridge1483.
•
Use to configure an ATM interface.
•
To specify an ATM interface for ERX7xx models, ERX14xx models, and ERX310 router,
use the slot/port.[subinterface ] format.
interface atm
•
•
slot—Number of the chassis slot
•
port—Port number on the I/O module
•
subinterface—Number of the subinterface in the range 1–2147483647
To specify an ATM interface for E120 and E320 routers, use the
slot/adapter/port[.subinterface ] format.
•
slot—Number of the chassis slot
•
adapter—Identifier for the IOA within the E320 chassis, either 0 or 1, where:
•
0 indicates that the IOA is installed in the right IOA bay (E120 router) or the upper
IOA bay (E320 router).
•
1 indicates that the IOA is installed in the left IOA bay (E120 router) or the lower
IOA bay (E320 router).
•
port—Port number on the IOA
•
subinterface—Number of the subinterface in the range 1–2147483647
•
For more information, see “Creating a Basic Configuration” on page 21 in “Configuring
ATM” on page 3.
•
Examples
host1(config)#interface atm 3/1.20
host1(config)#interface atm 5/0/1.20
442
•
Use the no version to remove the ATM subinterface or the logical interface.
•
See interface atm.
Copyright © 2010, Juniper Networks, Inc.
CHAPTER 14
Configuring Bridged Ethernet
This chapter describes how to configure bridged Ethernet on E Series routers.
E Series routers also support bridged Ethernet on dynamic interfaces. See “Configuring
Dynamic Interfaces” on page 511, for details.
This chapter contains the following sections:
•
Overview on page 443
•
Platform Considerations on page 446
•
References on page 447
•
Configuring Bridged Ethernet on page 447
•
Configuring VLANs over Bridged Ethernet on page 452
•
Configuring S-VLANs over Bridged Ethernet on page 457
•
Configuring the MTU Size for Bridged Ethernet on page 459
•
Monitoring Bridged Ethernet on page 460
Overview
Bridged Ethernet allows multiple upper-layer interface types (IP and PPPoE) to be
simultaneously multiplexed over the same interface. You can set up the router to either
terminate interfaces and route data or to pass data transparently through the router to
another terminating device. This capability supports multiple client devices that use both
IP and Point-to-Point Protocol over Ethernet (PPPoE) encapsulation over an Ethernet
LAN.
NOTE: Although connection-based forwarding is not supported on any
E Series router, as an alternative, you can configure a local cross-connect,
which uses layer 2 services over MPLS to transmit data between two layer 2
interfaces that reside on the same E Series router. Configuration of local
cross-connects is supported on all E Series routers. For more information
about configuring local cross-connects, see chapter Configuring Layer 2
Services over MPLS in JunosE BGP and MPLS Configuration Guide.
Copyright © 2010, Juniper Networks, Inc.
443
JunosE 11.3.x Link Layer Configuration Guide
Bridged Ethernet Application
Figure 43 on page 444 shows an example of a client computer using IP/PPP/PPPoE and
an Internet gaming system running IP, connecting to the E Series router over the same
ATM PVC. The client computer and gaming system can connect to an E Series router via
an xDSL modem over a single ATM PVC, and the router can forward these two data
streams independently. When the router receives the two data streams, it uses the
Ethertype contained in the bridged Ethernet header to select which upper interface (IP
or PPPoE) receives the frame.
In Figure 43 on page 444, IP and PPPoE interfaces are configured so that the non-PPPoE
IP traffic is received by the IP interface, and the IP/PPP/PPPoE traffic is received by the
PPPoE interface. Since the router receives these data streams on different IP interfaces,
they may be routed independently.
Figure 43: Bridged Ethernet Topology, Router Terminating and Routing Traffic
Assigning MAC Addresses
When you create a bridged Ethernet interface, the system media access control (MAC)
address is assigned to the interface by default. However, you can assign a specific MAC
address to each statically configured bridged Ethernet interface. For example, if multiple
statically configured bridged Ethernet interfaces are connected to the same device, using
specific MAC addresses enables the connected device to select the correct ATM port or
VC to use.
You configure a specific MAC address when you create the bridged Ethernet interface.
If you want to modify an existing MAC address, you must remove the interface and create
it again. Also, you cannot configure multicast MAC addresses on bridged Ethernet
interfaces.
VLAN and S-VLAN Configurations
Bridged Ethernet interfaces on E Series routers support the configuration of virtual local
area networks (VLANs) and stacked virtual local area networks (S-VLANs). A VLAN
permits multiplexing multiple higher-level protocols over a single physical port. An S-VLAN
444
Copyright © 2010, Juniper Networks, Inc.
Chapter 14: Configuring Bridged Ethernet
provides a two-level VLAN tag structure, which extends the VLAN ID space to more than
16 million VLAN tags.
Specifically, you can statically configure the following higher-level protocols over a VLAN
or an S-VLAN subinterface that is stacked above a bridged Ethernet interface:
•
IP
•
MPLS
•
PPPoE
•
Transparent bridging
Figure 44 on page 445 illustrates the interface stacking supported on E Series routers for
VLANs over bridged Ethernet.
Figure 44: Interface Stacking for VLANs over Bridged Ethernet
VLANs and S-VLANs configured over bridged Ethernet interfaces provide the same basic
capabilities as VLANs and S-VLANs configured over Ethernet interfaces, with the following
exception:
•
S-VLAN oversubscription is not supported on bridged Ethernet interfaces.
After you configure the bridged Ethernet interface, you configure the VLANs, S-VLANs,
and the supported higher-level protocols in the same way that you configure them over
Ethernet interfaces.
For more information, see:
•
“Configuring VLAN and S-VLAN Subinterfaces” on page 167 for introductory information
about VLANs and S-VLANs.
Copyright © 2010, Juniper Networks, Inc.
445
JunosE 11.3.x Link Layer Configuration Guide
•
“Configuring VLANs over Bridged Ethernet” on page 452 and “Configuring S-VLANs over
Bridged Ethernet” on page 457 for examples that illustrate VLAN and S-VLAN
configurations over bridged Ethernet.
Platform Considerations
You can configure bridged Ethernet on the following E Series Broadband Services Routers:
•
E120 router
•
E320 router
•
ERX1440 router
•
ERX1410 router
•
ERX710 router
•
ERX705 router
•
ERX310 router
Module Requirements
For information about the modules that support bridged Ethernet on ERX14xx models,
ERX7xx models, and the ERX310 router:
•
See ERX Module Guide, Table 1, Module Combinations for detailed module specifications.
•
See ERX Module Guide, Appendix A, Module Protocol Support for information about the
modules that support bridged Ethernet.
For information about the modules that support bridged Ethernet on the E120 and E320
routers:
•
See E120 and E320 Module Guide, Table 1, Modules and IOAs for detailed module
specifications.
•
See E120 and E320 Module Guide, Appendix A, IOA Protocol Support for information
about the modules that support bridged Ethernet.
Interface Specifiers
The configuration task examples in this chapter use the slot/port[.subinterface ] format
to specify the ATM physical interface on which you want to configure bridged Ethernet.
However, the interface specifier format that you use depends on the router that you are
using.
For ERX7xx models, ERX14xx models, and ERX310 router, use the slot/port[.subinterface
] format. For example, the following command specifies ATM 1483 subinterface 10 on
slot 0, port 1 of an ERX7xx model, ERX14xx model, or ERX310 router.
host1(config)#interface atm 0/1.10
446
Copyright © 2010, Juniper Networks, Inc.
Chapter 14: Configuring Bridged Ethernet
For E120 and E320 routers, use the slot/adapter/port[.subinterface ] format, which includes
an identifier for the bay in which the I/O adapter (IOA) resides. In the software, adapter
0 identifies the right IOA bay (E120 router) and the upper IOA bay (E320 router); adapter
1 identifies the left IOA bay (E120 router) and the lower IOA bay (E320 router). For
example, the following command specifies ATM 1483 subinterface 20 on slot 5, adapter
0, port 0 of an E320 router.
host1(config)#interface atm 5/0/0.20
For more information about supported interface types and specifiers on E Series routers,
see Interface Types and Specifiers in JunosE Command Reference Guide.
References
For more information about bridged Ethernet, consult the following resources:
•
RFC 826—An Ethernet Address Resolution Protocol (November 1982)
•
RFC 2684—Multiprotocol Encapsulation over ATM Adaptation Layer 5 (September
1999)
Configuring Bridged Ethernet
This section shows how to configure IP with PPPoE terminated at the E Series router.
With each step, an illustration shows how the router is building the interface columns.
Configuring IP with PPPoE Terminated at the Router
This section shows how to create IP with PPPoE interfaces that terminate the connection
and route the data received on the PVC, as shown in the example in Figure 43 on page 444.
To create a terminated PVC:
1.
Create an ATM 1483 subinterface and associated PVC.
host1(config)#interface atm 9/1.1 point-to-point
host1(config-subif)#atm pvc 1 0 32 aal5snap 0 0 0
2. Encapsulate the ATM 1483 subinterface with bridged Ethernet. The use of the
encapsulation keyword implies that the bridged Ethernet interface is the only interface
stacked directly above the ATM 1483 subinterface. As a result, the bridged Ethernet
interface cannot have a peer interface stacked above the same lower-layer interface.
host1(config-subif)#encapsulation bridge1483
3. Create a PPPoE major interface over the bridged Ethernet interface. This command
does not use the encapsulation keyword.
host1(config-subif)#pppoe
Copyright © 2010, Juniper Networks, Inc.
447
JunosE 11.3.x Link Layer Configuration Guide
4. Create an IP interface over the bridged Ethernet interface as a peer to the PPPoE
interface.
host1(config-subif)#ip address 160.1.0.1 255.255.255.0
5. (Optional) Set up the router to validate MAC addresses on the IP interface.
host1(config-subif)#ip mac-validate strict
6. Exit the subinterface context.
host1(config-subif)#exit
7. Create a PPPoE subinterface over the major interface.
host1(config)#pppoe subinterface atm 9/1.1.1
8. Configure PPP encapsulation over the PPPoE subinterface, and the IP interface over
the PPP interface.
host1(config-subif)#encapsulation ppp
host1(config-subif)#ip address 160.1.1.1 255.255.255.0
atm pvc
•
448
Use to configure a PVC on an ATM interface. Specify one of the following encapsulation
types:
Copyright © 2010, Juniper Networks, Inc.
Chapter 14: Configuring Bridged Ethernet
•
•
aal5snap—Specifies a logical link control (LLC) encapsulated circuit;
LLC/Subnetwork Access Protocol (LLC/SNAP) header precedes the protocol
datagram.
•
aal5mux ip—Specifies a VC multiplexed circuit. This option is used for IP only.
Example
host1(config-subif)#atm pvc 1 0 32 aal5snap 0 0 0
•
Use the no version to remove the specified PVC.
•
See atm pvc.
•
Use to configure bridged Ethernet as the encapsulation method on an interface, and
to optionally assign the MAC address to the interface.
•
Use the mac-address keyword to configure a specific MAC address for the interface.
Otherwise, the system MAC address is used. The same MAC address can be used on
multiple interfaces.
•
If the MAC address is configured, you must use the same MAC address whenever you
reenter the encapsulation bridge1483 command for the interface.
•
The MAC address can be configured only when the interface is created. To change a
MAC address, you must remove the interface and create it again.
•
Example
encapsulation bridge1483
host1(config-subif)#encapsulation bridge1483 mac-address 0090.1a01.1234
•
Use the no version, without the MAC address, to remove bridged Ethernet as the
encapsulation method on the interface.
•
See encapsulation bridge1483.
•
Use to configure PPP as the encapsulation method for an interface.
•
Example
encapsulation ppp
host1(config-subif)#encapsulation ppp
•
Use the no version to remove PPP as the encapsulation method on the interface.
•
See encapsulation ppp.
•
Use to configure an ATM interface or subinterface type.
•
To specify an ATM interface for ERX7xx models, ERX14xx models, and ERX310 router,
use the slot/port.[subinterface ] format.
interface atm
•
slot—Number of the chassis slot
•
port—Port number on the I/O module
Copyright © 2010, Juniper Networks, Inc.
449
JunosE 11.3.x Link Layer Configuration Guide
•
subinterface—Number of the subinterface in the range 1–2147483647
•
To specify an ATM interface for E120 and E320 routers, use the
slot/adapter/port[.subinterface ] format.
•
slot—Number of the chassis slot
•
adapter—Identifier for the IOA within the E320 chassis, either 0 or 1, where:
•
0 indicates that the IOA is installed in the right IOA bay (E120 router) or the upper
IOA bay (E320 router).
•
1 indicates that the IOA is installed in the left IOA bay (E120 router) or the lower
IOA bay (E320 router).
•
port—Port number on the IOA
•
subinterface—Number of the subinterface in the range 1–2147483647
•
For more information, see “Creating a Basic Configuration” on page 21 in “Configuring
ATM” on page 3.
•
Examples
host1(config)#interface atm 9/1.1 point-to-point
host1(config)#interface atm 5/0/1.1 point-to-point
•
Use the no version to remove the interface or subinterface.
•
See interface atm.
•
Use to set an IP address for the interface.
•
Note that you cannot add more than one IP address to bridged Ethernet interfaces.
•
Example
ip address
host1(config-subif)#ip address 160.1.0.1 255.255.255.0
•
Use the no version to remove the IP address.
•
See ip address.
•
Use to enable or disable MAC address validation on a per interface basis.
•
When MAC address validation is enabled, the router checks the entry in the MAC
validation table that corresponds to the IP source address of an incoming packet. The
MAC source address of the packet must match the MAC source address of the table
entry for the router to forward the packet.
•
Use the strict keyword to prevent transmission of IP packets that do not reside in the
validation table.
•
Use the loose keyword to allow IP packets to pass through even though the packets
do not have entries in the validation table. Only packets that have matching IP–MAC
pair entries in the table are validated. This is the default setting.
ip mac-validate
450
Copyright © 2010, Juniper Networks, Inc.
Chapter 14: Configuring Bridged Ethernet
•
The default behavior is not to perform MAC address validation.
•
Example
host1(config-subif)#ip mac-validate strict
•
Use the no version to disable the command.
NOTE: For more information, see MAC Address Validation in JunosE IP, IPv6,
and IGP Configuration Guide.
•
See ip mac-validate.
•
Use to create a PPPoE major interface.
•
Example
pppoe
host1(config-subif)#pppoe
•
Use the no version to remove the PPPoE major interface.
•
See pppoe.
•
Use to create a PPPoE subinterface on an ATM interface.
•
On ERX7xx models, ERX14xx models, and the ERX310 router, use the
slot/port.atmSubinterface.pppoeSubinterface format.
•
On the E120 and E320 routers, use the
slot/adapter/port.atmSubinterface.pppoeSubinterface format. RLI-1050
•
Examples
pppoe subinterface atm
host1(config)#pppoe subinterface atm 9/1.1.1
host1(config)#pppoe subinterface atm 5/0/1.1.1
•
Use the no version to remove the PPPoE subinterface.
•
See pppoe subinterface.
Alternative Configuration
In previous releases, you could configure a PPPoE major interface directly over ATM 1483
only. The router still supports this stacking and configuration method for PPPoE. Although
the older and newer interface stacks are different, they behave the same in terms of
frame encapsulation and handling. As a result, an interface created using the older
stacking will interoperate with an interface using the new stacking. Note, however, that
the previous command syntax (encapsulation pppoe) cannot be used when a bridged
Ethernet interface already exists, because it is intended to produce the old stacking for
PPPoE over ATM 1483.
1.
Create the ATM 1483 subinterface and associated PVC:
Copyright © 2010, Juniper Networks, Inc.
451
JunosE 11.3.x Link Layer Configuration Guide
host1(config)#interface atm 9/1.1 point-to-point
host1(config-subif)#atm pvc 1 0 32 aal5snap 0 0 0
2. Create a PPPoE major interface over the ATM 1483 subinterface. Note that since this
command uses the encapsulation keyword, it will fail if a bridged Ethernet interface
was already created over the ATM 1483 subinterface using the new syntax.
host1(config-subif)#encapsulation pppoe
3. Create a PPPoE subinterface over the major interface. Because PPPoE is the only top
layer protocol in the stack, there is no need to use pppoe to identify the subinterface
type (it is implied).
host1(config)#interface atm 9/1.1.1
4. Configure the PPP encapsulation over the PPPoE subinterface, and the IP interface
over the PPP interface.
host1(config-subif)#encapsulation ppp
host1(config-subif)#ip address 160.1.1.1 255.255.255.0
Configuring VLANs over Bridged Ethernet
This section describes how to create the following common static VLAN over bridged
Ethernet configurations:
•
IP over VLAN over bridged Ethernet
•
PPPoE over VLAN over bridged Ethernet
•
MPLS over VLAN over bridged Ethernet
You can also configure transparent bridging over VLANs over bridged Ethernet. For
information about configuring transparent bridging, see “Configuring Bridged Ethernet”
on page 443.
Configuring VLANs over bridged Ethernet interfaces consists of two basic tasks:
1.
Configure the layers up to and including the VLAN subinterface. The steps for this task
are common to all configurations.
2. Configure the higher-level protocols above the VLAN subinterface.
The following sections describe how to configure VLANs over bridged Ethernet. For more
information about the commands used in these procedures, see the command
descriptions listed in alphabetical order at the end of “Configuring Higher-Level Protocols
over VLANs” on page 453.
NOTE: Before you can remove a VLAN subinterface, you must remove the
upper-layer interface stack.
For more information about specifying ATM interfaces and subinterfaces,
see Interface Types and Specifiers in JunosE Command Reference Guide.
452
Copyright © 2010, Juniper Networks, Inc.
Chapter 14: Configuring Bridged Ethernet
Configuring VLAN Subinterfaces over Bridged Ethernet
To configure a VLAN subinterface over bridged Ethernet:
1.
Create an ATM 1483 subinterface and associated PVC.
host1(config)#interface atm 4/0.101
host1(config-subif)#atm pvc 1 0 32 aal5snap 0 0 0
2. Specify bridged Ethernet as the encapsulation method for the ATM 1483 subinterface.
host1(config-subif)#encapsulation bridge1483
3. Create a VLAN major interface by specifying VLAN as the encapsulation method for
the bridged Ethernet interface.
host1(config-subif)#encapsulation vlan
4. Create a VLAN subinterface to carry the higher-level protocols by adding a subinterface
number to the interface identification command.
host1(config-subif)#interface atm 4/0.101.1
5. Assign a VLAN ID for the subinterface.
host1(config-subif)#vlan id 10
6. (Optional) Configure additional VLAN subinterfaces by repeating Steps 4 and 5, using
unique values.
host1(config-subif)#interface atm 4/0.101.2
host1(config-subif)#vlan id 11
Proceed to the next section for instructions on configuring higher-level protocols over
the VLAN subinterfaces.
Configuring Higher-Level Protocols over VLANs
This section provides examples for configuring IP, PPPoE, and MPLS interfaces over VLAN
subinterfaces configured on bridged Ethernet. These procedures assume that you have
already configured one or more VLAN subinterfaces over the bridged Ethernet interface
to carry the higher-level protocols.
Configuring IP over VLAN
To configure IP over VLAN over a bridged Ethernet interface:
1.
Follow the steps in “Configuring VLAN Subinterfaces over Bridged Ethernet” on page 453
to configure the VLAN subinterface.
2. Assign an IP address and mask to the VLAN subinterface.
host1(config-subif)#ip address 10.1.1.1 255.255.255.0
Configuring PPPoE over VLAN
To configure PPPoE over VLAN over a bridged Ethernet interface:
Copyright © 2010, Juniper Networks, Inc.
453
JunosE 11.3.x Link Layer Configuration Guide
Follow the steps in “Configuring VLAN Subinterfaces over Bridged Ethernet” on page 453
to configure the VLAN subinterface.
1.
2. Create a PPPoE major interface on the VLAN subinterface.
host1(config-subif)#pppoe
3. Exit the subinterface context.
host1(config-subif)#exit
4. Create a PPPoE subinterface by adding a subinterface number to the interface
identification command.
host1(config)#pppoe subinterface atm 4/0.101.2.1
5. Specify PPP as the encapsulation method on the interface.
host1(config-subif)#encapsulation ppp
6. Assign an IP address and mask to the interface.
host1(config-subif)#ip address 10.1.1.2 255.255.255.0
Configuring MPLS over VLAN
To configure MPLS over VLAN over a bridged Ethernet interface:
Follow the steps in “Configuring VLAN Subinterfaces over Bridged Ethernet” on page 453
to configure the VLAN subinterface.
1.
2. Enable MPLS on the VLAN subinterface.
host1(config-subif)#mpls
atm pvc
•
•
Use to configure a PVC on an ATM interface. Specify one of the following encapsulation
types:
•
aal5snap—Specifies a logical link control (LLC) encapsulated circuit;
LLC/Subnetwork Access Protocol (LLC/SNAP) header precedes the protocol
datagram.
•
aal5mux ip—Specifies a VC multiplexed circuit. This option is used for IP only.
Example
host1(config-subif)#atm pvc 1 5 50 aal5snap 0 0 0
•
Use the no version to remove the specified PVC.
•
See atm pvc.
•
Use to configure bridged Ethernet as the encapsulation method on an ATM 1483
subinterface.
•
Example
encapsulation bridge1483
host1(config-subif)#encapsulation bridge1483
454
Copyright © 2010, Juniper Networks, Inc.
Chapter 14: Configuring Bridged Ethernet
•
Use the no version to remove bridged Ethernet as the encapsulation method on the
interface.
•
See encapsulation bridge1483.
•
Use to configure PPP as the encapsulation method on an interface.
•
Example
encapsulation ppp
host1(config-subif)#encapsulation ppp
•
Use the no version to remove PPP as the encapsulation method on the interface.
•
See encapsulation ppp.
•
Use to configure VLAN as the encapsulation method on an interface.
•
Example
encapsulation vlan
host1(config-subif)#encapsulation vlan
•
Use the no version to remove VLAN as the encapsulation method on the interface.
•
See encapsulation vlan.
•
Use to configure an ATM interface, ATM 1483 subinterface, or VLAN subinterface.
•
On ERX7xx models, ERX14xx models, and the ERX310 router, use the
slot/port.subinterface.vlanSubinterface format.
•
On E120 and E320 routers, use the slot/adapter/port.subinterface.vlanSubinterface
format.
•
For more information, see “Creating a Basic Configuration” on page 21 in “Configuring
ATM” on page 3.
•
Example 1—Configures a VLAN subinterface over bridged Ethernet on ERX7xx models,
ERX14xx models, and the ERX310 router
interface atm
host1(config)#interface atm 4/2.2 point-to-point
host1(config-subif)#interface atm 4/2.2.3
•
Example 2—Configures a VLAN subinterface over bridged Ethernet on the E320 router
host1(config)#interface atm 4/0/2.2 point-to-point
host1(config-subif)#interface atm 4/0/2.2.3
•
Use the no version to remove the interface or subinterface.
•
See interface atm.
•
Use to set an IP address for the interface.
•
Note that you cannot add more than one IP address to bridged Ethernet interfaces.
ip address
Copyright © 2010, Juniper Networks, Inc.
455
JunosE 11.3.x Link Layer Configuration Guide
•
Example
host1(config-subif)#ip address 10.1.2.3 255.255.255.255
•
Use the no version to remove the IP address.
•
See ip address.
•
Use to enable, disable, or delete MPLS on an interface. MPLS is disabled by default.
•
Example
mpls
host1(config)#mpls
•
Use the no version to halt MPLS on the interface and delete the MPLS interface
configuration.
•
See mpls.
•
Use to create a PPPoE major interface.
•
Example
pppoe
host1(config-subif)#pppoe
•
Use the no version to remove the PPPoE major interface.
•
See pppoe.
•
Use to create a PPPoE subinterface over a VLAN subinterface configured on a bridged
Ethernet interface.
•
On ERX7xx models, ERX14xx models, and the ERX310 router, use the
slot/port.atmSubinterface.vlanSubinterface.pppoeSubinterface format.
•
On E120 and E320 routers, use the
slot/adapter/port.atmSubinterface.vlanSubinterface.pppoeSubinterface format.
•
Examples
pppoe subinterface atm
host1(config)#pppoe subinterface atm 4/0.1.2.1
host1(config)#pppoe subinterface atm 4/1/0.1.2.1
•
Use the no version to remove the PPPoE subinterface.
•
See pppoe subinterface.
•
Use to specify the VLAN ID.
•
Use a VLAN ID that is in the range 0–4095 and is unique within the interface.
•
Issue the vlan id command before any upper bindings are made, such as IP or PPPoE.
vlan id
456
Copyright © 2010, Juniper Networks, Inc.
Chapter 14: Configuring Bridged Ethernet
•
Use the optional keyword untagged to specify that frames be sent untagged. The
keyword is valid only for VLAN ID 0. It allows tagged frames to be received, but sends
out untagged frames.
•
Example
host1(config-subif)#vlan id 400
•
There is no no version.
•
See vlan id.
Configuring S-VLANs over Bridged Ethernet
S-VLANs over bridged Ethernet support the same set of higher-level protocols as VLANs
over bridged Ethernet. You configure S-VLANs over bridged Ethernet in the same way
that you configure VLANs over bridged Ethernet, with the addition of certain commands.
Like VLANs, configuring S-VLANs over bridged Ethernet interfaces consists of two basic
tasks:
1.
Configure the layers up to and including the S-VLAN subinterface.
2. Configure the higher-level protocols above the S-VLAN subinterface.
Before you can remove an S-VLAN subinterface, you must remove the upper-layer
interface stack.
NOTE: S-VLAN oversubscription is not supported on bridged Ethernet
interfaces.
For more information about specifying ATM interfaces and subinterfaces,
see Interface Types and Specifiers in JunosE Command Reference Guide.
Configuring S-VLAN Subinterfaces over Bridged Ethernet
To configure an S-VLAN subinterface over bridged Ethernet:
1.
Create an ATM 1483 subinterface and associated PVC.
host1(config)#interface atm 3/1.1
host1(config-subif)#atm pvc 1 5 33 aal5snap 0 0 0
2. Specify bridged Ethernet as the encapsulation method for the ATM 1483 subinterface.
host1(config-subif)#encapsulation bridge1483
3. Create a VLAN major interface by specifying VLAN as the encapsulation method for
the bridged Ethernet interface.
host1(config-subif)#encapsulation vlan
4. Create a VLAN subinterface to carry the higher-level protocols by adding a subinterface
number to the interface identification command.
Copyright © 2010, Juniper Networks, Inc.
457
JunosE 11.3.x Link Layer Configuration Guide
host1(config-subif)#interface atm 3/1.1.1
5. Assign an S-VLAN ID and a VLAN ID for the subinterface.
host1(config-subif)#svlan id 4 255
6. Assign an S-VLAN Ethertype.
host1(config-subif)#svlan ethertype 9200
Proceed to “Configuring Higher-Level Protocols over S-VLANs” on page 458 for information
about configuring higher-level protocols over the S-VLAN subinterfaces.
svlan ethertype
•
Use to assign an Ethertype value for the S-VLAN subinterface.
•
Choose one of the following Ethertype values:
•
8100—Specifies Ethertype value 0x8100, as defined in IEEE Standard 802.1q
•
9100—Specifies Ethertype value 0x9100, which is the default
•
9200—Specifies Ethertype value 0x9200
•
Use an Ethertype value that matches the Ethertype value set on the customer premises
equipment (CPE) to which your router connects.
•
Example
host1(config-if)#svlan ethertype 8100
•
Use the no version to restore the default value, 9100.
•
See svlan ethertype.
•
Use to assign S-VLAN IDs and VLAN IDs to VLAN subinterfaces.
•
Use S-VLAN ID and VLAN ID numbers that are in the range 0–4095 and that are unique
within the Ethernet interface.
•
Issue the svlan id command before any upper bindings are made, such as IP or PPPoE.
•
Example
svlan id
host1(config-if)#svlan id 4 255
•
There is no no version.
•
See svlan id.
Configuring Higher-Level Protocols over S-VLANs
The procedures for configuring IP, PPPoE, and MPLS protocols over S-VLANs on bridged
Ethernet interfaces are identical to the procedures for configuring these protocols over
VLANs on bridged Ethernet interfaces.
458
Copyright © 2010, Juniper Networks, Inc.
Chapter 14: Configuring Bridged Ethernet
This section provides an example for configuring PPPoE interfaces over S-VLAN
subinterfaces configured on bridged Ethernet. For descriptions of the commands used
in this procedure, see “Configuring Higher-Level Protocols over VLANs” on page 453.
To configure PPPoE over S-VLAN over a bridged Ethernet interface:
1.
Follow the steps in “Configuring S-VLAN Subinterfaces over Bridged Ethernet” on
page 457 to configure the S-VLAN subinterface.
2. Create a PPPoE major interface on the S-VLAN subinterface.
host1(config-subif)#pppoe
3. Exit the subinterface context.
host1(config-subif)#exit
4. Create a PPPoE subinterface by adding a subinterface number to the interface
identification command.
host1(config)#pppoe subinterface atm 3/1.1.1.1
5. Specify PPP as the encapsulation method on the interface.
host1(config-subif)#encapsulation ppp
6. Assign an IP address and mask to the interface.
host1(config-subif)#ip address 10.1.2.3 255.255.255.255
Configuring the MTU Size for Bridged Ethernet
You can use the bridge1483 mtu command to configure a nondefault maximum
transmission unit (MTU) size, in bytes, for a bridged Ethernet interface. The default MTU
size for a bridged Ethernet interface is 1518 bytes.
Because you configure a bridged Ethernet interface over an ATM 1483 subinterface, the
MTU size set with the bridge1483 mtu command is limited by the MTU set for the
underlying ATM 1483 subinterface. As a result, the bridge1483 mtu command requires
you to configure an MTU size for the bridged Ethernet interface that does not exceed
the maximum allowable MTU size for the underlying ATM 1483 subinterface, 9180 bytes.
The configured MTU size for an interface is referred to as its administrative MTU, and the
MTU size at which the interface actually operates is referred to as its operational MTU.
For bridged Ethernet interfaces, the operational MTU is the lesser of the following two
values:
•
The administrative MTU of the bridged Ethernet interface
•
The administrative MTU of the underlying ATM 1483 subinterface
You can also use the bridge1483 mtu command in a profile to configure a nondefault
MTU size for a dynamic bridged Ethernet interface. For information, see “Configuring a
Dynamic Interface from a Profile” on page 559 in “Configuring Dynamic Interfaces” on
page 511.
bridge1483 mtu
Copyright © 2010, Juniper Networks, Inc.
459
JunosE 11.3.x Link Layer Configuration Guide
•
Use to set the maximum allowable size, in bytes, of the MTU for bridged Ethernet
interfaces.
•
Specify an MTU size in the range 64–9180 bytes.
•
Example
host1(config-subif)#bridge1483 mtu 1684
•
Use the no version to restore the default MTU size for bridged Ethernet interfaces, 1518
bytes.
•
See bridge1483 mtu.
Monitoring Bridged Ethernet
You can:
•
Display information about bridged Ethernet interfaces by using the show bridge1483
interface command.
•
Monitor MAC address validation by using the show ip mac-validate interface command.
•
Display information about VLANs configured on bridged Ethernet interfaces by using
the show vlan subinterface command.
Bridged Ethernet interfaces are not bound to a specific virtual router (VR).
NOTE: The E120 and E320 routers output for monitor and show commands
is identical to output from other E Series routers, except that the E120 and
E320 routers output also includes information about the adapter identifier
in the interface specifier (slot/adapter/port).
show bridge1483 interface
460
•
Use to display configuration and status information for all bridged Ethernet interfaces
currently configured on the router.
•
Use the atm keyword and an interface specifier to display information for a bridged
Ethernet interface that is stacked over an ATM subinterface.
•
Use the summary keyword to display only a count of all bridged Ethernet interfaces
configured on the router.
•
Field descriptions
•
Interface—Type and specifier of the lower-layer interface on which bridged Ethernet
is configured
•
Status—Status of the bridged Ethernet interface: up, down, lowerLayerDown,
notPresent
•
MAC Address—MAC address assigned to the bridged Ethernet interface, if configured
•
Type—Type of interface: static or dynamic
Copyright © 2010, Juniper Networks, Inc.
Chapter 14: Configuring Bridged Ethernet
•
Oper/Admin MTU—Operational MTU, which is the MTU at which the interface actually
operates, and administrative MTU, which is the MTU configured for the interface;
the administrative MTU displays 1518 (the default value) if not configured
•
In—Analysis of inbound traffic on this interface
•
•
•
•
•
Bytes—Number of bytes received in error-free packets
•
Packets—Number of packets received
•
Multicast—Number of multicast packets received
•
Broadcast—Number of broadcast packets received
•
Errors—Total number of errors in all received packets; some packets might contain
more than one error
•
Discards—Total number of discarded incoming packets
Out—Analysis of outbound traffic on this interface
•
Bytes—Number of bytes sent
•
Packets—Number of packets sent
•
Multicast—Number of multicast packets sent
•
Broadcast—Number of broadcast packets sent
•
Errors—Total number of errors in all transmitted packets; some packets might
contain more than one error
•
Discards—Total number of discarded outgoing packets
ARP Statistics—Analysis of ARP traffic on this interface; In fields are for traffic received
on the interface and Out fields are for traffic sent on the interface
•
ARP requests—Number of ARP requests
•
ARP responses—Number of ARP responses
•
Errors—Total number of errors in all ARP packets
•
Discards—Total number of discarded ARP packets
Total bridge1483 interfaces—Total number of bridged Ethernet interfaces configured
on the router; this is the only information that appears when you specify the summary
keyword
Example 1—Displays full configuration and status information
host1#show bridge1483 interface
Oper/Admin
Interface
Status
MAC Address
Type
MTU
------------------------- ---------- -------------- ------- ---------ATM 5/1.1
Up
----.----.---- Static 1500/1684
Copyright © 2010, Juniper Networks, Inc.
461
JunosE 11.3.x Link Layer Configuration Guide
ATM 5/1.2
Up
2 bridge1483 interfaces found
•
----.----.---- Static
8192/9188
Example 2—Displays full status and configuration information for the specified
bridge1483 interface
host1#show bridge1483 interface atm 12/0.1
Oper/Admin
Interface
Status
MAC Address
Type
MTU
------------------------- ---------- -------------- ------- ---------ATM 12/0.1
Up
----.----.---- Static 1522/1522
In: Bytes 0, Packets 0
Multicast 0, Broadcast 0
Errors 0, Discards 0
Out: Bytes 0, Packets 0
Multicast 0, Broadcast 0
Errors 0, Discards 0
ARP Statistics:
In: ARP requests 0, ARP responses 0
Errors 0, Discards 0
Out: ARP requests 0, ARP responses 0
Errors 0, Discards 0
•
Example 3—Displays only brief summary information
host1#show bridge1483 interface summary
Total bridge1483 interfaces: 3
•
See show bridge1483 interface.
show ip mac-validate interface
•
Use to display the status of the MAC address validation on the physical interface.
•
Field descriptions
•
•
interfaceSpecifier—Interface type slot/port
•
Keyword assigned to interface—Strict or Loose
•
Address—IP address of the entry
•
Hardware Addr—Physical (MAC) address of the entry
Example
host1:vr1#show ip mac-validate interface atm 8/0.1
ATM8/0.1: Strict
Address
180.1.0.2
•
Hardware Addr
0000.1111.2222
See show ip mac-validate interface.
show vlan subinterface
462
Copyright © 2010, Juniper Networks, Inc.
Chapter 14: Configuring Bridged Ethernet
•
Use to display configuration and status information for a specified VLAN subinterface
or for all VLAN subinterfaces configured on the router.
•
Use the summary keyword to display only the counts of all VLAN subinterfaces and
VLAN major interfaces configured on the router.
•
Field descriptions
•
•
Interface—Type and specifier of the VLAN subinterface. For more information about
specifying the ATM physical interface on which you want to configure the VLAN
subinterface, see Interface Types and Specifiers in JunosE Command Reference Guide.
•
Status—Status of the VLAN subinterface: up, down, lowerLayerDown, notPresent
•
MTU—Maximum allowable size (in bytes) of the maximum transmission unit for the
VLAN subinterface
•
Svlan Id—S-VLAN ID value, if configured
•
Vlan Id—VLAN ID value for the VLAN subinterface
•
Ethertype—S-VLAN Ethertype value, if configured
•
Total VLAN interfaces—Total numbers of VLAN subinterfaces and VLAN major
interfaces configured on the router; this is the only field that appears when you specify
the summary keyword
Example 1—Displays full status and configuration information for all VLAN subinterfaces
configured on the router
host1#show vlan subinterface
Interface
Status
------------------------- ---------ATM 3/0.1.2
Up
ATM 3/0.1.3
Up
ATM 3/1.1.1
Up
ATM 3/1.1.2
Up
ATM 3/2.1.1
Down
FastEthernet 4/5.1
Up
6 vlan subinterfaces found
•
MTU
---1522
1522
1522
1522
1526
1522
Svlan Id
-------------------4
----
Vlan Id
-------11
12
13
14
255
1
Ethertype
--------------------0x9200
----
Example 2—Displays full status and configuration information for the specified VLAN
subinterface
host1#show vlan subinterface atm 3/0.1.2
Interface
Status
MTU Svlan Id Vlan Id Ethertype
------------------------- ---------- ---- -------- -------- --------ATM 3/0.1.2
Up
1522 ---11
----
•
Example 3—Displays only brief summary information for all VLAN subinterfaces
configured on the router
host1#show vlan subinterface summary
Total VLAN interfaces: 6 subinterfaces, 3 major interfaces
•
See show vlan subinterface.
Copyright © 2010, Juniper Networks, Inc.
463
JunosE 11.3.x Link Layer Configuration Guide
464
Copyright © 2010, Juniper Networks, Inc.
CHAPTER 15
Configuring Transparent Bridging
This chapter provides an introduction to transparent bridging and describes how to
configure transparent bridging on E Series routers.
This chapter contains the following sections:
•
Overview on page 465
•
Platform Considerations on page 470
•
References on page 471
•
Before You Configure Transparent Bridging on page 471
•
Configuration Tasks on page 472
•
Configuration Examples on page 485
•
Monitoring Transparent Bridging on page 487
Overview
This section introduces important concepts that you need to understand before
configuring transparent bridging. These concepts include:
•
How Transparent Bridging Works on page 465
•
Bridge Groups and Bridge Group Interfaces on page 466
•
Bridge Interface Types and Supported Configurations on page 467
•
Subscriber Policies on page 468
•
Concurrent Routing and Bridging on page 469
•
Transparent Bridging and VPLS on page 470
•
Unsupported Features on page 470
How Transparent Bridging Works
A transparent bridge is a data-link layer (layer 2) relay device that connects two or more
networks or network systems. When a transparent bridge powers up, it automatically
begins learning the network topology by examining the media access control (MAC)
source address of every incoming packet. The bridge then creates an entry in the
forwarding table consisting of the address and associated interface where the packet
was received.
Copyright © 2010, Juniper Networks, Inc.
465
JunosE 11.3.x Link Layer Configuration Guide
More specifically, a transparent bridge performs all of the following actions to learn the
network topology:
•
Learning—The bridge examines the MAC address of every incoming packet, records
the MAC address and associated interface in the forwarding table, and manages the
database of MAC addresses and their associated interfaces.
•
Flooding—When a packet’s destination address does not match any entries in the
forwarding table, the bridge transmits (floods) the packet on all bridge interfaces to
all network segments except the interface on which the packet was received.
•
Forwarding—Once the bridge has learned a packet’s destination address (that is, has
a matching entry in its forwarding table), the bridge uses the associated port and
interface information to send the packet toward its destination.
•
Filtering—If the bridge detects that a packet’s source and destination addresses are
on the same network segment, it ignores (filters) that packet. Filtering is the process
by which the bridge can screen network traffic for certain characteristics and determine
wh