virtual chas lag

ImplementatIon GuIde

Copyright © 2009, Juniper Networks, Inc.

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.

EX4200 METro riNg wiTh MX SEriES hEAd-ENd

Using Virtual Chassis Technology in the WAN

2 Copyright © 2009, Juniper Networks, Inc.

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

table of Contentsintroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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. 3

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

table of FiguresFigure 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



IntroductionA 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.

ScopeThis 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 ConsiderationsWhich 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 Juniper’s 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). Juniper’s 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 recovery—Virtual 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.

Manageability—Using a single router configuration and one management IP address simplifies network •configuration, monitoring, and troubleshooting.



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 network—The 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 links—The EX4200 has a limited number of high-speed (> 1 Gbps) interfaces, two 10 Gbps ports and •two special Virtual Chassis ports.

Failure recovery and standards—Providing carrier grade failover using the EX4200 dictates using Juniper’s •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 traffic—Because 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.

ImplementationThe 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.

Figure 1: Broadband network overview

EX4200Ring

MSAN

Business

MSAN

MetroCore

MetroEdge

MX Series MX Series

Metro Core, Super Core andData Centers

AggregationNetwork

AccessNetwork

Aggregation-to-Metro Core

Interconnection

SuperCore

EX Series



physical ConnectivityThe 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.

Figure 2: Test network overview

There are three ways to interconnect EX4200s into a single Virtual Chassis:

Using Virtual Chassis extension cables—These short, high-speed cables are designed to be used when the •EX4200 members are colocated.

Using 10 Gbps Ethernet links.•

Using 1 Gbps Ethernet links—Note 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.

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.

EX4200-2

EX4200-7

EX4200-5

EX4200-4

EX4200-9

EX4200-0

MX Series

EX4200-6

EX4200-8

EX4200-3 EX4200-1

VIRTUAL CHASSISPROTOCOL (VCP)

10 Gbps

10 Gbps

10 Gbps

10 Gbps

10 Gbps

Virtual ChassisCable (128 Gbps)

MX Series

EX Series



Redundant ConnectionsThe following options are possible for controlling an Ethernet connection between the EX Series Virtual Chassis and the MX Series router:

Link aggregation group (LAG) on both MX Series and EX Series, to bundle multiple physical links into a single 1. logical interface. The standardized implementation is IEEE 802.3ad.

LAG on the MX Series router, RTG (Redundant Trunk Group) on EX Series switches. RTG is a Juniper 2. implementation.

RSTP.3.

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.

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

Configurationsdefining the eX4200 Virtual ChassisBy 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.


10 Gbps

10 Gbps

10 Gbps

2 X 10 Gbps (LAG)



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:

Figure 6: interfaces

eX4200 Configurationsenable 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;

}

}

VCP-0 VCP-1vcp-255/1/0 vcp-255/1/1

vcp-255/1/0

vcp-255/1/1

vcp-255/1/0

vcp-255/1/1

vcp-1

ae0 ae0

vcp-0

vcp-255/1/1

vcp-255/1/0

ge-3/0/1

ge-3/0/0

ge-6/0/0

xe-0/1/0 xe-9/3/0

xe-9/1/1 xe-8/2/0

WX SeriesEX4200-3

EX4200-6

EX4200-0

EX4200-9



Virtual Chassis mastershipMastership 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 maSteRSHIpvirtual-chassis {

member 2 {

mastership-priority 150;

}

member 7 {

mastership-priority 150;

}

fast-failover {

xe;

}

}

Configuring mSan ConnectionsMSANs 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.

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 ControlNetworks 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 SeRIeSethernet-switching-options {

storm-control {

interface all {

level 5;

}

}

}


MX Series

EX Series



mX Series and eX Series ConfigurationsConfiguring link aggregation Group (laG)/aggregated ethernetLAG 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 mX SeRIeS laG1. Set the total number of aggregate interfaces in system (MX Series or entire Virtual Chassis).chassis {

aggregated-devices {

ethernet {

device-count 5;

}

}

}

chassis {

aggregated-devices {

ethernet {

device-count 5;

}

}

}

2. Configure the LAg interface. interfaces {

ae0 {

aggregated-ether-options {

minimum-links 1;

link-speed 10g;

}

}

}

interfaces {

ae0 {


minimum-links 1;

link-speed 10g;

}

}

}

3. Configure the individual LAg member interfaces. This example shows one link being assigned to the LAg group.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;

}

}



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

eX SeRIeS mX SeRIeS1. System-wide LACP protocol configurationprotocols {

lacp {

traceoptions {

filelacp.logsize5m;

flagall;

}

}

}

protocols {

lacp {

traceoptions {

filelacp.logsize5m;

flagall;

}

}

}

2. LAg interface configurationinterfaces {

ae0 {


lacp {

active;

periodic fast;

}

}

}

}

interfaces {

ae0 {


lacp {

active;

periodic fast;

}

}

}

}

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 VlanS alloCatedresidential (Service VLANs)

MSAN management 101-199

RG management 201-299

Residential data 301-399

IPTV, VOD 401-499

VoIP 501-599

Business (Customer VLANs)

Businesses 1000-4094



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 mX SeRIeSinterfaces { 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; } }}

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 mX SeRIeSethernet-switching-options { mac-table-aging-time 300; }}

system { arp { aging-timer 5; }}

Configuring IGmpOn 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.



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

eX SeRIeS (IGmp SnoopInG) mX SeRIeS (teRmInateS IGmp)protocols { igmp-snooping { vlan all; }}

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:

Classify—Each 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.

Schedule—The 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.

Figure 8: CoS overview

ae0

EX Series WX Series

Schedule and Re-Write (Mark) Classify (using classifier)

Classify (using filter) Schedule and Re-Write (Mark)

Downstreamtraffic

Upstreamtraffic



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.

Figure 9: EX Series CoS processing overview

planningThe first step is to plan how traffic will be treated across the network. This is broken down into the following components:

Identify traffic—Define 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.

Classify—Define 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.

Rewrite—For 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.

Classify(based onCoS fields)

Ingress Egress

Ingress Egress

EgressIngress

If MSAN supportsCoS markings

Rewrite(set CoSfields)

PlanDefine

forwardingclasses

Schedule

Classify(based onCoS fields)

TrafficFrom MSAN

TrafficFrom MX

Rewrite(set CoSfields)



table 2: Sample QoS definitions

SeRVICe – tYpe oF tRaFFIC

CRIteRIa Queue FoRWaRdInG ClaSS

plp dSCp 802.1p

Management VLAN=Mgmt (Management VLAN)

7 Mgmt Low cs6 7

Voice VLAN=Voice (Voice VLAN) 6 Voice Low ef 6

iPTV VLAN=Video, ip.dest=224.0.0.0/4 (Video VLAN, multicast) or ARP

5 IPTV Low af42 5

Video on demand (Vod)

VLAN=Video, ip.dest = 10.0.0.0/8 (Video VLAN, unicast, private IP addresses)

4 VOD Low af41 4

Business data VLAN=BusDataXYZ (Business Data VLANs)

1 BusData Low af11 1

residential data VLAN=ResData (Residential Data VLANs)

0 ResData Low be 0

Schedule—Determine 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 ClaSS

plp SCHeduleR-map mSan1 SCHeduleR-map mSan2

priority transmit rate (%)

Buffer size (%)

priority transmit rate (%)

Buffer size (%)

Management 7 Mgmt Low Strict-high

- 5 Strict-high

- 5

Voice 6 Voice Low Strict-high

- 5 Strict-high

- 5

IPTV 5 IPTV Low Low 50 50 Low 30 30

Video on demand (VOD)

4 VOD Low Low 15 15 Low 25 25

Business data 1 BusData Low Low 20 20 Low 25 25

Residential data 0 ResData Low Low Rest Rest Low Rest Rest



defining Forwarding ClassesThe 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 QueueSethernet-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 SeriesFor 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 interface—the 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 poIntSclass-of-service { classifiers { dscp Metro-dscp { import default; forwarding-class ResData { loss-priority low code-points be; } forwarding-class BusData { loss-priority low code-points af11; } forwarding-class VoD { loss-priority low code-points af41; } forwarding-class IPTV { loss-priority low code-points af42; } forwarding-class Voice { loss-priority low code-points ef; } forwarding-class Mgmt { loss-priority low code-points cs6; } }



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 low code-points 000; } forwarding-class BusData { loss-priority low code-points 001; } forwarding-class VoD { loss-priority low code-points 100; } forwarding-class IPTV { loss-priority low code-points 101; } forwarding-class Voice { loss-priority low code-points 110; } forwarding-class Mgmt { loss-priority low 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 RouteRclass-of-service { interfaces { ae0 { unit 0 { classifiers{ ieee-802.1 Metro-1p; } } } }}

Classifying traffic from mSansThe 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.



tRaFFIC FRom mSan: CReate FIlteRS WHICH aSSIGn tRaFFIC to FoRWaRdInG ClaSSeSfirewall{ family ethernet-switching { filterMetro-vlan-Mgmt{ term all { then { forwarding-class Mgmt; loss-priority low; } } } filterMetro-vlan-Voice{ term all { then { forwarding-class Voice; loss-priority low; } } } filterMetro-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; } } } filterMetro-vlan-BusData{ term all { then { forwarding-class BusData; loss-priority low; } } }



tRaFFIC FRom mSan: CReate FIlteRS WHICH aSSIGn tRaFFIC to FoRWaRdInG ClaSSeS

(continued)

filterMetro-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 InteRFaCeSvlans { 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 doesn’t 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•



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 maRKInGSclass-of-service {rewrite-rules { dscp Metro-dscp { forwarding-class ResData { loss-priority low code-point be; } forwarding-class BusData { loss-priority low code-point af11; } forwarding-class VoD { loss-priority low code-point af41; } forwarding-class IPTV { loss-priority low code-point af42; } forwarding-class Voice { loss-priority low code-point ef; } forwarding-class Mgmt { loss-priority low code-point cs6; } } ieee-802.1 Metro-1p { forwarding-class ResData { loss-priority low code-point 000; } forwarding-class BusData { loss-priority low code-point 001; } forwarding-class VoD { loss-priority low code-point 100; } forwarding-class IPTV { loss-priority low code-point 101; } forwarding-class Voice { loss-priority low code-point 110; } forwarding-class Mgmt { loss-priority low 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; }}



egress SchedulingThe final step is to configure how to treat traffic as it leaves the system.

This is a three-step process:

Define the schedulers—This defines the priority and resources available to each scheduler. •

Define the scheduler map—This 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 SCHeduleRSclass-of-service { schedulers { MSAN1-Mgmt { buffer-size percent 5; priority strict-high; } MSAN1-Voice { buffer-size percent 5; priority strict-high; } MSAN1-IPTV { transmit-rate percent 50; buffer-size percent 50; priority low; } MSAN1-VoD { transmit-rate percent 15; buffer-size percent 15; priority low; } MSAN1-BusData { transmit-rate percent 20; buffer-size percent 20; priority low; } MSAN1-ResData { transmit-rate remainder; buffer-size remainder; priority low; } }}



The scheduler map configuration below maps our forwarding classes (e.g., ResData) to schedulers (e.g., MSAN1-ResData). 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 mapSclass-of-service { scheduler-maps { MSAN1 { forwarding-class ResData scheduler MSAN1-ResData; forwarding-class BusData scheduler MSAN1-BusData; forwarding-class VoD scheduler MSAN1-VoD; forwarding-class IPTV scheduler MSAN1-IPTV; forwarding-class Voice scheduler MSAN1-Voice; forwarding-class Mgmt scheduler MSAN1-Mgmt; } }}

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

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


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 headquartersJuniper Networks (Hong Kong) 26/F, Cityplaza One 1111 King’s Road Taikoo Shing, Hong Kong Phone: 852.2332.3636 Fax: 852.2574.7803

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

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.

8010045-001-EN July 2009 Printed on recycled paper.

23

To purchase Juniper Networks solutions, pleasecontact your Juniper Networks representative

at 1-866-298-6428 or authorized reseller.

ReferencesAll 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/implementation-guides/8010018-en.pdf

mX Series ethernet Services RoutersMX 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/.

SummaryThe 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 networksJuniper 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.

virtual chas lag

Documents