Juniper Networks OS 10.4 User Manual

Download

Junos

MX Series Ethernet Services Routers Solutions Guide

Release

10.4

Published: 2010-10-07

Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, California 94089 USA 408-745-2000 www.juniper.net

This productincludes the Envoy SNMP Engine, developed by Epilogue Technology, an Integrated Systems Company. Copyright © 1986-1997, Epilogue Technology Corporation. All rights reserved. This program and its documentation were developed at private expense, and no part of them is in the public domain.

This product includes FreeBSD software developed by the University of California, Berkeley, and its contributors. All of the documentation and software included in the 4.4BSD and 4.4BSD-Lite Releases is copyrighted by the Regents of the University of California. Copyright © 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994. The Regents of the University of California. All rights reserved.

GateD software copyright © 1995, the Regents of the University. All rights reserved. Gate Daemon was originated and developed through release 3.0 by Cornell University and its collaborators. Gated is based on Kirton’s EGP, UC Berkeley’s routing daemon (routed), and DCN’s HELLO routing protocol. Development of Gated has been supported in part by the National Science Foundation. Portions of the GateD software copyright © 1988, Regents of the University of California. All rights reserved. Portions of the GateD software copyright © 1991, D. L. S. Associates.

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.

Junos®OS MX Series Ethernet Services Routers Solutions Guide

Writing: Walter Goralski Editing: Sonia Saruba, Joanne McClintock Illustration: Nathaniel Woodward, Faith Bradford Cover Design: Edmonds Design

Revision History October 2010—R1 Junos OS Release 10.4

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.

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 TOBE BOUND BYTHIS AGREEMENT. IFYOU 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 (ifthe Customer’sprincipal officeis located outsidethe Americas) (such applicableentity being referred to herein as“Juniper”), and (ii) theperson or organization thatoriginally purchased from Juniperor an authorized Juniperreseller 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 feesand 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 limitsto Customer’s useof the Software. Suchlimits mayrestrict use toa 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, toany thirdparty; (d)remove any proprietarynotices, labels, or marks on orin any copy ofthe Softwareor 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 inthe secondhand market; (f)use any ‘locked’ orkey-restricted feature,function, service, application, operation, orcapability 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

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 anymanner 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 statementthat accompanies the Software (the“WarrantyStatement”). Nothingin this Agreementshall give riseto any obligationto 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 COSTSOR PROCUREMENTOF SUBSTITUTEGOODS ORSERVICES,OR FOR ANYSPECIAL, INDIRECT,OR CONSEQUENTIAL DAMAGES ARISING OUTOF THIS AGREEMENT,THE SOFTWARE,OR ANYJUNIPER OR JUNIPER-SUPPLIEDSOFTWARE. INNO EVENT SHALLJUNIPER 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.

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 embeddedin 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)).

Abbreviated Table of Contents

About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

Part 1 Overview

Chapter 1 Overview of Ethernet Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Part 2 Basic Solutions for MX Series Routers

Chapter 2 Basic Layer 2 Features on MX Series Routers . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Chapter 3 Virtual Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Chapter 4 VLANs Within Bridge Domain and VPLS Environments . . . . . . . . . . . . . . . . 43

Chapter 5 Bulk Administration of Layer 2 Features on MX Series Routers . . . . . . . . . . 59

Chapter 6 Dynamic Profiles for VLAN Interfaces and Protocols . . . . . . . . . . . . . . . . . . . 63

Chapter 7 MX Series Router as a DHCP Relay Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Chapter 8 MX Series Router in an ATM Ethernet Interworking Function . . . . . . . . . . . . 77

Part 3 Ethernet Filtering, Monitoring, and Fault Management Solutions

for MX Series Routers

Chapter 9 Layer 2 Firewall Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Chapter 10 IEEE 802.1ag OAM Connectivity-Fault Management . . . . . . . . . . . . . . . . . . 103

Chapter 11 ITU-T Y.1731 Ethernet Frame Delay Measurements . . . . . . . . . . . . . . . . . . . . 119

Chapter 12 IEEE 802.3ah OAM Link-Fault Management . . . . . . . . . . . . . . . . . . . . . . . . . 137

Chapter 13 Ethernet Ring Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Part 4 Index

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

Junos Documentation and Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii

Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii

Supported Routing Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix

Using the Indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix

Using the Examples in This Manual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix

Merging a Full Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix

Merging a Snippet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx

Documentation Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xx

Documentation Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxii

Requesting Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxii

Self-Help Online Tools and Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii

Opening a Case with JTAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii

Part 1 Overview

Chapter 1 Overview of Ethernet Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Ethernet Terms and Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Networking and Internetworking with Bridges and Routers . . . . . . . . . . . . . . . . . . . 6

Network Addressing at Layer 2 and Layer 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Networking at Layer 2: Benefits of Ethernet Frames . . . . . . . . . . . . . . . . . . . . . . . . 9

Networking at Layer 2: Challenges of Ethernet MAC Addresses . . . . . . . . . . . . . . . 10

Networking at Layer 2: Forwarding VLAN Tagged Frames . . . . . . . . . . . . . . . . . . . . 11

Networking at Layer 2: Forwarding Dual-Tagged Frames . . . . . . . . . . . . . . . . . . . . 13

Networking at Layer 2: Logical Interface Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

A Metro Ethernet Network with MX Series Routers . . . . . . . . . . . . . . . . . . . . . . . . . 15

Layer 2 Networking Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Part 2 Basic Solutions for MX Series Routers

Chapter 2 Basic Layer 2 Features on MX Series Routers . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Layer 2 Features for a Bridging Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Example Roadmap: Configuring a Basic Bridge Domain Environment . . . . . . . . . 22

Example Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Example Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Example Configuration Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Example Step: Configuring Interfaces and VLAN Tags . . . . . . . . . . . . . . . . . . . . . . 24

Example Step: Configuring Bridge Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Example Step: Configuring Spanning Tree Protocols . . . . . . . . . . . . . . . . . . . . . . . 32

Example Step: Configuring Integrated Bridging and Routing . . . . . . . . . . . . . . . . . 34

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

Chapter 3 Virtual Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Layer 2 Features for a Switching Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Configuring Virtual Switches as Separate Routing Instances . . . . . . . . . . . . . . . . 40

Chapter 4 VLANs Within Bridge Domain and VPLS Environments . . . . . . . . . . . . . . . . 43

VLANs Within a Bridge Domain or VPLS Instance . . . . . . . . . . . . . . . . . . . . . . . . . 43

Packet Flow Through a Bridged Network with Normalized VLANs . . . . . . . . . . . . 44

Configuring a Normalized VLAN for Translation or Tagging . . . . . . . . . . . . . . . . . . 45

Implicit VLAN Translation to a Normalized VLAN . . . . . . . . . . . . . . . . . . . . . . 45

Sending Tagged or Untagged Packets over VPLS Virtual Interfaces . . . . . . . 46

Configuring a Normalized VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Configuring Learning Domains for VLAN IDs Bound to Logical Interfaces . . . . . . . 47

Example: Configuring a Provider Bridge Network with Normalized VLAN Tags . . . 47

Example: Configuring a Provider VPLS Network with Normalized VLAN Tags . . . . 51

Example: Configuring One VPLS Instance for Several VLANs . . . . . . . . . . . . . . . . 55

Chapter 5 Bulk Administration of Layer 2 Features on MX Series Routers . . . . . . . . . . 59

Bulk Configuration of VLANs and Bridge Domains . . . . . . . . . . . . . . . . . . . . . . . . . 59

Example: Configuring VLAN Translation with a VLAN ID List . . . . . . . . . . . . . . . . . 59

Example: Configuring Multiple Bridge Domains with a VLAN ID List . . . . . . . . . . . 60

Chapter 6 Dynamic Profiles for VLAN Interfaces and Protocols . . . . . . . . . . . . . . . . . . . 63

Dynamic Profiles for VPLS Pseudowires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

Example: Configuring VPLS Pseudowires with Dynamic Profiles—Basic

Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

VPLS Pseudowire Interfaces Without Dynamic Profiles . . . . . . . . . . . . . . . . . 64

VPLS Pseudowire Interfaces and Dynamic Profiles . . . . . . . . . . . . . . . . . . . . 65

CE Routers Without Dynamic Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

CE Routers and Dynamic Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Example: Configuring VPLS Pseudowires with Dynamic Profiles—Complex

Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Configuration of Routing Instance and Interfaces Without Dynamic

Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Configuration of Routing Instance and Interfaces Using Dynamic

Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Configuration of Tag Translation Using Dynamic Profiles . . . . . . . . . . . . . . . . 72

Chapter 7 MX Series Router as a DHCP Relay Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

MX Series Router as a Layer 2 DHCP Relay Agent . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Example: Configuring DHCP Relay in a Bridge Domain VLAN Environment . . . . . 74

Example: Configuring DHCP Relay in a VPLS Routing Instance Environment . . . . 75

Chapter 8 MX Series Router in an ATM Ethernet Interworking Function . . . . . . . . . . . . 77

MX Series Router ATM Ethernet Interworking Function . . . . . . . . . . . . . . . . . . . . . 77

Example: Configuring MX Series Router ATM Ethernet Interworking . . . . . . . . . . . 79

Configuring PE2 with a Layer 2 Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Configuring PE2 with a Layer 2 Circuit over Aggregated Ethernet . . . . . . . . . . 82

Configuring PE2 with a Remote Interface Switch . . . . . . . . . . . . . . . . . . . . . . 85

Configuring PE2 with a Remote Interface Switch over Aggregated

Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Table of Contents

Part 3 Ethernet Filtering, Monitoring, and Fault Management Solutions

for MX Series Routers

Chapter 9 Layer 2 Firewall Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Firewall Filters for Bridge Domains and VPLS Instances . . . . . . . . . . . . . . . . . . . . 95

Example: Configuring Policing and Marking of Traffic Entering a VPLS Core . . . . 96

Example: Configuring Filtering of Frames by MAC Address . . . . . . . . . . . . . . . . . . 98

Example: Configuring Filtering of Frames by IEEE 802.1p Bits . . . . . . . . . . . . . . . . 99

Example: Configuring Filtering of Frames by Packet Loss Priority . . . . . . . . . . . . . 101

Chapter 10 IEEE 802.1ag OAM Connectivity-Fault Management . . . . . . . . . . . . . . . . . . 103

Ethernet Operations, Administration, and Maintenance . . . . . . . . . . . . . . . . . . . . 103

Ethernet OAM Connectivity Fault Management . . . . . . . . . . . . . . . . . . . . . . . . . . 104

Example: Configuring Ethernet CFM over VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Example: Configuring Ethernet CFM on Bridge Connections . . . . . . . . . . . . . . . . . 112

Example: Configuring Ethernet CFM on Physical Interfaces . . . . . . . . . . . . . . . . . 116

Chapter 11 ITU-T Y.1731 Ethernet Frame Delay Measurements . . . . . . . . . . . . . . . . . . . . 119

Ethernet Frame Delay Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

Configuring MEP Interfaces to Support Ethernet Frame Delay Measurements . . 122

Triggering an Ethernet Frame Delay Measurements Session . . . . . . . . . . . . . . . . 123

Viewing Ethernet Frame Delay Measurements Statistics . . . . . . . . . . . . . . . . . . . 124

Example: Configuring One-Way Ethernet Frame Delay Measurements with

Single-Tagged Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

Example: Configuring Two-Way Ethernet Frame Delay Measurements with

Single-Tagged Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130

Example: Configuring Ethernet Frame Delay Measurements with Untagged

Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

Chapter 12 IEEE 802.3ah OAM Link-Fault Management . . . . . . . . . . . . . . . . . . . . . . . . . 137

Ethernet OAM Link Fault Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

Example: Configuring Ethernet LFM Between PE and CE . . . . . . . . . . . . . . . . . . . 138

Example: Configuring Ethernet LFM for CCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Example: Configuring Ethernet LFM for Aggregated Ethernet . . . . . . . . . . . . . . . 140

Example: Configuring Ethernet LFM with Loopback Support . . . . . . . . . . . . . . . . 142

Chapter 13 Ethernet Ring Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Ethernet Ring Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Ethernet Ring Protection Using Ring Instances for Load Balancing . . . . . . . . . . . 147

Example: Configuring Ethernet Ring Protection for MX Series Routers . . . . . . . . 148

Example Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

Router 1 (RPL Owner) Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149

Router 2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

Router 3 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

Example: Configuring Load Balancing Within Ethernet Ring Protection for MX

Series Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

Example: Viewing Ethernet Ring Protection Status—Normal Ring Operation . . . 171

Example: Viewing Ethernet Ring Protection Status—Ring Failure Condition . . . . 172

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

Part 4 Index

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

List of Figures

Part 1 Overview

Chapter 1 Overview of Ethernet Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Figure 1: Native (Normal) and VLAN-Tagged Ethernet Fames . . . . . . . . . . . . . . . . 12

Figure 2: A Metro Ethernet Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Figure 3: A Metro Ethernet Network with MX Series Routers . . . . . . . . . . . . . . . . . 16

Figure 4: VLAN Tags on a Metro Ethernet Network . . . . . . . . . . . . . . . . . . . . . . . . . 16

Part 2 Basic Solutions for MX Series Routers

Chapter 2 Basic Layer 2 Features on MX Series Routers . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Figure 5: Bridging Network with MX Series Routers . . . . . . . . . . . . . . . . . . . . . . . . 23

Figure 6: Designated, Root, and Alternate Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Chapter 4 VLANs Within Bridge Domain and VPLS Environments . . . . . . . . . . . . . . . . 43

Figure 7: Provider Bridge Network Using Normalized VLAN Tags . . . . . . . . . . . . . 48

Figure 8: VLAN Tags and VPLS Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Figure 9: Many VLANs on One VPLS Instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Chapter 8 MX Series Router in an ATM Ethernet Interworking Function . . . . . . . . . . . . 77

Figure 10: ATM Ethernet VLAN Interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Figure 11: ATM Ethernet VLAN Interworking Packet Structure . . . . . . . . . . . . . . . . 78

Figure 12: CCC to Stacked VLAN Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Figure 13: ATM Ethernet VLAN Interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Part 3 Ethernet Filtering, Monitoring, and Fault Management Solutions

for MX Series Routers

Chapter 9 Layer 2 Firewall Filters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Figure 14: Policing and Marking Traffic Entering a VPLS Core . . . . . . . . . . . . . . . . 96

Chapter 10 IEEE 802.1ag OAM Connectivity-Fault Management . . . . . . . . . . . . . . . . . . 103

Figure 15: Ethernet OAM with VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Figure 16: Ethernet CFM over a Bridge Network . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Figure 17: Ethernet CFM on Physical Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

Chapter 11 ITU-T Y.1731 Ethernet Frame Delay Measurements . . . . . . . . . . . . . . . . . . . . 119

Figure 18: Ethernet OAM Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

Chapter 12 IEEE 802.3ah OAM Link-Fault Management . . . . . . . . . . . . . . . . . . . . . . . . . 137

Figure 19: Ethernet LFM Between PE and CE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

Figure 20: Ethernet LFM for CCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

Figure 21: Ethernet LFM for Aggregated Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . 140

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

Figure 22: Ethernet LFM with Loopback Support . . . . . . . . . . . . . . . . . . . . . . . . . 142

Chapter 13 Ethernet Ring Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Figure 23: Ethernet Ring Protection Example Nodes . . . . . . . . . . . . . . . . . . . . . . 148

Figure 24: ERPwith Multiple Protection Instances Configuredon Three MXSeries

Routers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

List of Tables

About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

Table 1: Notice Icons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi

Table 2: Text and Syntax Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi

Part 3 Ethernet Filtering, Monitoring, and Fault Management Solutions

for MX Series Routers

Chapter 11 ITU-T Y.1731 Ethernet Frame Delay Measurements . . . . . . . . . . . . . . . . . . . . 119

Table 3: Monitor Ethernet Delay Command Parameters . . . . . . . . . . . . . . . . . . . . 123

Table 4: Show Ethernet Delay Command Parameters . . . . . . . . . . . . . . . . . . . . . 125

Chapter 13 Ethernet Ring Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145

Table 5: Components of the Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . 156

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

About This Guide

This preface provides the following guidelines for using the Junos®OS MX Series Ethernet Services Routers Solutions Guide:

•

Junos Documentation and Release Notes on page xvii

•

Objectives on page xviii

•

Audience on page xviii

•

Supported Routing Platforms on page xix

•

Using the Indexes on page xix

•

Using the Examples in This Manual on page xix

•

Documentation Conventions on page xx

•

Documentation Feedback on page xxii

•

Requesting Technical Support on page xxii

Junos Documentation and Release Notes

For a list of related Junos documentation, see

http://www.juniper.net/techpubs/software/junos/ .

If the information in the latest release notes differs from the information in the documentation, follow the Junos 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/.

Juniper Networks supports a technical book programto publishbooks byJuniper Networks engineers and subject matter experts with book publishers around the world. These books go beyond the technical documentation to explore the nuances of network architecture, deployment, and administration using the Junos operating system (Junos OS) and Juniper Networks devices. In addition, the Juniper Networks Technical Library, published in conjunction with O'Reilly Media, explores improving network security, reliability, and availability using Junos OS configuration techniques. All the books are for sale at technical bookstores and book outlets around the world. The current list can be viewed at http://www.juniper.net/books .

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

Objectives

This guide provides an overview of the Layer 2 features of the Junos OS and describes how to configure the features to provide solutions to several network scenarios.

NOTE: For additional information about Junos OS—either corrections to or

information that might have been omitted from this guide—see the software release notes at http://www.juniper.net/.

Audience

This guide is designed for network administrators who are configuring and monitoring Layer 2 features of the Junos OS.

To use this guide, you need a broad understanding of networks in general, the Internet in particular, networking principles, and network configuration. You must also be familiar with one or more of the following Internet routing protocols:

•

Border Gateway Protocol (BGP)

•

Distance Vector Multicast Routing Protocol (DVMRP)

•

Intermediate System-to-Intermediate System (IS-IS)

•

Internet Control Message Protocol (ICMP) router discovery

•

Internet Group Management Protocol (IGMP)

•

Multiprotocol Label Switching (MPLS)

•

Open Shortest Path First (OSPF)

•

Protocol-Independent Multicast (PIM)

•

Resource Reservation Protocol (RSVP)

•

Routing Information Protocol (RIP)

•

Simple Network Management Protocol (SNMP)

Personnel operating the equipment must be trained and competent; must not conduct themselves in a careless, willfully negligent, or hostile manner; and must abide by the instructions provided by the documentation.

Supported Routing Platforms

For the Layer 2 features described in this manual, the Junos OS currently supports the following routing platforms:

•

Juniper Networks MX Series Ethernet Services Routers

Using the Indexes

This reference contains a standard index with topic entries.

Using the Examples in This Manual

If you want to use the examples in this manual, you can use the load merge or the load

merge relative command. These commands cause the software to merge the incoming

configuration into the current candidate configuration. If the example configuration contains the top level of the hierarchy (or multiple hierarchies), the example is a full example. In this case, use the load merge command.

About This Guide

If the example configuration does not start at the top level of the hierarchy, the example is a snippet. In this case, use the load merge relative command. These procedures are described in the following sections.

Merging a Full Example

To merge a full example, follow these steps:

1. From the HTML or PDF version of the manual, copy a configuration example into a

text file, save the file with a name, and copy the file to a directory on your routing platform.

For example, copy thefollowing configuration to a file and name the file ex-script.conf. Copy the ex-script.conf file to the /var/tmp directory on your routing platform.

system {

scripts {

commit {

file ex-script.xsl;

}

} interfaces {

fxp0 {

disable; unit 0 {

family inet {

address 10.0.0.1/24;

}

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

2. Merge the contents of the file into your routing platform configuration by issuing the

load merge configuration mode command:

[edit] user@host# load merge /var/tmp/ex-script.conf load complete

Merging a Snippet

To merge a snippet, follow these steps:

1. From the HTML or PDF version of the manual, copy a configuration snippet into a text

file, save the file with a name, and copy the file to a directory on your routing platform.

For example, copy the following snippet to a file and name the file

ex-script-snippet.conf. Copy the ex-script-snippet.conf file to the /var/tmp directory

on your routing platform.

commit {

file ex-script-snippet.xsl; }

2. Move to the hierarchy level that is relevant for this snippet by issuing the following

configuration mode command:

[edit] user@host# edit system scripts [edit system scripts]

3. Merge the contents of the file into your routing platform configuration by issuing the

load merge relative configuration mode command:

[edit system scripts] user@host# load merge relative /var/tmp/ex-script-snippet.conf load complete

For more information about the load command, see the Junos OS CLI User Guide.

Documentation Conventions

Table 1 on page xxi defines notice icons used in this guide.

Table 1: Notice Icons

About This Guide

DescriptionMeaningIcon

Indicates important features or instructions.Informational note

Indicates a situation that might result in loss of data or hardware damage.Caution

Alerts you to the risk of personal injury or death.Warning

Alerts you to the risk of personal injury from a laser.Laser warning

Table 2 on page xxi defines the text and syntax conventions used in this guide.

Table 2: Text and Syntax Conventions

Represents text that you type.Bold text like this

Fixed-width text like this

Italic text like this

Text like this

Represents output that appears on the terminal screen.

•

Introduces important new terms.

•

Identifies book names.

•

Identifies RFC and Internet draft titles.

Represents variables (options for which you substitute a value) in commands or configuration statements.

Represents names of configuration statements, commands, files, and directories; IP addresses; configuration hierarchy levels; or labels on routing platform components.

ExamplesDescriptionConvention

To enter configuration mode, type the

configure command:

user@host> configure

user@host> show chassis alarms

No alarms currently active

•

A policy term is a named structure that defines match conditions and actions.

•

Junos System Basics Configuration Guide

•

RFC 1997, BGP Communities Attribute

Configure the machine’s domain name:

[edit] root@# set system domain-name

domain-name

•

To configure a stub area, include the

stub statement at the [edit protocols ospf area area-id] hierarchy level.

•

The console port is labeled CONSOLE.

stub <default-metric metric>;Enclose optional keywords or variables.< > (angle brackets)

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

Table 2: Text and Syntax Conventions (continued)

ExamplesDescriptionConvention

| (pipe symbol)

# (pound sign)

[ ] (square brackets)

Indention and braces ( { } )

; (semicolon)

J-Web GUI Conventions

Bold text like this

Indicates a choice betweenthe mutually exclusivekeywords or variables on either side of the symbol. The set of choices is often enclosed in parenthesesfor clarity.

same lineas theconfiguration statement to which it applies.

Enclose a variable for which you can substitute one or more values.

Identify a level in the configuration hierarchy.

Identifies a leaf statement at a configuration hierarchy level.

Represents J-Web graphical user interface (GUI) items you click or select.

broadcast | multicast

(string1 | string2 | string3)

rsvp { # Required for dynamic MPLS onlyIndicates a comment specified on the

community name members [ community-ids ]

[edit] routing-options {

static {

route default {

nexthop address; retain;

}

•

In the Logical Interfaces box, select All Interfaces.

•

To cancel the configuration, click

Cancel.

> (bold right angle bracket)

Documentation Feedback

We encourage you to provide feedback, comments, and suggestions so that we can improve the documentation. You can send your comments to

techpubs-comments@juniper.net, 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 (if applicable)

Requesting Technical Support

Technical productsupport is available through the Juniper NetworksTechnical Assistance Center (JTAC). If you are a customer with an active J-Care or JNASC support contract,

Separates levels in a hierarchy of J-Web selections.

In the configuration editor hierarchy, select Protocols>Ospf.

or are covered under warranty, and need postsales 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/

About This Guide

•

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 verifyservice entitlement by productserial 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, visit us at

http://www.juniper.net/support/requesting-support.html

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

PART 1

Overview

•

Overview of Ethernet Solutions on page 3

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

CHAPTER 1

Overview of Ethernet Solutions

•

Ethernet Terms and Acronyms on page 3

•

Networking and Internetworking with Bridges and Routers on page 6

•

Network Addressing at Layer 2 and Layer 3 on page 7

•

Networking at Layer 2: Benefits of Ethernet Frames on page 9

•

Networking at Layer 2: Challenges of Ethernet MAC Addresses on page 10

•

Networking at Layer 2: Forwarding VLAN Tagged Frames on page 11

•

Networking at Layer 2: Forwarding Dual-Tagged Frames on page 13

•

Networking at Layer 2: Logical Interface Types on page 14

•

A Metro Ethernet Network with MX Series Routers on page 15

•

Layer 2 Networking Standards on page 17

Ethernet Terms and Acronyms

Networking with a switch over Ethernet on a LAN is different than networking with a router with IP over a wider area. Even the words used to talk about Ethernet networking are different from those used in IP routing. This topic provides a list of all the terms and acronyms used in the Junos OS Layer 2 Configuration Guide, as well terms that apply to a complete network using Ethernet as a carrier technology.

•

802.1ad—The IEEE specification for “Q-in-Q” encapsulation and bridging of Ethernet frames.

•

802.1ah—The IEEE specification for media access control (MAC) tunneling encapsulation and bridging of Ethernet frames across a provided backbone-managed bridge.

•

802.3ag—The IEEE specificationfor awide range ofEthernet Operations, Administration, and Maintenance (OAM) features. See also OAM, CFM, and ETH-DM.

•

802.3ah—The IEEE specification for link fault management (LFM), a method for OAM of Ethernet links.

•

802.1Q—The IEEE specification for adding virtual local area network (VLAN) tags to an Ethernet frame.

•

B–MAC—The backbone source and destination MAC address fields found in the IEEE

802.1ah provider MAC encapsulation header.

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

•

bridge—A network componentdefined by the IEEE that forwards frames fromone LAN segment or VLAN to another. The bridging function can be contained in a router, LAN switch, or other specialized device. See also switch.

•

bridge domain—A set of logical ports that share the same flooding or broadcast characteristics.As ina virtualLAN, abridge domainspans oneor moreports ofmultiple devices. By default, each bridge domain maintains its own forwarding database of MAC addresses learned from packets receivedon ports belonging tothat bridge domain. See alsobroadcast domain and VLAN.

•

B-TAG—A field defined in the IEEE 802.1ah provider MAC encapsulation header that carries the backbone VLAN identifier information. The format of the B-TAG field is the same as that of the IEEE 802.1ad S-TAG field. See also S-TAG.

•

B-VID—The specific VLAN identifier carried in a B-TAG.

•

CFM—Connectivity-fault management. The part of Ethernet OAM thatmonitors events at levels above the physical level, as does LFM. See also OAM, LFM, and ETH-DM.

•

CIST—Common and Internal Spanning Tree. The single spanning tree calculated by the spanning tree protocol (STP) and the rapid spanning tree protocol (RSTP) and the logical continuation of that connectivity through multiple spanning tree (MST) bridges and regions, calculated to ensure that all LANs in the bridged LAN are simply and fully connected. See also MSTI.

•

ETH-DM—Ethernet Frame Delay Measurements. See also OAM, CFM, and Y.1731.

•

Ethernet—A term loosely applied to a family of LAN standards based on the original proprietary Ethernet from DEC, Intel, and Xerox (DIX Ethernet), and the open specifications developed by the IEEE 802.3 committee (IEEE 802.3 LANs). In practice, few LANs comply completely with DIX Ethernet or IEEE 802.3.

•

IRB—Integrated bridging and routing. IRB provides simultaneous support for Layer 2 bridging and Layer 3 routing within the same bridge domain. Packets arriving on an interface of the bridge domain are Layer 2 switched or Layer 3 routed based on the destination MAC address. Packets addressed to the router's MAC address are routed to other Layer 3 interfaces.

•

I-SID—The 24–bit service instance identifier field carried inside an I-TAG. The I-SID defines the service instance to which the frame is mapped.

•

I-TAG—A field defined in the IEEE 802.1ah provider MAC encapsulation header that carries the service instance information (I-SID) associated with the frame.

•

learning domain—A MAC address database where theMAC addresses are added based on the normalized VLAN tags.

•

LFM—Link fault management. A method used to detect problems on links and spans on an Ethernet network defined in IEEE 802.3ah. See also OAM.

•

MSTI—Multiple Spanning Tree Instance. One of a number of spanning trees calculated by MSTP within an MST region. The MSTI provides a simple and fully connected active topology for frames classified as belonging to a VLAN that is mapped to the MSTI by the MST configuration table used by the MST bridges of that MST region. See also CIST.

Chapter 1: Overview of Ethernet Solutions

•

MSTP—Multiple Spanning Tree Protocol. A spanning-tree protocol used to prevent loops in bridge configurations. Unlike other types of STPs, MSTP can block ports selectively by VLAN. See also RSTP.

•

OAM—Operation, Administration, and Maintenance. A set of tools used to provide management for links, device, and networks. See also LFM.

•

PBB—Provider backbone bridge.

•

Q-in-Q—See 802.1ad.

•

PBBN—Provider backbone bridged network.

•

RSTP—Rapid Spanning Tree Protocol. A spanning-tree protocol used to prevent loops in bridge configurations. RSTP is not aware of VLANs and blocks ports at the physical level. See also MSTP.

•

S-TAG—A field defined in the IEEE 802.1ad Q-in-Q encapsulation header that carries the S-VLAN identifier information. See also B-TAG.

•

S-tagged service interface—The interface between a customer edge (CE) device and the I-BEBor IB-BEB network components. Frames passed through thisinterfacecontain an S-TAG field. See also B-tagged service interface.

Documentation

•

S-VLAN—The specific service instance VLAN identifier carried inside the S-TAG field. See also B-VID.

•

switch—A network device that attempts to perform as much of the forwarding task in hardware as possible. The switch can function as a bridge (LAN switch), router, or some other specialized device, and forwards frames, packets, or other data units. See also bridge.

•

virtual switch—A routing instance that can contain one or more bridge domains.

•

VLAN—Virtual LAN. Defines a broadcast domain, a set of logical ports that share the same floodingor broadcast characteristics. VLANs span one or more ports on multiple devices. By default, each VLAN maintains its own Layer 2 forwarding database containing MAC addresses learned from packets received on ports belonging to the VLAN. See also bridge domain.

•

Y.1731—Theinternational standard forEthernet FrameDelay Measurements (ETH-DM).

At this point, these acronyms and terms are just a bewildering array of letters and words. It is the goal of this manual to make the contents of this list familiar and allow you to place each of them in context and understand how they relate to each other. To do that, a basic understanding of modern Ethernet standards and technology is necessary.

MX Series Ethernet Services Routers Solutions Page•

• Networking and Internetworking with Bridges and Routers on page 6

• Network Addressing at Layer 2 and Layer 3 on page 7

• Networking at Layer 2: Benefits of Ethernet Frames on page 9

• Networking at Layer 2: Challenges of Ethernet MAC Addresses on page 10

• Networking at Layer 2: Forwarding VLAN Tagged Frames on page 11

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

• Networking at Layer 2: Forwarding Dual-Tagged Frames on page 13

• Networking at Layer 2: Logical Interface Types on page 14

• A Metro Ethernet Network with MX Series Routers on page 15

• Layer 2 Networking Standards on page 17

Networking and Internetworking with Bridges and Routers

Traditionally, different hardware, software, and protocols have been used on LANs and on networks that cover wider areas (national or global). A LAN switch is different than a router, an Ethernet frame is different than an IP packet, and the methods used to find destination MAC addresses aredifferent than those usedto finddestination IPaddresses. This is because LANs basedon Ethernetwere intended for different network environments than networks based on IP. The Internet protocol suite (TCP/IP) was intended as an internetworkingmethod toconnect local customer networks. The localcustomer network that a service provider's IP routers connected was usually based onsome formof Ethernet. This is why Ethernet andIP fit so well together: Ethernet definesthe LAN, and the Internet protocols define how these LANs are connected.

More specifically, Ethernet LANsand IP networks occupy different layers ofthe Internet’s TCP/IP protocol suite. Between senderand receiver,networks deal with thebottom three layers of the model: the physical layer (Layer 1), the data link or MAC layer (Layer 2), and the network layer (Layer 3).

NOTE: These layers are also found in the Open Systems Interconnect

Reference Model (OSI-RM); however, in this chapter they are applied to the TCP/IP protocol suite.

All digital networks ultimately deal with zeroes and ones, and the physical layer defines bit representationon themedia. Physical layerstandards also definemechanical aspects of the network, such as electrical characteristics or connector shapes, functional aspects such as bit sequence and organization, and so on. The physical layer only “spits bits” and has very little of the intelligence required to implement a complete network. Devices that connect LAN segments at the physical layer are called hubs, and all bits that appear on one port of the hub are also sent out on the other ports. This also means that bad bits that appear on one LAN segment are propagated to all other LAN segments.

Above the physical layer, the data link layer defines the first-order bit structure, or frame, for the network type. Also loosely called the MAC layer (technically, the MAC layer is a sublayer required only on LANs), Layer 2 sends and receives frames. Frames are the last things that bits were before they left the sender and the first things that bits become when they arrive on an interface. Because frames have a defined structure, unlike bits, frames can be used for error detection, control plane activities (not all frames must carry user data: some frames are used by the network to control the link), and so forth. LAN segments can be linked at the frame level, and these devices are called bridges. Bridges examine arriving frames and decide whether to forward them on an interface. All bridges today are called learning bridges because they can find out more about the network than

Chapter 1: Overview of Ethernet Solutions

could older bridges that were less intelligent devices. Bridges learn much about the LAN segments they connect to from protocols like those in the Spanning Tree Protocol (STP) family.

The network layer (Layer 3) is the highest layer used by network nodes to forward traffic as part of the data plane. On the Internet, the network layer is the IP layer and can run either IPv4 or IPv6, which are independent implementations of the same functions. The IP layer defines the structure and purpose of the packet, which is in turn the content of the frame at Layer 2. As expected, LAN segments (which now form perfectly functional networks on their own at the frame level) can be linked at the network layer, and in fact that is one of the major functions of IP. Devices that link LANs at the network layer are called routers, and IP routers are the network nodes of the Internet.

Documentation

MX Series Ethernet Services Routers Solutions Page•

• Ethernet Terms and Acronyms on page 3

• Network Addressing at Layer 2 and Layer 3 on page 7

• Networking at Layer 2: Benefits of Ethernet Frames on page 9

• Networking at Layer 2: Challenges of Ethernet MAC Addresses on page 10

• Networking at Layer 2: Forwarding VLAN Tagged Frames on page 11

• Networking at Layer 2: Forwarding Dual-Tagged Frames on page 13

• Networking at Layer 2: Logical Interface Types on page 14

• A Metro Ethernet Network with MX Series Routers on page 15

• Layer 2 Networking Standards on page 17

Network Addressing at Layer 2 and Layer 3

The Internet is a global, public network with IP subnets connected by routers and exchanging packets. Can a global, public network consist of Ethernet LANs connected by bridges and exchanging frames? Yes, it can, but there are several differences that must be addressed before Ethernet can function as effectively as IP in the metropolitan area (Metro Ethernet), let alone globally. One of the key differences is the addresses used by Layer 2 frames and Layer 3 packets.

Both Ethernet and IP use globally unique network addresses that can be used as the basis for a truly global network. Ethernet MAC addresses come from the IEEE and IP subnet addresses come from various Internet authorities. (IP also employs a naming convention absent in Ethernet, but we'll ignore that in this discussion.) The keydifferences in how these addresses are assigned make all the difference when it comes to the basic functions of a bridge as opposed to a router.

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

NOTE: The opposite of a “globally unique network address” is the “locally

significant connection identifier” which connects two endpoints on a network. For example, MPLS labels such as 1000001 can repeat in a network, but a public IP address can appear on the Internet in only one place at a time (otherwise it is an error).

All devices on LANs that are attached to the Internet have both MAC layer and IP addresses. Frames and packets contain both source and destination addresses in their headers. In general:

•

MAC addresses are 48 bits long. The first 24 bits are assigned by the IEEE and form the organizationally unique identifier (OUI) of the manufacturer or vendor requesting the address. The last 24 bits form the serial number of the LAN interface cards and their uniqueness must be enforced by the company (some companies reuse numbers of bad or returned cards while others do not).

•

IPv4 addresses are 32 bits long. A variable number of the beginning bits are assigned by an Internet authority and represent a subnet located somewhere in the world. The remaining bits are assigned locally and, when joined to the network portion of the address, uniquely identify some host on a particular network.

•

IPv6 addresses are 128 bits long. Although there are significant differences, for the purposes of this discussion, it is enough to point out that there is also a network and host portion to an IPv6 address.

Note that MAC addresses are mainly organized by manufacturer and IP addresses are organized by network, which is located in a particular place. Therefore, the IP address can easily be used by routers for a packet's overall direction (for example, “192.168.27.48 is west of here”). However, the MAC addresses on a vendor's interface cards can end up anywhere in the world, and often do. Consider a Juniper Networks router as a simple example.Every Ethernet LANinterface on the router thatsends or receives packets places them inside Ethernet frames with MAC addresses. All of these interfaces share the initial 24 bitsassigned to Juniper Networks. Two might differ only in one digitfrom one interface to another. Yet the routers containing these MAC interfaces could be located on opposite sides of the world.

An Internet backbone router only needs a table entry for every network (not host) in the world. Most other routers only have a portion of this full table, and a default route for forwarding packets with no entries in their table. In contrast, to perform the same role, a bridge would need one table entry for every LAN interface, on host or bridge, in the world. This is hard enough to do for Ethernets that span a metropolitan area, let alone the entire world.

NOTE: There are other reasons that Ethernet would be hard-pressed to

become a truly global network, including the fact that MAC addresses do not often have names associated with them while IP addresses do (for example,

192.168.27.48 might be host48.accounting.juniper.net). This section addresses

only the address issues.

Chapter 1: Overview of Ethernet Solutions

Documentation

MX Series Ethernet Services Routers Solutions Page•

• Ethernet Terms and Acronyms on page 3

• Networking and Internetworking with Bridges and Routers on page 6

• Networking at Layer 2: Benefits of Ethernet Frames on page 9

• Networking at Layer 2: Challenges of Ethernet MAC Addresses on page 10

• Networking at Layer 2: Forwarding VLAN Tagged Frames on page 11

• Networking at Layer 2: Forwarding Dual-Tagged Frames on page 13

• Networking at Layer 2: Logical Interface Types on page 14

• A Metro Ethernet Network with MX Series Routers on page 15

• Layer 2 Networking Standards on page 17

Networking at Layer 2: Benefits of Ethernet Frames

In spite of the difficulties of using a bridge to perform the network role of a router, many vendors, customers, and service providers are attracted to the idea of using Ethernet in as many places of their networks as possible.

The perceived benefits of Ethernet are:

•

Most information starts and ends inside Ethernet frames. Today, this applies to data, as well as voice (for example, VoIP) and video (for example, Web cams).

•

Ethernet frames have all the essentials for networking, such as globally unique source and destination addresses, error control, and so on.

•

Ethernet frames can carry any kind of packet. Networking at Layer 2 is protocol independent (independent of the Layer 3 protocol). Layer 2 networks work for IP packets and all other Layer 3 protocols.

•

More layers added to the Ethernet frame only slow the networking process down (“nodal processing delay”).

•

Adjunct networking features such as class of service (CoS) or multicasting can be added to Ethernet as readily as IP networks.

If more of the end-to-end transfer of information from a source to a destination can be done in the form of Ethernet frames, more of the benefits of Ethernet can be realized on the network. Networking at Layer 2 can be a powerful adjunct to IP networking, but it is not usually a substitute for IP networking.

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

NOTE: Networking at the frame level says nothing about the presence or

absence of IP addressesat the packet level. Almost all ports, links,and devices on a network of LAN switches still have IP addresses, just as do all the source and destination hosts. There are many reasons for the continued need for IP, not the least of which is the need to manage the network. A device or link without an IP address is usually invisible to most management applications. Also, utilities such as remote access for diagnostics, file transfer of configurations and software, and so on cannot run without IP addresses as well as MAC addresses.

Documentation

MX Series Ethernet Services Routers Solutions Page•

• Ethernet Terms and Acronyms on page 3

• Networking and Internetworking with Bridges and Routers on page 6

• Network Addressing at Layer 2 and Layer 3 on page 7

• Networking at Layer 2: Challenges of Ethernet MAC Addresses on page 10

• Networking at Layer 2: Forwarding VLAN Tagged Frames on page 11

• Networking at Layer 2: Forwarding Dual-Tagged Frames on page 13

• Networking at Layer 2: Logical Interface Types on page 14

• A Metro Ethernet Network with MX Series Routers on page 15

• Layer 2 Networking Standards on page 17

Networking at Layer 2: Challenges of Ethernet MAC Addresses

If a networked Layer 2 device such as a bridge or LAN switch could contain a list of all known MAC addresses, then the network node could function in much the same way as a router, forwarding frames instead of packets hop-by-hop through the network from source LAN to destination LAN. However, the MAC address is much larger than the IPv4 address currently used on the Internet backbone (48 bits compared to the 32 bits of IPv4).

Documentation

This poses problems. Also, because the MAC address has no “network organization” like the IPv4or IPv6 address, anLayer 2network node must potentially store every conceivable MAC address in memory for next-hop table lookups. Instead of tables of about 125,000 entries, every Layer 2 network node would have to store millions of entries (for example, 24 bits, the potential NIC production from one Ethernet vendor, would require a table of more than 16 million entries).

MX Series Ethernet Services Routers Solutions Page•

• Ethernet Terms and Acronyms on page 3

• Networking and Internetworking with Bridges and Routers on page 6

• Network Addressing at Layer 2 and Layer 3 on page 7

• Networking at Layer 2: Benefits of Ethernet Frames on page 9

• Networking at Layer 2: Forwarding VLAN Tagged Frames on page 11

• Networking at Layer 2: Forwarding Dual-Tagged Frames on page 13

• Networking at Layer 2: Logical Interface Types on page 14

• A Metro Ethernet Network with MX Series Routers on page 15

• Layer 2 Networking Standards on page 17

Networking at Layer 2: Forwarding VLAN Tagged Frames

VLAN tags were not developed as a way to limit network node table entries. They were originally invented to allow LAN switches to distinguish between physical groups of LAN ports and logical groups of LAN ports. In other words, there was a need to configure a LAN switch (or group of local LAN switches) to know that “these ports belong to VLAN A” and “these ports belong to VLAN B.”

Chapter 1: Overview of Ethernet Solutions

This was important because of how all LANs, not just Ethernet, work at the frame level. Lots of frames on a LAN are broadcast to all stations (hosts and network nodes) on the LAN segment. Also, multicasting works by flooding traffic within the VLAN. The stations that received broadcast frames form the broadcast domain of the LAN. Only Ethernet frames belonging to same broadcastdomain are forwarded out certain ports on the LAN switch. This prevents broadcast storms and isolates routine control frames onto the LAN segment where they make the most sense.

The VLAN tag was invented to distinguish among different VLAN broadcast domains on a group of LAN switches. The VLAN tag is a two-byte field inserted between the source MAC address and the Ethertype (or length) field in an Ethernet frame. Another two-byte field, the Tag Protocol Identifier (TPI or TPID), precedes the VLAN tag field.

Two fields were necessary to hold one piece of information, the VLAN tag, to enable receiversto distinguish between untagged or plain Ethernet frames and thosecontaining VLAN tags. Amechanism was required to differentiatebetween the Ethertype andlength field for the untagged case and to distinguish among VLAN tag, Ethertype, and length field for the tagged case. The answer was to constrain the TPID field to values that were not valid Ethernet frame lengths or defined asvalid Ethertypes. The first VLAN tag added to an Ethernet frame is always indicated by a TPID value of 0x8100. This is not the VLAN identifier, which appears in the next two bytes.

In Figure 1 on page 12, a native or normal Ethernet frame is compared to a VLAN-tagged Ethernet frame. The lengths of each field, in bytes, is shown next to the field name.

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

Figure 1: Native (Normal) and VLAN-Tagged Ethernet Fames

The VLAN tag subtracts four bytes from the total MTU length of the Ethernet frame, but this is seldom a problem if kept in mind. When this tag is used in an Ethernet frame, the frame complies with the IEEE 802.1Q (formerly IEEE 802.1q) specification.

Together, the four added bytes form the VLAN tag,but the individual fields that comprise it are more important. The 2–byte TPID field is just a number and has no structure, only having allowed and disallowed values. However, the 2-byte Tag Control Information (TCI) field has a defined structure:

Documentation

•

The three bits of the User Priority field are defined by the IEEE 802.1p specification. These can mimic class-of-service (CoS) parameters established at other layers of the network (IP precedence bits, or MPLS EXP bits, and so on).

•

The Canonical Format Indicator (CFI) bit indicates whether the following 12 bits of VLAN identifier conform to Ethernet or not. For Ethernet frames, this bit is always set to 0. (The other possible value, CFI=1, is used for Token Ring LANs, and tagged frames should never be bridged between an Ethernet and Token Ring LAN regardless of the VLAN tag or MAC address.)

•

The 12-bit VLAN ID allows for 4096 possible VLANs, but not all values are used in all cases.

MX Series Ethernet Services Routers Solutions Page•

• Ethernet Terms and Acronyms on page 3

• Networking and Internetworking with Bridges and Routers on page 6

• Network Addressing at Layer 2 and Layer 3 on page 7

• Networking at Layer 2: Benefits of Ethernet Frames on page 9

• Networking at Layer 2: Challenges of Ethernet MAC Addresses on page 10

• Networking at Layer 2: Forwarding Dual-Tagged Frames on page 13

• Networking at Layer 2: Logical Interface Types on page 14

• A Metro Ethernet Network with MX Series Routers on page 15

• Layer 2 Networking Standards on page 17

Networking at Layer 2: Forwarding Dual-Tagged Frames

The use of VLAN tagging to group (or bundle) sets of MAC addresses is a start toward a method of forwarding LAN traffic based on information found in the frame, not on IP address in the packet. However, there is a major limitation in trying to build forwarding tables based on VLAN tags. Simply put, there are not enough VLAN tags.

Twelve bits only supply enough space for 4096 unique VLAN tags. This is hardly enough for all the LANson a large corporatecampus, let alone the whole world. A 12-bit tag might suffice for the local campus arena, but for the metropolitan area, comprising a whole city, more bits are needed.

The number of bits in the VLAN tag, two bytes for the TPID and two bytes for the TCI field, are fixed and cannot be extended. However, another VLAN tag can be added to the frame, forming an inner and outer VLAN tag arrangement. This arrangement is defined in the IEEE 802.1ad specification and applies to devices that function on the provider bridge level. This means that Ethernet frames tagged at the local (or customer) VLAN level can receive another outer VLAN tag when they are sent to the provider's LAN switches. As a result, Ethernet frames can be switched across a metropolitan area, not just among the local organizations devices at the campus level.

Chapter 1: Overview of Ethernet Solutions

The outer tag defined in IEEE 802.1ad is often called theVirtual Metropolitan Area Network (VMAN) tag, a good way to recall the intended scope of the specification. The outer tag is placed after the MAC source address, moving the inner tag backwards in the frame. Both tags can be added at the same time by the same device (called a push/push operation), changed by a device (a swap operation), or removed by a device one at a time (pop) or together (pop/pop). Devices can perform elaborate variations on these operations (such as pop/swap/push) to accomplish the necessary networking tasks with the frames they process.

The IEEE specification indicates that the outer tag of a doubly-tagged Ethernet frame should have a TPID value of 0x88a8. Any network device can easily tell if it has received a frame withone tag(0x8100) or two tags (0x88a8).However, because thevalue 0x8100 always means that a VLAN tag is present, most vendors and networks use the same TPID value (0x8100) for the inner and outer tags. As long as the configuration and processing are consistent, there is no confusion, and the TPID value can usually be changed if necessary.

How do nested VLAN tags solve the VLAN numbering limitation? Taken together, the two VLAN tags can be thought of as providing 24 bits for tagging space: 12 bits at the outer level and 12 bits at the inner level. However, it is important to realize that the bits are not acted on as if they were all one tag. Even when the tags are nested, bridges on a provider backbone will normally only switch on the outer VLAN tag. All in all, the inner 12-bit tagging space is more than adequate for a Metro Ethernet network.Any limitations in the VLAN tag space can be addressed by adding more VLAN tags to the basic Ethernet frame.

Documentation

MX Series Ethernet Services Routers Solutions Page•

• Ethernet Terms and Acronyms on page 3

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

• Networking and Internetworking with Bridges and Routers on page 6

• Network Addressing at Layer 2 and Layer 3 on page 7

• Networking at Layer 2: Benefits of Ethernet Frames on page 9

• Networking at Layer 2: Challenges of Ethernet MAC Addresses on page 10

• Networking at Layer 2: Forwarding VLAN Tagged Frames on page 11

• Networking at Layer 2: Logical Interface Types on page 14

• A Metro Ethernet Network with MX Series Routers on page 15

• Layer 2 Networking Standards on page 17

Networking at Layer 2: Logical Interface Types

Two main types of interfaces are used in Layer 2 configurations:

•

Layer 2 logical interface—This type of interface uses the VLAN-ID as a virtual circuit identifier and the scope of the VLAN-ID is local to the interface port. This type of interface is often used in service-provider-centric applications.

Documentation

•

Accessor trunkinterface—This type of interface usesa VLAN-ID with global significance. The access or trunk interface is implicitly associated with bridge domains based on VLAN membership. Access or trunk interfaces are typically used in enterprise-centric applications.

NOTE: The difference between access interfaces and trunk interfaces is

that access interfaces can be part of one VLAN only and the interface is normally attached to an end-user device (packetsare implicitlyassociated with the configured VLAN). In contrast, trunk interfaces multiplex traffic from multiple VLANs and usually interconnect switches.

MX Series Ethernet Services Routers Solutions Page•

• Ethernet Terms and Acronyms on page 3

• Networking and Internetworking with Bridges and Routers on page 6

• Network Addressing at Layer 2 and Layer 3 on page 7

• Networking at Layer 2: Benefits of Ethernet Frames on page 9

• Networking at Layer 2: Challenges of Ethernet MAC Addresses on page 10

• Networking at Layer 2: Forwarding VLAN Tagged Frames on page 11

• Networking at Layer 2: Forwarding Dual-Tagged Frames on page 13

• A Metro Ethernet Network with MX Series Routers on page 15

• Layer 2 Networking Standards on page 17

A Metro Ethernet Network with MX Series Routers

What would aMetro Ethernet network withJuniper Networks MXSeries Ethernet Services Routers look like? It is very likely that the Metro Ethernet network will place MX Series routers at the edge of a VPLS and MPLS core network.

The VLAN labels in the packet are stacked with MPLS labels, as shown in Figure 2 on page 15. For a more detailed examination of this type of Metro Ethernet network, see “Example: Configuring a Provider VPLS Network with Normalized VLAN Tags” onpage 51.

Figure 2: A Metro Ethernet Network

Chapter 1: Overview of Ethernet Solutions

Another possible configuration, this one without the VPLS and MPLS core, is shown in Figure 3 on page 16.

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

Figure 3: A Metro Ethernet Network with MX Series Routers

In Figure 3 on page 16, the circled numbers reflect the different formats that the Ethernet frames can take as the frames make their way from a host on one Ethernet switching hub to a host on the other hub. The frame can have two VLAN tags (inner and outer), one tag (only the inner), or no tags at all. The structure of these various Ethernet frames is shown in Figure 4 on page 16.

Figure 4: VLAN Tags on a Metro Ethernet Network

Documentation

As the frame flows froma LAN-basedhost on oneend of Figure 4 on page 16 to the other, the Ethernet frame can have:

•

No VLAN tags—At locations 1 and 5, the Ethernet frames can be native and have no VLAN tags at all (many NIC cards can include configuration of a VLAN identifier, but not all).

•

One VLAN tag—At locations 2 and 4, from the VLAN-aware switching hub to the MX Series router, the Ethernet frame has one VLAN tag (if a VLAN tag is not present on arriving frames, a tag is added by the MX Series router).

•

Two VLAN tags—At location 3, between two provider bridges, the MX Series routers exchange frames with two VLAN tags. The outer tags are added and removed by the MX Series routers.

MX Series Ethernet Services Routers Solutions Page•

• Ethernet Terms and Acronyms on page 3

• Networking and Internetworking with Bridges and Routers on page 6

• Network Addressing at Layer 2 and Layer 3 on page 7

• Networking at Layer 2: Benefits of Ethernet Frames on page 9

• Networking at Layer 2: Challenges of Ethernet MAC Addresses on page 10

• Networking at Layer 2: Forwarding VLAN Tagged Frames on page 11

• Networking at Layer 2: Forwarding Dual-Tagged Frames on page 13

• Networking at Layer 2: Logical Interface Types on page 14

• Layer 2 Networking Standards on page 17

Layer 2 Networking Standards

For additional information about the Layer 2 networking features available on Juniper Networks MX Series Ethernet Services Routers, see the following references:

Chapter 1: Overview of Ethernet Solutions

•

802.1ad—IEEE standard Provider Bridges .

•

802.1ag—IEEE standard Connectivity Fault Management.

•

802.1ah—IEEE standard Provider Backbone Bridges.

•

802.1p—IEEE draft standard Wireless Access in Vehicular Environments.

•

802.1Q—IEEE standard Provider Backbone Bridge Traffic Engineering.

•

802.3ah-2004—IEEE standard Operations Administration, and Management (OAM) for link fault management (LFM), or simple connectivity fault management (CFM) at the data link layer. Also known as “Ethernet in the First Mile (EFM)” and EFM-OAM.

•

802.3-2008, Clause 57—IEEE standard Operations Administration, and Maintenance (OAM). Incorporates 802.3ah-2004 within the IEEE standard Carrier sense multiple access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications.

•

RFC 4761—IETF draft Virtual Private LAN Service (VPLS) Using BGP for Auto-discovery and Signaling.

•

RFC 4762—IETF draft Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling.

•

Y.1731—ITU-T recommendation OAM Functions and Mechanisms for Ethernet-based Networks.

•

OSI-RM—Open Systems Interconnection Reference Model.

Documentation

• MX Series Ethernet Services Routers Solutions Page

• Ethernet Terms and Acronyms on page 3

• Networking and Internetworking with Bridges and Routers on page 6

• Network Addressing at Layer 2 and Layer 3 on page 7

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

• Networking at Layer 2: Benefits of Ethernet Frames on page 9

• Networking at Layer 2: Challenges of Ethernet MAC Addresses on page 10

• Networking at Layer 2: Forwarding VLAN Tagged Frames on page 11

• Networking at Layer 2: Forwarding Dual-Tagged Frames on page 13

• Networking at Layer 2: Logical Interface Types on page 14

• A Metro Ethernet Network with MX Series Routers on page 15

PART 2

Basic Solutions for MX Series Routers

•

Basic Layer 2 Features on MX Series Routers on page 21

•

Virtual Switches on page 39

•

VLANs Within Bridge Domain and VPLS Environments on page 43

•

Bulk Administration of Layer 2 Features on MX Series Routers on page 59

•

Dynamic Profiles for VLAN Interfaces and Protocols on page 63

•

MX Series Router as a DHCP Relay Agent on page 73

•

MX Series Router in an ATM Ethernet Interworking Function on page 77

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

CHAPTER 2

Basic Layer 2 Features on MX Series Routers

•

Layer 2 Features for a Bridging Environment on page 21

•

Example Roadmap: Configuring a Basic Bridge Domain Environment on page 22

•

Example Step: Configuring Interfaces and VLAN Tags on page 24

•

Example Step: Configuring Bridge Domains on page 30

•

Example Step: Configuring Spanning Tree Protocols on page 32

•

Example Step: Configuring Integrated Bridging and Routing on page 34

Layer 2 Features for a Bridging Environment

You configure MX Series routers exactly as you would any other router running the Junos OS. That is, all the familiar Layer 3 features and protocols are available on the MX Series routers. However, you can configure Layer 2 features that are unique to the MX Series routers. This chapter addresses Layer 2 configuration for the MX Series routers. For information about configuring Layer 3 features and protocols, as well as comprehensive informationabout interfaces and systembasics, please see the other Junos configuration guides.

Configuring Layer 2 features on an MX Series router can vary from the very simple (aggregated Ethernet trunk interfaces, spanning trees), to the more complex (inner and outer VLAN tags, broadcast domains), to the very complicated (integrated bridging and routing, Layer 2 filtering). This chapter offers a fairly complex configuration for Layer 2 processing in a bridged environment.

Generally, there are four things that you must configure in an Layer 2 environment:

•

Interfaces and virtual LAN (VLAN) tags—Layer 2 interfaces are usually various type of Ethernet links with VLAN tags used to connect to customer devices or other bridges or routers.

•

Bridge domains—Bridge domains limit the scope of media access control (MAC) learning (and thereby the size of the MAC table) and also determine where the device should propagate frames sent to broadcast, unknown unicast, and multicast (BUM) MAC addresses.

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

•

Spanning Tree Protocols (xSTP, where the “x” represents the STP type)—Bridges function by associating a MAC address with an interface, similar to the way a router associates an IP network address with a next-hop interface. Just as routing protocols use packets to detect and prevent routing loops, bridges use xSTP frames to detect and prevent bridging loops. (Layer 2 loops are more devastating to a network because of the broadcast nature of Ethernet LANs.)

•

Integrated bridging and routing (IRB)—Support for both Layer 2 bridging and Layer 3 routing on the same interface. Frames are bridged if they are not sent to the router's MAC address. Frames sent to the router's MAC address are routed to other interfaces configured for Layer 3 routing.

Documentation

MX Series Ethernet Services Routers Solutions Page•

• Example Roadmap: Configuring a Basic Bridge Domain Environment on page 22

• Example Step: Configuring Interfaces and VLAN Tags on page 24

• Example Step: Configuring Bridge Domains on page 30

• Example Step: Configuring Spanning Tree Protocols on page 32

• Example Step: Configuring Integrated Bridging and Routing on page 34

Example Roadmap: Configuring a Basic Bridge Domain Environment

Configuring Layer 2 features on MX Series routers can vary from the very simple (aggregated Ethernet trunk interfaces, spanning trees), to the more complex (inner and outer VLAN tags, broadcast domains), to the very complicated (integrated bridging and routing, Layer 2 filtering). This example offers a fairly complex configuration for Layer 2 processing in a bridged environment.

•

Example Topology on page 22

•

Example Scenario on page 23

•

Example Configuration Summary on page 24

Example Topology

Consider the network in Figure 5 on page 23. The figure shows three MX Series routers acting as Layer 2 devices.

Figure 5: Bridging Network with MX Series Routers

Chapter 2: Basic Layer 2 Features on MX Series Routers

Example Scenario

The three routers each have a series of hosts on their Ethernet interfaces, as well as aggregated Ethernet linksbetween them.Router 2 and Router 3are linked tothe Internet, and Router 1 and Router 3 are also linked to switches configured with a range of VLANs, as shown in the figure. Because the VLAN tags are important, the routers run Multiple STP (MSTP) on the links connecting them to preventbridging loops(Rapid STP, or RSTP, does not recognize VLAN tags and blocks ports without regard for VLAN tagging).

The network administrator wants to configure these links and devices so that:

•

The six Gigabit Ethernet links between Router 1 and the otherrouters (ge-2/1/0 through

ge-2/1/5) are gathered into two aggregated Ethernet (AE) links mixing bridged traffic

from the VLANs. AE1 will consist of the first three links and AE2 will use the last three links. The same approach is taken for the links on Router 2 and Router 3.

•

The Gigabit Ethernet links from Router 1to thecustomer devices (ge-2/2/1 and ge-2/2/6 ) willbe bridgedand includeVLAN tag100 on ge-2/2/1 and VLAN tag 200on ge-2/2/6. The other two routers, Router 2 and Router 3, also have two ports configured to handle VLAN 100 on one port (ge-2/2/2) and VLAN 200 on the other (ge-3/3/3).

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

•

Router 2 and Router 3 have IRB configured so that they can pass trafficto other routers in the rest of the network.

•

Router1 has anaccessinterfacewhich provides bridging on VLAN 205 and is connected to a customer device configured on ge-2/2/2. Router 3 has an access interface which provides bridging on VLAN 200 and is connected to a customer device configured on

ge-2/2/6.

•

Router 1 and Router 3 are configured with a trunk interface to a switch for VLANs 200–205. On both routers, this interface is ge-2/2/4.

Example Configuration Summary

This procedure summarizes the minimum configuration steps required for Layer 2 processing in a bridged environment, as described in “Layer 2 Features for a Bridging Environment” on page 21. The individual configuration steps are described in greater detail in separate topics.

To configure Layer 2 processing in a bridged domain network:

1. Configure the Ethernet interfaces and VLAN tags on all three routers, as described in

“Example Step: Configuring Interfaces and VLAN Tags” on page 24

2. Configure the bridge domains on all three routers, as described in “Example Step:

Configuring Bridge Domains” on page 30.

3. Configure the Spanning Tree Protocol on all three routers, as described in “Example

Step: Configuring Spanning Tree Protocols” on page 32

4. Configure IRB, as described in “Example Step: Configuring Integrated Bridging and

Routing” on page 34

Documentation

MX Series Ethernet Services Routers Solutions Page•

• Layer 2 Features for a Bridging Environment on page 21

• Example Step: Configuring Interfaces and VLAN Tags on page 24

• Example Step: Configuring Bridge Domains on page 30

• Example Step: Configuring Spanning Tree Protocols on page 32

• Example Step: Configuring Integrated Bridging and Routing on page 34

Example Step: Configuring Interfaces and VLAN Tags

Configure the Ethernet interfaces and VLAN tags on all three routers.

NOTE: The configurations in this chapter are only partial examples of

complete and functional router configurations. Do not copy these configurations and use them directly on an actual system.

Chapter 2: Basic Layer 2 Features on MX Series Routers

To configure the Ethernet interfaces and VLAN tags on all three routers:

Configure the Ethernet interfaces and VLAN tags on Router 1:

[edit] chassis {

aggregated-devices {

ethernet {

device-count 2; # Number of AE interfaces on router

}

} } interfaces ge-2/1/0 {

gigether-options {

802.3ad ae2;

} } interfaces ge-2/1/1 {

gigether-options {

802.3ad ae2;

} } interfaces ge-2/1/2 {

gigether-options {

802.3ad ae2;

} } interfaces ge-2/1/3 {

gigether-options {

802.3ad ae1;

} } interfaces ge-2/1/4 {

gigether-options {

802.3ad ae1;

} } interfaces ge-2/1/5 {

gigether-options {

802.3ad ae1;

} } interfaces ge-2/2/1 {

encapsulation flexible-ethernet-services;

vlan-tagging; # Customer interface uses singly-tagged frames

unit 100 {

encapsulation vlan-bridge;

vlan-id 100; } unit 200 {

encapsulation vlan-bridge;

vlan-id 200; }

} interfaces ge-2/2/2 {

unit 0 {

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

family bridge {

interface-mode access; vlan-id 205;

} }

} interfaces ge-2/2/4 {

native-vlan-id 200; # Untagged packets get vlan 200 tag unit 0 {

family bridge {

interface-mode trunk; vlan-id-list 200-205; # This trunk port is part of VLAN range 200–205

} }

} interfaces ge-2/2/6 {

encapsulation flexible-ethernet-services; vlan-tagging; # Customer interface uses singly-tagged frames unit 200 {

encapsulation vlan-bridge;

vlan-id 200; }

} interfaces ae1 {

encapsulation extended-vlan-bridge; vlan-tagging; unit 100 {

vlan-id 100; } unit 200 {

vlan-id 200; }

} interfaces ae2 {

unit 0 {

family bridge {

interface-mode trunk; vlan-id-list 100, 200–205;

} }

}

Configure the Ethernet interfaces and VLAN tags on Router 2:

[edit] chassis {

aggregated-devices {

ethernet {

device-count 2; # Number of AE interfaces on the router

} }

} interfaces ge-2/2/2 {

encapsulation flexible-ethernet-services; vlan-tagging; # Customer interface uses singly-tagged frames unit 100 {

Chapter 2: Basic Layer 2 Features on MX Series Routers

encapsulation vlan-bridge;

vlan-id 100; }

} interfaces ge-3/3/3 {

encapsulation flexible-ethernet-services; vlan-tagging; # Customer interface uses singly-tagged frames unit 200 {

encapsulation vlan-bridge;

vlan-id 200; }

} interfaces ge-5/1/0 {

gigether-options {

802.3ad ae3;

}

} interfaces ge-5/1/1 {

gigether-options {

802.3ad ae3;

}

} interfaces ge-5/1/2 {

gigether-options {

802.3ad ae3;

}

} interfaces ge-5/1/3 {

gigether-options {

802.3ad ae1;

}

} interfaces ge-5/1/4 {

gigether-options {

802.3ad ae1;

}

} interfaces ge-5/1/5 {

gigether-options {

802.3ad ae1;

}

} interfaces ae1 {

encapsulation extended-vlan-bridge; vlan-tagging; unit 100 {

vlan-id 100; } unit 200 {

vlan-id 200; }

} interfaces ae3 {

encapsulation extended-vlan-bridge; vlan-tagging; unit 100 {

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

vlan-id 100; } unit 200 {

vlan-id 200; }

}

Configure the Ethernet interfaces and VLAN tags on Router 3:

[edit] chassis {

aggregated-devices {

ethernet {

device-count 2; # Number of AE interfaces on router

} }

} interfaces ge-2/2/2 {

encapsulation flexible-etherent-services; vlan-tagging; # Customer interface uses singly-tagged frames unit 100 {

encapsulation vlan-bridge;

vlan-id 100; }

} interfaces ge-2/2/4 {

unit 0 {

family bridge {

interface-mode trunk; vlan-id-list 200-205; # This trunk port is part of VLAN range 200–205

} }

} interfaces ge-2/2/6 {

unit 0 {

family bridge {

interface-mode acess; vlan-id 200;

} }

} interfaces ge-3/3/3 {

encapsulation flexible-ethernet-services; vlan-tagging; # Customer interface uses singly-tagged frames unit 200 {

encapsulation vlan-bridge;

vlan-id 200; }

} interfaces ge-11/1/0 {

gigether-options {

802.3ad ae3;

}

} interfaces ge-11/1/1 {

gigether-options {

802.3ad ae3;

}

} interfaces ge-11/1/2 {

gigether-options {

802.3ad ae3;

}

} interfaces ge-11/1/3 {

gigether-options {

802.3ad ae2;

}

} interfaces ge-11/1/4 {

gigether-options {

802.3ad ae2;

}

} interfaces ge-11/1/5 {

gigether-options {

802.3ad ae2;

}

} interfaces ae2 {

unit 0 {

family bridge {

interface-mode trunk; vlan-id-list 100, 200–205;

} }

} interfaces ae3 {

encapsulation extended-vlan-bridge; vlan-tagging; unit 100 {

vlan-id 100; } unit 200 {

vlan-id 200; }

}

Chapter 2: Basic Layer 2 Features on MX Series Routers

Documentation

MX Series Ethernet Services Routers Solutions Page•

• Layer 2 Features for a Bridging Environment on page 21

• Example Roadmap: Configuring a Basic Bridge Domain Environment on page 22

• Example Step: Configuring Bridge Domains on page 30

• Example Step: Configuring Spanning Tree Protocols on page 32

• Example Step: Configuring Integrated Bridging and Routing on page 34

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

Example Step: Configuring Bridge Domains

To configure the bridge domains on all three routers:

Configure a bridge domain on Router 1:

[edit] bridge-domains {

vlan100 {

domain-type bridge;

vlan-id 100;

interface ge-2/2/1.100;

interface ae1.100; } vlan200 {

domain-type bridge;

vlan-id 200;

interface ge-2/2/1.200;

interface ge-2/2/6.200;

interface ae1.200; } vlan201 {

domain-type bridge;

vlan-id 201; } vlan202 {

domain-type bridge;

vlan-id 202; } vlan203 {

domain-type bridge;

vlan-id 203; } vlan204 {

domain-type bridge;

vlan-id 204; } vlan205 {

domain-type bridge;

vlan-id 205; }

}

Configure a bridge domain on Router 2:

[edit] bridge-domains {

vlan100 {

domain-type bridge;

vlan-id 100;

interface ge-2/2/2.100;

interface ae1.100;

interface ae3.100; } vlan200 {

domain-type bridge;

vlan-id 200;

interface ge-3/3/3.200;

interface ae1.200;

interface ae3.200; }

}

Configure a bridge domain on Router 3:

[edit] bridge-domains {

vlan100 {

domain-type bridge;

vlan-id 100;

interface ge-2/2/2.100;

interface ae3.100; } vlan200 {

domain-type bridge;

vlan-id 200;

interface ge-3/3/3.200;

interface ae3.200; } vlan201 {

domain-type bridge;

vlan-id 201; } vlan202 {

domain-type bridge;

vlan-id 202; } vlan203 {

domain-type bridge;

vlan-id 203; } vlan204 {

domain-type bridge;

vlan-id 204; } vlan205 {

domain-type bridge;

vlan-id 205; }

}

Chapter 2: Basic Layer 2 Features on MX Series Routers

Documentation

MX Series Ethernet Services Routers Solutions Page•

• Layer 2 Features for a Bridging Environment on page 21

• Example Roadmap: Configuring a Basic Bridge Domain Environment on page 22

• Example Step: Configuring Interfaces and VLAN Tags on page 24

• Example Step: Configuring Spanning Tree Protocols on page 32

• Example Step: Configuring Integrated Bridging and Routing on page 34

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

Example Step: Configuring Spanning Tree Protocols

Configure the Spanning Tree Protocol on all three routers. This is necessary to avoid the potential bridging loop formed by the triangular architecture of the routers. MSTP is configured on the three routers so the set of VLANs has an independent, loop-free topology. The Layer 2 traffic can be load-shared over 65 independent paths (64 Multiple Spanning Tree Instances [MSTIs] and one Common and Internal Spanning Tree [CIST]), each spanning a set ofVLANs. Theconfiguration names, revisionlevel, and VLAN-to-MSTI mapping mustmatch in order to utilize the load-sharing capabilities of MSTP (otherwise, each router will be in a different region).

To configure the Spanning Tree Protocol on all three routers:

Configure MSTP on Router 1:

[edit] protocols {

mstp {

configuration-name mstp-for-R1-2-3; # The names must match to be in the same

region revision-level 3; # The revision levels must match bridge-priority 0; # This bridge acts as root bridge for VLAN 100 and 200 interface ae1; interface ae2; msti 1 {

vlan100; # This VLAN corresponds to MSTP instance 1 } msti 2 {

vlan200; # This VLAN corresponds to MSTP instance 2 }

}

Configure MSTP on Router 2:

[edit] protocols {

mstp {

configuration-name mstp-for-R1-2-3; # The names must match to be in the same

region revision-level 3; # The revision levels must match interface ae1; interface ae3; msti 1 {

vlan100; # This VLAN corresponds to MSTP instance 1

bridge-priority 4096; # This bridge acts as VLAN 100 designated bridge on

} msti 2 {

vlan200; # This VLAN corresponds to MSTP instance 2 }

}

# the R2-R3 segment

Configure MSTP on Router 3:

[edit] protocols {

mstp {

configuration-name mstp-for-R1-2-3; # The names must match to be in the same

region revision-level 3; # The revision levels must match interface ae2; interface ae3; msti 1 {

vlan100; # This VLAN corresponds to MSTP instance 1 } msti 2 {

vlan200; # This VLAN corresponds to MSTP instance 2

bridge-priority 4096; # This bridge acts as VLAN 200 designated bridge on

}

Chapter 2: Basic Layer 2 Features on MX Series Routers

# the R2-R3 segment

As a result of this configuration, VLAN 100 and VLAN 200 share physical links, but have different designated ports, root ports, and alternate ports on the three different routers. The designated, root, and alternate ports for the two VLANs on the three routers are shown in Figure 6 on page 34.

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

Figure 6: Designated, Root, and Alternate Ports

Documentation

MX Series Ethernet Services Routers Solutions Page•

• Layer 2 Features for a Bridging Environment on page 21

• Example Roadmap: Configuring a Basic Bridge Domain Environment on page 22

• Example Step: Configuring Interfaces and VLAN Tags on page 24

• Example Step: Configuring Bridge Domains on page 30

• Example Step: Configuring Integrated Bridging and Routing on page 34

Example Step: Configuring Integrated Bridging and Routing

Router 2 and Router 3 on the bridging network act as a kind of gateway to the Layer 3 routers in the rest of the network. Router 2 and Router 3 must be able to route packets as well asbridge frames. Thisrequires the configuration of integrated routing andbridging (IRB) on Routers 2 and 3. The link to the router network is xe-2/1/0 on Router 2 and

xe-1/1/0 on Router 3.

You configure IRB in two steps:

1. Configure the IRB interface using the irb statement.

Chapter 2: Basic Layer 2 Features on MX Series Routers

2. Reference the IRB interface at the bridge domain level of the configuration.

IRB supports Layer 2 bridging and Layer 3 routing on the same interface. If the MAC address on the arriving frame is the same as that of the IRB interface, then the packet inside the frame is routed. Otherwise,the MAC address is learned or looked upin the MAC address database.

NOTE: You configure IRB on Router 2 and Router 3. The Virtual Router

Redundancy Protocol (VRRP) is configured on the IRB interface so that both links can be used to carry traffic between the bridge domain and the router network.

To configure IRB on Router 2 and Router 3:

Configure the router link and IRB on Router 2:

[edit] interfaces {

xe-2/1/0 {

unit 0 {

family inet {

address 10.0.10.2/24; # Routing interface

} }

} irb {

unit 0 {

family inet {

address 10.0.1.2/24 { vrrp-group 1 {

virtual-address 10.0.1.51;

priority 254;

}

} } unit 1 {

family inet {

address 10.0.2.2/24 { vrrp-group 2 {

virtual-address 10.0.2.51;

priority 100;

}

} }

} } bridge-domains {

vlan-100 {

domain-type bridge; vlan-id 100; interface ge-2/2/2.100;

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

interface ae1.100; interface ae3.100

routing-interface irb.0; } vlan-200 {

domain-type bridge;

vlan-id 200;

interface ge-3/3/3.200;

interface ae1.200;

interface ae3.200

routing-interface irb.1; }

}

Configure the router link and IRB on Router 3:

[edit] interfaces {

xe-1/1/0 {

unit 0 {

family inet {

address 10.0.20.3/24; # Routing interface

}

} } irb {

unit 0 {

family inet {

address 10.0.1.3/24 { vrrp-group 1 {

virtual-address 10.0.1.51;

priority 100;

}

} } unit 1 {

family inet {

address 10.0.2.3/24 { vrrp-group 2 {

virtual-address 10.0.2.51;

priority 254;

}

} } unit 2 {

family inet {

address 10.0.3.2/24 {

} } unit 3 {

family inet {

address 10.0.3.3/24 {

} }

unit 4 {

family inet {

address 10.0.3.4/24 {

} } unit 5 {

family inet {

address 10.0.3.5/24 {

} } unit 6 {

family inet {

address 10.0.3.6/24 {

} } unit 7 {

family inet {

address 10.0.3.7/24 {

} } unit 8 {

family inet {

address 10.0.3.8/24 {

} }

} } bridge-domains {

vlan-100 {

domain-type bridge; vlan-id 100; interface ge-2/2/2.100; interface ae2.100; interface ae3.100;

routing-interface irb.0; } vlan-200 {

domain-type bridge;

vlan-id 200;

interface ge-3/3/3.200;

interface ae2.200;

interface ae3.200;

routing-interface irb.1; } vlan201 {

vlan-id 201;

routing-interface irb.2 } vlan202 {

vlan-id 202;

routing-interface irb.3 } vlan203 {

vlan-id 203;

routing-interface irb.4 }

Chapter 2: Basic Layer 2 Features on MX Series Routers

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

vlan204 {

vlan-id 204;

routing-interface irb.5 } vlan205 {

vlan-id 205;

routing-interface irb.6 }

}

Documentation

• MX Series Ethernet Services Routers Solutions Page

• Layer 2 Features for a Bridging Environment on page 21

• Example Roadmap: Configuring a Basic Bridge Domain Environment on page 22

• Example Step: Configuring Interfaces and VLAN Tags on page 24

• Example Step: Configuring Bridge Domains on page 30

• Example Step: Configuring Spanning Tree Protocols on page 32

CHAPTER 3

Virtual Switches

•

Layer 2 Features for a Switching Environment on page 39

•

Configuring Virtual Switches as Separate Routing Instances on page 40

Layer 2 Features for a Switching Environment

Juniper Networks MX Series Ethernet Services Routers include all standard Ethernet capabilities as well as enhanced mechanisms for service providers to provision and support large numbers of Ethernet services in addition to all Layer 3 services. The MX Series routers include several features to contain and control the Ethernet environment.

One of these features is the virtual switch. MX Series routers allow the collapsing of multiple diverse switch networks to a single platform by running virtual instances of as many Spanning TreeProtocols (STPs) as needed to support all broadcast domains. This is important because there are many incompatible versions of STP, and without a way to run multiple virtual instances, a separate switch would be needed to support each one. With MX Series virtual switch configuration, you can continue to running existing STP protocols with the option to migrate to a common STP protocol if desired.

Documentation

Virtual switches also make it easy to separate independent switched Ethernet networks, each possibly carrying several VLANs.Because thesame VLAN ID can be used inmultiple switched networks, virtualswitches can keep eachVLAN and broadcast domainlogically separated.

NOTE: In a router environment, there is always a default routing instance.

When you need only one routing instance on the router, you use the default routing instance without qualification. However, if you need more than one routing instance, you must configure statements to create additional routing instances. In a switching environment, the same is true of virtual switches: if you need more than one virtual switch in addition to the “default,” you must create them.

For more information about STPs and virtual switches, see the Junos OS Layer 2 Configuration Guide.

MX Series Ethernet Services Routers Solutions Page•

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

• Configuring Virtual Switches as Separate Routing Instances on page 40

Configuring Virtual Switches as Separate Routing Instances

You can configure two virtual switches as separate routing instances on an MX Series router with bridge domains and VLANs.

Beforeyou begin, youshould have already configured abasicbridge domainenvironment. For a general description of a basic bridge domain environment, see “Layer 2 Features for a Bridging Environment” on page 21. For an example of a basic bridge domain configuration,see “Example Roadmap: Configuring a Basic Bridge Domain Environment” on page 22. More detailed examples are also provided for the four features generally required in a Layer 2 environment:

•

Interfaces and VLAN tags required.

•

Bridge domains required by the topology.

•

Spanning tree protocols required by the topology.

•

Integrated bridging and routing required by the topology.

At the end of this configuration, you create two virtual switches as separate routing instances to separate the VLANs and broadcast domains. Because the same VLAN ID can be used in multiple switched networks, virtual switches can keep each VLAN and broadcast domain logically separated.

To configure two virtual switches as separate routing instances:

The following statements configure the first virtual switch in a routing instance.

[edit] routing-instances {

virtual-switch-1 {

instance-type virtual-switch;

...virtual-switch-1 configuration with one STP/VLAN ID set... }

}

The following statement configure the second virtual switch in a different routing

instance.

[edit] routing-instances {

virtual-switch-2 {

instance-type virtual-switch;

...virtual-switch-2 configuration with another STP/VLAN ID set... }

}

This is not a complete configuration.

For more information about configuring virtual switches, see the Junos OS Layer 2 Configuration Guide.

Chapter 3: Virtual Switches

Documentation

• MX Series Ethernet Services Routers Solutions Page

• Layer 2 Features for a Switching Environment on page 39

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

CHAPTER 4

VLANs Within Bridge Domain and VPLS Environments

•

VLANs Within a Bridge Domain or VPLS Instance on page 43

•

Packet Flow Through a Bridged Network with Normalized VLANs on page 44

•

Configuring a Normalized VLAN for Translation or Tagging on page 45

•

Configuring Learning Domains for VLAN IDs Bound to Logical Interfaces on page 47

•

Example:Configuring aProvider Bridge Networkwith NormalizedVLAN Tags on page 47

•

Example: Configuring a Provider VPLS Network with Normalized VLAN Tags on page 51

•

Example: Configuring One VPLS Instance for Several VLANs on page 55

VLANs Within a Bridge Domain or VPLS Instance

A packet received on a physical port is only accepted for processing if the VLAN tags of the received packet match the VLAN tags associated with one of the logical interfaces configured on the physical port. The VLAN tags of the received packet are translated only if they are different than the normalized VLAN tags. For the translation case, the VLAN identifier tags specify the normalized VLAN. For this case, the terms “learn VLAN” and “normalized VLAN” can be used interchangeably.

Documentation

You can specify the normalized VLAN using one of the following conditions:

•

The VLAN identifier is determined explicitly by configuration

•

The VLAN identifier is specified as “none,” meaning the VLAN tags are not translated or generated

•

The inner and outer VLANidentifier tags are both determined explicitly by configuration

MX Series Ethernet Services Routers Solutions Page•

• Packet Flow Through a Bridged Network with Normalized VLANs on page 44

• Configuring a Normalized VLAN for Translation or Tagging on page 45

• Configuring Learning Domains for VLAN IDs Bound to Logical Interfaces on page 47

• Example: Configuring a Provider Bridge Network withNormalized VLANTags on page 47

• Example: Configuring aProvider VPLS Network with Normalized VLAN Tags on page 51

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

• Example: Configuring One VPLS Instance for Several VLANs on page 55

Packet Flow Through a Bridged Network with Normalized VLANs

Packets received over a Layer 2 logical interface for bridging are processed in a strict sequence of steps.

Packets received over a Layer 2 logical interface for bridging when a normalized VLAN is configured with a single or inner and outer VLAN identifier tags under the bridge domain or the VPLS routing instance are processed with the following steps:

1. A packet receivedon aphysical port is only acceptedfor furtherprocessing if the VLAN

tags of the received packet match the VLAN tags associated with one of the logical interfaces configured on that physical port.

2. The VLAN tags of the received packet are compared with the normalized VLAN tags.

If the VLAN tags of the received packet are different from the normalized VLAN, then the appropriate VLAN operations(such as push-push,pop-pop, pop-swap, swap-swap, swap, and others) are done implicitly to convert the received VLAN tags to the normalized VLAN tag value. For more information these operations, see the Junos Routing Protocols Configuration Guide.

Documentation

3. If the source MAC address of the received packet is not present in the source MAC

table, then it is learned based on the normalized VLAN tag value.

4. The packet is forwarded toward one or more egress Layer 2 logical interfaces based

on the destination MAC address. A packet with a known unicast destination MAC address is only forwarded to one egress logical interface. For each egress Layer 2 logical interface, the normalized VLAN tag within the packet is compared with the VLAN tags configured on that logical interface. If the VLAN tags associated with an egress logical interface do not match the normalized VLAN tag in the frame, then appropriate VLAN operations (such as push-push, pop-pop, pop-swap, swap-swap, swap, and others) are implicitly done to convert the normalized VLAN tags to the VLAN tags of the egress logical interface. For more information these operations, see the Junos Routing Protocols Configuration Guide.

MX Series Ethernet Services Routers Solutions Page•

• VLANs Within a Bridge Domain or VPLS Instance on page 43

• Configuring a Normalized VLAN for Translation or Tagging on page 45

• Configuring Learning Domains for VLAN IDs Bound to Logical Interfaces on page 47

• Example: Configuring a Provider Bridge Network withNormalized VLANTags on page 47

• Example: Configuring aProvider VPLS Network with Normalized VLAN Tags on page 51

• Example: Configuring One VPLS Instance for Several VLANs on page 55

Chapter 4: VLANs Within Bridge Domain and VPLS Environments

Configuring a Normalized VLAN for Translation or Tagging

This topic provides configuration and operational information to help you manipulate virtual local area networks (VLANs) within abridge domainor a virtual privateLAN service (VPLS) instance. TheVPLS configuration is not coveredin this topic. For more information about configuring Ethernet pseudowires as part of VPLS, see the Junos OS Feature Guide.

NOTE: This topic is not intended as a troubleshooting guide. However, you

can use it with a broader troubleshootingstrategyto identify Juniper Networks MX Series Ethernet Services Routers network problems.

The manipulation of VLANs within a bridge domain or a VPLS instance can be done in several ways:

•

By using the vlan-map statements at the [edit interfaces] hierarchy level. This chapter does not use vlan-map. For more information about VLAN maps, see the Junos OS Network Interfaces Configuration Guide.

•

By using vlan-id statements within a bridge domain or VPLS instance hierarchy. This method is used in the configuration in this chapter.

The vlan-id and vlan-tags statements under the bridge domain or VPLS routing instance are used to:

•

Translate (normalize) received VLAN tags, or

•

Implicitly create multiple learning domains, each with a “learn” VLAN.

The use of a VLAN map or a normalized VLAN is optional.

NOTE: You cannot use vlan-map when configuring a normalized VLAN.

This section discusses the following topics:

•

Implicit VLAN Translation to a Normalized VLAN on page 45

•

Sending Tagged or Untagged Packets over VPLS Virtual Interfaces on page 46

•

Configuring a Normalized VLAN on page 46

Implicit VLAN Translation to a Normalized VLAN

The VLAN tags of a received packet are compared with the normalized VLAN tags specified with either the vlan-id or vlan-tags statements. If the VLAN tags of the received packetare different fromthe normalizedVLAN tags, thenappropriateVLAN tagoperations (such as push-push, pop-pop, pop-swap, swap-swap, swap, and others) are implicitly made to convert the received VLAN tags to the normalized VLAN tags. For more information about these operations, see the Junos OS Routing Protocols Configuration Guide.

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

Then, the source MAC address of a received packet is learned based on the normalized VLAN configuration.

For output packets, if the VLAN tags associated with an egress logical interface do not matchthe normalizedVLAN tagswithin thepacket, then appropriateVLAN tagoperations (such as push-push, pop-pop, pop-swap, swap-swap, swap, and others) are implicitly made to convert the normalized VLAN tags to the VLAN tags for the egress logical interface. Formore information aboutthese operations, seethe JunosOS Routing Protocols Configuration Guide.

Sending Tagged or Untagged Packets over VPLS Virtual Interfaces

If the packets sent over the VPLS virtual interfaces (vt- or lsi- interfaces) need to be tagged by the normalized VLAN, use one of the following configuration statements:

•

vlan-id vlan-number—Tags all packets sent over the VPLS virtual interface with the

configuredvlan-number. For an exampleof thisconfiguration,see “Example: Configuring One VPLS Instance for Several VLANs” on page 55.

•

vlan-tags outer outer-vlan-number inner inner-vlan-number—Tags all packets sent over

the VPLS virtual interfaces with the specified inner and outer VLAN tags.

If theincoming VLANtags identifyinga Layer 2logical interfaceare removed when packets are sent over VPLS virtual interfaces, use the vlan-id none statement.

Configuring a Normalized VLAN

The following factors are important when configuring a normalized VLAN:

•

Use either the vlan-id vlan-number statement (to tag all packets with one normalized VLAN tag) or the vlan-tags outer outer-vlan-number inner inner-vlan-number statement (to tag all packets with the normalized outer and inner VLAN tags) if you want to tag packets sent onto the VPLS pseudowires.

•

Use the vlan-id none statement to remove the incoming VLAN tags identifying a Layer 2 logical interface when packets are sent over VPLS pseudowires. This statement is also used to configure shared VLAN learning.

•

If integrated routing and bridging (IRB) is configured for a bridge domain or a VPLS routing instance, then you must configure a normalized VLAN using one of thefollowing statements:

NOTE: Even when the vlan-id none statement is configured, the packets can

still contain other customer VLAN tags.

NOTE: The outgoing packets can still contain customer VLAN tags.

•

vlan-id vlan-number

•

vlan-id none

Chapter 4: VLANs Within Bridge Domain and VPLS Environments

•

vlan-tags outer outer-vlan-number inner inner-vlan-number

•

Use the vlan-id all statement to configure bridging for several VLANS with minimal amount of configuration and switch resources. For an example of this configuration, see “Example: Configuring One VPLS Instance for Several VLANs” on page 55.

Documentation

MX Series Ethernet Services Routers Solutions Page•

• VLANs Within a Bridge Domain or VPLS Instance on page 43

• Packet Flow Through a Bridged Network with Normalized VLANs on page 44

• Example: Configuring a Provider Bridge Network withNormalized VLANTags on page 47

• Example: Configuring aProvider VPLS Network with Normalized VLAN Tags on page 51

Configuring Learning Domains for VLAN IDs Bound to Logical Interfaces

A learning domain is a MAC address database to which the MAC addresses are added based on the normalized VLAN tags. Thenormalized VLANtags associated with a learning domain are always carried within packets sent over VPLS virtual interfaces.

To configure bridging for several VLANs using a minimal amount of configuration and switch resources, use the vlan-id all configuration statement to implicitly configure multiple learning domains for a bridge domain or VPLS instance:

•

For alogical interfacewith a single VLAN tag, thestatement implicitly creates a learning domain for each normalized VLAN of the interface.

•

For a logical interface with dual VLAN tags, the statement implicitly creates a learning domain for each inner VLAN (normalized VLAN).

Documentation

MX Series Ethernet Services Routers Solutions Page•

• VLANs Within a Bridge Domain or VPLS Instance on page 43

• Packet Flow Through a Bridged Network with Normalized VLANs on page 44

• Example: Configuring One VPLS Instance for Several VLANs on page 55

Example: Configuring a Provider Bridge Network with Normalized VLAN Tags

This topic provides a configuration example to help you effectively configure a network of Juniper Networks MX Series Ethernet Services Routers for a bridge domain or virtual privateLAN service(VPLS) environment. The emphasis hereis onchoosing the normalized virtual LAN (VLAN) configuration. The VPLS configuration is not covered in this chapter. For more information about configuring Ethernet pseudowires as part of VPLS, see the Junos OS Feature Guide.

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

NOTE: This topic does not present exhaustive configuration listings for all

routers in the figures. However, you can use it with a broader configuration strategy to complete the MX Series router network configurations.

Consider the provider bridge network shown in Figure 7 on page 48.

Figure 7: Provider Bridge Network Using Normalized VLAN Tags

The Layer 2 provider edge (PE) routers are MX Series routers. Each site is connected to two provider (P) routers for redundancy, although both links are only shown for L2-PE1 at Site 1. Site 1 is connected to P0 and P1 (as shown), Site 2 is connected to P0 and P2 (not shown), Site 3 is connected to P2 and P3 (as shown), and Site 4 is connected to P1 and P3 (as shown). VPLS pseudowires configured on the PE and P routers carry traffic between the sites.

Chapter 4: VLANs Within Bridge Domain and VPLS Environments

The VLANs’ bridging paths are shown with distinct dashed and dotted lines. The VLANs at each site are:

•

L2-PE1 at Site 1: VLAN 100 and VLAN 300

•

L2-PE2 at Site 2: VLAN 100

•

L2-PE3 at Site 3: VLAN 100

•

L2-PE4 at Site 4: VLAN 300

NOTE: The configurations in this chapter are only partial examples of

complete and functional router configurations. Do not copy these configurations and use them directly on an actual system.

The following is the configuration of interfaces, virtual switches, and bridge domains for MX Series router L2-PE1:

[edit] interfaces ge-1/0/0 {

encapsulation flexible-ethernet-services; flexible-vlan-tagging; unit 1 {

encapsulation vlan-bridge;

vlan-id 100; } unit 11 {

encapsulation vlan-bridge;

vlan-id 301; }

} interface ge-2/0/0 {

encapsulation flexible-ethernet-services; flexible-vlan-tagging; unit 1 {

encapsulation vlan-bridge;

vlan-id 100; }

} interface ge-3/0/0 {

encapsulation flexible-ethernet-services; flexible-vlan-tagging; unit 1 {

encapsulation vlan-bridge;

vlan-id 200; # NOTE: 200 is translated to normalized VLAN vlaue }

} interfaces ge-4/0/0 {

encapsulation flexible-ethernet-services; flexible-vlan-tagging; unit 1 {

encapsulation vlan-bridge;

vlan-tags outer 500 inner 100; # This places two VLAN tags on the provider

# pseudowire

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

}

} interfaces ge-5/0/0 {

encapsulation flexible-ethernet-services; flexible-vlan-tagging; unit 1 {

encapsulation vlan-bridge;

vlan-tags outer 500 inner 100; # This places two VLAN tags on the provider

} unit 11 {

encapsulation vlan-bridge;

vlan-tags outer 600 inner 300; # This places two VLAN tags on the provider

}

} interfaces ge-6/0/0 {

encapsulation flexible-ethernet-services; flexible-vlan-tagging; unit 11 {

encapsulation vlan-bridge;

vlan-id 300; }

} routing-instances {

customer-c1-virtual-switch {

instance-type virtual-switch ;

bridge-domains {

c1-vlan-100 {

domain-type bridge; vlan-id 100; # Customer VLAN 100 uses these five logical interfaces interface ge-1/0/0.1; interface ge-2/0/0.1; interface ge-3/0/0.1; interface ge-4/0/0.1; interface ge-5/0/0.1;

} # End of c1-vlan-100

} # End of bridge-domains } # End of customer-c1-virtual-switch customer-c2-virtual-switch {

instance-type virtual-switch ;

bridge-domains {

c2-vlan-300 {

domain-type bridge; vlan-id 300; # Customer VLAN 300 uses these three logical interfaces interface ge-1/0/0.11; interface ge-5/0/0.11; interface ge-6/0/0.11;

} # End of c1-vlan-300

} # End of bridge-domains } # End of customer-c2-virtual-switch

} # end of routing-instances

# pseudowire

Chapter 4: VLANs Within Bridge Domain and VPLS Environments

Bridge domain c1–vlan-100 for customer-c1–virtual-switch has five logical interfaces:

•

Logical interface ge-1/0/0.1 configured on physical port ge-1/0/0.

•

Logical interface ge-2/0/0.1 configured on physical port ge-2/0/0.

•

Logical interface ge-3/0/0.1 configured on physical port ge-3/0/0.

•

Logical interface ge-4/0/0.1 can exist on an extended port/subinterface defined by the pair ge-4/0/0 and outer-vlan-tag 500.

•

Logical interface ge-5/0/0.1 can exist on an extended port/subinterface defined by the pair ge-5/0/0 and outer-vlan-tag 500.

The association of the received packet to a logical interface is done by matching the VLAN tags of the received packet with the VLAN tags configured on one of the logical interfaces on that physical port. The vlan-id 100 configuration within the bridge domain

c1–vlan-100 sets the normalized VLAN value to 100.

The following happens as a result of this configuration:

•

Packets received on logical interfaces ge-1/0/0.1 or ge-2/0/0.1 with a single VLAN tag of 100 in the frame are accepted.

•

Packets received on logical interface ge-3/0/0.1 with a single VLAN tag of 200 in the frame are accepted and have their tag values translated to the normalized VLAN tag value of 100.

•

Packets received on logical interfaces ge-4/0/0.1 and ge-5/0/0.1 with outer tag values of 500 and inner tag values of 100 are accepted.

•

Unknown source MAC addresses and unknown destination MACaddresses are learned based on their normalized VLAN values of 100 or 300.

•

All packets sent on a logical interface always have their associated vlan-id value(s) in their VLAN tag fields.

Configuration and function of bridge domain c2-vlan-300 for customer-c2-virtual-switch is similar to, but not identical to, that of bridge domain c1-vlan-100 for

customer-c1-virtual-switch.

Documentation

MX Series Ethernet Services Routers Solutions Page•

• VLANs Within a Bridge Domain or VPLS Instance on page 43

• Packet Flow Through a Bridged Network with Normalized VLANs on page 44

• Configuring a Normalized VLAN for Translation or Tagging on page 45

Example: Configuring a Provider VPLS Network with Normalized VLAN Tags

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

For more information about configuring Ethernet pseudowires as part of VPLS, see the Junos OS Feature Guide.

NOTE: This topic does not present exhaustive configuration listings for all

routers in the figures. However, you can use it with a broader configuration strategy to complete the MX Series router network configurations.

Consider the VPLS network shown in Figure 8 on page 52.

Figure 8: VLAN Tags and VPLS Labels

The Layer 2 PE routers are MX Series routers. Each site is connected to two P routers for redundancy, although both links are only shown for L2-PE1 at Site 1. Site 1 is connected

Chapter 4: VLANs Within Bridge Domain and VPLS Environments

to P0 and P1, Site 2 is connected to P0 and P2 (not shown), Site 3 is connected to P2 and P3, and Site 4 is connected to P1 and P3. VPLS pseudowires configured on the PE and P routers carry traffic between the sites.

The pseudowires for the VPLS instances are shown with distinct dashed and dotted lines. The VLANs at each site are:

•

L2-PE1 at Site 1: VLAN 100 and VLAN 300

•

L2-PE2 at Site 2: VLAN 100

•

L2-PE3 at Site 3: VLAN 100

•

L2-PE4 at Site 4: VLAN 300

Service provider SP-1 is providing VPLS services for customer C1 and C2. L2-PE1 is configured with a VPLS instance called customer-c1-vsi. The VPLS instance sets up pseudowires to remote Site 2 and Site 3. L2-PE1 is also configured with a VPLS instance called customer-c2-vsi. The VPLS instance sets up a pseudowire to remote Site 4.

The following is the configuration of interfaces, virtual switches, and bridge domains for MX Series router L2-PE1:

[edit] interfaces ge-1/0/0 {

encapsulation flexible-ethernet-services; flexible-vlan-tagging; unit 1 {

encapsulation vlan-vpls;

vlan-id 100; } unit 11 {

encapsulation vlan-vpls;

vlan-id 301; }

} interfaces ge-2/0/0 {

encapsulation flexible-ethernet-services; flexible-vlan-tagging; unit 1 {

encapsulation vlan-vpls;

vlan-id 100; }

} interfaces ge-3/0/0 {

encapsulation flexible-ethernet-services; flexible-vlan-tagging; unit 1 {

encapsulation vlan-vpls;

vlan-id 200; # Should be translated to normalized VLAN value }

} interfaces ge-6/0/0 {

encapsulation flexible-ethernet-services; flexible-vlan-tagging; unit 11 {

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

encapsulation vlan-vpls;

vlan-id 302; }

} routing-instances {

customer-c1-vsi {

instance-type vpls;

vlan-id 100;

interface ge-1/0/0.1;

interface ge-2/0/0.1;

interface ge-3/0/0.1; } # End of customer-c1-vsi customer-c2-vsi {

instance-type vpls;

vlan-id none; # This will removethe VLAN tags from packetssent on VPLS for customer

2 interface ge-1/0/0.11; interface ge-6/0/0.11;

} # End of customer-c2-vsi

} # End of routing-instances

NOTE: This is not a complete router configuration.

Consider the first VLAN for customer C1. The vlan-id 100 statement in the VPLS instance called customer-c1-vsi sets the normalized VLAN to 100. All packets sent over the pseudowires have a VLAN tag of 100.

The following happens on VLAN 100 as a result of this configuration:

•

Packets received on logical interfaces ge-1/0/0.1 or ge-2/0/0.1 with a single VLAN tag of 100 in the frame are accepted.

•

Packets received on logical interface ge-3/0/0.1 with a single VLAN tag of 200 in the frame are accepted and have their tag values translated to the normalized VLAN tag value of 100.

•

Unknown source MAC addresses and unknown destination MACaddresses are learned based on their normalized VLAN values of 100.

•

All packets sent on the VPLS pseudowire have vlan-id 100 in their VLAN tag fields.

Now consider the second VLANfor Customer C2.The vlan-idnone statement inthe VPLS instance called customer-c2-vsi removes the incoming VLAN tags before the packets are sent over the VPLS pseudowires.

Chapter 4: VLANs Within Bridge Domain and VPLS Environments

The following happens on the C2 VLAN as a result of the vlan-id none configuration:

•

A MAC table is created for each instance of vlan-id none. All MAC addresses learned over the interfaces belonging tothis VPLSinstance are addedto thistable. The received or configured VLAN tags are not considered when the MAC addresses are added to this table. This is a case of shared VLAN learning.

•

Packets with a single VLAN tag value of 301 are accepted on interface ge-1/0/0.11. The VLAN tag value 301 is then popped and removed from the frame of this packet.

•

Packets with a single VLAN tag value of 302 are accepted on interface ge-6/0/0.11. The VLAN tag value 302 is then popped and removed from the frame of this packet.

•

All packets sent on pseudowires will not have any VLAN tags used to identify the incoming Layer 2 logical interface.

NOTE: The packet can still contain other customer VLAN tags.

•

Packets received from pseudowires are looked up in the MAC table associated with the VPLS instance. Any customer VLAN tags in the frame are ignored.

Documentation

MX Series Ethernet Services Routers Solutions Page•

• VLANs Within a Bridge Domain or VPLS Instance on page 43

• Packet Flow Through a Bridged Network with Normalized VLANs on page 44

• Configuring a Normalized VLAN for Translation or Tagging on page 45

Example: Configuring One VPLS Instance for Several VLANs

NOTE: This topic does not present exhaustive configuration listings for all

routers in the figures. However, you can use it with a broader configuration strategy to complete the MX Series router network configurations.

Consider the VPLS network shown in Figure 9 on page 56.

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

Figure 9: Many VLANs on One VPLS Instance

The Layer 2 PE routers are MX Series routers. Each site is connected to two P routers for redundancy, although both links are only shown for L2-PE1 at Site 1. Site 1 is connected to P0 and P1, Site 2 is connected to P0 and P2 (not shown), Site 3 is connected to P2 and P3, and Site 4 is connected to P1 and P3. VPLS pseudowires configured on the PE and P routers carry traffic between the sites.

The pseudowires for the VPLS instances are shown with distinct dashed and dotted lines. Most sites have multiple VLANs configured.

Service provider SP-1 is providing VPLS services forcustomer C1, services thatcould span several sites. Now customer C1 can have many VLANs in the range from 1 through 1000 (for example).

Chapter 4: VLANs Within Bridge Domain and VPLS Environments

If VLANs 1 through 1000 for customer C1 span the same sites, then the vlan-id all and

vlan-range statements provide a way to switch all of these VLANs with a minimum

configuration effort and fewer switch resources.

NOTE: You cannot use the vlan-id all statement if you configure an IRB

interface on one or more of the VLANs.

The following example illustrates the use of the vlan-id all statement:

[edit] interfaces ge-1/0/0 {

flexible-ethernet-services; flexible-vlan-tagging; unit 1 {

encapsulation vlan-vpls; vlan-id-range 1-1000;

} unit 11 {

encapsulation vlan-vpls; vlan-id 1500;

} } interfaces ge-2/0/0 {

flexible-ethernet-services;

flexible-vlan-tagging;

unit 1 {

encapsulation vlan-vpls; vlan-id-range 1-1000; # Note the use of the VLAN id range statement.

} } interfaces ge-3/0/0 {

flexible-ethernet-services;

flexible-vlan-tagging;

unit 1 {

encapsulation vlan-vpls; vlan-id 1-1000;

} } interfaces ge-6/0/0 {

flexible-ethernet-services;

flexible-vlan-tagging;

unit 11 {

encapsulation vlan-vpls; vlan-id 1500;

} } routing-instances {

customer-c1-v1-to-v1000 {

instance-type vpls; vlan-id all; # Note the use of the VLAN id all statement interface ge-1/0/0.1; interface ge-2/0/0.1; interface ge-3/0/0.1;

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

} # End of customer-c1-v1-to-v1000

customer-c1-v1500 {

instance-type vpls; vlan-id 1500; interface ge-1/0/0.11; interface ge-6/0/0.11;

} # End of customer-c1-v1500 } # End of routing-instances

Note the use of the vlan-id all and vlan-id-range statements in the VPLS instance called

customer-c1-v1-to-v1000. The vlan-id all statement implicitly creates multiple learning

domains, each with its own normalized VLAN.

The following happens as a result of the vlan-id all configuration:

•

Packets received on logical interfaces ge-1/0/0.1 , or ge-2/0/0.1, or ge-3/0/0.1, with a single VLAN tag in the range from 1 through 1000 in the frame are accepted.

•

Unknown source MAC addresses and unknown destination MACaddresses are learned based on their normalized VLAN values of 1 through 1000.

•

All packets sent on the VPLS pseudowire have a normalized VLAN tag after the source MAC address field in the encapsulated Ethernet packet.

Documentation

•

Although there are only three logical interfaces in the VPLS instance called

customer-c1-v1-to-v1000, the same MAC address (for example, M1) can be learned on

different logical interfaces for different VLANs. For example, MAC address M1 could be learned on logical interface ge-1/0/0.1 for VLAN 500 and also on logical interface

ge-2/0/0.1 for VLAN 600.

• MX Series Ethernet Services Routers Solutions Page

• VLANs Within a Bridge Domain or VPLS Instance on page 43

• Packet Flow Through a Bridged Network with Normalized VLANs on page 44

• Configuring Learning Domains for VLAN IDs Bound to Logical Interfaces on page 47

CHAPTER 5

Bulk Administration of Layer 2 Features on MX Series Routers

•

Bulk Configuration of VLANs and Bridge Domains on page 59

•

Example: Configuring VLAN Translation with a VLAN ID List on page 59

•

Example: Configuring Multiple Bridge Domains with a VLAN ID List on page 60

Bulk Configuration of VLANs and Bridge Domains

In some cases, service providers must deal with thousands of bridge domains on a single switch. By default the router does not create more than one bridge domain. The configuration of even several hundred bridge domains one at a time can be a burden.

However, you can configure multiple bridge domains with only one statement. Each bridge domainwill havethe form prefix-vlan-number. Theprefix and number are supplied by the configuration statement.

Documentation

MX Series Ethernet Services Routers Solutions Page•

• Example: Configuring VLAN Translation with a VLAN ID List on page 59

• Example: Configuring Multiple Bridge Domains with a VLAN ID List on page 60

Example: Configuring VLAN Translation with a VLAN ID List

In manycases, the VLAN identifierson the frames of an interface’s packets are not exactly correct. VLAN translation, or VLAN rewrite, allows you to configure bidirectional VLAN identifier translation with a list on frames arriving on and leaving from a logical interface. This lets you use unique VLAN identifiers internally and maintain legacy VLAN identifiers on logical interfaces.

To perform VLAN translation on the packets on a trunk interface, insert the vlan-rewrite statement at the [edit interfaces interface-name unit unit-number] hierarchy level. You must alsoinclude thefamilybridge statement atthe samelevel because VLAN translation is only supported on trunk interfaces. The reverse translation takes place on egress. In other words, ifVLAN 200 is translated to 500 oningress, VLAN500 is translatedto VLAN 200 on egress.

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

The following example translates incoming trunk packets from VLAN identifier 200 to 500 and 201 to 501 (other valid VLAN identifiers are not affected):

[edit interfaces ge-1/0/1] unit 0 {

... # Other logical interface statements

family bridge {

interface-mode trunk # Translation is only for trunks vlan-id-list [ 100 500–600 ]; vlan-rewrite {

translate 200 500; translate 201 501;

} ... # Other bridge statements }

}

NOTE: This example also translates frame VLANs from 500 to 200 and 501 to 201 on egress.

Documentation

MX Series Ethernet Services Routers Solutions Page•

• Bulk Configuration of VLANs and Bridge Domains on page 59

• Example: Configuring Multiple Bridge Domains with a VLAN ID List on page 60

Example: Configuring Multiple Bridge Domains with a VLAN ID List

To configure multiple bridge domains with one statement, include the vlan-id-list statement at the [edit bridge-domains] hierarchy level.

The following example automaticallyconfigures4093 bridgedomains namedsales-vlan-2 through sales-vlan-4094:

[edit] bridge-domains {

sales { # This is the prefix

vlan-id-list [ 2–4096 ]; # These are the numbers }

}

You can configure these bridge domains in a virtual switch routing instance. However, if a VLANidentifier isalready part of a VLAN identifier list in a bridge domainunder arouting instance, then you cannot configure an explicit bridge domain with that VLAN identifier. In other words. there can be no overlap between a VLAN identifier list and another VLAN identifier configuration.

The following example removes the VLAN identifier 5 from the original VLAN list (vlan-id-list [ 1–10 ]) and configures the bridge domain explicitly:

[edit routing-instance rtg-inst-10] instance-type virtual-switch; interface ge-7/3/0.0;

Chapter 5: Bulk Administration of Layer 2 Features on MX Series Routers

bridge-domains {

bd-vlan–5 {

vlan-id 5; } bd {

vlan-id [ 1–4 6–10 ]; }

}

If a VLAN identifier is already part of a VLAN identifier list in a bridge domain under a routing instance, then you must delete the VLAN identifier from the list before you can configure an explicit or “regular” bridge domain. Also, the explicit bridge domain will not perform properly unless ithas thesame name as the bridge domain in the VLAN identifier list.

In other words, if sales-vlan-100 was part of a bridge domain VLAN list and you wish to configure it explicitly, you must use the same naming convention:

[edit] bridge-domains {

sales-vlan-100 { # You must use this name explicitly

vlan-id 100; }

}

Documentation

The following limitations apply to automatic bridge domain configuration:

•

Only one vlan-id-list statement is allowed in a routing instance.

•

Bridge options are not supported with the vlan-id-list statement.

•

Only trunk interfaces are supported.

•

There is no support for integrated routing and bridging (IRB).

You display the status and other parameters for automatic bridge domains configured with the vlan-id-list statement using the same show l2-learning instance command as used for individually configured bridge domains.

• MX Series Ethernet Services Routers Solutions Page

• Bulk Configuration of VLANs and Bridge Domains on page 59

• Example: Configuring VLAN Translation with a VLAN ID List on page 59

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

CHAPTER 6

Dynamic Profiles for VLAN Interfaces and Protocols

•

Dynamic Profiles for VPLS Pseudowires on page 63

•

Example: Configuring VPLS Pseudowires with Dynamic Profiles—Basic Solutions on page 64

•

Example: Configuring VPLS Pseudowires with Dynamic Profiles—Complex Solutions on page 68

Dynamic Profiles for VPLS Pseudowires

A router often has two types of interfaces:

•

Static interfaces, which are configured before the router is booted

•

Dynamic interfaces, which are created after the router is booted and while it is running

A VPLSpseudowire interface (such as lsi.1048576) is dynamically created by the system. Therefore, the logical interface unit number for the VPLS pseudowire is not available for in advance to configure characteristics such as VLAN identifiers and other parameters. As aresult, certain VLANmanipulation features that are easily appliedto static interfaces (such asxe-, ge-,and so on)are either not supported on dynamic interfaces or supported in an awkward fashion.

Documentation

However, on MX Series routers, there is another configuration method that dynamic interfaces can use to determine their VLAN parameters when they are created by a running router: dynamicprofiles. A dynamic profile is a conceptual container thatincludes parameters associated with a dynamic entity, parameters whose values are not know at the time the entity is configured. For more information about dynamic profiles, see the Junos OS Subscriber Access Configuration Guide.

There are many types of dynamic profiles. The two dynamic profiles that are used in conjunction with VLANs and VPLS are $junos-interface-ifd-name for a dynamic physical interface and $junos-underlying-unit-number for a dynamic logical interface (unit).

Dynamic profiles for VPLS are only supported on MX Series routers.

MX Series Ethernet Services Routers Solutions Page•

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

• Example: Configuring VPLS Pseudowires with Dynamic Profiles—Basic Solutions on

page 64

• Example: Configuring VPLS Pseudowires with Dynamic Profiles—Complex Solutions

on page 68

Example: Configuring VPLS Pseudowires with Dynamic Profiles—Basic Solutions

The following limitations apply to dynamic profiles for VPLS on MX Series routers:

•

The native-vlan-id statement is not supported.

•

The native-inner-vlan-id statement is not supported.

•

The interface-mode access statement option is not supported.

•

The vlan-id-range statement is not supported.

In many cases, a configuration using dynamic profiles is more efficient than a static configuration, as shown by the examples in this topic.

•

VPLS Pseudowire Interfaces Without Dynamic Profiles on page 64

•

VPLS Pseudowire Interfaces and Dynamic Profiles on page 65

•

CE Routers Without Dynamic Profiles on page 66

•

CE Routers and Dynamic Profiles on page 67

VPLS Pseudowire Interfaces Without Dynamic Profiles

Consider the following configuration, which does not use dynamic profiles to manipulate VLAN identifiers:

[edit routing-instances] green {

instance-type vpls; interface ge-0/0/1.1; interface ge-0/0/2.1; interface ge-0/0/3.1; vlan-tags outer 200 inner 100; protocols vpls {

vpls-id 10;

neighbor 10.1.1.20; } {...more...}

}

[edit interfaces] ge-0/0/1 {

unit 0 {

vlan-id 10; }

} ge-0/0/2 {

unit 0 {

Chapter 6: Dynamic Profiles for VLAN Interfaces and Protocols

vlan-id 20; }

} ge-0/0/3 {

unit 0 {

vlan-id 30; }

}

NOTE: This is not a complete router configuration.

With this configuration, broadcast packets inside frames arriving with VLAN identifier 10 on ge-0/0/1 are normalized to a dual-tagged frame with an outer VLAN value of 200 and an inner VLAN value of 100. The broadcast packet and frames egressing ge-0/0/2 or ge-0/0/3 have the outer VLAN value stripped and the inner VLAN value swapped to 20 and 30 respectively, according to the interface configuration. However, this stripping of theouter VLAN tag and the swapping is extra work, becausethe frames will still egress the VPLS pseudowire in routing instance green with an outer VLAN tag value of 200 and an inner VLAN tag value of 100, also according to the configuration.

The same configuration can be accomplished more effectively using dynamic profiles.

VPLS Pseudowire Interfaces and Dynamic Profiles

Consider the following configuration, which uses dynamic profiles to manipulate VLAN identifiers:

[edit routing-instances] green {

instance-type vpls; interface ge-0/0/1.1; interface ge-0/0/2.1; interface ge-0/0/3.1; vlan-id 100; # Desired inner VLAN tag on the VPLS pseudowire protocols vpls {

vpls-id 10;

neighbor 10.1.1.20 {

associate-profile green_vpls_pw_1; # The profile

} } {...more...}

}

[edit interfaces] ge-0/0/1 {

unit 0 {

vlan-id 10; }

} ge-0/0/2 {

unit 0 {

vlan-id 20; }

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

} ge-0/0/3 {

unit 0 {

vlan-id 30; }

}

[edit dynamic-profiles] green_vpls_pw_1 interfaces $junos-interface-ifd-name {

unit $junos-underlying-unit-number {

vlan-tags outer 200 inner 100; }

}

NOTE: This is not a complete router configuration.

With this configuration, broadcast packets inside frames arriving with VLAN identifier 10 on ge-0/0/1 are normalized to a frame with VLAN identifier 100. The broadcast packet and frames egressing ge-0/0/2 or ge-0/0/3 have this VLAN value swapped to 20 and 30 respectively, according to the interface configuration. Frames egress the VPLS pseudowire in routing instance green with an outer VLAN tag value of 200pushed on top of the normalized value.

CE Routers Without Dynamic Profiles

You can apply a dynamic profile to an entire VPLS configuration, not just a neighbor.

Consider the following configuration, which does not use dynamic profiles to manipulate VLAN identifiers on a customer edge (CE) router with VLAN identifier 100:

[edit routing-instances] green {

instance-type vpls; interface ge-0/0/1.1; interface ge-0/0/2.1; interface ge-0/0/3.1; vlan-tags outer 200 inner 100; protocols vpls {

vpls-id 10;

neighbor 10.1.1.20; } {...more...}

}

[edit interfaces] ge-0/0/1 {

unit 0 {

vlan-id 100; }

} ge-0/0/2 {

unit 0 {

vlan-id 100;

}

} ge-0/0/3 {

unit 0 {

vlan-id 100; }

}

NOTE: This is not a complete router configuration.

With this configuration, broadcast packets inside frames arriving on ge-0/0/1 are normalized to a dual-tagged frame with an outer VLAN value of 200 and an inner VLAN value of 100. The same configuration can be accomplished using dynamic profiles.

CE Routers and Dynamic Profiles

Consider the following configuration, which uses dynamic profiles at the protocols level:

[edit routing-instances] green {

instance-type vpls; interface ge-0/0/1.1; interface ge-0/0/2.1; interface ge-0/0/3.1; vlan-id 100; # Desired inner VLAN tag on the VPLS pseudowire protocols vpls {

associate-profile green_vpls_pw_2; # The profile

vpls-id 10;

neighbor 10.1.1.20; } {...more...}

}

Chapter 6: Dynamic Profiles for VLAN Interfaces and Protocols

[edit interfaces] ge-0/0/1 {

unit 0 {

vlan-id 100; }

} ge-0/0/2 {

unit 0 {

vlan-id 100; }

} ge-0/0/3 {

unit 0 {

vlan-id 100; }

}

[edit dynamic-profiles] green_vpls_pw_2 interfaces $junos-interface-ifd-name {

unit $junos-underlying-unit-number {

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

vlan-tags outer 200 inner 100; }

}

NOTE: This is not a complete router configuration.

With this configuration, broadcast packets inside frames arriving with VLAN identifier 100 on ge-0/0/1 are normalized to a frame with VLAN identifier 100 (in this case, they are unchanged). The broadcast packet and frames egressing ge-0/0/2 or ge-0/0/3 are unchanged as well, according to the interface configuration. Frames egress the VPLS pseudowire in routing instance green with an outer VLAN tag value of 200pushed on top of the normalized value.

Documentation

MX Series Ethernet Services Routers Solutions Page•

• Dynamic Profiles for VPLS Pseudowires on page 63

• Example: Configuring VPLS Pseudowires with Dynamic Profiles—Complex Solutions

on page 68

Example: Configuring VPLS Pseudowires with Dynamic Profiles—Complex Solutions

Dynamic profiles for VPLS pseudowires can be helpfulin a variety ofVLAN configurations. This section explores some of these situations through examples.

NOTE: These examples are not complete router configurations.

All of the examples in this section address the same basic topology. A routing instance

blue uses a trunk bridge to connect different departments in an organization, each with

their own VLANs, at two different sites. The organization uses a BGP-based VPLS with a virtual switch to accomplish this.

•

Configurationof RoutingInstance andInterfacesWithout Dynamic Profiles onpage 68

•

Configuration of Routing Instance and Interfaces Using Dynamic Profiles on page 69

•

Configuration of Tag Translation Using Dynamic Profiles on page 72

Configuration of Routing Instance and Interfaces Without Dynamic Profiles

The basic configuration of routing instance and interfaces without dynamic profiles follows:

[edit routing-instance blue] instance-type virtual-switch; route-distinguisher 10.1.1.10:1; vrf-target target:1000:1; interface ge-3/0/0; # The trunk interface bridge-domains {

sales {

vlan-id 10;

Chapter 6: Dynamic Profiles for VLAN Interfaces and Protocols

interface ge-0/0/0.1;

... # Other interfaces and statements for Sales } engineering {

vlan-id 20;

interface ge-1/0/2.0;

... # Other interfaces and statements for Engineering } accounting {

vlan-id 30;

interface ge-2/0/3.0;

... # Other interfaces and statements for Accounting } others {

vlan-id—list [ 40 50 ]; # Other departements }

}

protocols vpls {

site-range 10;

site sample-site-1 {

site-identifier 1;

} }

... # Other statements for instance Blue

[edit interfaces] ge-0/0/1 {

unit 0 {

vlan-id 100; }

} ge-3/0/0 {

unit 0 {

family bridge {

interface-mode trunk; # This is the trunk vlan-id-list [ 10 20 30 40 50 ];

} }

} ... # More interface statements

This configuration switches the departmental VLAN traffic (sales, engineering, etc.) bridge domains over the VPLS pseudowire trunk connecting to the other site.

Configuration of Routing Instance and Interfaces Using Dynamic Profiles

Here is how dynamic profiles can be applied to this basic configuration.

First, consider the requirement to push an outer VLAN tag value of 200 onto the VPLS pseudowire frames on egress. Dynamic profiles easily satisfy this requirement.

[edit routing-instance green] instance-type virtual-switch; ... # Other routing instance statements protocols vpls {

site-range 10;

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

site sample-site-1 {

site-identifier 1; } associate-profile green_vpls_pw_1; # Apply profile here

} ... # Other routing instance statements

[edit dynamic-profiles] green_vpls_pw_1 interfaces $junos-interface-ifd-name {

unit $junos-underlying-unit-number {

vlan-id 200; # This is the outer tag

family bridge {

interface-mode trunk; inner-vlan-id-list [ 10 20 30 40 50 ];

} }

}

NOTE: This is not a complete router configuration.

With the dynamic profile, a packet in a frame arriving on an interface is classified as belonging to one of the bridge domains (VLANs 10–50). At the egress of the trunk VPLS pseudowire, the outer VLAN tag 200 is pushed onto the frame. At the ingress of the psuedowire at the remote location, the outer VLAN tag 200 is removed and the frame is delivered to the appropriate bridge domain.

But what if the packets associated with the Accounting VLAN are not to be forwarding to the remote site? Dynamic profiles are useful here as well.

This configuration keeps the Accounting frames from reaching the remote site.

[edit routing-instances green] instance-type virtual-switch; ... # Other routing instance statements protocols vpls {

site-range 10; site sample-site-1 {

site-identifier 1; } associate-profile green_vpls_pw_2; # Apply profile here

} ... # Other routing instance statements

[edit dynamic-profiles] green_vpls_pw_2 interfaces $junos-interface-ifd-name {

unit $junos-underlying-unit-number {

family bridge {

interface-mode trunk; inner-vlan-id-list [ 10 20 40 50 ]; # Removed Accounting VLAN 30

} }

}

Chapter 6: Dynamic Profiles for VLAN Interfaces and Protocols

NOTE: This is not a complete router configuration.

In this case, frames arriving on the interfaces are classified according to their bridge domains andswitched, if necessary, to the VPLS pseudowire trunk, exceptfor Engineering frames. Engineering frames (VLAN 30) are only switched within the interfaces listed within bridge domain accounting and any statically configured trunk interfaces and are prevented from crossing the VPLS pseudowire due to the absence of VLAN 30 on the trunk.

We can combine the two examples and use dynamic profiles to forward the frames (other than accounting frames) to the remote site with an out tag of 200.

This configuration keeps the Accounting frames fromreaching theremote site and pushes an outer tag of 200 on VPLS pseudowire traffic.

[edit routing-instances green] instance-type virtual-switch; ... # Other routing instance statements protocols vpls {

site-range 10; site sample-site-1 {

site-identifier 1; } associate-profile green_vpls_pw_3; # Apply profile here

} ... # Other routing instance statements

[edit dynamic-profiles] green_vpls_pw_3 interfaces $junos-interface-ifd-name {

unit $junos-underlying-unit-number {

vlan-id 200; # This is the outer tag

family bridge {

interface-mode trunk; inner-vlan-id-list [ 10 20 40 50 ]; # Removed Accounting VLAN 30

} }

}

NOTE: This is not a complete router configuration.

In this case, frames arriving on the interfaces are classified according to their bridge domains and switched, if necessary, to the VPLS pseudowire trunk with an outer VLAN tag of 200, except for Engineering frames. Engineering frames (VLAN 30) are only switched within the interfaces listed within bridge domain accounting and any statically configured trunk interfaces and are prevented from crossing the VPLS pseudowire due to the absence of VLAN 30 on the trunk.

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

Configuration of Tag Translation Using Dynamic Profiles

Consider a final case where the bridge domain VLANs need translation at the VPLS pseudowire trunk interface. In this case, sales (VLAN 10) is mapped to VLAN 110 and

engineering (VLAN 20) is mapped to VLAN 120.

This configuration adds tag translation to the VPLS pseudowire traffic.

[edit routing-instances green] instance-type virtual-switch; ... # Other routing instance statements protocols vpls {

site-range 10; site sample-site-1 {

site-identifier 1; } associate-profile green_vpls_pw_4; # Apply profile here

} ... # Other routing instance statements

Documentation

[edit dynamic-profiles] green_vpls_pw_4 interfaces $junos-interface-ifd-name {

unit $junos-underlying-unit-number {

family bridge {

interface-mode trunk; vlan-id-list [ 10 20 30 40 50 ]; # All VLANs vlan-rewrite translate 110 10; # Sales VLAN vlan-rewrite translate 120 20; # Engineering VLAN

} }

}

NOTE: This is not a complete router configuration.

This translates the sales and engineering VLAN tags egressing the VPLS pseudowire accordingly. At the ingress of the VPLS pseudowire, VLANs 110 and 120 are translated back to 10 and 20, respectively.

• MX Series Ethernet Services Routers Solutions Page

• Dynamic Profiles for VPLS Pseudowires on page 63

• Example: Configuring VPLS Pseudowires with Dynamic Profiles—Basic Solutions on

page 64

CHAPTER 7

MX Series Router as a DHCP Relay Agent

•

MX Series Router as a Layer 2 DHCP Relay Agent on page 73

•

Example: Configuring DHCP Relay in a Bridge Domain VLAN Environment on page 74

•

Example: Configuring DHCP Relay ina VPLS Routing Instance Environmenton page 75

MX Series Router as a Layer 2 DHCP Relay Agent

The Dynamic Host Configuration Protocol (DHCP) is used by a DHCP client (host) to determine Layer 3 information (such as an IP address) from a DHCP server. DHCP uses the client’s MAC (Layer 2) address to query the server. A router can be used as a DHCP relay agent to pass the query on to a server while the router appears to reply to the client. You can configure a Juniper Networks MX Series Ethernet Services Router to act as a DHCP relay agent. The MX Series router configuration at Layer 2 accesses the Layer 3 information with DHCP snooping.

DHCP servers and relay agents have a level of trust in the MAC addresses used in DHCP client queries. A hacker can spoof invalid MAC addresses and overwhelm the server or relay agent with flooded traffic. Or the hacker can try to determine other information, such as the IP address range used by devices on the network. The DHCP process should only trust MAC addresses that are valid for a particular network.

You can configure the MX Series router to use MAC addresses obtained by the Layer 2 address learning process to control the flooding of DHCP packets.

Several restrictions apply to DHCP configuration on the MX Series routers:

•

All statements referring to “option 82” (including circuit information in DHCP relay messages) are not supported on the MX Series routers.

•

This feature works for static IP/MAC bindings on the MX Series routers.

•

The DHCP snooping database table is not restored after a Routing Engine reboot.

•

The DHCP Discovermessage is not flooded tothe DHCPserver whenbroadband service aggregator (BSA) and broadband service router (BSR) are provisioned on the same switch.

For more information on configuring DHCP, see the Junos OS Subscriber Access Configuration Guide.

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

Documentation

MX Series Ethernet Services Routers Solutions Page•

• Example: Configuring DHCP Relay in a Bridge Domain VLAN Environment on page 74

• Example: Configuring DHCP Relay in a VPLS Routing Instance Environment on page 75

Example: Configuring DHCP Relay in a Bridge Domain VLAN Environment

The following example configures DHCP relay in a VPLS environment to trust only the MAC addresses learned on the listed interfaces.

NOTE: This is not a complete router configuration.

[edit] routing-instances {

classic-vpls {

instance-type vpls;

interface ge-1/1/1.0;

interface ge-1/1/2.0;

interface ge-1/1/3.0;

interface ge-1/1/4.0;

interface ge-1/1/5.0;

vlan-id 20;

forwarding-options {

dhcp-relay { # Here is where DHCP is configured.

group vlan-20–bridge {

interface ge-1/1/1.0; interface ge-1/1/2.0; interface ge-1/1/3.0; interface ge-1/1/4.0; interface ge-1/1/5.0;

}

} } protocol vpls { site-id 567; # Other VPLS configuration statements... }

}

Documentation

Only MAC addresses learned on the five listed Gigabit Ethernet interfaces will be trusted for DHCP relay purposes.

For more information on configuring DHCP, see the Junos OS Subscriber Access Configuration Guide.

MX Series Ethernet Services Routers Solutions Page•

• MX Series Router as a Layer 2 DHCP Relay Agent on page 73

• Example: Configuring DHCP Relay in a VPLS Routing Instance Environment on page 75

Chapter 7: MX Series Router as a DHCP Relay Agent

Example: Configuring DHCP Relay in a VPLS Routing Instance Environment

The following example configures DHCP relay in a bridge domain (VLAN) environment. The MX Series router will trust only the MAC addresses learned on the listed interfaces.

NOTE: This is not a complete router configuration.

The router has three interfaces: two interfaces (ge-2/2/4 and ge-2/2/6) using VLAN 100 for the DHCP clients, and one(xe-9/2/0) leading ot the DHCPserver.The router performs the DHCP snooping (relay) function.

Configure the

Interfaces

[edit interfaces] ge-2/2/4 {

encapsulation ethernet-bridge; unit 0 {

family bridge {

interface-mode access;

vlan-id 100; }

} } ge-2/2/6 {

encapsulation ethernet-bridge;

unit 0 {

family bridge {

interface-mode access; vlan-id 100;

}

} } xe-9/2/0 {

unit 0 {

family bridge {

interface-mode access; vlan-id 100;

}

} }

Configure the Routing

Instance (Virtual

Switch)

[edit routing-instances] vs1 {

instance-type virtual-switch;

interface ge-2/2/4.0;

interface ge-2/2/6.0;

interface xe-9/2/0;

bridge-domains {

bd1 {

domain-type bridge; vlan-id 100; forwarding-options {

dhcp-relay { # DHCP snooping

group hdhcp {

Junos 10.4 MX Series Ethernet Services Routers Solutions Guide

interface ge-2/2/4.0; interface ge-2/2/6.0;

}

} }

You verify your configuration by using two related commands:

•

show dhcp relay binding routing-instance vs1 bridge-domains bd1

•

show dhcp relay binding routing-instance vs1 bridge-domains bd1 detail

user@router1> show dhcp relay binding routing-instance vs1 bridge-domains bd1 2 clients, (2 bound, 0 slecting, 0 renewing, 0 rebinding) IP address Hardware address Type Lease expires at

192.168.1.1 00:00:00:42:a8:e3 active 2008–12–12 15:56:04 PST

192.168.1.2 00:00:00:42:a8:e4 active 2008–12–12 15:56:10 PST

user@router1> show dhcp relay binding routing-instance vs1 bridge-domains bd1 detail 2 clients, (2 bound, 0 slecting, 0 renewing, 0 rebinding) Clients bindings information: IP address : 192.168.1.1 Hardware address : 00:00:00:42:a8:e3 Type : active Lease expires at : 2008–12–12 15:56:04 PST State : bound interface : ge—2/2/6.0 IP address : 192.168.1.2 Hardware address : 00:00:00:42:a8:e4 Type : active Lease expires at : 2008–12–12 15:56:10 PST State : bound interface : ge—2/2/4.0

Documentation

• MX Series Ethernet Services Routers Solutions Page

• MX Series Router as a Layer 2 DHCP Relay Agent on page 73

• Example: Configuring DHCP Relay in a Bridge Domain VLAN Environment on page 74

Juniper Networks OS 10.4 User Manual

Specifications and Main Features

Frequently Asked Questions

User Manual

Abbreviated Table of Contents

Table of Contents

List of Figures

List of Tables

About This Guide

Junos Documentation and Release Notes

Objectives

Audience

Supported Routing Platforms

Using the Indexes

Using the Examples in This Manual

Merging a Full Example

Merging a Snippet

Documentation Conventions

Documentation Feedback

Requesting Technical Support

Self-Help Online Tools and Resources

Opening a Case with JTAC

Ethernet Terms and Acronyms

Networking and Internetworking with Bridges and Routers

Network Addressing at Layer 2 and Layer 3

Networking at Layer 2: Benefits of Ethernet Frames

Networking at Layer 2: Challenges of Ethernet MAC Addresses

Networking at Layer 2: Forwarding VLAN Tagged Frames

Networking at Layer 2: Forwarding Dual-Tagged Frames

Networking at Layer 2: Logical Interface Types

A Metro Ethernet Network with MX Series Routers

Layer 2 Networking Standards

Layer 2 Features for a Bridging Environment

Example Roadmap: Configuring a Basic Bridge Domain Environment

Example Topology

Example Scenario

Example Configuration Summary

Example Step: Configuring Interfaces and VLAN Tags

Example Step: Configuring Bridge Domains

Example Step: Configuring Spanning Tree Protocols

Example Step: Configuring Integrated Bridging and Routing

Layer 2 Features for a Switching Environment

Configuring Virtual Switches as Separate Routing Instances

VLANs Within a Bridge Domain or VPLS Instance

Packet Flow Through a Bridged Network with Normalized VLANs

Configuring a Normalized VLAN for Translation or Tagging

Implicit VLAN Translation to a Normalized VLAN

Sending Tagged or Untagged Packets over VPLS Virtual Interfaces

Configuring a Normalized VLAN

Configuring Learning Domains for VLAN IDs Bound to Logical Interfaces

Example: Configuring a Provider Bridge Network with Normalized VLAN Tags

Example: Configuring a Provider VPLS Network with Normalized VLAN Tags

Example: Configuring One VPLS Instance for Several VLANs

Bulk Configuration of VLANs and Bridge Domains

Example: Configuring VLAN Translation with a VLAN ID List

Example: Configuring Multiple Bridge Domains with a VLAN ID List

Dynamic Profiles for VPLS Pseudowires

Example: Configuring VPLS Pseudowires with Dynamic Profiles—Basic Solutions

VPLS Pseudowire Interfaces Without Dynamic Profiles

VPLS Pseudowire Interfaces and Dynamic Profiles

CE Routers Without Dynamic Profiles

CE Routers and Dynamic Profiles

Example: Configuring VPLS Pseudowires with Dynamic Profiles—Complex Solutions

Configuration of Routing Instance and Interfaces Without Dynamic Profiles

Configuration of Routing Instance and Interfaces Using Dynamic Profiles

Configuration of Tag Translation Using Dynamic Profiles

MX Series Router as a Layer 2 DHCP Relay Agent

Example: Configuring DHCP Relay in a Bridge Domain VLAN Environment

Example: Configuring DHCP Relay in a VPLS Routing Instance Environment