ImplementatIon GuIde

EX4200 METro riNg wiTh MX SEriES hEAd-ENd

Using Virtual Chassis Technology in the WAN

Although Juniper Networks has attempted to provide accurate information in this guide, Juniper Networks does not warrant or guarantee the accuracy of the information provided herein. Third party product descriptions and related technical details provided in this document are for information purposes only and such products are not supported by Juniper Networks. All information provided in this guide is provided as is, with all faults, and without warranty of any kind, either expressed or implied or statutory. Juniper Networks and its suppliers hereby disclaim all warranties related to this guide and the information contained herein, whether expressed or implied of statutory including, without limitation, those of merchantability, fitness for a particular purpose and noninfringement, or arising from a course of dealing, usage, or trade practice.

Copyright 2009, Juniper Networks, Inc.

iMPLEMENTATioN gUidE - EX4200 Metro ring with MX Series head-End

table of Contents
introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Scope. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 design Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Which EX Series Device Should I Use? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Why Virtual Chassis? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 When Can I Use the EX4200? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Physical Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Redundant Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Defining the EX4200 Virtual Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 EX4200 Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Enable Graceful Routing Engine Switchover (GRES) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Virtual Chassis Mastership . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Configuring MSAN Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Configuring Storm Control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 MX Series and EX Series Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Configuring Link Aggregation Group (LAG)/Aggregated Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Configuring LACP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Configuring VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Configuring IGMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Configuring Class of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Defining Forwarding Classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Forwarding Within the EX4200 Virtual Chassis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Classifying Traffic from the MX Series . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Classifying Traffic from MSANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 CoS Rewriting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Egress Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 EX Series Ethernet Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 MX Series Ethernet Services Routers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 About Juniper Networks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Copyright 2009, Juniper Networks, Inc.

iMPLEMENTATioN gUidE -EX4200 Metro ring with MX Series head-End

table of Figures
Figure 1: Broadband network overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Figure 2: Test network overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Figure 3: interconnecting EX Series and MX Series devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Figure 4: LAg link between EX Series Virtual Chassis and MX Series router. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Figure 5: EX4200 front (top) and back (bottom) views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Figure 6: interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Figure 7: dual-homed MSAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Figure 8: CoS overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Figure 9: EX Series CoS processing overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Copyright 2009, Juniper Networks, Inc.

iMPLEMENTATioN gUidE - EX4200 Metro ring with MX Series head-End

Introduction
A metro IP network delivers a wide range of services to business and residential customers. These include multicast IPTV and video on demand (VOD), VoIP, business data, and residential data. While Juniper Networks MX Series Ethernet Services Routers are typically the recommended product for these services, their advanced functionality is not required in some portions of the network. Specifically in a ring topology, there is tremendous interest in using Juniper Networks EX Series Ethernet Switches to aggregate traffic within the metro. This document provides recommendations for building an EX Series-based aggregation ring using Juniper Networks EX4200 Ethernet Switch. The information provided here has been validated in the lab. The tested network had many thousands of subscribers actively using services, to closely emulate real networks.

Scope
This document provides information about EX Series and MX Series devices used in metro Ethernet rings for delivering service to residential and business subscribers. It describes the solution, explains main concepts, and presents information about designing networks and configuring network elements. Specifically, it covers two subsystems: A ring topology aggregation network built using EX4200 switches, and an MX Series router which is the gateway between the aggregation ring and the metro core. This document is intended for system engineers, system administrators, and others who have the technical background that is required to understand network operations, network hardware, and software components. Juniper Networks JUNOS Software 9.3R2.8 was used for both the EX Series and MX Series devices.

design Considerations
Which eX Series device Should I use?
The EX Series product family covers a wide range of functionality. Juniper Networks EX8200 line of Ethernet switches consists of large chassis-based platforms designed for the data center, which is typically not the desired form factor. The EX2200 line and EX2500 line of switches are single speed devices (all 1 Gbps ports on the EX2200 Ethernet Switch, all 10 Gbps ports on the EX2500 Ethernet Switch) designed for top of rack interconnection, so are not targeted at traffic aggregation. Juniper Networks EX2200 Ethernet Switch and EX2500 Ethernet Switch are single speed devices (all 1 Gbps ports on the EX2200 and all 10 Gbps ports on the EX2500) designed for top of rack interconnection, so are not targeted at traffic aggregation. The Juniper Networks EX3200 Ethernet Switch and the EX4200 are designed to aggregate traffic, with up to 48 Gigabit Ethernet ports connecting to 10 Gbps uplinks. These have the same software feature set, with the key difference being that the EX4200 line supports Junipers Virtual Chassis technology. Therefore, EX4200 is the best fit for this application.

Why Virtual Chassis?

There are two key software technologies available for creating the aggregation ring: Rapid Spanning Tree Protocol (RSTP) or Virtual Chassis (VC). Junipers unique Virtual Chassis technology allows multiple physical EX4200 switches to be treated as a single logical chassis, even if they are at different locations. Preliminary testing has shown Virtual Chassis to be the preferred solution for several reasons: Failure recoveryVirtual Chassis recovers from failures much more quickly than RSTP. When using RSTP, a chassis or network failure required that all media access control (MAC) addresses be learned by all chassis in the backup path. This resulted in a multi-second delay. ManageabilityUsing a single router configuration and one management IP address simplifies network configuration, monitoring, and troubleshooting.

Copyright 2009, Juniper Networks, Inc.

iMPLEMENTATioN gUidE -EX4200 Metro ring with MX Series head-End

When Can I use the eX4200?

In determining whether an EX4200 should be deployed for the aggregation network, there are several factors to consider: Number of MAC addresses across the networkThe EX4200 supports up to 24,000 MAC addresses, which is less than the 1 million MAC addresses supported by the MX Series product family. Number of linksThe EX4200 has a limited number of high-speed (> 1 Gbps) interfaces, two 10 Gbps ports and two special Virtual Chassis ports. Failure recovery and standardsProviding carrier grade failover using the EX4200 dictates using Junipers proprietary Virtual Chassis technology, which supports a ring of up to 10 nodes. RSTP may be used but typically does not recover from errors quickly enough to satisfy Tier 1/Tier 2 carriers. The MX Series implements both IP routing and MPLS techniques which significantly improves scalability and failure recovery time. Service VLANs for residential trafficBecause of VLAN stacking restrictions on the EX4200, service VLANs should be used to deliver residential traffic. Having a separate VLAN per customer could result in exceeding the standard limitation of 4094 VLANs. If the EX4200 does not fit the requirements, the MX Series platform can be deployed.

Implementation
The metro network for delivering broadband services to residential and business subscribers can be divided into the following sub-networks. Access network: These are multiservice access nodes (MSANs such as digital subscriber line access multiplexers or DSLAMs) and customer premises equipment (CPE) devices. Juniper does not provide this equipment. Aggregation network: These Ethernet switches consolidate traffic from the access network. In this document, the aggregation network is a ring of EX4200 switches. Metro core network: This backbone may consist of Juniper Networks M Series Multiservice Edge Routers, Juniper Networks T Series Core Routers, and MX Series routers, as well as non-Juniper products. This report focuses on the aggregation portion, including the interconnection to the core network.
Business

MSAN EX Series EX4200 Ring Metro Edge MX Series MX Series Metro Core Super Core

MSAN

Access Network

Aggregation Network

Aggregationto-Metro Core Interconnection

Metro Core, Super Core and Data Centers

Figure 1: Broadband network overview

Copyright 2009, Juniper Networks, Inc.

iMPLEMENTATioN gUidE - EX4200 Metro ring with MX Series head-End

physical Connectivity
The aggregation network consists of 10 EX4200 Ethernet switches, configured as one Virtual Chassis. Each physical EX4200 node is a member of the virtual chassis. A member identifier (ID) uniquely identifies each physical node. To simplify the discussion, we will focus on four virtual chassis members, as depicted in Figure 2.
EX4200-2 EX4200-3 EX4200-4 EX4200-5 EX4200-6 EX4200-8 EX4200-7 Figure 2: Test network overview EX4200-1 MX Series EX4200-0

EX4200-9

There are three ways to interconnect EX4200s into a single Virtual Chassis: Using Virtual Chassis extension cablesThese short, high-speed cables are designed to be used when the EX4200 members are colocated. Using 10 Gbps Ethernet links. Using 1 Gbps Ethernet linksNote that, in JUNOS 9.3, multiple links cannot be aggregated into a bundle to provide higher throughput between virtual chassis members. The recommended method for interconnecting EX Series and MX Series devices in the head-end is to use one 10 Gbps link from each EX Series switch to the MX Series router, as depicted in Figure 3. Note that, since there are a maximum of two 10 Gbps connections per EX Series chassis, there are no additional 10 Gbps ports available to interconnect the head-end EX Series switches EX4200-0 and EX4200-9. Therefore, a Virtual Chassis cable is used to interconnect these devices. This scenario assumes that head-end EX4200 switches are colocated.
10 Gbps EX Series 10 Gbps 10 Gbps MX Series

VIRTUAL CHASSIS PROTOCOL (VCP)

10 Gbps

10 Gbps

Virtual Chassis Cable (128 Gbps)

Figure 3: interconnecting EX Series and MX Series devices

If the head-end EX4200s reside at different locations, then they must be interconnected via a 10 Gbps Ethernet connection. In this case, N x 1-Gigabit Ethernet links may be used from the EX Series to the MX Series. This scenario, while valid, is not covered in this document. Since Virtual Chassis does not use standard MAC framing, Ethernet signal repeaters should not be used on links between Virtual Chassis members (ring links). In most cases, this is not expected to cause any concern.

Copyright 2009, Juniper Networks, Inc.

iMPLEMENTATioN gUidE -EX4200 Metro ring with MX Series head-End

Redundant Connections
The following options are possible for controlling an Ethernet connection between the EX Series Virtual Chassis and the MX Series router: 1. Link aggregation group (LAG) on both MX Series and EX Series, to bundle multiple physical links into a single logical interface. The standardized implementation is IEEE 802.3ad. 2. LAG on the MX Series router, RTG (Redundant Trunk Group) on EX Series switches. RTG is a Juniper implementation. 3. RSTP. LAG is recommended on both platforms. Since LAG is seen as one logical interface, using LAG eliminates the need for relearning L2 and L3 addresses in cases where individual physical links fail (as long as one LAG member stays active). This is depicted in Figure 4. LAG can be configured with or without Link Aggregation Control Protocol (LACP). Since graceful Routing Engine switchover (GRES) does not support LACP, the recommendation is not to use it. In addition, link protection is not supported on EX Series devices running JUNOS 9.3R2.8.
10 Gbps

10 Gbps

VIRTUAL CHASSIS PROTOCOL (VCP)

10 Gbps

2 X 10 Gbps (LAG)

Figure 4: LAg link between EX Series Virtual Chassis and MX Series router

Configurations
defining the eX4200 Virtual Chassis
By default, the Virtual Chassis ports located on the back panel are used to create the Virtual Chassis. Before connecting a chassis into the Virtual Chassis using Ethernet ports, we must specify which ports (1GbE or 10GbE) are to be used for interconnecting the members of the Virtual Chassis. Use these operational-mode commands to define these ports: request virtual-chassis vc-port set pic-slot 1 port 0 request virtual-chassis vc-port set pic-slot 1 port 1 These commands tell JUNOS to use these ports to create the Virtual Chassis, excluding them from regular use as a network/customer interface. When issuing show commands to verify setup, the following port names are used: vcp-0, dedicated port located on the back, first port from left side vcp-1, dedicated port located on the back, second port from left side vcp-255/1/0, 1GbE/10GbE port located on the front, uplink module 1, first port from left side vcp-255/1/1, 1GbE/10GbE port located on the front, uplink module 1, second port from left side These VCP interfaces are local to individual physical chassis, and do not appear in any configuration file.

Copyright 2009, Juniper Networks, Inc.

iMPLEMENTATioN gUidE - EX4200 Metro ring with MX Series head-End

VCP-0

VCP-1

vcp-255/1/0

vcp-255/1/1

Figure 5: EX4200 front (top) and back (bottom) views

Note that Figure 5 shows the 4-port 1 Gbps uplink module, not the 2-port 10 Gbps uplink module. Figure 6 provides an overview of the relevant interfaces configured in this document:
vcp-255/1/0 ge-3/0/0 EX4200-3 ge-3/0/1 vcp-255/1/1 vcp-1 vcp-0 ge-6/0/0 EX4200-6 vcp-255/1/0 xe-0/1/0 vcp-255/1/0 EX4200-0 ae0 EX4200-9 vcp-255/1/1 xe-9/1/1 ae0 xe-9/3/0 WX Series

xe-8/2/0

vcp-255/1/1 Figure 6: interfaces

eX4200 Configurations
enable Graceful Routing engine Switchover (GReS)
Enabling GRES causes the master and backup Routing Engines (REs) to synchronize protocol states and forwarding tables.

eX GRaCeFul RoutInG enGIne SWItCHoVeR (GReS)

chassis { redundancy { graceful-switchover; } }

Copyright 2009, Juniper Networks, Inc.

iMPLEMENTATioN gUidE -EX4200 Metro ring with MX Series head-End

Virtual Chassis mastership

Mastership priority should be set only for master and backup switches, and should be the same. This is to avoid an unnecessary transition of mastership after a failed master becomes active again. If possible, the switches hosting uplinks should not be master or backup REs for the EX4200 Virtual Chassis.

eX VIRtual CHaSSIS maSteRSHIp

virtual-chassis { member 2 { mastership-priority 150; } member 7 { mastership-priority 150; } fast-failover { xe; } }

Configuring mSan Connections

MSANs are typically connected to the EX4200 using one or more 1GbE links. In case of multiple links between the EX4200 Virtual Chassis and MSAN, the links should terminate on different EX4200 switches if possible, as illustrated in Figure 7.
MX Series EX Series

VIRTUAL CHASSIS PROTOCOL (VCP)

Figure 7: dual-homed MSAN

As before, this connection can be done using RSTP or LAG (with or without LACP). As before, LAG without LACP is recommended. The LAG configurations to the MX Series router (described later in this document) can be used as an example for configuring the EX4200 connections to MSANs.

Configuring Storm Control

Networks built using a service VLAN (S-VLAN) model are sensitive to the amount of broadcast, unknown unicast, or multicast (BUM) traffic, which increases CPU utilization on nodes within a broadcast domain. The amount of broadcast and unknown unicast (BU) traffic can be controlled on EX4200 switches by specifying the maximum amount (level) of that traffic on each ingress interface, as a percentage of total link speed. This value can be applied on both types of traffic or on only one of them (broadcast or unknown-unicast). It is recommended to keep the level of BU traffic in the network as low as possible at all times.

eX SeRIeS
ethernet-switching-options { storm-control { interface all { level 5; } } }

Copyright 2009, Juniper Networks, Inc.

iMPLEMENTATioN gUidE - EX4200 Metro ring with MX Series head-End

mX Series and eX Series Configurations

Configuring link aggregation Group (laG)/aggregated ethernet
LAG configuration consists of three parts. Note that the EX Series uses the syntax ether-options, while the MX Series uses the keyword gigether-options.

eX SeRIeS laG
chassis { aggregated-devices { ethernet { device-count 5; } } }

mX SeRIeS laG
chassis { aggregated-devices { ethernet { device-count 5; } } } interfaces { ae0 {

1. Set the total number of aggregate interfaces in system (MX Series or entire Virtual Chassis).

2. Configure the LAg interface.

interfaces { ae0 { aggregated-ether-options { minimum-links 1; link-speed 10g; } } } interfaces { xe-9/1/1 { description MX-8/2/0; ether-options { 802.3ad ae0; } } } } } interfaces { xe-8/2/0 { description EX-9/1/1; gigether-options { 802.3ad ae0; } }

aggregated-ether-options { minimum-links 1; link-speed 10g;

3. Configure the individual LAg member interfaces. This example shows one link being assigned to the LAg group.

10

Copyright 2009, Juniper Networks, Inc.

iMPLEMENTATioN gUidE -EX4200 Metro ring with MX Series head-End

Configuring laCp
As noted above, LACP is not recommended. However, if LACP is used, configuration consists of two parts:

eX SeRIeS
1. System-wide LACP protocol configuration
protocols { lacp { traceoptions { file lacp.log size 5m; flag all; } } }

mX SeRIeS
protocols { lacp { traceoptions { file lacp.log size 5m; flag all; } } } interfaces { ae0 { aggregated-ether-options { lacp { active; periodic fast; } } } } } } aggregated-ether-options { lacp { active; periodic fast;

2. LAg interface configuration

interfaces { ae0 {

} }

Configuring Vlans
Table 1 depicts how VLANs are used for service delivery. Residential traffic is delivered using service VLANs (S-VLANs), where a VLAN delivers one service to customers (e.g., VoIP). Because each VLAN is a broadcast domain, a single VLAN is typically limited to 500 subscribers; after that, additional S-VLANs are configured to support additional customers. Business customers use customer VLANs (C-VLANs), where a unique VLAN is used to reach each customer.

table 1: Vlan assignments

Role
residential (Service VLANs) MSAN management RG management Residential data IPTV, VOD VoIP Business (Customer VLANs) Businesses 1000-4094 101-199 201-299 301-399 401-499 501-599

VlanS alloCated

Copyright 2009, Juniper Networks, Inc.

11

iMPLEMENTATioN gUidE - EX4200 Metro ring with MX Series head-End

Sample VLAN configurations for the MX Series and EX Series are shown below. Since business traffic belongs to a VPLS VPN (which is not covered in this document), an IP address is not specified.

eX SeRIeS
interfaces { ge-0/0/0 { description MSAN 01.01; unit 0 { family ethernet-switching { port-mode trunk; } } } } vlans { Video1 { vlan-id 401; interface { ae0.0; ge-0/0/0.0; ge-1/0/0.0; } } Voice1 { vlan-id 501; interface { ae0.0; ge-0/0/0.0; ge-1/0/0.0; ge-2/0/0.0; ge-3/0/0.0; ge-4/0/0.0; } } }

mX SeRIeS
interfaces { ae0 { vlan-tagging; unit 401 { description Video1; vlan-id 401; family inet { address 10.244.0.1/20; } } unit 501 { description Voice1; vlan-id 501; family inet { address 10.245.0.1/20; } } unit 1001 { description Business1; vlan-id 1001; }

To prevent some unnecessary flooding of unknown-unicast traffic, the Address Resolution Protocol (ARP) timeout value on the MX Series router should match the EX Series L2 forwarding timeout. Note that the EX Series specifies this in seconds while the MX Series specifies this in minutes.

eX SeRIeS
ethernet-switching-options { mac-table-aging-time 300; } }

mX SeRIeS
system { arp { } aging-timer 5;

Configuring IGmp
On EX4200, IGMP snooping is configured on all MSAN facing ports, which is the default configuration. Note that IGMP snooping will work on a given EX4200 port only if enabled for all VLANs on the port. If snooping is disabled on any VLAN, then it will not work for any VLANs on that port. The MX Series router terminates IGMP traffic. IGMP should be configured on the LAG interface toward the aggregation network to statically join all known multicast streams. This is to mitigate the risk of losing multicast streams in case some IGMP reports are lost or dropped in the MX Series due to its throttling of control traffic.

12

Copyright 2009, Juniper Networks, Inc.

iMPLEMENTATioN gUidE -EX4200 Metro ring with MX Series head-End

To simplify the example, only five multicast groups are shown below.

eX SeRIeS (IGmp SnoopInG)

protocols { igmp-snooping { vlan all; } }

mX SeRIeS (teRmInateS IGmp)

protocols { igmp { query-interval 25; interface all { promiscuous-mode; } interface ae0.0 { static { group 225.1.1.1; group 225.1.1.2; group 225.1.1.3; group 225.1.1.4; group 225.1.1.5; } }

Configuring Class of Service

Class of service (CoS) is used to prioritize traffic in case of congestion, when all traffic cannot be delivered over the intended interface. CoS rules are determined on a network-wide level and implemented on individual nodes as required. The key functions include: ClassifyEach type of traffic receiving non-default behavior must be identified, as well as how this traffic is to be treated. Rewrite (mark)It is often desirable to set priority bits in packets so that upstream/downstream devices know how to treat this traffic. ScheduleThe final step is to specify how each type of traffic should be treated. An interface may be any of the following: A physical connection into the router, such as a 10GbE port. An aggregated Ethernet (a.k.a. Link Aggregation Group, or LAG) interface, which groups multiple physical links together into a single logical interface. A VLAN These functions occur for traffic in each direction. Figure 8 illustrates where these functions can be enabled.
Downstream trafc

Schedule and Re-Write (Mark)

Classify (using classier)

EX Series

WX Series

ae0

Upstream trafc

Classify (using lter)

Schedule and Re-Write (Mark)

Figure 8: CoS overview

Copyright 2009, Juniper Networks, Inc.

13

iMPLEMENTATioN gUidE - EX4200 Metro ring with MX Series head-End

There are two approaches for classifying traffic. The first option is to assume that the CoS (DiffServ code point and/ or 802.1p) markings have already been set correctly, such as an upstream router or application server. In this case, a behavior aggregate (BA) classifier can be used to inspect these fields and determine how to treat packets as they traverse the switch/router. The second choice is to expect that the CoS markings may be inaccurate. In this case, a multi-field (MF) filter must be created to look deeper into the packet to determine the proper treatment. This is more appropriate for traffic coming from the customer or from other service providers. In this document, we assume that the CoS fields coming from the MX Series router are marked correctly, while CoS markings from the MSAN may be invalid. The overall process is summarized in Figure 9.

Trafc From MX
Ingress

Ingress

Egress

Classify (based on CoS elds)

Rewrite (set CoS elds)

If MSAN supports CoS markings

Egress

Plan

Dene forwarding classes Trafc From MSAN

Schedule

Ingress

Egress

Classify (based on CoS elds)

Rewrite (set CoS elds)

Figure 9: EX Series CoS processing overview

planning
The first step is to plan how traffic will be treated across the network. This is broken down into the following components: Identify trafficDefine how to identify each type of traffic which will be prioritized. The criteria column in Table 2 depicts the multi-field criteria which will be used to identify traffic. ClassifyDefine the desired treatment for each type of traffic. This includes defining two tags which are carried internally with every packet: forwarding class and packet loss priority (PLP). Forwarding class is a name which represents this traffic; PLP specifies whether the packet should have a high or low chance of being dropped. Traffic will be classified into forwarding classes, which are associated with hardware queues. These are the next three fields in Table 2. RewriteFor each type of traffic, determine which priority fields will be marked as it leaves the switch/router. This process sets one or more priority fields which may be carried within the packet. The fields which may be set are IP DiffServ code point (DSCP), IEEE Ethernet VLAN priority (802.1p), or Internet precedence. Since this is a Layer 2 network, it is most appropriate to set the 802.1p bits on downstream traffic so that downstream devices such as MSANs can use this information to prioritize traffic. For upstream traffic, it is more appropriate to set the DSCP settings. In JUNOS 9.3, the EX4200 requires that both or neither markings be set. These are shown in the last two columns in Table 2.

14

Copyright 2009, Juniper Networks, Inc.

iMPLEMENTATioN gUidE -EX4200 Metro ring with MX Series head-End

table 2: Sample QoS definitions

SeRVICe tYpe oF tRaFFIC
Management Voice iPTV Video on demand (Vod) Business data residential data

CRIteRIa
VLAN=Mgmt (Management VLAN) VLAN=Voice (Voice VLAN) VLAN=Video, ip.dest=224.0.0.0/4 (Video VLAN, multicast) or ARP VLAN=Video, ip.dest = 10.0.0.0/8 (Video VLAN, unicast, private IP addresses) VLAN=BusDataXYZ (Business Data VLANs) VLAN=ResData (Residential Data VLANs)

Queue
7 6 5 4 1 0

FoRWaRdInG plp ClaSS

Mgmt Voice IPTV VOD BusData ResData Low Low Low Low Low Low

dSCp
cs6 ef af42 af41 af11 be

802.1p
7 6 5 4 1 0

ScheduleDetermine how the traffic will be treated as it leaves the router. The scheduler-map specifies this for every forwarding class/PLP pair. There are three key parameters which must be specified for every forwarding class/PLP pair. One is priority level, or the percentage of bandwidth which is available to each forwarding class. The other is the percentage of the buffer available to each forwarding class. More than one scheduler may be defined and applied to different egress ports. For example, there may be one map for MSANs connected using a single 1 Gbps link, another for MSANs connected via two 1 Gbps links, and another for the 20 Gbps connection to the MX Series router. Table 3 shows an example of two schedulers.

table 3: egress Scheduling

SeRVICe tYpe oF tRaFFIC Queue FoRWaRdInG plp ClaSS SCHeduleR-map mSan1 priority
Management Voice IPTV Video on demand (VOD) Business data Residential data 7 6 5 4 1 0 Mgmt Voice IPTV VOD BusData ResData Low Low Low Low Low Low Stricthigh Stricthigh Low Low Low Low

SCHeduleR-map mSan2 priority

Stricthigh Stricthigh Low Low Low Low

transmit Buffer rate (%) size (%)

50 15 20 Rest 5 5 50 15 20 Rest

transmit Buffer rate (%) size (%)

30 25 25 Rest 5 5 30 25 25 Rest

Copyright 2009, Juniper Networks, Inc.

15

iMPLEMENTATioN gUidE - EX4200 Metro ring with MX Series head-End

defining Forwarding Classes

The first step is to define the forwarding classes and assign them to the desired hardware queues. More than one forwarding class can be assigned to each queue, although this is not required for our aggregation network.

deFIne FoRWaRdInG ClaSSeS and aSSIGn to QueueS

ethernet-switching-options { class-of-service { forwarding-classes { class Mgmt queue-num 7; class Voice queue-num 6; class IPTV queue-num 5; class VoD queue-num 4; class BusData queue-num 1; class ResData queue-num 0; } }

Forwarding Within the eX4200 Virtual Chassis

The next step is to specify how traffic will get assigned to each forwarding class and PLP. There are two ways to achieve this: If the CoS fields are already marked appropriately and these markings are set by the network, then a classifier can be used to inspect the DSCP or 802.1p bits and assign the traffic to the appropriate forwarding class and PLP. Otherwise, a more specific filter must be created. This inspects one or more non-CoS fields within the packet to determine the appropriate forwarding class and PLP.

Classifying traffic from the mX Series

For traffic coming from the MX Series router, we can use classifiers to assign the proper forwarding class and PLP. These classifiers are then applied to the appropriate ingress interfaces. In the example, this means applying them to interfaces facing the MX Series. In the example below, we have shown both IEEE-802.1p and DSCP classifiers, but only one should be applied to each interfacethe EX4200 will look at either the DSCP or 802.1p values to determine how to classify the packet.

tRaFFIC FRom mX SeRIeS: ClaSSIFY tRaFFIC Into appRopRIate FoRWaRdInG ClaSS BaSed on Code poIntS
class-of-service { classifiers { dscp Metro-dscp { import default; forwarding-class ResData loss-priority } forwarding-class BusData loss-priority } forwarding-class VoD { loss-priority } forwarding-class IPTV loss-priority } forwarding-class Voice { loss-priority } forwarding-class Mgmt loss-priority } } 16

{ low { low

code-points

be;

code-points

af11;

low { low

code-points

af41;

code-points

af42;

low { low

code-points

ef;

code-points

cs6;

Copyright 2009, Juniper Networks, Inc.

iMPLEMENTATioN gUidE -EX4200 Metro ring with MX Series head-End

tRaFFIC FRom mX SeRIeS: ClaSSIFY tRaFFIC Into appRopRIate FoRWaRdInG ClaSS BaSed on Code poIntS
(continued) ieee-802.1 Metro-1p { import default; forwarding-class ResData loss-priority } forwarding-class BusData loss-priority } forwarding-class VoD { loss-priority } forwarding-class IPTV loss-priority } forwarding-class Voice { loss-priority } forwarding-class Mgmt loss-priority } }

{ low { low

code-points

000;

code-points

001;

low { low

code-points

100;

code-points

101;

low { low

code-points

110;

code-points

111;

The classifier is then applied to the appropriate interfaces. In our example, only traffic from the MX Series (ae0) is classified using the existing 802.1p CoS field.

tRaFFIC FRom mX SeRIeS: aSSIGn ClaSSIFIeR to InteRFaCeS FaCInG mX SeRIeS RouteR

class-of-service { interfaces { ae0 {

unit 0 { classifiers { ieee-802.1 Metro-1p; } }

Classifying traffic from mSans

The process for classifying packets from MSAN ports is similar to the one shown above. However, traffic cannot be classified based on pre-existing CoS fields, since we assume that they are not present or may not be valid. Instead, other fields must be examined. To do this, we create a filter defined under the firewall stanza. This filter looks at non-CoS fields to determine which forwarding class traffic each packet gets assigned to. The Metro-vlan-Video filter is the most complex. It uses the destination IP address to assign multicast IPTV and unicast VOD traffic to different forwarding classes, and it also assigns all ARP traffic to the IPTV forwarding class. In most other cases, all traffic (within a given VLAN) is mapped to the same forwarding class.

Copyright 2009, Juniper Networks, Inc.

17

iMPLEMENTATioN gUidE - EX4200 Metro ring with MX Series head-End

tRaFFIC FRom mSan: CReate FIlteRS WHICH aSSIGn tRaFFIC to FoRWaRdInG ClaSSeS
firewall { family ethernet-switching { filter Metro-vlan-Mgmt { term all { then { forwarding-class Mgmt; loss-priority low; } } } filter Metro-vlan-Voice { term all { then { forwarding-class Voice; loss-priority low; } } } filter Metro-vlan-Video { term IPTV { from { destination-address { 224.0.0.0/4; } } then { forwarding-class IPTV; loss-priority low; } } term VoD { from { destination-address { 10.0.0.0/8; } } then { forwarding-class VoD; loss-priority low; } } term ARP { from { ether-type arp; } then { forwarding-class IPTV; loss-priority low; } } } filter Metro-vlan-BusData { term all { then { forwarding-class BusData; loss-priority low; } } } 18
Copyright 2009, Juniper Networks, Inc.

iMPLEMENTATioN gUidE -EX4200 Metro ring with MX Series head-End

tRaFFIC FRom mSan: CReate FIlteRS WHICH aSSIGn tRaFFIC to FoRWaRdInG ClaSSeS
(continued) filter Metro-vlan-ResData { term all { then {

forwarding-class ResData; loss-priority low;

These filters are then applied to the appropriate logical interfaces. In this case, the video filter (Metro-vlan-Video) is applied to the video service VLAN (vlan-id 401). In JUNOS 9.3, firewall filters such as this cannot be applied to a LAG interface.

tRaFFIC FRom mSan: applYInG InGReSS FIlteRS to InteRFaCeS

vlans { Video1 { vlan-id 401; interface { ge-0/0/0.0; ge-1/0/0.0; ge-2/0/0.0; ae0.0; } filter { input Metro-vlan-Video; } }

CoS Rewriting
To allow other devices in our network domain to classify traffic based on valid CoS fields, we can set the IP DSCP and/or Ethernet (802.1p) fields. CoS values are assigned based upon the forwarding class and PLP values. The configuration below shows the filters for rewriting both 802.1p and DSCP markings. We do this on the EX4200 since it doesnt trust CoS values coming from MSANs. For example, IPTV traffic is assigned DSCP = AF42 and 802.1p = 5, while VOD is assigned to DSCP = AF41 and 802.1p = 4. In JUNOS 9.3, a firewall filter is applied to the egress interface (VLAN or physical interface) to trigger the rewriting of L2 traffic. The EX4200 always rewrites both fields when this function is configured. Rewriting is a three step process: Define the markings (rewrite rules) which will be applied upon egress. Create a filter to map traffic to the appropriate service class/PLP. These are the same filters that we created in the previous step. Apply the filters to interfaces, to assign the appropriate forwarding class/PLP

Copyright 2009, Juniper Networks, Inc.

19

iMPLEMENTATioN gUidE - EX4200 Metro ring with MX Series head-End

Once the forwarding class and PLP are assigned, the rewrite rules specify the DSCP and 802.1p values to use when marking the packets.

ReWRItInG: deFIne CoS maRKInGS

class-of-service { rewrite-rules { dscp Metro-dscp { forwarding-class ResData loss-priority } forwarding-class BusData loss-priority } forwarding-class VoD { loss-priority } forwarding-class IPTV loss-priority } forwarding-class Voice { loss-priority } forwarding-class Mgmt loss-priority } } ieee-802.1 Metro-1p { forwarding-class ResData loss-priority } forwarding-class BusData loss-priority } forwarding-class VoD { loss-priority } forwarding-class IPTV loss-priority } forwarding-class Voice { loss-priority } forwarding-class Mgmt loss-priority } }

{ low { low

code-point be;

code-point af11;

low { low

code-point af41;

code-point af42;

low { low

code-point ef;

code-point cs6;

{ low { low

code-point 000;

code-point 001;

low { low

code-point 100;

code-point 101;

low { low

code-point 110;

code-point 111;

Here is an example of the Metro-vlan-Video filter being applied to an egress port. (Note the keyword output which indicates that this is applied at egress.) This process assigns the forwarding class and PLP.

ReWRItInG: applY FIlteR to eGReSS InteRFaCe

vlans { Video1 { filter { output Metro-vlan-Video; } } 20

Copyright 2009, Juniper Networks, Inc.

iMPLEMENTATioN gUidE -EX4200 Metro ring with MX Series head-End

egress Scheduling
The final step is to configure how to treat traffic as it leaves the system. This is a three-step process: Define the schedulersThis defines the priority and resources available to each scheduler. Define the scheduler mapThis assigns forwarding classes to schedulers. Assign scheduler maps to interfaces. Below is a sample scheduler configuration. The rules for transmit bandwidth are here: Queues with strict-high priority will always be served before queues with low priority. Among queues with strict-high priority, those with the higher queue number will always be served before those with a lower queue number. Among queues with low priority, the port scheduler will try to allocate bandwidth based upon the specified percentages.

eGReSS Step 1: deFIne SCHeduleRS

class-of-service { schedulers { MSAN1-Mgmt { buffer-size percent priority strict-high; } MSAN1-Voice { buffer-size percent priority strict-high; } MSAN1-IPTV { transmit-rate percent buffer-size percent priority low; } MSAN1-VoD { transmit-rate percent buffer-size percent priority low; } MSAN1-BusData { transmit-rate percent buffer-size percent priority low; } MSAN1-ResData { transmit-rate remainder; buffer-size remainder; priority low; } } }

5;

5;

50; 50;

15; 15;

20; 20;

Copyright 2009, Juniper Networks, Inc.

21

iMPLEMENTATioN gUidE - EX4200 Metro ring with MX Series head-End

The scheduler map configuration below maps our forwarding classes (e.g., ResData) to schedulers (e.g., MSAN1ResData). In our simple case, all of the schedulers defined above are included in this map. Residential data will get at least 5 percent of the total, since the other schedulers add up to 95 percent.

eGReSS Step 2: deFIne SCHeduleR mapS

class-of-service { scheduler-maps { MSAN1 { forwarding-class forwarding-class forwarding-class forwarding-class forwarding-class forwarding-class } } }

ResData scheduler MSAN1-ResData; BusData scheduler MSAN1-BusData; VoD scheduler MSAN1-VoD; IPTV scheduler MSAN1-IPTV; Voice scheduler MSAN1-Voice; Mgmt scheduler MSAN1-Mgmt;

Finally, the scheduler map is assigned to an egress interface.

eX SeRIeS
class-of-service { interfaces { ge-0/0/0 { scheduler-map MSAN1; } } }

22

Copyright 2009, Juniper Networks, Inc.

iMPLEMENTATioN gUidE - EX4200 Metro ring with MX Series head-End

References
All testing was performed using JUNOS 9.3R2.8. Additional information on product capabilities is available at the following locations:

eX Series ethernet Switches

EX Series hardware and software documentation is available at http://www.juniper.net/techpubs/en_US/junos9.3/ information-products/pathway-pages/ex-series/index.html. Interface configuration, including LAG, is available at http://www.juniper.net/techpubs/en_US/junos9.3/ information-products/pathway-pages/ex-series/interfaces.html. QoS configuration is available at http://www.juniper.net/techpubs/en_US/junos9.3/information-products/ pathway-pages/ex-series/cos.html. Additional information about the EX Series is available at http://www.juniper.net/us/en/products-services/switching/ ex-series/. One recommended document is: Virtual Chassis Technology Best Practices, http://www.juniper.net/us/en/local/pdf/implementationguides/8010018-en.pdf

mX Series ethernet Services Routers

MX Series and JUNOS Software documentation is available at http://www.juniper.net/techpubs/software/junos/. JUNOS 9.3 software manuals are available at http://www.juniper.net/techpubs/software/junos/junos93/index.html. Manuals can be downloaded in various formats or can be viewed online from this page. GRES information can be found in the High Availability manual. LAG information can be found in the Network Interfaces manual, under Configuring Ethernet Interfaces Configuring Aggregated Ethernet Interfaces. CoS information can be found in the Class of Service manual. Additional information about the MX Series is available at http://www.juniper.net/us/en/products-services/routing/ mx-series/.

Summary
The EX4200 may be used successfully for delivering residential and business services when configured as a Virtual Chassis. The Virtual Chassis configuration supports up to ten EX4200 nodes, with a maximum of 48 Gigabit Ethernet interfaces per node. For additional information, please contact your Juniper Networks representative.

about Juniper networks

Juniper Networks, Inc. is the leader in high-performance networking. Juniper offers a high-performance network infrastructure that creates a responsive and trusted environment for accelerating the deployment of services and applications over a single network. This fuels high-performance businesses. Additional information can be found at www.juniper.net.

Corporate and Sales headquarters Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA Phone: 888.JUNIPER (888.586.4737) or 408.745.2000 Fax: 408.745.2100

APAC headquarters Juniper Networks (Hong Kong) 26/F, Cityplaza One 1111 Kings Road Taikoo Shing, Hong Kong Phone: 852.2332.3636 Fax: 852.2574.7803

EMEA headquarters Juniper Networks Ireland Airside Business Park Swords, County Dublin, Ireland Phone: 35.31.8903.600 Fax: 35.31.8903.601

To purchase Juniper Networks solutions, please contact your Juniper Networks representative at 1-866-298-6428 or authorized reseller.
8010045-001-EN July 2009

Copyright 2009 Juniper Networks, Inc. All rights reserved. Juniper Networks, the Juniper Networks logo, JUNOS, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. JUNOSe is a trademark of Juniper Networks, Inc. All other trademarks, service marks, registered marks, 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.

Printed on recycled paper.

23