The Juniper Networks® Vertical Campus Implementation Guide provides a simple, tested, step-by-step process for rapidly deploying a large campus solution. The deployment incorporates the most commonly used enterprise network technologies to provide a simple and scalable network architecture that includes LAN, WLAN, and security components. This guide presents a specific configuration of Juniper Networks hardware and software platforms that have been tested and provide a reliable foundation on which to base a customized network for your business.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
eX-Xre200-aC 12.1r9 eX8200 Virtual Chassis Juniper Networks Xre200 external routing engine with dual aC power supplies, dual fans, two 160 GB hard disks and one 4-port 10/100/1000Base-t rJ-45 I/O card
eX8208-reDuND-aC 12.1r9 redundant eX8208 2000 W aC system bundle: 8-slot chassis with passive backplane and 1x fan tray, 2x routing engine with switch fabric, 1x switch fabric module, 6x 2000 W aC psus with power cords, and all necessary blank panels
eX8200-8Xs n/a 8-port 10 Gbe sFp+ line card; requires sFp+ optics sold separately
eX8200-40Xs n/a 40-port Gbe / 10Gbe line card; requires sFp and/or sFp+ optics sold separately
eX4500-40F-VC1-FB 12.1r9 40-port Gbe/10Gbe sFp/sFp+ front-to back airflow, 128 Gbps Virtual Chassis Interconnect module, hardware support for Data Center Bridging, and support for eight pFC (802.1Qbb) queues
eX4200-48p 12.1r9 48-port 10/100/1000Base-t (48 poe ports) + 930 W aC psu. Includes 50cm Virtual Chassis cable.
eX-pWr2-930-aC n/a 930 W poe+ aC power supply unit (psu)
eX3300-48p 12.1r9 eX3300 48-port 10/100/1000Base-t (48 poe+ ports) with 4 sFp+ uplink ports (optics not included)
eX3300-24p 12.1r9 eX3300 24-port 10/100/1000Base-t (24 poe+ ports) with 4 sFp+ uplink ports (optics not included)
eX3300-48t 12.1r9 eX3300 48-port 10/100/1000Base-t with 4 sFp+ uplink ports (optics not included)
eX-sFp-10Ge-DaC-1m n/a sFp+ 10-Gigabit ethernet Direct attach Copper (twinax copper cable) 1 m
srX650-Base-sre6-645ap 12.1r9 srX650 services Gateway with sre 6, 645 W aC poe psu; includes 4 onboard 10/100/1000Base-t ports, 2 GB Dram, 2 GB CF, 247 W poe power, fan tray, power cord and rack-mount kit
WlC2800* 7.7.1.6 WlaN controller with two 10Gbe XFp ports and 8 x 1000Base-t (rJ-45 and sFp) ports, including single psu and 64 ap license.
Wla532-us* n/a ap with dual radios 802.11a/b/g/n 3x3 mImO (3ss), single 1000Base-t 802.3af poe ethernet port, 6 internal antennas. Not rated for plenum use. Ceiling mount bracket included. For operation only in usa.
Wlm-rmts-10 7.7.1.3.0
*When estimating your wireless needs, 25–30 users per ap is a good place to start for most wireless deployments. For
highest performance wireless, one ap per 10–15 users is the recommended starting value.
Wired LAN Infrastructurethe example network tested is shown in Figure 1. It uses a two-tiered, collapsed core network model in each building.
this design combines the distribution and core layers together, reducing the complexity and cost of the network.
the heart of the network is the switching infrastructure. Juniper Networks eX8200 ethernet switches are used for the
campus core. the two eX8200 switches are configured as a single Virtual Chassis, which provides high availability (Ha)
and resiliency features not found in standalone chassis-based solutions. this configuration provides hardware-level
redundancy with a simplified configuration process because only one logical device needs to be configured, instead of
manually configuring and synchronizing multiple core devices.
the Juniper Networks Virtual Chassis technology reduces the number of actively managed devices and removes the
need for relying on legacy redundancy protocols, such as spanning tree protocol (stp) and Virtual router redundancy
protocol (Vrrp). Virtual Chassis also provides the flexibility to incrementally grow the network on an as-needed basis
You can configure the WlCs in clusters of up to 32 units. the design example uses a two-WlC cluster, as shown in
Figure 4. the primary WlC (also known as the primary seed controller) is in charge of configuration management for all
WlCs and aps and acts as a central configuration point for all wireless laN changes.
Each WLA forms two WLC connections — a primary WLC connection and a backupWLC connection. This provides non-stop wireless performance in case of failure.
The primary WLC is the configuration point for the network andautomatically load balances WLAs between the WLCs in the cluster.
Wireless LANController
Cluster
WLA
WLA
PrimaryWLC
SecondaryWLC
SwitchEX Series
Figure 4: WLC Clustering
the primary WlC also configures and load-balances the aps across the WlCs to distribute the wireless traffic load.
access points form connections with two separate WlCs—one connection is active, and the other acts as a backup. If
the connection to the active WlC is interrupted, the backup connection takes over immediately, preserving all existing
wireless sessions so that users are not affected.
SRX Series Service Gateway Infrastructurethe Juniper Networks srX series services Gateway is a zone-based firewall in which different traffic networks are
classified as logical zones for easier management. Figure 5 illustrates the logical zones that are defined in the tested
design and the VlaNs contained in each zone.
this illustration sets the Guest zone apart from the eX series to present a clear logical view. the eX series switches
provide only layer 2 connectivity for these zones. the Guest VlaNs use the srX series services Gateway as their
default gateway to obtain Ip addresses using DHCp.
In the examples illustrated in Figure 6, no session is reset in the case of local link failure because there is no change in
the source Nat address for the sessions—they continue to use the same service provider. Where the source address for
srX650-1b or service provider 1 is lost completely, traffic switches to service provider 2. the source Ip address for the
traffic changes when this occurs and results in existing sessions being reset due to the change.
Virtual Chassis for Collapsed Backbone Designtraditional networks achieve high availability and performance by configuring redundant devices and complex
protocols in multiple tiers that each require independent configuration, thereby increasing network complexity. this
design uses a collapsed core, a two-tier model that combines the distribution and core layers, reducing the complexity
and cost of the network. although the tiers are reduced, the network provides the redundancy benefits typically
associated with multiple-tiered designs.
a Virtual Chassis allows multiple eX series switches to act as a single device, achieving device-level redundancy
without creating loops in the network, requiring additional protocols, or tedious configuration management between
devices. all links can be fully utilized, reducing the cost associated with bandwidth upgrades and providing improved
resiliency and performance.
the core and distribution layer is commonly configured as the layer 2 and layer 3 boundary. using a Virtual Chassis in
both the core and access layer allows further simplification of the network by reducing the number of actively managed
devices.
NOTE: Juniper Virtual Chassis technology is unique in its ability to span distances of up to 40 km between devices.
multiple wiring closets—in the same or different buildings—can be easily combined to reduce the total number of
managed devices.
Subnets and VLANsIt is highly recommended that you consistently implement a VlaN and subnetting convention throughout a deployed
network to decrease network management and troubleshooting complexity. You can easily adapt the configuration
presented in this section to any network environment. the configuration matches the VlaN ID with the third octet of
the subnet used (where applicable) to simplify the network and maintain consistency. It is also recommended to leave
room between VlaN numbering to allow for future expansion and to maintain a consistent range of VlaNs for specific
functions. the network example uses the following VlaNs and addressing.
• VlaNs 8–31 are dedicated to wired data and voice. the tested design uses only four of these VlaNs, leaving plenty of
room for future expansion.
• VlaNs 32–42 are dedicated for corporate wireless data and voice access. the tested design uses only four of these
VlaNs
• VlaNs 44–59 are dedicated for network infrastructure.
- the management VlaN manages all the network devices, such as switches and routers.
- the ap VlaNs provide connectivity to the Wlas.
- the server VlaNs service network servers and applications. they are connected to the network.
- the internet_edge VlaN is where the eX8200 Virtual Chassis ethernet switch connects to the srX series services
Gateway and further out to the Internet. this is where the majority of security policies on the srX series are enforced.
• VlaN 60 is used for guest wireless access. the guest VlaN connects directly to the srX series services Gateway. the eX
series switches do not have any interfaces on the guest VlaN—it acts only as a layer 2 switch.
the network example uses private addressing, which enables flexible Ip address allocation. In this design, many of
the networks use a 24-bit subnet mask, but larger subnet masks are used for some services to reduce the number of
subnets and VlaNs to be managed and simplify configuration. larger subnets reduce the number of subnets required,
allowing more hosts to participate in each subnet.
the VlaNs are named in this order: purpose, number, and building. For example, the VlaN name “data_wired_1a”
indicates the purpose (data wired) , the number of the VlaN (1), and the building (a).
You should also reserve some addresses on each subnet for networking devices, typically the first or last few addresses
in a subnet. this design reserves the first 10 Ip addresses of the subnet for network devices and the last Ip address
(.254) for the srX series interface if it resides on a subnet.
tables 2 and 3 map the VlaNs IDs and subnets that are configured on each device. the core switches are configured to
support all VlaNs pertinent to their building. each access switch is configured with its management VlaN address.
32 data_wireless_1a 10.10.32.0/22 Ip VlaN VlaN VlaN VlaN
40 voip_wireless_1a 10.10.40.0/23 Ip VlaN VlaN VlaN VlaN
51 management_1a 10.10.51.0/24 Ip Ip Ip Ip
54 access_points_1a 10.10.54.0/24 Ip VlaN VlaN VlaN Ip
Table 5: Building B VLAN and Device Map
Building B Device and VLAN Map
VLAN ID VLAN Name Subnet EX8200-
VC-1bEX6200
-1b WLC SRX WLA
8 data_wired_1b 10.10.8.0/22 Ip VlaN
24 voip_wired_1b 10.10.24.0/22 Ip VlaN
36 data_wireless_1b 10.10.36.0/22 Ip VlaN VlaN
42 voip_wireless_1b 10.10.42.0/23 Ip VlaN VlaN
44 internet_edge 10.10.44.0/24 Ip Ip
46 servers_1b 10.10.46.0/24 Ip
48 servers_2b 10.10.48.0/24 Ip
50 management_1b 10.10.50.0/24 Ip Ip Ip Ip
52 access_points_1b 10.10.52.0/24 Ip VlaN Ip
60 guest_wireless 10.10.60.0/24 VlaN Ip Ip
Class of Service and Quality of Servicethis section provides a high-level description of the most commonly used Juniper quality of service (Qos) and class of
service (Cos) items. Not all of these are used in the network example. they are listed here to provide a comprehensive
picture of the options available.
For the purposes of this guide, Qos is the manipulation of aggregates of traffic so that each is forwarded in a fashion
that is consistent with the required behaviors of the applications generating that traffic. From a user’s point of view,
Qos is experienced on the end-to-end (usually round trip) flow of traffic. It is implemented as a set of behaviors at
each hop. this is an important distinction. Basically, a single hop with no configured Qos can destroy the end-to-end
experience, and subsequent nodes can do nothing to recover the end-to-end quality of experience for the user. that
does not mean that Qos must be configured at every hop. However, it is critical to understand that a single, congested
hop can be the undoing of the most intricate Qos design.
On the other hand, Cos within the Junos Os is a configuration construct used to configure an individual node to
implement certain behaviors at that node so that the end-to-end Qos is consistent with the desired end-to-end user
experience or application behavior.
each class is associated with an aggregate of traffic that requires the same behaviors as it flows through the network
device. Classes do not relate implicitly to traffic belonging to a single application. Instead, any application requiring the
same behaviors generates traffic belonging to the same class.
each Cos implementation has certain functions that are required to be able to influence the behavior of outbound
packets on a particular interface. In the network example, only some of the Qos and Cos methods are used. For more
information on these methods, see Deploying Basic QoS or Juniper technical documentation.
NOTE: each vendor’s networking equipment implements the control of these functions in different ways and might use
slightly different terminology. the terminology in this guide is used in Junos Os configurations. the explanations are
vendor-agnostic to be broadly applicable to different vendors’ equipment.
Forwarding Classa forwarding class is a label used entirely within a network node. It identifies all traffic that requires a single behavior
when leaving that node. a forwarding class does not explicitly appear outside a node. although if the Qos configuration
of all nodes in a network is consistent, it can easily be derived from information in packet headers.
ClassificationClassification identifies the class to which a packet belongs. Classification is usually initially performed on ingress
to each node, although a packet can be reclassified at various points on its path through a network node. Junos Os
has three main approaches to classifying packets, which vary in their degree of flexibility and in the complexity of
the required configuration: interface-based, behavior aggregate (Ba), and multifield (mF). these approaches are not
mutually exclusive and can be applied in a series to get a less granular first-pass behavior, followed by a more granular
reclassification of a subset of the traffic.
Interface-based ClassificationIf all traffic arriving on a single interface is known to be associated with a single class, the easiest way to classify this
traffic is to associate all traffic arriving on the interface with the relevant forwarding class. While trivial to implement,
this method assumes that all traffic arriving on the interface is of the same class. there is no inherent mechanism
to indicate any exceptions, so it is very inflexible. You can use interface-based classification in conjunction with mF
classifiers to provide more granular exceptions to the default interface classification, if required.
TIP: this mechanism is useful if the upstream node is untrusted and you want to bleach all traffic coming in by
applying a single class (usually Best effort).
Behavior Aggregate ClassificationBa classification provides a good balance between flexibility and complexity. this approach is particularly attractive
when the traffic being classified is transported in large aggregates, for example, in the core of a network where
traffic associated with many unique applications passes over a single link, making mF classification unattractive. Ba
classification relies on markings placed in the headers of incoming packets: ethernet frames, Ipv4 or Ipv6 packets,
or mpls frames. each of these packet or frame types includes a field in the header specifically designated for the
indication of a class to which this packet has been previously assigned.
ethernet 802.1Q VlaN frames include three 802.1p bits to indicate previous assignment. Ipv4 packets have the type
of service byte from which you can use either the three precedence bits or 6 bits to indicate the Diffserve Code point
(DsCp). Ipv6 has 6 bits of the Ipv6 DsCp, and mpls has the three experimental bits. the network example uses the
DsCp marking and Ba classification method.
the main constraint with this model is that the upstream node must be trusted to correctly (and fairly) mark packets.
If the upstream node cannot be trusted, the node could mismark traffic into a class that receives a higher Qos than it
requires.
Multifield Classificationthe most flexible but most complex classification to configure and maintain is mF classification. It uses firewall filters,
also known as access lists, to identify arbitrary attributes of an Ip packet—it is less commonly applicable to non-Ip
traffic types—and places traffic into a particular traffic class based on the contents of the Ip packet.
this approach is constrained only by the characteristics that can be matched in a firewall filter. It is possible to be very
granular in the choice of traffic class to which the packet belongs. However, granular choices require comparatively
complex filters, which might have to be customer-specific. this degree of complexity and administrative overhead
makes using mF classifiers attractive when the upstream node is not trusted (or not able) to mark the packets, and the
requirement to apply Qos based on arbitrary parameters is strong.
mF classifiers can also be used to modify the forwarding class selected by a Ba or interface classifier. You make a
rough classification based on a Ba or interface marking and then reclassify a subset of the traffic based on arbitrary
attributes in the Ip headers. the network example does not use mF classification, but it can be easily added to the
network.
Policingpolicing applies a hard limit to the rate at which traffic can access a resource (for example, upon ingress to a node or
to a queue on egress). a policer constrains access to the node or queue. If a packet is determined to be nonconforming
and should not gain access to the protected resource, it is dropped or reclassified. the hard-drop behavior can have a
negative impact, particularly on tCp traffic and when the policer is run consistently at its limit. While it is possible to
reclassify packets based on a policer, it is important to avoid reordering packets in applications that are sensitive to the
order in which packets are received, such as voice, video, and other real-time traffic. the example does not use policing.
Random Early Detection and Congestion Avoidancerandom early detection (reD), also known as random early discard, is a congestion avoidance mechanism. It helps
mitigate the impact of congestion, specifically with tCp-based traffic. For a thorough review of the behavior of tCp in
the presence of congestion and why reD can help avoid some of the worst aspects of that behavior, see QoS Enabled Networks: Tools and Foundations, by peter lundqvist and miguel Barreiros, (2011, John Wiley & sons).
By selecting random tCp packets from a queue and discarding them, the endpoint that was awaiting delivery of that
packet fails to send an acknowledgement for the packet (or, if that packet was an acknowledgement, the far end does
not receive the acknowledgement). this triggers retransmission of the packet and reduces the transmission window
size. as a consequence, it also reduces the speed with which the source transmits tCp packets, thereby reducing the
degree of congestion. the random nature of selecting packets to be dropped ensures that no single flow of traffic,
application, or source is unfairly penalized, and every source continues to get its “fair share” of the available capacity on
a link that is close to congestion.
although the mechanism is “fair” to all, Qos is not necessarily about being fair to all. rather, Qos is about ensuring that
high-priority traffic—high value or sensitive to loss, latency, or jitter—is given priority. to manipulate the rate at which
packets belonging to particular forwarding classes are dropped, it is necessary to apply a weight to each forwarding
class. this process is known as weighted reD (WreD). It is particularly important to apply a weight to avoid dropping
packets in forwarding classes that are intolerant of loss, such as expedited forwarding and assured forwarding.
Often, the traffic associated with applications that are intolerant of loss, latency, and jitter is transported in uDp. In this
case, using reD is counterproductive because it damages the perceived Qos of the application. In addition, because
uDp has no built-in mechanism to identify the loss of a packet and modify its rate of transmission, the packet is either
lost (reducing the perceived Qos) without having significant impact on the throughput, or worse, the application
identifies the loss and demands retransmission of the packet, so the packet is then seen twice, potentially increasing
the congestion. the network example does not use WreD.
Shapingshaping limits the rate at which traffic can be transmitted. unlike policing, it acts on traffic that has already been
granted access to a queue but is awaiting access to transmission resources. traffic that does not conform to the
shaper’s criteria is held in the queue until it does conform. No explicit constraint is placed on more traffic entering
the queue, as long as the queue is not full. shaping can be less aggressive than policing and have fewer negative side
effects.
Schedulingscheduling decides the order in which to place packets onto the wire based on the class to which they belong or the
queue in which they are waiting. there are multiple queues, all of which may contain packets waiting to be transmitted,
but only a single serial transmission medium is available. the configuration must designate which queue to service first,
for how long, and with what frequency.
Remarkingethernet, mpls, Ipv4, and Ipv6 packets all have a field in the header that can be used to inform another node about a
classification decision made earlier in the path. remarking places a value in the header of an outgoing packet, which
identifies the class to which the packet was assigned by the transmitting router. subsequent nodes can use this
marking to easily and consistently classify the packet using a Ba classifier. It is possible to remark each packet header
type using each marking type (Ieee 802.1p, mpls eXp, Ipv4 precedence, Ipv4 DsCp, or Ipv6 DsCp) that can be used by
Ba classifiers.
Class of Service Used in Design Examplethe network example addresses a primarily unicast environment with little to no multicast. If multicast is present, it is
treated as best effort. If more multicast handling is required, additional queues can be configured to properly manage
that traffic, but it is outside the scope of this document. For more information, see Enabling Class of Service on EX Series Switches in a Campus LAN or Juniper technical documentation.
table 6 shows the Cos settings used in the network example. Depending on the role the device plays in the network,
different features are enabled. For example, on the access devices, traffic is classified and remarked if needed. It is
assumed that remarking has already occurred at the access layer devices, so it is not required on the core devices.
the example uses the Ba classification method, which assumes that traffic is being properly classified by the hosts
or application before entering the switch. this type of deployment is considered a trusted environment. If the network
hosts do not mark traffic, you can configure the access layer to use mF classification instead, which allows for flexible
identification and classification of almost any traffic type.
Device Role Classification Congestion Management Scheduling Rate Shaping Remarking
Core Ba - X X X
access Ba - X X X
table 7 lists the queues and forwarding classes used in the network example. traffic is classified by DsCp marking
on the received packets. We have identified several DsCp classifiers and assigned them to queues. additional DsCp
classifiers can be assigned to these queues and is described in the configuration section.
Table 7: CoS Forwarding Classes Used
Forwarding Class Queue # DSCP Buffer Transmit Rate Rate Shaping
control 7NC1/Cs6NC2/Cs7
5% n/a 5%
voice 5 eF 5% n/a 5%
business-app 3 aF21 40% 40% n/a
server-bulk 1 aF11 30% 30% n/a
best-effort 0 n/a remainder remainder n/a
NOTE: eX series switches require a scheduler for every queue used. Queues without a scheduler are not serviced.
eX series switches support eight queues. the tested network example uses five queues. the remaining three queues
can be configured at a later time if additional granularity is needed. It is typically easier to use fewer queues than trying
to define a queue for each application type.
Implementationeach deployment section provides step-by-step processes to set up the network components. each section is
independent. although they can be configured in any order, they are presented in a logical chronology in which each
section builds on the previous one. When deploying a new network, we recommend that you follow the order outlined
here. as you progress through the deployment sections, the diagrams indicate the components being configured. the
“You are here” labels point to where you are in the configuration process.
Wired LAN DeploymentBuilding B: Configuring the Campus Corethe core switch, as shown in Figure 7, connects all networking components together. In this network, it is responsible
for routing all traffic on the intranet, and it is the default gateway for all user networks in Building B, except the Guest
network wireless traffic. Guest access is routed directly to the srX series to maintain clear separation between the
guest and user network traffic. the WlCs, srX series, and network servers and services are also connected directly to
EX8200 Virtual Chassis Configurationthe eX8200 Virtual Chassis consists of two eX8200 chassis and two Xres. Because the eX8200 Virtual Chassis has
several components and can be configured in multiple ways, we suggest reading the Best Practice Guidelines for Deploying EX8200 Virtual Chassis Configurations or Appendix B: EX8200 Virtual Chassis Overview for the available
options and features. this guide steps through the required items for configuring the eX8200 in a Full mesh Fabric
the network example assumes that all eX8200s and Xres are running the default configuration as a starting point.
Procedure overview 1. upgrade all Xre200s and eX8200s to the same version of the Juniper Networks Junos® operating system.
2. Configure global configuration items.
3. Configure the Virtual Chassis.
4. Configure layer 2 settings.
5. Configure layer 3 settings.
6. Configure Cos.
Verifying and Upgrading the Software Version for XRE200the Os version used for the tested network is Junos Os 12.1r9, available at www.Juniper.net/support. all Xre200
routing engines must be running the same version.
1. unpack the Xres.
2. Connect to the Xre Console port (setting: s9600, 8, 1, none).
3. press enter. the following prompt appears.
Amnesiac (ttyu0)login
4. log in as root and press enter.
Because no password is configured, you are not prompted for one.
login: rootLogging to master.– – – JUNOS 11.4R1.6 built 2011-11-15 11:14:01 UTCroot@:RE:0%
5. Verify that the Xre is running the correct Os version (12.1r9 for this validation). If the version is correct, verify the next
Verifying and Upgrading the Software Version for EX8200the tested network example assumes that each eX8200 has dual routing engines. You must verify, and possibly
upgrade, the software for each routing engine. the Os version used for the tested network is Junos Os 12.1r9, available
at www.juniper.net/support. all eX8200 routing engines must be running the same version. perform the following for
routing engine 0 and routing engine 1.
Connect to the Console port of EX8200 routing engine 0 (Setting: s9600, 8, 1, none).press enter. the following prompt appears.
Amnesiac (ttyu0)login
Log in as root and press Enter.Because no password is configured, you are not prompted for one.
login: rootLogging to master.– – – JUNOS 12.1R9 built 2011-11-15 11:14:01 UTCroot@:RE:0%root@:RE:0%
Verify that routing engine 0 is running the correct Os version. If the version is correct, verify the routing engine 1 by
repeating steps 1–3.
Type cli at the % prompt.
root@:RE:0% cli{master:0}root>
Enter configuration mode by typing configure or edit.
Configuring the EX8200 for Virtual ChassisOn the master routing engine of the first EX8200, connect to the console port (Setting: s9600, 8, 1, none).
Log in as root and enable edit mode.
root@ex8200> edit
Enable graceful switchover, nonstop routing, and nonstop bridging.
root# set chassis redundancy graceful-switchoverset system commit synchronizeset routing-options nonstop-routingset ethernet-switching-options nonstop-bridging commit and-quit
Configure resilient dual-boot partitions.this step is highly recommended because it improves the resiliency of the system in case of a primary boot partition
failure. It creates a backup copy of the Os. the process takes approximately 5 minutes for each routing engine or
member.
request system snapshot slice alternate all-members
Configure the EX8200 for Virtual Chassis.
root@ex8200> set chassis virtual-chassis This will reboot the RE(s)Do you want to continue ? [yes, no] yes
Verify that the EX8200 has booted back up in Virtual Chassis mode.after you log in to the eX8200 and type cli, you should see this:
root@:RE:0% cliwarning: This chassis is operating in a non-master role as part of a virtual-chassis (VC) system.warning: Use of interactive commands should be limited to debugging and VC Port operations.warning: Full CLI access is provided by the Virtual Chassis Master (VC-M) chassis.warning: The VC-M can be identified through the show virtual-chassis status command executed at this console.warning: Please logout and log into the VC-M to use CLI.{master:0}
You can also verify the mode using the show virtual-chassis status command.
the following example shows that Virtual Chassis mode is enabled.
{master:0}root> show virtual-chassis status
Virtual Chassis ID: 5ddf.6b28.132fVirtual Chassis Mode: Enabled Mastership Neighbor ListMember ID Status Serial No Model priority Role ID Interface0 (FPC 0-15) Prsnt BT0910434033 ex8208 0 Linecard*
Repeat these steps for the second EX8200 Virtual Chassis.
Preprovisioning the XRE200 for Virtual ChassisIt is important to understand the numbering of Virtual Chassis members before continuing with the configuration. the
member details are shown in Figure 10. the following eX8200 Virtual Chassis numbering is used:
• primary Xre200 is member 8
• Backup Xre200 is member 9
• eX8200 Virtual Chassis are member 0 and member 1.
1. Identify the serial number for each component of the Virtual Chassis (Xre200 and eX8200 chassis serial numbers) and
determine the member ID for each device.
2. log in to the Xre that is used as the master Xre and enable edit mode.
root@ex8200> edit
3. preprovision the chassis. Only preprovisioned eX8200 Virtual Chassis are supported.
4. the Xres are configured as routing engines, and the eX8200s are configured as line cards. Note which member ID each
device is assigned, because you need that information when configuring the chassis later.
root#set virtual-chassis preprovisionedset virtual-chassis member 8 role routing-engineset virtual-chassis member 8 serial-number 042011000023set virtual-chassis member 9 role routing-engineset virtual-chassis member 9 serial-number 042011000036set virtual-chassis member 0 role line-cardset virtual-chassis member 0 serial-number BT0910433933set virtual-chassis member 1 role line-cardset virtual-chassis member 1 serial-number BT0910434033
NOTE: split-detection is enabled by default. However, all devices in the test network are located in the same room and
have many redundant connections, so an accidental chassis split is highly unlikely. But because this is the network core,
we recommend leaving split-detection enabled. If you want to disable split-detection, use the set virtual-chassis no-
split-detection command. If you are not familiar with how split-detection works, review the split-detection section in
Configuring Virtual Chassis Ports on the EX8200Only line-rate 10Gbe ports on the eX8200-8Xs line card support VCps. the 10Gbe network ports are converted to
VCps in pairs. For example, interfaces xe-0/0/0 and xe-0/0/1 are both converted to VCps, even though the ClI request
is to convert only one of them. VCps for both eX8200 Virtual Chassis members are configured from the master
Xre200 operational mode.
these are operational commands and are not entered in edit mode. these commands do not appear in the
configuration of the device. the port configurations are specific to each eX8200 chassis and do not reflect the Virtual
Chassis port numbering. For example, eX8200-2b, as part of a Virtual Chassis, uses slots 16–31 when configuring
ports in normal operation. However, because VCps are special, they are configured as their native port designations. to
configure port xe-0/0/6 as a VCp on eX8200-2b, type the following command:
request virtual-chassis vc-port set fpc-slot 0 pic-slot 0 port 6 member 1
We use six ports: xe-0/0/6, xe- 0/0/7, xe-1/0/6, xe-1/0/7, xe-2/0/6, and xe-2/0/7. You only need to configure the first
port in each pair.
Configure the VCPs for EX8200-1b.
root>request virtual-chassis vc-port set fpc-slot 0 pic-slot 0 port 6 member 0member0:--------------------------------------------------------------------------This will also convert FPC slot 0 PIC slot 0 Port 7 to virtual chassis port.
root> request virtual-chassis vc-port set fpc-slot 1 pic-slot 0 port 6 member 0member0:--------------------------------------------------------------------------This will also convert FPC slot 1 PIC slot 0 Port 7 to virtual chassis port.root> request virtual-chassis vc-port set fpc-slot 2 pic-slot 0 port 6 member 0member0:--------------------------------------------------------------------------This will also convert FPC slot 2 PIC slot 0 Port 7 to virtual chassis port.
Configure the VCPs for EX8200-2b.
root> request virtual-chassis vc-port set fpc-slot 2 pic-slot 0 port 6 member 1member1:--------------------------------------------------------------------------This will also convert FPC slot 2 PIC slot 0 Port 7 to virtual chassis port.root>
request virtual-chassis vc-port set fpc-slot 0 pic-slot 0 port 6 member 1member0:--------------------------------------------------------------------------This will also convert FPC slot 0 PIC slot 0 Port 7 to virtual chassis port.
root> request virtual-chassis vc-port set fpc-slot 1 pic-slot 0 port 6 member 1member0:--------------------------------------------------------------------------This will also convert FPC slot 1 PIC slot 0 Port 7 to virtual chassis port.
Connect all six ports together to create a highly resilient LAG connection between the EX8200 chassis, which will be spread across three separate cards in each chassis .
Connect the EX8200s together using the six ports.Verify that the VCps on the eX8200s came up correctly.
{master:8}root> show virtual-chassis vc-portmember0:--------------------------------------------------------------------------Interface Type Trunk Status Speed Neighboror ID (mbps) ID InterfaceSlot/PIC/Portvcp-0/0 Dedicated -1 Up 1000 8 vcp-1/0vcp-0/1 Dedicated -1 Up 1000 9 vcp-1/00/0/6 Configured 3 Up 10000 1 vcp-0/0/60/0/7 Configured 3 Up 10000 1 vcp-0/0/71/0/6 Configured 3 Up 10000 1 vcp-1/0/61/0/7 Configured 3 Up 10000 1 vcp-1/0/72/0/6 Configured 3 Up 10000 1 vcp-2/0/62/0/7 Configured 3 Up 10000 1 vcp-2/0/7
member1:--------------------------------------------------------------------------Interface Type Trunk Status Speed Neighboror ID (mbps) ID InterfaceSlot/PIC/Portvcp-0/0 Dedicated -1 Up 1000 8 vcp-1/1vcp-0/1 Dedicated -1 Up 1000 9 vcp-1/10/0/6 Configured 3 Up 10000 0 vcp-0/0/60/0/7 Configured 3 Up 10000 0 vcp-0/0/71/0/6 Configured 3 Up 10000 0 vcp-1/0/61/0/7 Configured 3 Up 10000 0 vcp-1/0/72/0/6 Configured 3 Up 10000 0 vcp-2/0/62/0/7 Configured 3 Up 10000 0 vcp-2/0/7
NOTE: Only the eX8200 is shown for brevity.
Configure graceful switchover and nonstop routing.
root# set chassis redundancy graceful-switchoverset system commit synchronizeset routing-options nonstop-routingset ethernet-switching-options nonstop-bridgingcommit and-quit
use the following commands to view the status of the Virtual Chassis:
show virtual-chassis
show virtual-chassis vc-port
this completes the setup of the basic eX8200 Virtual Chassis. Now it’s time to configure it.
Configuring Global Settings for the Core EX8200 Virtual Chassis SwitchConnect to the Console port of the Master XRE200 and login (Setting: s9600, 8, 1, none). Note the version of Junos at the prompt and update as needed.
login: rootLogging to master.– – – JUNOS 12.1R9 built 2011-11-15 11:14:01 UTCroot@:RE:0%
Type cli at the % prompt.
root@:RE:0% cli{master:0}root>
You should now be at the >prompt.
Configure the date and time in the format: YYYYMMDDhhmm.ss.
set date 201210220830.00
Enter configuration mode by typing configure or edit.
You should now be at the # prompt and ready to start configuring the switch.
Configure the time zone.
root# set system time-zone America/Los_Angeles
Configure the hostname.
root# set system host-name EX8200VC-1b
Configure the management interfaces on the XREs.
EX8200VC-1b#set groups member8 interfaces me0 unit 0 family inet address <IP address/mask>set groups member9 interfaces me0 unit 0 family inet address <IP address/mask>set apply-groups member8set apply-groups member9
Configure management access.
root@EX8200VC-1b# set system services web-management https system-generated-certificateset system services sshdelete system services web-management httpdelete system services telnet
Configure DNS.
root@EX8200VC-1b# set system name-server 10.10.46.100set system domain-name xyzcompany.com
Configuring Layer 2 Settings on EX8200 Virtual Chassis Core Switchto configure layer 2 parameters and settings on the core switch:
Set the bridge priority on the core switch.NOTE: spanning tree protocol is enabled to prevent loops from forming in the network, even though we do not use it as
a topology protocol. as an extra precaution, we set the bridge priority on the core switch to 8192, which ensures that it
is the default root bridge in the event another bridging device is connected to the network. Juniper Networks eX series
switches run rstp by default.
root@EX8200VC-1b# set protocols rstp bridge-priority 8k
commit
Configure VLANs and IP interfaces.NOTE: We configure all of the inter-VlaN routing on the core switch, except for our guest VlaN. this makes it easier to
simultaneously configure the VlaNs and Ip interfaces for those VlaNs. When creating VlaN names, it is important to
note that these names are case sensitive.
In our examples you may notice that the VlaN ID is the same as the interface VlaN unit number. this is not mandatory,
but we recommend that you match the VlaN ID and interface VlaN unit number. this helps to make things easier to
understand later when you have many VlaNs and interfaces to track.
NOTE: When you issue a large number of commands at once, it is recommended that you issue a commit command to
verify that the commands take effect with no configuration errors. alternatively, a commit check can be issued instead,
which verifies the configuration without making it active.
the complete set of VlaN and layer 3 interface statements for the core switch in the tested network example follows.
We also add the guest VlaN here, but we do not assign any layer 3 interfaces to this VlaN, because routing for the
root@EX8200VC-1b# set interfaces vlan unit 8 family inet address 10.10.8.1/22set interfaces vlan unit 20 family inet address 10.10.20.1/22set interfaces vlan unit 32 family inet address 10.10.32.1/22set interfaces vlan unit 40 family inet address 10.10.40.1/23set interfaces vlan unit 44 family inet address 10.10.44.1/24set interfaces vlan unit 46 family inet address 10.10.46.1/24set interfaces vlan unit 48 family inet address 10.10.48.1/24set interfaces vlan unit 50 family inet address 10.10.50.1/24set interfaces vlan unit 52 family inet address 10.10.52.1/24
the interface configuration for laG ae1 which connects to eX4500VC-1a is layer 3 interface and communicates routing
information using the OspF protocol. We will configure the laG for this in the next section.
root@EX8200VC-1b# set interfaces ae1 unit 0 family inet address 10.10.200.1/24commit
Configure LAG (aggregated Ethernet) portsIn the tested network configuration, the laG ports configured will be used to connect to the eX6200 series access
switches and for the inter-building connection to the eX4500VC-1a core chassis for building a.
Junos Os requires that you configure the number of laG interfaces you want to use before you begin configuring
the interfaces. We suggest picking a number slightly larger than you might need, in case you need to add more laG
interfaces later. You can change this value in the future. We need two aggregated ethernet ports for the tested network
example, but most deployments would have more than a single eX6200 so we will configure the core chassis with
eight, allowing us to add additional devices later without having to adjust this.
Disable RSTP on LAG connections to access switches.
Because we are not using stp, we can disable it on the laG ports going to our access switches. this also reduces
potential convergence times in case a laG member fails, because fewer protocols need to converge.
NOTE: all access switches have rstp enabled locally to prevent looping.
root@EX8200VC-1b# set protocols rstp interface ae0.0 disable
commit
Configure trunk, access and VLAN settings for LAGs.We need to configure the laG ports as trunks and add the VlaNs that will be supported on the individual access
switches. after setting the trunks, commit the configuration.
root@EX8200VC-1b# set interfaces ae0 unit 0 family ethernet-switching port-mode trunk
commit
Configure VLANs on the trunk ports.You can configure port-to-VlaN mapping in two different ways:
• You can configure the VlaNs directly as part of the port configuration.
• You can configure the ports included in the VlaN under the VlaN configuration.
each of these has different advantages and disadvantages. Generally, it makes sense to configure access ports (client-
facing) under the VlaN configuration and configure VlaNs directly on the port for trunk port configuration. You cannot
configure the VlaN mapping in both places, because that might result in errors when doing a configuration commit
operation.
as discussed, it is recommended to configure the VlaNs that the trunk port will carry directly on the interface
configuration section. this simplifies identifying what VlaNs a specific trunk is part of when viewing the configuration.
When adding VlaNs directly to a trunk port you have the option of adding them by their VlaN ID or by the VlaN name.
In this example, we will add them by VlaN name; this makes the overall configuration more readable.
to add several VlaNs to a trunk, you can either specify them one at a time or you can specify several VlaNs at the
same time by enclosing them in [] brackets and separating them with spaces.
The VLAN configuration for ae0 connecting to EX6200-1b
root@EX8200VC-1b# set interfaces ae0 unit 0 family ethernet-switching vlan members [ data_wired_1b voip_wired_1b data_wireless_1b voip_wireless_1b access_points_1b management ]
or you can enter it one line at a time
set interfaces ae0 unit 0 family ethernet-switching vlan members data_wired_1bset interfaces ae0 unit 0 family ethernet-switching vlan members voip_wired_1bset interfaces ae0 unit 0 family ethernet-switching vlan members data_wireless_1bset interfaces ae0 unit 0 family ethernet-switching vlan members voip_wireless_1bset interfaces ae0 unit 0 family ethernet-switching vlan members access_points_1bset interfaces ae0 unit 0 family ethernet-switching vlan members management_1b
Configure dual-homed or other network device connections.Configuring connections for other devices that are dual homed (but do not use laG connections or other network
equipment) typically involves connections to the core and trunk ports. In the tested network, the srX series and
wireless laN controllers both use clustering technologies to provide High availability, In this case they are not
configured with laG connections to the core. each of these devices requires two identical port configurations on
separate eX series switches to provide link-level and box-level redundancy.
Configure Wireless LAN controllers.Connect wireless laN controllers (WlCs) to ports ge-4/0/0 and ge-20/0/0 and add them to the following VlaNs:
management, and guest_wireless.
root@EX8200VC-1b# set interfaces ge-4/0/0 unit 0 family ethernet-switching port-mode trunkset interfaces ge-4/0/0 unit 0 family ethernet-switching vlan members management_1bset interfaces ge-4/0/0 unit 0 family ethernet-switching vlan members guest_wirelessset interfaces ge-20/0/0 unit 0 family ethernet-switching port-mode trunkset interfaces ge-20/0/0 unit 0 family ethernet-switching vlan members management_1bset interfaces ge-20/0/0 unit 0 family ethernet-switching vlan members guest_wireless
Configure SRX Firewalls.Connect the srX firewalls to ports ge-2/0/47 and ge-3/0/47 and make them part of the following VlaNs: Internet_
edge, management, Guest_Wired and Guest_Wireless.
root@EX8200VC-1b# set interfaces ge-4/0/1 unit 0 family ethernet-switching port-mode trunkset interfaces ge-4/0/1 unit 0 family ethernet-switching vlan members internet_edgeset interfaces ge-4/0/1 unit 0 family ethernet-switching vlan members management_1bset interfaces ge-4/0/1 unit 0 family ethernet-switching vlan members guest_wireless
set interfaces ge-20/0/1 unit 0 family ethernet-switching port-mode trunkset interfaces ge-20/0/1 unit 0 family ethernet-switching vlan members internet_edgeset interfaces ge-20/0/1 unit 0 family ethernet-switching vlan members management_1bset interfaces ge-20/0/1 unit 0 family ethernet-switching vlan members guest_wireless
Commit the configuration.
commit
Configure the server port.
server ports are typically configured as access ports that have a single VlaN. In the tested network example, we have a
few VlaNs where servers would typically reside. to configure a server port that is part of a single VlaN, it must first be
configured as an access port.
Set port into access mode:
root@EX8200VC-1b# set interfaces ge-4/0/44 unit 0 family ethernet-switching port-mode access
assign the port to a VlaN. as a general rule, we assign access ports under the VlaN configuration instead of the port
configuration, but either can be used. In this case we need to assign the server port to the VlaN servers.
root@EX8200VC-1b# set vlans server_1b interface ge-4/0/44
In some cases it may make more sense to assign the VlaN directly in the port configuration because servers are
different from a standard network host.
Configure server port in trunk mode.some servers reside on more than one VlaN and require a trunk port. In this case, configure the port for trunking and
assign the VlaNs it should belong to directly in the port configuration as we did for the laG ports. Below is an example
of an interface configured as a trunk that belongs to the VlaNs server_1b and management_1b. You can also review the
earlier trunk configuration sections discussing configuration of ports for WlC and srX devices.
root@ EX8200VC-1b# set interfaces <interface> unit 0 family ethernet-switching port-mode trunkset interfaces <interface> unit 0 family ethernet-switching vlan members [servers_1b management_1b]
Configure Class of Servicethe basic Cos configuration is almost identical across core and access platforms in the network example. We will
configure Cos on the core eX8200 Virtual Chassis. the configuration defines the Cos service and then applies it to
specific interfaces.
Configuring forwarding classesFirst we will configure the forwarding classes; this step also defines what queues are used as well.
root@EX8200VC-1b# set class-of-service forwarding-classes class control queue-num 7set class-of-service forwarding-classes class voice queue-num 5set class-of-service forwarding-classes class business-app queue-num 3set class-of-service forwarding-classes class server-bulk queue-num 1set class-of-service forwarding-classes class best-effort queue-num 0
Configuring classifiersNext we will create the classifiers. In the tested network example we are only using DsCp marking for our classification
of traffic. the classifiers map the different DsCp marked packets to the correct queue – if the traffic is not marked or
marked with a DsCp value it will be considered best-effort traffic and treated accordingly.
You should now be at the # prompt and ready to start configuring the switch.
Configure the password.
root# set system root-authentication plain-text-passwordNew password:*******Retype new password:*******{master:0}[edit]root#
Configure the management (me0) interface.
root# set interfaces me0 unit 0 family inet address <IP address/mask>commit and-quit
Connect the me0 interface to the network and upgrade the XRE. the following line will Ftp the code to the system and then reboot it running the new code.
root> request system software add ftp://anonymous@<IP_address>/<code_version> reboot
Configure the management and VME interface (optional).
root@EX6200-1b# set interfaces vme unit 0 family inet address <IP address/mask>
Configure management access.
root@EX6200-1b# set system services web-management https system-generated-certificateset system services sshdelete system services web-management httpdelete system services telnet
Configure DNS.
root@EX6200-1b# set system name-server 10.10.46.100set system domain-name xyzcompany.com
Configure NTP.
root@EX6200-1b#set system ntp server 10.10.46.100
Configuring the EX6200 ChassisConfigure global Virtual Chassis commands.
root@EX6200-1b# set system commit synchronizeset ethernet-switching-options nonstop-bridgingset chassis redundancy graceful-switchover
Commit the configuration.
root@EX6200-1b# commit
Configure resilient dual-boot partitions.NOTE: It is important to run this step as it improves the resiliency of the system in the case of primary boot partition
failure. this step creates a backup copy of the operating system and is highly recommended. this process takes
approximately 5 minutes for each re or member.
request system snapshot slice alternate re0request system snapshot slice alternate re1
Configure default settings.the following commands show items that should be enabled by default in the configuration. You may wish to review
and verify that these setting are desired for your specific network.
Configure interfaces.We need to configure one Ip interface on the management VlaN.
root@EX6200-1b# set interfaces vlan unit 50 family inet address 10.10.50.10/24
Configure LAG (aggregated Ethernet) ports.the eX6200-1 chassis has only one laG port configured to connect to the eX8200VC core switch. Junos Os requires
that you configure the number of laG interfaces you want to use before you begin configuring the laG interfaces. We
suggest picking a number slightly larger than what you need in case you add more laG interfaces later. You can change
this value in the future.
Because we need one laG interface for this configuration, we will configure the eX6200-1b chassis with two in case we
add another laG connection later.
root@EX6200-1b# set chassis aggregated-devices ethernet device-count 2
the 10-Gigabit ethernet ports on the eX6200 are only available on the route-engines themselves at this time. each
routing-engine has four 10Gbe ports. the port designations for routing-engine 0 are xe-4/0/0 through 4/0/3 and
for routing-engine 1 xe-5/0/0 through 5/0/3. the routing-engines can only be inserted in slots 4 or 5 so the starting
interface slot numbers will always be 4 or 5.
In the tested network example we will use four ports to create the laG xe-4/0/0, xe-4/0/1, xe-5/0/0 and xe-5/0/1
NOTE: If there are pre-existing configurations on the interfaces required for laG ports they must be removed prior to
laG configuration. a new eX6200 chassis has no port configuration by default, so we can move directly to configuring
Disable RSTP on LAG connections to access switches.Because we do not use rstp as a topology protocol, we can disable it on the laG ports going to our access switches.
Disabling rstp also reduces potential convergence times in case a laG member fails, because fewer protocols need to
converge.
NOTE: Note all access switches have rstp enabled locally for loop protection.
root@EX6200-1b# set protocols rstp interface ae0.0 disable
Configure the trunk port and VLAN.Next, we need to configure the laG port as a trunk and add the VlaNs that will be supported going to the core switch.
to enable the laG port as a trunk port, use the set interfaces command.
root@EX6200-1b# set interfaces ae0 unit 0 family ethernet-switching port-mode trunk
Configure VLANs on trunk ports.
Table 9: EX6200 Trunked VLANs
LAG Ports to device to port Trunk/Access VLANs Native VLAN
root@EX6200-1b#set interfaces ae0 unit 0 family ethernet-switching vlan members access_points_1bset interfaces ae0 unit 0 family ethernet-switching vlan members data_wired_1bset interfaces ae0 unit 0 family ethernet-switching vlan members data_wireless_1bset interfaces ae0 unit 0 family ethernet-switching vlan members voip_wired_1bset interfaces ae0 unit 0 family ethernet-switching vlan members voip_wireless_1bset interfaces ae0 unit 0 family ethernet-switching vlan members management_1b
Connect the LAG connections to the core switch using the show lldp neighbors command to verify that the connection is up and you can see the other side of the connection.
root@EX6200-1> show lldp neighborsLocal Interface Parent Interface Chassis Id Port info System Namexe-5/0/0.0 ae0.0 28:c0:da:ba:90:00 xe-1/0/5.0 EX8200VC-1bxe-5/0/1.0 ae0.0 28:c0:da:ba:90:00 xe-17/0/5.0 EX8200VC-1bxe-4/0/0.0 ae0.0 28:c0:da:ba:90:00 xe-1/0/4.0 EX8200VC-1bxe-4/0/1.0 ae0.0 28:c0:da:ba:90:00 xe-17/0/4.0 EX8200VC-1bge-0/0/0.0 - 10.10.52.10 port 1 WLA532-US
Run the show lacp interfaces command to verify that LACP is running.
root@EX6200-1> show lacp interfacesAggregated interface: ae0 LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity xe-4/0/0 Actor No No Yes Yes Yes Yes Slow Active xe-4/0/0 Partner No No Yes Yes Yes Yes Slow Active xe-4/0/1 Actor No No Yes Yes Yes Yes Slow Active xe-4/0/1 Partner No No Yes Yes Yes Yes Slow Active xe-5/0/0 Actor No No Yes Yes Yes Yes Slow Active xe-5/0/0 Partner No No Yes Yes Yes Yes Slow Active xe-5/0/1 Actor No No Yes Yes Yes Yes Slow Active xe-5/0/1 Partner No No Yes Yes Yes Yes Slow Active LACP protocol: Receive State Transmit State Mux State xe-4/0/0 Current Slow periodic Collecting distributing xe-4/0/1 Current Slow periodic Collecting distributing xe-5/0/0 Current Slow periodic Collecting distributing xe-5/0/1 Current Slow periodic Collecting distributing
Configure secure access port features.NOTE: in the version of code tested in the tested network (12.1r9), there is an issue where DHCp requests do not
complete when configuring ports for arp-inspection and dhcp-examine. so we are omitting this step for the eX6200
in this guide. the bug id for this problem is pr# 787161 this pr# has been fixed in newer versions of code. If you need
this feature verify the fix is in the version of code you are loading by looking at the release notes in the issues resolved
section.
We recommend configuring basic security features on user facing VlaNs on access switches. enable these features on
the data_wired_1b and voip_wired_1b, VlaNs.
NOTE: Do not enable these features on networks that frequently have static Ip address assignments. each device with
a static Ip address attached to a port on a VlaN – with these features enabled – requires a static port configuration
with an Ip address and a maC address in order to communicate with the rest of the network. If required, this additional
level of security can be configured, but it will add some overhead when network changes are made.
root@EX6200-1b# set interfaces interface-range wireless_access_points member-range ge-0/0/0 to ge-0/0/4set interfaces interface-range wired_access_ports member-range ge-0/0/5 to ge-0/0/26set interfaces interface-range wired_voice_ports member-range ge-0/0/27 to ge-0/0/47
Set the port mode.For the user facing ports we need to set the port mode to access. Because we have used the interface-ranges
statement, we only need to set the port mode at the interface-range level, instead of editing every port. For the ports
supporting Wlas we will configure these as trunk ports, but they all have the same VlaN configuration.
root@EX6200-1b# set interfaces interface-range wired_access_ports unit 0 family ethernet-switching port-mode accessset interfaces interface-range wired_voice_ports unit 0 family ethernet-switching port-mode accessset interfaces interface-range wireless_access_points unit 0 family ethernet-switching port-mode trunk
Configure port to VLAN.
root@EX6200-1b# set vlans voip_wired_1b interface wired_voice_portsset vlans data_wired_1b interface wired_access_ports
the ports for the Wlas require a trunking configuration and require a native VlaN (access_points_1b) be configured in
order for the access point to boot up. When configuring a native VlaN you cannot configure the port VlaN members
with this same VlaN or it will ignore the native VlaN configuration and will not work.
set interfaces interface-range wireless_access_points unit 0 family ethernet-switching vlan members data_wireless_1bset interfaces interface-range wireless_access_points unit 0 family ethernet-switching vlan members voip_wireless_1bset interfaces interface-range wireless_access_points unit 0 family ethernet-switching native-vlan-id access_points_1b
Configure Layer 3 settings.layer 3 configuration for the access switch involves setting a default route in the case of the tested network. In this
case, it points to 10.10.50.1 which is the core switch Ip interface on the management_1a VlaN.
set routing-options static route 0.0.0.0/0 next-hop 10.10.50.1
Verify IP reachability.Next, you need to verify Ip reachability by “pinging” the core switch management Ip address from the access switch.
this also indicates that trunking is configured properly on the interface and working properly.
root@EX6200-1b> ping 10.10.50.1PING 10.10.50.1 (10.10.50.1): 56 data bytes64 bytes from 10.10.50.1: icmp_seq=0 ttl=64 time=3.458 ms64 bytes from 10.10.50.1: icmp_seq=1 ttl=64 time=3.070 ms
Verify VLANs and trunking.to verify that the proper VlaNs are configured for trunking on the ae0 interface, you can use the show ethernet-
switching interfaces ae0 command.
root@EX6200-1b> show ethernet-switching interfaces ae0Interface State VLAN members Tag Tagging Blockingae0.0 up access_points_1b 52 tagged unblocked data_wired_1b 8 tagged unblocked data_wireless_1b 32 tagged unblocked management_1b 50 tagged unblocked voip_wired_1b 20 tagged unblocked voip_wireless_1b 40 tagged unblocked
to see what ports are configured for specific VlaNs use the show vlans command.
NOTE: Because of the large number of ports in eX6200-1b, the show command output below show the first VlaN’s output.
root@EX6200-1b> show vlansName Tag Interfacesaccess_points_1b 52 ae0.0*, ge-0/0/0.0*, ge-0/0/1.0, ge-0/0/2.0, ge-0/0/3.0, ge-0/0/4.0, ge-1/0/0.0
Configure Class of Servicethe basic Class of service configuration used is almost identical across core and access platforms in the tested
network example.
We will configure Class of service on the core eX6210. the configuration of Cos is done in five steps the first four define
what the Cos service will look like and the last step applies Cos to specific interfaces.
• Forwarding Classes
• Classifiers
• schedulers
• scheduler-maps
• rewrite rules
• Configuring Interfaces
Configuring forwarding classes.First we will configure the forwarding classes, this step also defines what queues are used as well.
root@EX6200-1b# set class-of-service forwarding-classes class control queue-num 7set class-of-service forwarding-classes class voice queue-num 5set class-of-service forwarding-classes class business-app queue-num 3set class-of-service forwarding-classes class server-bulk queue-num 1set class-of-service forwarding-classes class best-effort queue-num 0
root# set system root-authentication plain-text-passwordNew password:*******Retype new password:*******{master:0}[edit]root#
Configure the time zone.
root# set system time-zone America/Los_Angeles
Configure the hostname.
root# set system host-name EX4500VC-1a
Configure the management and VME interface (optional).
set interfaces vme unit 0 family inet address 10.94.188.101/24
Configure management access.
root@EX4500VC-1a# set system services web-management https system-generated-certificateset system services sshdelete system services web-management httpdelete system services telnet
Configure DNS.
root@EX4500VC-1a# set system name-server 10.10.24.100set system domain-name xyzcompany.com
Configuring a Virtual Chassis for the Mixed Mode Core Chassisto configure a Virtual Chassis for the core switch:
Identify the Virtual Chassis type.In the case of the tested network, the core switch is a mixed mode Virtual Chassis (both eX4500 and eX4200 switches
in the same Virtual Chassis). For more information about Virtual Chassis, see “Virtual Chassis” on page 93, or the Day
One book, Configuring EX Series Ethernet Switches.
Configure a pre-provisioned Virtual Chassis.the recommended setup process for a Virtual Chassis is called pre-provisioned, which is the process we will use here.
to pre-provision a Virtual Chassis, you need to identify the serial numbers of each device that will be part of the Virtual
Chassis, the device function, and the order in which you want each switch to be placed. Here we have configured the
eX4500 switches to be in slot 0 and slot 1, and act as routing engines. the eX4200 switches are in slot 2 and slot 3,
and configured as line cards. later, when all the switches are connected and powered up, they will automatically be
assigned the proper function and slot. make sure you pay attention to the serial numbers and ordering of each switch
when you connect them together.
the eX series switches by default automatically form a Virtual Chassis, but because the ordering is nondeterministic,
and so the switches may not be numbered sequentially, making things confusing. For more information about Virtual
Chassis, see appendix a and B, or the Day One book, Configuring EX Series Ethernet Switches.
root@EX4500VC-1a# set virtual-chassis preprovisionedset virtual-chassis member 0 role routing-engineset virtual-chassis member 0 serial-number GX0212140825set virtual-chassis member 1 role routing-engineset virtual-chassis member 1 serial-number GX0212140845set virtual-chassis member 2 role line-cardset virtual-chassis member 2 serial-number FP0211490796set virtual-chassis member 3 role line-cardset virtual-chassis member 3 serial-number FP0211490618
Verify that the mode is correct, by typing show virtual-chassis.
root@EX4500VC-1a> show virtual-chassisPreprovisioned Virtual ChassisVirtual Chassis ID: 8c7a.9353.df56Virtual Chassis Mode: MixedMstr Mixed Neighbor ListMember ID Status Serial No Model prio Role Mode ID Interface0 (FPC 0) Prsnt GX0212140825 ex4500-40f 129 Master* Y
using the VCp ports at the back of the units, cable the remaining members together in a daisy-chained configuration.
When all of the units are cabled properly, power them up. remember to pay attention to the serial number of each
switch when connecting them together to ensure they are in the right position.
after the switches finish booting up, verify that all of the members of the Virtual Chassis are active by running the show
virtual-chassis command.
Preprovisioned Virtual ChassisVirtual Chassis ID: 804d.1d7f.fd6aVirtual Chassis Mode: Mixed Mstr Mixed Neighbor ListMember ID Status Serial No Model prio Role Mode ID Interface0 (FPC 0) Prsnt GX0212140825 ex4500-40f 129 Backup Y 1 vcp-1 2 vcp-01 (FPC 1) Prsnt GX0212140845 ex4500-40f 129 Master* Y 3 vcp-1 0 vcp-02 (FPC 2) Prsnt FP0211490796 ex4200-48px 0 Linecard Y 3 vcp-0 0 vcp-13 (FPC 3) Prsnt FP0211490618 ex4200-48px 0 Linecard Y 1 vcp-0 2 vcp-1
root@EX4500VC-1a# set system commit synchronizeset routing-options nonstop-routingset ethernet-switching-options nonstop-bridgingset chassis redundancy graceful-switchovercommit and-quit
Configure resilient dual-boot partitions.NOTE: It is important to run this step as it improves the resiliency of the system in case of primary boot partition failure.
this step creates a backup copy of the operating system and is highly recommended. the process takes approximately
5 minutes for each re or member.
request system snapshot slice alternate all-members
Configure default settings.the following items should be enabled by default in the configuration. You may wish to review and verify that these
Configuring Layer 2 Settings For Mixed Mode Core Switchto configure layer 2 parameters and settings on the core switch:
Set the bridge priority on the core switch.
NOTE: We enable spanning tree protocol to prevent loops from forming in the network, even though we do not use it
as a topology protocol. as an extra precaution, we set the bridge priority on the core switch to 8192, which will ensure
that it will be the default root bridge in the event another bridging device is connected to the network.
Juniper Networks eX series switches run rstp by default.
root@EX4500VC-1a# set protocols rstp bridge-priority 8k
Configure VLANs and IP interfaces.NOTE: We configure all of the inter-VlaN routing on the core switch. this makes it easier to simultaneously configure
the VlaNs and Ip interfaces for those VlaNs. When creating VlaN names, it is important to note that these names
are case sensitive. the first command creates the VlaN data_wired_1a with a VlaN ID of 12 and then assigns a layer 3
interface called vlan.10 to that VlaN. the second line creates the vlan.12 interface and assigns an Ip address.
root@EX4500VC-1a# set vlans data_wired_1a vlan-id 12set vlans data_wired_1a l3-interface vlan.12
You may notice that the VlaN ID is the same as the interface VlaN unit number (both are number 12). this is not
mandatory, but we recommend that you match the VlaN ID and interface VlaN unit number. It helps to make things
easier to understand later when you have many VlaNs and interfaces to track. We also used a compound command for
the first line. We created the VlaN, assigned the VlaN ID, and assigned a layer 3 interface all at the same time. this
can save you some time but does not have to be done in a single statement. When you look at the configuration, you
will notice that this is separated into two disparate statements.
root@EX4500VC-1a# set interfaces vlan unit 12 family inet address 10.10.12.1/22set interfaces vlan unit 24 family inet address 10.10.24.1/22set interfaces vlan unit 36 family inet address 10.10.36.1/22set interfaces vlan unit 42 family inet address 10.10.42.1/23set interfaces vlan unit 51 family inet address 10.10.51.1/24set interfaces vlan unit 54 family inet address 10.10.54.1/24
Commit the configuration.
commit
Configure LAG (aggregated Ethernet) ports.In the tested network configuration, laG ports are configured to connect to access switches as trunk ports, and one
laG is the routed interface connecting to building B core eX8200ViC.
Junos Os requires that you configure the number of laG interfaces you want to use before you begin configuring
the interfaces. We suggest picking a number slightly larger than you might need, in case you need to add more laG
interfaces later. You can change this value in the future. We need four aggregated ethernet ports for the tested network
example, so we will configure the core chassis with six, in case we add another access switch.
root@EX4500VC-1a# delete interfaces xe-1/0/38 unit 0delete interfaces xe-1/0/39 unit 0delete interfaces xe-0/0/38 unit 0delete interfaces xe-0/0/39 unit 0delete interfaces xe-0/0/8 unit 0delete interfaces xe-1/0/8 unit 0delete interfaces xe-0/0/4 unit 0delete interfaces xe-1/0/4 unit 0delete interfaces xe-0/0/6 unit 0 delete interfaces xe-1/0/6 unit 0
then we configure the interfaces to be part of the respective aggregated interfaces:
Disable RSTP on LAG connections to access switches.Because we are not using stp, we will disable it on the laG ports going to our access switches. this reduces potential
convergence times in case a laG member fails because fewer protocols need to converge.
NOTE: all access switches have rstp enabled locally to prevent looping. Interface ae0.0 is not enabled for switching
so we do not need to disable rstp for that interface.
We need to configure the laG ports as trunks and add the VlaNs that will be supported on the individual access
switches.
root@EX4500VC-1a# set interfaces ae0 unit 0 family ethernet-switching port-mode trunkset interfaces ae1 unit 0 family ethernet-switching port-mode trunkset interfaces ae2 unit 0 family ethernet-switching port-mode trunk
Configure VLANs on the trunk ports.You can configure port-to-VlaN mapping in two different ways:
• You can configure the VlaNs directly as part of the port configuration.
• You can configure the ports included in the VlaN under the VlaN configuration.
each of these has different advantages and disadvantages. Generally, it makes sense to configure access ports (client-
facing) under the VlaN configuration and configure VlaNs directly on the port for trunk port configuration. You cannot
configure the VlaN mapping in both places— that might produce errors when doing a configuration commit operation.
as discussed previously, we need to configure the VlaNs that the trunk port will carry directly on the interface
configuration section. this makes it easier to tell what VlaNs a specific trunk is part of when viewing the configuration.
When you add VlaNs directly to a trunk port you have the option of adding them by their VlaN ID or by the VlaN
name. In this example, we will add them by VlaN name, because this makes the overall configuration more readable.
the addition of several VlaNs to a trunk can be achieved in two ways: specified one at a time, or several VlaNs can
be configured simultaneously by enclosing them in [] brackets and separating them with spaces. this example shows
each set command. the interfaces are being configured as a trunk and then vlans being added for each of the laG
interfaces we have configured as trunk ports ae1, ae2, and ae3.
root@EX4500VC-1a#set interfaces ae1 unit 0 family ethernet-switching port-mode trunkset interfaces ae1 unit 0 family ethernet-switching vlan members data_wired_1aset interfaces ae1 unit 0 family ethernet-switching vlan members voip_wired_1aset interfaces ae1 unit 0 family ethernet-switching vlan members data_wireless_1aset interfaces ae1 unit 0 family ethernet-switching vlan members voip_wireless_1aset interfaces ae1 unit 0 family ethernet-switching vlan members access_points_1aset interfaces ae1 unit 0 family ethernet-switching vlan members management_1aset interfaces ae2 unit 0 family ethernet-switching port-mode trunkset interfaces ae2 unit 0 family ethernet-switching vlan members data_wired_1aset interfaces ae2 unit 0 family ethernet-switching vlan members voip_wired_1aset interfaces ae2 unit 0 family ethernet-switching vlan members data_wireless_1aset interfaces ae2 unit 0 family ethernet-switching vlan members voip_wireless_1aset interfaces ae2 unit 0 family ethernet-switching vlan members access_points_1aset interfaces ae2 unit 0 family ethernet-switching vlan members management_1aset interfaces ae3 unit 0 family ethernet-switching port-mode trunkset interfaces ae3 unit 0 family ethernet-switching vlan members data_wired_1aset interfaces ae3 unit 0 family ethernet-switching vlan members voip_wired_1aset interfaces ae3 unit 0 family ethernet-switching vlan members data_wireless_1aset interfaces ae3 unit 0 family ethernet-switching vlan members voip_wireless_1aset interfaces ae3 unit 0 family ethernet-switching vlan members access_points_1aset interfaces ae3 unit 0 family ethernet-switching vlan members management_1a
Configure Secure Access Port Features.
most ports on core switches do not need any secure access port features enabled it unnecessarily complicates the
configuration. the reason is that statically assigned Ip addresses are typically used for servers and other networking
devices, and each of these would require exceptions to be manually entered in order to work if these features are
enabled. there are some VlaNs on the core switch, however, on which we recommend enabling these features: the
data_wired_1a, voip_wired_1a ; client-facing VlaNs that are configured on this switch.
Configure Class of Servicethe basic Cos configuration used is almost identical across core and access platforms in the network example. We
will configure Cos on the core eX4500VC-1a. the configuration first defines the Cos and then applies it to specific
interfaces.
Configuring forwarding classesFirst we will configure the forwarding classes, this step also defines what queues are used as well.
root@EX4500VC-1a# set class-of-service forwarding-classes class control queue-num 7set class-of-service forwarding-classes class voice queue-num 5set class-of-service forwarding-classes class business-app queue-num 3set class-of-service forwarding-classes class server-bulk queue-num 1set class-of-service forwarding-classes class best-effort queue-num 0
Configuring classifiersNext we will create the classifiers. In the tested network example we are only using DsCp marking for our classification
of traffic. the classifiers map the different DsCp marked packets to the correct queue, if the traffic is not marked or
marked with a DsCp value not listed it will be considered best-effort traffic and treated accordingly.
Configuring EX4200 as Extended Mode Virtual ChassisConfiguring access switches is simpler than configuring the core switch. We only configure layer 2 services on the
access switches and an Ip address on the management VlaN to provide remote management. this section covers the
configuration for eX4200VC-3b, which is an extended mode Virtual Chassis in the tested network (see Figure 14). this
section includes the following topics:
Procedure overview 1. Configure global configuration items
2. Configure the Virtual Chassis
• Identify the type of Virtual Chassis
• pre-provision the Virtual Chassis
• perform the Virtual Chassis type-specific configuration
• perform the Virtual Chassis standard configuration
3. Configure layer 2 settings
4. Configure layer 3 settings
5. Configure Class of service
Configuring Global Settings for the Core Switchto configure global settings on the core switch:
Connect to the Console port of the EX4200 switch (Setting: s9600, 8, 1, none).press enter. the following prompt appears.
You should now be at the # prompt and ready to start configuring the switch.
Configure the password.
root# set system root-authentication plain-text-passwordNew password:*******Retype new password:*******{master:0}[edit]root#
Configure the time zone.
root# set system time-zone America/Los_Angeles
Configure the hostname.
root# set system host-name EX4200VC-3b
Configure the management and VME interface.
set interfaces vme unit 0 family inet address 10.94.188.101/24
Configure management access.
root@ EX4200VC-3b# set system services web-management https system-generated-certificateset system services sshdelete system services web-management httpdelete system services telnet
root@EX4200VC-3a#set system name-server 10.10.24.100set system domain-name xyzcompany.com
Configuring an Extended Mode Virtual Chassis for the EX4200to configure a Virtual Chassis for the core switch:
Identify the Virtual Chassis Type.In the case of the tested network, this access switch is an extended mode Virtual Chassis (it uses 10-Gigabit ethernet
links to extend the Virtual Chassis between wiring closets and is managed as a single logical switch). For more
information about Virtual Chassis, see appendix a and B, or the Day One book, Configuring EX Series Ethernet Switches.
Configure a Pre-provisioned Virtual Chassis.the recommended setup process for a Virtual Chassis is called pre-provisioned, which is the process we will use here.
to pre-provision a Virtual Chassis, you need to identify the serial numbers of each device that will be part of the Virtual
Chassis, the device function, and the order in which you want each switch to be placed.
the eX series switches will by default form a Virtual Chassis group automatically when connected together be Virtual
Chassis ports. However, the ordering is nondeterministic, so the switches may not be numbered sequentially, making
things confusing. For more information about Virtual Chassis, see appendix a and B, or the Day One book, Configuring EX Series Ethernet Switches.
root@EX4200VC-3a# set virtual-chassis preprovisionedset virtual-chassis member 0 role routing-engineset virtual-chassis member 0 serial-number FP0211490670set virtual-chassis member 1 role line-cardset virtual-chassis member 1 serial-number FP0211490804set virtual-chassis member 2 role routing-engineset virtual-chassis member 2 serial-number FP0211490739set virtual-chassis member 3 role line-cardset virtual-chassis member 3 serial-number FP0211490735
Set the Virtual Chassis to support fast failover on 10-Gigabit Ethernet Virtual Chassis interfaces.
root@EX4200VC-3a# set virtual-chassis fast-failover xe
NOTE: by default split-detection is enabled, and because all devices are not located in the same location we
recommend leaving split-detection enabled. If you want to disable split detection it can be done by issuing the
command “set virtual-chassis no-split-detection”. It is recommended that split-detection be disabled for Virtual
Chassis with only two devices. If you are not familiar with how split-detection works please review the section on
Virtual Chassis split-detection located appendix a for more details.
Configure global virtual chassis commands.
root@EX4200VC-3a# set system commit synchronizeset ethernet-switching-options nonstop-bridgingset chassis redundancy graceful-switchover
Commit the configuration.
root@EX4200VC-3a# commit
If you see an error message like the following, you can ignore it. the configuration commit operation has been
root@EX4200VC-3a# commiterror: Could not connect to fpc-1 : Can’t assign requested addresswarning: Cannot connect to other RE, ignoring itconfiguration check succeedscommit complete
using the VCp ports at the back of the units, cable each pair of eX series switches together. remember to pay careful
attention to the serial numbers of each switch before cabling them together.
WARNING: Do not connect the 10-Gigabit Ethernet ports at this time.
When all of the switches are cabled properly, power them up. You should now have two Virtual Chassis each, with two
members. One of the two-member chassis will be pre-provisioned. Verify that this is working properly by running the
show virtual-chassis command. Output similar to the example below indicates that the chassis members are present,
the Virtual Chassis is pre-provisioned, and that the members are correctly identified. Here, member 0 supposed to be a
routing engine and member 1 is supposed to be in line card mode. this is verified by the output.
root@EX4200VC-3a> show virtual-chassisPreprovisioned Virtual ChassisVirtual Chassis ID: 3f68.0cec.a7e1Virtual Chassis Mode: EnabledMstr Mixed Neighbor ListMember ID Status Serial No Model prio Role Mode ID Interface0 (FPC 0) Prsnt FP0211490670 ex4200-48px 129 Master* N 1 vcp-0 1 vcp-11 (FPC 1) Prsnt FP0211490804 ex4200-48px 0 Linecard N 0 vcp-0 0 vcp-1
Configure Virtual Chassis extended ports.since this is an extended mode chassis, we need to configure it to use some of the 10-Gigabit ethernet ports as Virtual
Chassis extended ports so the switches can form a single Virtual Chassis. In our example, we use the eX-um-2x4sFp
uplink module on our chassis that supports either two 10-Gbps or four 1-Gbps ports. the first and third positions
coincide with the 10-Gigabit ethernet ports and are filled on the uplink module, so we will configure ports xe-x/1/0 and
xe-x/1/2. We will use port 0 in our case for each switch.
NOTE: the port definition in your example could be different if you use a different model of eX series device as your
uplink module, but as it should still have port 0, this part of the configuration does not change.
root@EX4200VC-3a> request virtual-chassis vc-port set pic-slot 1 port 0 member 0request virtual-chassis vc-port set pic-slot 1 port 0 member 1
use the show virtual-chassis vc-port command to verify that the ports are configured correctly. Here we can see that
interface 1/0 on each switch is configured and up but has no neighbors.
root@EX4200VC-3a> show virtual-chassis vc-portfpc0:--------------------------------------------------------------------------Interface Type Trunk Status Speed Neighboror ID (mbps) ID InterfacePIC / Portvcp-0 Dedicated 1 Up 32000 1 vcp-1vcp-1 Dedicated 2 Up 32000 1 vcp-01/0 Configured -1 Up 10000fpc1:--------------------------------------------------------------------------Interface Type Trunk Status Speed Neighboror ID (mbps) ID InterfacePIC / Portvcp-0 Dedicated 1 Up 32000 0 vcp-1vcp-1 Dedicated 2 Up 32000 0 vcp-01/0 Configured -1 Up 10000
Connect your console to the second pair of switches. Press Enter and you should see the following prompt:
Amnesiac (ttyu0)login:
Log in as root and press Enter. there should be no password configured, so you should not be prompted for one. Note the version of Junos and
upgrade the unit if necessary.
login: rootLogging to master.- - - JUNOS 12.1R9 built 2011-11-15 11:14:01 UTCroot@:RE:0%
You should now be at the % prompt of the switch.
Type cli at the % Prompt.
root@:RE:0% cli{master:0}root>
You should now be at the > prompt.
use the show virtual-chassis command to verify that the switches are up and running. When both of the switches show
up, we can configure the Virtual Chassis ports on these switches.
root> show virtual-chassisVirtual Chassis ID: b155.0784.e162Virtual Chassis Mode: EnabledMstr Mixed NeighborListMember ID Status Serial No Model prio Role Mode ID Interface0 (FPC 0) Prsnt FP0211490739 ex4200-48px 128 Master* N 1 vcp-0 1 vcp-11 (FPC 1) Prsnt FP0211490735 ex4200-48px 128 Backup N 0 vcp-0 0 vcp-1
Configure the Second Set of Virtual Chassis Extended Ports
root>request virtual-chassis vc-port set pic-slot 1 port 0 member 0request virtual-chassis vc-port set pic-slot 1 port 0 member 1
use the show virtual-chassis vc-port command to verify the ports are configured correctly. Here we can see that
interface 1/0 on each switch is configured and up but has no neighbors.
root> show virtual-chassis vc-portfpc0:--------------------------------------------------------------------------Interface Type Trunk Status Speed Neighboror ID (mbps) ID InterfacePIC / Portvcp-0 Dedicated 1 Up 32000 1 vcp-1vcp-1 Dedicated 2 Up 32000 1 vcp-01/0 Configured -1 Down 10000fpc1:--------------------------------------------------------------------------Interface Type Trunk Status Speed Neighboror ID (mbps) ID InterfacePIC / Portvcp-0 Dedicated 1 Up 32000 0 vcp-1vcp-1 Dedicated 2 Up 32000 0 vcp-01/0 Configured -1 Down 10000
Connect the Virtual Chassis extended ports• Connect switches 1 and 3 together using the 10-Gigabit ethernet port xe-x/1/0 on each switch
• Connect switches 2 and 4 together using the 10-Gigabit ethernet port xe-x/1/0 on each switch.
Verify Virtual Chassis extended ports• Connect the console back to the first pair of switches.
• use the show virtual-chassis vc-port command to verify the port configuration is correct. all of the four switches are
visible, with one configured 1/0 port that has a neighbor listed.
root@EX4200VC-3a> show virtual-chassis vc-portfpc0:--------------------------------------------------------------------------Interface Type Trunk Status Speed Neighboror ID (mbps) ID InterfacePIC / Portvcp-0 Dedicated 1 Up 32000 1 vcp-1vcp-1 Dedicated 2 Up 32000 1 vcp-01/0 Configured -1 Up 10000 2 vcp-255/1/0
fpc1:--------------------------------------------------------------------------Interface Type Trunk Status Speed Neighboror ID (mbps) ID InterfacePIC / Portvcp-0 Dedicated 1 Up 32000 0 vcp-1vcp-1 Dedicated 2 Up 32000 0 vcp-01/0 Configured -1 Up 10000 3 vcp-255/1/0
fpc2:--------------------------------------------------------------------------Interface Type Trunk Status Speed Neighboror ID (mbps) ID InterfacePIC / Portvcp-0 Dedicated 1 Up 32000 3 vcp-1vcp-1 Dedicated 2 Up 32000 3 vcp-01/0 Configured -1 Up 10000 0 vcp-255/1/0
fpc3:--------------------------------------------------------------------------Interface Type Trunk Status Speed Neighboror ID (mbps) ID InterfacePIC / Portvcp-0 Dedicated 1 Up 32000 2 vcp-1vcp-1 Dedicated 2 Up 32000 2 vcp-01/0 Configured -1 Up 10000 1 vcp-255/1/0
use the show virtual-chassis command to verify that the Virtual Chassis is built as expected, based on the pre-
provisioning configuration we did earlier.
root@EX4200VC-3a> show virtual-chassis
Preprovisioned Virtual ChassisVirtual Chassis ID: 3f68.0cec.a7e1Virtual Chassis Mode: Enabled Mstr Mixed Neighbor ListMember ID Status Serial No Model prio Role Mode ID Interface0 (FPC 0) Prsnt FP0211490670 ex4200-48px 129 Backup N 1 vcp-0 1 vcp-1 2 vcp-255/1/01 (FPC 1) Prsnt FP0211490804 ex4200-48px 0 Linecard N 0 vcp-0 0 vcp-1 3 vcp-255/1/02 (FPC 2) Prsnt FP0211490739 ex4200-48px 129 Master* N 3 vcp-0 3 vcp-1 0 vcp-255/1/03 (FPC 3) Prsnt FP0211490735 ex4200-48px 0 Linecard N 2 vcp-0 2 vcp-1 1 vcp-255/1/0
Configure resilient dual-boot partitionsNOTE: It is important to run this step as it improves the resiliency of the system in the case of primary boot partition
failure. this step creates a backup copy of the operating system and is highly recommended. this process takes
approximately 5 minutes for each re or member.
request system snapshot slice alternate all-members
Configure default settingsthe following commands show items that should be enabled by default in the configuration. You may wish to review
and verify that these setting are desired for your specific network.
Configure LAG (aggregated Ethernet) Portsthe eX4200VC-3b chassis has only one laG port configured to connect to the core switch. Junos Os requires that you
configure the number of laG interfaces you want to use before you begin configuring the laG interfaces. We suggest
picking a number slightly larger than what you need in case you add more laG interfaces later. You can change this
value in the future.
Because we need one laG interface for this configuration, we will configure the chassis with two in case we add
another laG connection later.
root@EX4200VC-3a# set chassis aggregated-devices ethernet device-count 2
the 10-Gigabit ethernet ports on the eX4200 series are only available using the uplink module ports. We have uplink
modules on each of the four switches. However, the first port xe-x/1/0 is already in use on each switch to form the
extended Virtual Chassis. We need to configure the laG connection on switch members 1 and 3, using ports xe-1/1/1
and xe-3/1/1.
First, we need to remove any port-specific configuration on the physical ports we want to aggregate. By default,
interfaces have unit 0 defined, but this is not allowed on an interface that is part of an aggregate interface because it
would conflict with unit 0 on the logical aggregate interface.
root@EX4200VC-3a# delete interfaces xe-1/1/1 unit 0delete interfaces xe-3/1/1 unit 0
Next, we need to add LACP to each LAG interface to provide some health checking.NOTE: laCp must be configured on both sides for the laG port to become active.
Disable RSTP on LAG connections to access switches.Because we are not using rstp as a topology protocol, we can disable it on the laG ports going to our access
switches. Disabling rstp also reduces potential convergence times in case of a laG member failure, because fewer
protocols need to converge.
NOTE: all access switches will have rstp enabled for loop protection locally.
root@EX4200VC-3a# set protocols rstp interface ae0.0 disable
Configure the trunk port and VLAN
Next, we need to configure the laG port as a trunk and add the VlaNs that will be going to the core switch. to enable
the laG port as a trunk port, use the set interfaces command.
root@EX4200VC-3a# set interfaces ae0 unit 0 family ethernet-switching port-mode trunk
Configure VLANs on trunk ports.VlaN configuration for ae0, which connects to the eX4500VC-1a has data_wired_1a, voip_wired_1a, data_wireless_1a,
voip_wireless_1a, the management_1a VlaN for switch management and access_points_1a for the Wlas to reside.
VlaNs can be added in a single statement surrounded by [] or can be added one line at a time. this example shows
root@EX4200VC-3a# set interfaces ae0 unit 0 family ethernet-switching vlan members data_wired_1aset interfaces ae0 unit 0 family ethernet-switching vlan members voip_wired_1aset interfaces ae0 unit 0 family ethernet-switching vlan members access_points_1aset interfaces ae0 unit 0 family ethernet-switching vlan members data_wireless_1aset interfaces ae0 unit 0 family ethernet-switching vlan members voip_wireless_1aset interfaces ae0 unit 0 family ethernet-switching vlan members management_1a
Commit the configuration.
commit
You should see the commit operation finish on each of the eX series switches in the Virtual Chassis.
Now Connect the LAG connections to the core switch.run the show lldp neighbors command to verify that the connection is up and you can see the other side of the
connection.
root@EX4200VC-3a> show lldp neighborsLocal Interface Parent Interface Chassis Id Port info System Namexe-1/1/1.0 ae0.0 a8:d0:e5:b5:0f:80 xe-0/0/4.0 EX4500VC-1axe-3/1/1.0 ae0.0 a8:d0:e5:b5:0f:80 xe-1/0/4.0 EX4500VC-1a
run the show lacp interfaces command to verify that lacp is running
root@EX4200VC-3a# run show lacp interfacesAggregated interface: ae0 LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity xe-3/1/1 Actor No No Yes Yes Yes Yes Slow Active xe-3/1/1 Partner No No No No Yes Yes Slow Active xe-1/1/1 Actor No No Yes Yes Yes Yes Slow Active xe-1/1/1 Partner No No Yes Yes Yes Yes Slow Active LACP protocol: Receive State Transmit State Mux State xe-3/1/1 Current Slow periodic Collecting distributing xe-1/1/1 Current Slow periodic Collecting distributing
Configure secure access port features.We recommend configuring these basic security features on the majority of the VlaNs on access switches. We need to
enable these features on the data_wired_1a and voip_wired_1a VlaNs.
You may notice that we do not enable these features on all the VlaNs. some VlaNs have a greater tendency to have
statically configured devices or may not require this feature. each device with a static Ip address attached to a port on
a VlaN, with these features enabled, requires a static port configuration with an Ip address and a maC address in order
to communicate with the rest of the network. this additional level of security can be configured If required, but it will
add some configuration overhead when network changes are made.
root@EX4200VC-3a# set interfaces interface-range wired_access_ports member-range ge-0/0/5 to ge-0/0/26set interfaces interface-range wired_voice_ports member-range ge-0/0/27 to ge-0/0/47set interfaces interface-range wireless_access_points member-range ge-0/0/0 to ge-0/0/4
Set the port mode.set the port mode to access. Because we have used the interface-ranges statement, we only need to set the port mode
at the interface-range instead of editing every port.
root@EX4200VC-3a# set interfaces interface-range wired_access_ports unit 0 family ethernet-switching port-mode accessset interfaces interface-range wired_voice_ports unit 0 family ethernet-switching port-mode accessset interfaces interface-range wireless_access_points unit 0 family ethernet-switching port-mode trunk
Configure port to VLAN.
root@EX4200VC-3a# set vlans data_wired_1a interface wired_access_portsset vlans voip_wired_1a interface wired_voice_ports
the ports for the Wlas require a trunking configuration and require a native VlaN (access_points_1a) be configured in
order for the access point to boot up. When configuring a native VlaN you cannot configure the port VlaN members
with this same VlaN or it will ignore the native VlaN configuration and will not work as expected.
root@EX4200VC-3a# set interfaces interface-range wireless_access_points unit 0 family ethernet-switching vlan members data_wireless_1aset interfaces interface-range wireless_access_points unit 0 family ethernet-switching vlan members voip_wireless_1aset interfaces interface-range wireless_access_points unit 0 family ethernet-switching native-vlan-id access_points_1a
Configure layer 3 settings.layer 3 configuration for the access switch involves setting a default route in the case of the tested network. In this
case, it points to 10.10.28.1 which is the core switch
Ip interface on the management VlaN.
root@EX4200VC-3a# set routing-options static route 0.0.0.0/0 next-hop 10.10.51.1
Commit the configuration.
root@EX4200VC-3a# commit
Verify IP reachability.Next, you need to verify Ip reachability by “pinging” the core switch management Ip address from the access switch.
this also indicates that trunking is configured properly on the interface and working properly.
root@EX4200VC-3a# run ping 10.10.51.1PING 10.10.51.1 (10.10.51.1): 56 data bytes64 bytes from 10.10.51.1: icmp_seq=0 ttl=64 time=2.254 ms64 bytes from 10.10.51.1: icmp_seq=1 ttl=64 time=1.759 ms64 bytes from 10.10.51.1: icmp_seq=2 ttl=64 time=1.720 ms
Verify VLANs and trunking.to verify that the proper VlaNs are configured for trunking on the ae0 interface, you can use the show ethernet-
switching interfaces ae0 command.
root@EX4200VC-3a> show ethernet-switching interfaces ae0Interface State VLAN members Tag Tagging Blockingae0.0 up access_points_1a 54 tagged unblocked data_wired_1a 12 tagged unblocked data_wireless_1a 36 tagged unblocked management_1a 51 tagged unblocked voip_wired_1a 24 tagged unblocked voip_wireless_1a 42 tagged unblocked
to see what ports are configured for specific VlaNs use the show vlans command.
NOTE: Because of the large number of ports in eX4200VC-3a, the show command output below show the first
VlaN’s output.
root@EX4200VC-3a> show vlansName Tag Interfacesaccess_points_1a 54 ae0.0*, ge-0/0/0.0*, ge-0/0/1.0, ge-0/0/2.0, ge-0/0/3.0, ge-0/0/4.0
Configure Class of Servicethe basic Class of service configuration used is almost identical across core and access platforms in the tested
network example.
We will configure Class of service on the core eX4500VC-1a. the configuration of Cos is done in five steps the first four
define what the Cos service will look like and the last step applies Cos to specific interfaces.
• Forwarding Classes
• Classifiers
• schedulers
• scheduler-maps
• rewrite rules
• Configuring Interfaces
Configuring forwarding classes.First we will configure the forwarding classes, this step also defines what queues are used as well.
root@EX4200VC-3a# set class-of-service forwarding-classes class control queue-num 7set class-of-service forwarding-classes class voice queue-num 5set class-of-service forwarding-classes class business-app queue-num 3set class-of-service forwarding-classes class server-bulk queue-num 1set class-of-service forwarding-classes class best-effort queue-num 0
Configuring classifiers.Next we will create the classifiers. In the tested network example we are only using DsCp marking for our classification
of traffic. the classifiers map the different DsCp marked packets to the correct queue; if the traffic is not marked, or
marked with a DsCp value not listed, it will be considered best-effort traffic and treated accordingly.
root@EX3300VC-1a# set system services web-management https system-generated-certificate set system services sshdelete system services web-management httpdelete system services telnet
Configure DNS
root@EX3300VC-1a# set system name-server 10.10.24.100set system domain-name xyzcompany.com
Configuring an EX3300 Virtual Chassisto configure a Virtual Chassis for the access switch in dedicated mode:
Identify the Virtual Chassis type
In the case of the tested network, access switch eX3300 is a dedicated mode Virtual Chassis using only the VCp ports
to form the switching fabric interconnect. all switches are the same model.
Configure a pre-provisioned Virtual Chassisto pre-provision a Virtual Chassis you need to identify the serial numbers of each device that will be part of the Virtual
Chassis, the device function, and the order in which you want each switch to be placed. later, when all of the switches
are connected and powered up, they will automatically be assigned the proper function and slot. make sure you pay
attention to the serial numbers and positioning of each switch when you connect them together.
By default, the eX series devices automatically form a Virtual Chassis, but because the ordering is nondeterministic,
the switches may not be numbered sequentially. For more information about Virtual Chassis, see appendix a and B, or
the Day One book, Configuring EX Series Ethernet Switches.
root@EX3300VC-1a# set virtual-chassis preprovisionedset virtual-chassis member 0 role line-cardset virtual-chassis member 0 serial-number GE0211392919set virtual-chassis member 1 role line-cardset virtual-chassis member 1 serial-number GE0211371778set virtual-chassis member 2 role routing-engineset virtual-chassis member 2 serial-number GB0211501128set virtual-chassis member 4 role line-cardset virtual-chassis member 4 serial-number GB0211501285set virtual-chassis member 5 role line-cardset virtual-chassis member 5 serial-number GB0211494458set virtual-chassis member 3 role routing-engineset virtual-chassis member 3 serial-number GA0212039606
Configure Specific Virtual Chassis CommandsNOTE: split-detection is enabled by default, but because all devices are located in the same room and have dual
redundant connections, an accidental chassis split is unlikely. the eX3300 series switches use an extended Virtual
Chassis type we recommend keeping split-detection enabled. If you want to disable split detection it can be done by
issuing the command “set virtual-chassis no-split-detection”. For Virtual Chassis composed of only two devices we
recommend disabling split-detection. If you are not familiar with how split-detection works please review the section
on Virtual Chassis split-detection located in appendix a for more details.
using the VCpe ports on the front of the units, cable each the eX series switches together. When all of the switches are
cabled properly, power up the remaining switches. Once all the switches are powered up, verify that all of the members
are active by running the show virtual-chassis command.
Preprovisioned Virtual ChassisVirtual Chassis ID: 897e.c906.f943Virtual Chassis Mode: Enabled Mstr Mixed Neighbor ListMember ID Status Serial No Model prio Role Mode ID Interface0 (FPC 0) Prsnt GE0211392919 ex3300-24p 0 Linecard NA 5 vcp-255/1/2 1 vcp-255/1/31 (FPC 1) Prsnt GE0211371778 ex3300-24p 0 Linecard NA 0 vcp-255/1/2 2 vcp-255/1/32 (FPC 2) Prsnt GB0211501128 ex3300-48p 129 Master* NA 1 vcp-255/1/2 3 vcp-255/1/33 (FPC 3) Prsnt GA0212039606 ex3300-48t 129 Backup NA 2 vcp-255/1/2 4 vcp-255/1/34 (FPC 4) Prsnt GB0211501285 ex3300-48p 0 Linecard NA 3 vcp-255/1/2 5 vcp-255/1/35 (FPC 5) Prsnt GB0211494458 ex3300-48p 0 Linecard NA 4 vcp-255/1/2 0 vcp-255/1/3
Configure global Virtual Chassis commands.
root@EX3300VC-1a# set system commit synchronizeset ethernet-switching-options nonstop-bridgingset chassis redundancy graceful-switchover
Commit the configuration.
root@EX3300VC-1a# commit
Configure resilient dual-boot partitions.NOTE: It is important to run this step as it improves the resiliency of the system in the case of primary boot partition
failure. this step creates a backup copy of the operating system and is highly recommended. this process takes
approximately 5 minutes for each re or member.
request system snapshot slice alternate all-members
Configure default settings.
the following commands show items that should be enabled by default in the configuration. You may wish to review
and verify that these setting are desired for your specific network.
Configure interfaces.We need to configure one Ip interface on the management VlaN.
root@EX3300VC-1a# set interfaces vlan unit 51 family inet address 10.10.51.6/24
Configure LAG (aggregated Ethernet) ports.the eX3300 chassis has only one laG port configured to connect to the core building switch. Junos Os requires that
you configure the number of laG interfaces you want to use before you begin configuring the laG interfaces. We
suggest picking a number slightly larger than what you need in case you add more laG interfaces later. You can change
this value in the future.
Because we need one laG interface for this configuration, we will configure the eX3300 chassis with two in case we
add another laG connection later.
root@EX3300VC-1a# set chassis aggregated-devices ethernet device-count 2
there are four 10-Gigabit ethernet ports on the eX3300 series however, only two of those are pre-configured as VCpe
connections. the remaining two can be used as uplinks. the ports are numbered as xe-0/1/0 through xe-0/1/3. By
default only xe-0/1/0 and xe-0/1/1 are available as uplinks, while the remaining two ports are configured to act as
VCpe ports.
We will use ports xe-0/1/0 and xe-5/1/0 for our laG connection.
First, we need to remove any port-specific configuration on the physical ports we want to aggregate. By default,
interfaces have unit 0 defined, but this is not allowed on an interface that is part of an aggregate interface, because it
would conflict with unit 0 on the logical aggregate interface.
root@EX3300VC-1a# delete interfaces xe-0/1/0 unit 0delete interfaces xe-5/1/0 unit 0
Because we do not use rstp as a topology protocol, we can disable it on the laG ports going to our access switches.
Disabling rstp also reduces potential convergence times in case a laG member fails, because fewer protocols need to
converge.
NOTE: Note all access switches have rstp enabled locally for loop protection.
root@EX3300VC-1a# set protocols rstp interface ae0.0 disable
Configure the trunk port and VLAN.Next, we need to configure the laG port as a trunk and add the VlaNs that will be supported going to the core switch.
to enable the laG port as a trunk port, use the set interfaces command.
root@EX3300VC-1a# set interfaces ae0 unit 0 family ethernet-switching port-mode trunk
Configure VLANs on trunk ports.VlaN configuration for ae0, which connects to: eX4500VC-1a switch, data_wired_1a, voip_wired_1a, data_wireless_1a,
voip_wireless_1a, the management_1a VlaN for switch management and access_points_1a for the Wlas to reside.
VlaNs can be added in a single statement surrounded by [] or can be added one line at a time. In this example we will
show each command.
set interfaces ae0 unit 0 family ethernet-switching port-mode trunkset interfaces ae0 unit 0 family ethernet-switching vlan members data_wired_1aset interfaces ae0 unit 0 family ethernet-switching vlan members voip_wired_1aset interfaces ae0 unit 0 family ethernet-switching vlan members access_points_1aset interfaces ae0 unit 0 family ethernet-switching vlan members data_wireless_1aset interfaces ae0 unit 0 family ethernet-switching vlan members voip_wireless_1aset interfaces ae0 unit 0 family ethernet-switching vlan members management_1a
Commit the configuration.
root@EX3300VC-1a# commit
Connect the LAG connections to the core switch using the show lldp neighbors command to verify that the connection is up and you can see the other side of the connection.
root@EX3300VC-1a# run show lldp neighborsLocal Interface Parent Interface Chassis Id Port info System Namexe-0/1/0.0 ae0.0 a8:d0:e5:b5:0f:80 xe-0/0/6.0 EX4500VC-1axe-5/1/0.0 ae0.0 a8:d0:e5:b5:0f:80 xe-1/0/6.0 EX4500VC-1a
Run the show lacp interfaces command to verify that LACP is running.
root@EX3300VC-1a# run show lacp interfacesAggregated interface: ae0 LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity xe-5/1/0 Actor No No Yes Yes Yes Yes Slow Active xe-5/1/0 Partner No No Yes Yes Yes Yes Slow Active xe-0/1/0 Actor No No Yes Yes Yes Yes Slow Active xe-0/1/0 Partner No No Yes Yes Yes Yes Slow Active LACP protocol: Receive State Transmit State Mux State xe-5/1/0 Current Slow periodic Collecting distributing xe-0/1/0 Current Slow periodic Collecting distributing
Configure secure access port features.We recommend configuring these basic security features on the majority of the VlaNs on access switches. We need to
enable these features on the data_wired_1a and voip_wired_1a VlaNs.
You may notice that we do not enable these features on all the VlaNs. some VlaNs have a greater tendency to have
statically configured devices or may not require this feature. each device with a static Ip address attached to a port on
a VlaN – with these features enabled – requires a static port configuration with an Ip address and a maC address in
order to communicate with the rest of the network. If required, this additional level of security can be configured, but it
will add some overhead when network changes are made.
root@EX3300VC-1a# set interfaces interface-range wired_access_ports member-range ge-0/0/5 to ge-0/0/26set interfaces interface-range wired_voice_ports member-range ge-0/0/27 to ge-0/0/47set interfaces interface-range wireless_access_points member-range ge-0/0/0 to ge-0/0/4
Set the port mode.We need to set the port mode to access. Because we have used the interface-ranges statement, we only need to set
the port mode at the interface-range level, instead of editing every port.
root@EX3300VC-1a# set interfaces interface-range wired_access_ports unit 0 family ethernet-switching port-mode accessset interfaces interface-range wired_voice_ports unit 0 family ethernet-switching port-mode accessset interfaces interface-range wireless_access_points unit 0 family ethernet-switching port-mode trunk
root@EX3300-vc2# set vlans data_wired_1a interface wired_access_portsset vlans voip_wired_1a interface wired_voice_ports
the ports for the Wlas require a trunking configuration and require a native VlaN (access_points_1a) be configured in
order for the access point to boot up. When configuring a native VlaN you cannot configure the port VlaN members
with this same VlaN or it will ignore the native VlaN configuration and will not work as expected.
root@EX3300VC-1a# set interfaces interface-range wireless_access_points unit 0 family ethernet-switching vlan members data_wireless_1aset interfaces interface-range wireless_access_points unit 0 family ethernet-switching vlan members voip_wireless_1aset interfaces interface-range wireless_access_points unit 0 family ethernet-switching native-vlan-id access_points_1a
Configure layer 3 settings.layer 3 configuration for the access switch involves setting a default route in the case of the tested network. In this
case, it points to 10.10.28.1 which is the core switch Ip interface on the management_1a VlaN
set routing-options static route 0.0.0.0/0 next-hop 10.10.51.1
Commit the configuration.
commit
Verify IP reachability.Next, you need to verify Ip reachability by “pinging” the core switch management Ip address from the access switch.
this also indicates that trunking is configured properly on the interface and working properly.
root@EX3300VC-1a> ping 10.10.51.1PING 10.10.51.1 (10.10.51.1): 56 data bytes64 bytes from 10.10.51.1: icmp_seq=0 ttl=64 time=4.240 ms64 bytes from 10.10.51.1: icmp_seq=1 ttl=64 time=3.078 ms
Verify VLANs and trunking.to verify that the proper VlaNs are configured for trunking on the ae0 interface, you can use the show ethernet-
switching interfaces ae0 command.
root@EX3300VC-1a# run show ethernet-switching interfaces ae0Interface State VLAN members Tag Tagging Blockingae0.0 up access_points_1a 54 tagged unblocked data_wired_1a 12 tagged unblocked data_wireless_1a 36 tagged unblocked management_1a 51 tagged unblocked voip_wired_1a 24 tagged unblocked voip_wireless_1a 42 tagged unblocked
to see what ports are configured for specific VlaNs use the show vlans command.
NOTE: Because of the large number of ports in eX4200VC-3a, the show command output below show the first VlaN’s
output.
root@EX3300VC-1a> show vlansName Tag Interfacesaccess_points_1a 54 ae0.0*, ge-0/0/0.0*, ge-0/0/1.0, ge-0/0/2.0, ge-0/0/3.0, ge-0/0/4.0, ge-5/0/0.0*
Configure Class of Servicethe basic Class of service configuration used is almost identical across core and access platforms in the tested
network example.
We will configure Class of service on the access switch eX3300VC-1a. the configuration of Cos is done in five steps
the first four define what the Cos service will look like and the last step applies Cos to specific interfaces.
• Forwarding Classes
• Classifiers
• schedulers
• scheduler-maps
• rewrite rules
• Configuring Interfaces
Configuring forwarding classes.First we will configure the forwarding classes, this step also defines what queues are used as well.
root@EX3300VC-1a# set class-of-service forwarding-classes class control queue-num 7set class-of-service forwarding-classes class voice queue-num 5set class-of-service forwarding-classes class business-app queue-num 3set class-of-service forwarding-classes class server-bulk queue-num 1set class-of-service forwarding-classes class best-effort queue-num 0
Configuring classifiers.Next we will create the classifiers. In the tested network example we are only using DsCp marking for our classification
of traffic. the classifiers map the different DsCp marked packets to the correct queue, if the traffic is not marked or
marked with a DsCp value not listed it will be considered best-effort traffic and treated accordingly.
You should now be at the # prompt and ready to start configuring the switch.
Configure the password.
root# set system root-authentication plain-text-passwordNew password:*******Retype new password:*******{master:0}[edit]root#
Configure the time zone.
root# set system time-zone America/Los_Angeles
Configure the hostname.
root# set system host-name EX4200VC-2a
Configure the management and VME interface (optional)
set interfaces vme unit 0 family inet address 10.94.188.101/24
Configure management access.
root@EX4200VC-2a# set system services web-management https system-generated-certificateset system services sshdelete system services web-management httpdelete system services telnet
Configure DNS.
root@EX4200VC-2a# set system name-server 10.10.24.100set system domain-name xyzcompany.com
Configuring a Dedicated Mode Virtual Chassisto configure a Virtual Chassis for the access switch in dedicated mode:
Identify the Virtual Chassis type.In the case of the tested network, access switch eX4200VC-2a is a dedicated mode Virtual Chassis using only the VCp
ports to form the switching fabric interconnect. Configure a pre-provisioned Virtual Chassis.
to pre-provision a Virtual Chassis you need to identify the serial numbers of each device that will be part of the Virtual
Chassis, the device function, and the order in which you want each switch to be placed. later, when all of the switches
are connected and powered up, they will automatically be assigned the proper function and slot. make sure you pay
attention to the serial numbers and ordering of each switch when you connect them together later.
By default, the eX series devices automatically form a Virtual Chassis, but because the ordering is nondeterministic,
the switches may not be numbered sequentially. For more information about Virtual Chassis, see “Virtual Chassis” on
page 93, or the Day One book, Configuring EX Series Ethernet Switches.
root@EX4200VC-2a# set virtual-chassis preprovisionedset virtual-chassis member 0 role line-cardset virtual-chassis member 0 serial-number BP0211386965set virtual-chassis member 1 role line-cardset virtual-chassis member 1 serial-number BP0211386975set virtual-chassis member 2 role line-cardset virtual-chassis member 2 serial-number BP0211386950set virtual-chassis member 3 role routing-engineset virtual-chassis member 3 serial-number BP0211386957set virtual-chassis member 4 role routing-engineset virtual-chassis member 4 serial-number BP0211386944set virtual-chassis member 5 role line-cardset virtual-chassis member 5 serial-number FP0211490429set virtual-chassis member 6 role line-cardset virtual-chassis member 6 serial-number FP0211490761set virtual-chassis member 7 role line-cardset virtual-chassis member 7 serial-number FP0211490744
Configure specific Virtual Chassis commands.NOTE: by default split-detection is enabled, but because all devices are located in the same room, and there are dual
redundant connections between devices, an accidental chassis split is unlikely. split detection can be disabled by
issuing the command “set virtual-chassis no-split-detection”. If you are making a Virtual Chassis with only two devices
we recommend disabling split-detection. If you are not familiar with how split-detection works please review the
section on Virtual Chassis split-detection located in appendix a for more details.
using the VCp ports at the back of the units, cable each pair of eX series switches together. When all of the switches
are cabled properly, power up the remaining switch. Once all the switches are powered up, verify that all of the
members are active by running the Commit the configuration show virtual-chassis command.
Preprovisioned Virtual ChassisVirtual Chassis ID: a2e4.9152.3afeVirtual Chassis Mode: Enabled Mstr Mixed Neighbor ListMember ID Status Serial No Model prio Role Mode ID Interface0 (FPC 0) Prsnt BP0211386965 ex4200-48t 0 Linecard N 7 vcp-0 1 vcp-11 (FPC 1) Prsnt BP0211386975 ex4200-48t 0 Linecard N 0 vcp-0 2 vcp-12 (FPC 2) Prsnt BP0211386950 ex4200-48t 0 Linecard N 1 vcp-0 3 vcp-13 (FPC 3) Prsnt BP0211386957 ex4200-48t 129 Backup N 2 vcp-0 4 vcp-14 (FPC 4) Prsnt BP0211386944 ex4200-48t 129 Master* N 3 vcp-0 5 vcp-15 (FPC 5) Prsnt FP0211490429 ex4200-48px 0 Linecard N 4 vcp-0 6 vcp-16 (FPC 6) Prsnt FP0211490761 ex4200-48px 0 Linecard N 5 vcp-0 7 vcp-17 (FPC 7) Prsnt FP0211490744 ex4200-48px 0 Linecard N 6 vcp-0 0 vcp-1 1
Configure global Virtual Chassis commands.
root@EX4200VC-2a# set system commit synchronizeset ethernet-switching-options nonstop-bridgingset chassis redundancy graceful-switchover
Commit the configuration.
root@EX4200VC-2a# commit
Configure resilient dual-boot partitionsNOte: It is important to run this step as it improves the resiliency of the system in the case of primary boot partition
failure. this step creates a backup copy of the operating system and is highly recommended. this process takes
approximately 5 minutes for each re or member.
request system snapshot slice alternate all-members
Configure default settings.the following commands show items that should be enabled by default in the configuration. You may wish to review
and verify that these setting are desired for your specific network.
Disable RSTP on LAG connections to access switches.Because we do not use rstp as a topology protocol, we can disable it on the laG ports going to our access switches.
Disabling rstp also reduces potential convergence times in case a laG member fails, because fewer protocols need to
NOTE: Note all access switches have rstp enabled locally for loop protection.
root@EX4200VC-2a# set protocols rstp interface ae0.0 disable
Configure the trunk port and VLAN.Next, we need to configure the laG port as a trunk and add the VlaNs that will be supported going to the core switch.
to enable the laG port as a trunk port, use the set interfaces command.
root@EX4200VC-2a# set interfaces ae0 unit 0 family ethernet-switching port-mode trunk
Configure VLANs on trunk ports.VlaN configuration for ae0, which connects to the eX4500VC-1a switch, data_wired_1a, voip_wired_1a, data_
wireless_1a, voip_wireless_1a, the management_1a VlaN for switch management and access_points_1a for the Wlas to
reside. VlaNs can be added in a single statement surrounded by [] or can be added one line at a time. In this example
we will show each command.
set interfaces ae0 unit 0 family ethernet-switching vlan members data_wired_1aset interfaces ae0 unit 0 family ethernet-switching vlan members voip_wired_1aset interfaces ae0 unit 0 family ethernet-switching vlan members access_points_1aset interfaces ae0 unit 0 family ethernet-switching vlan members data_wireless_1aset interfaces ae0 unit 0 family ethernet-switching vlan members voip_wireless_1aset interfaces ae0 unit 0 family ethernet-switching vlan members management_1a
Commit the configuration.
root@EX4200VC-2a# commit
Connect the LAG connections to the core switch. the show lldp neighbors command will verify that the connection is up and that you can see the other side of the
connection.
root@EX4200VC-2a> show lldp neighborsLocal Interface Parent Interface Chassis Id Port info System Namexe-0/1/0.0 ae0.0 a8:d0:e5:b5:0f:80 xe-0/0/8.0 EX4500VC-1axe-7/1/0.0 ae0.0 a8:d0:e5:b5:0f:80 xe-1/0/8.0 EX4500VC-1a
Run the show lacp interfaces command to verify that LACP is running.
root@EX4200VC-2a> show lacp interfacesAggregated interface: ae0 LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity xe-0/1/0 Actor No No Yes Yes Yes Yes Slow Active xe-0/1/0 Partner No No Yes Yes Yes Yes Slow Active xe-7/1/0 Actor No No Yes Yes Yes Yes Slow Active xe-7/1/0 Partner No No Yes Yes Yes Yes Slow Active LACP protocol: Receive State Transmit State Mux State xe-0/1/0 Current Slow periodic Collecting distributing xe-7/1/0 Current Slow periodic Collecting distributing
Configure secure access port features.We recommend configuring these basic security features on the majority of the VlaNs on access switches. We need to
enable these features on the data_wired_1a and data_wireless_1a VlaNs.
You may notice that we do not enable these features on all the VlaNs. some VlaNs are more likely to have statically
configured devices or may not require this feature. each device with a static Ip address attached to a port on a VlaN
– with these features enabled – requires a static port configuration with an Ip address and a maC address in order to
communicate with the rest of the network. If required, this additional level of security can be configured, but it will add
configuration overhead when network changes are made.
root@EX3300VC-1a# set interfaces interface-range wired_access_ports member-range ge-0/0/5 to ge-0/0/26set interfaces interface-range wired_voice_ports member-range ge-0/0/27 to ge-0/0/47set interfaces interface-range wireless_access_points member-range ge-0/0/0 to ge-0/0/4
Set the port mode.We need to set the port mode to access. Because we have used the interface-ranges statement, we only need to set
the port mode at the interface-range level, instead of editing every port.
root@EX4200VC-2a# set interfaces interface-range wired_access_ports unit 0 family ethernet-switching port-mode accessset interfaces interface-range wired_voice_ports unit 0 family ethernet-switching port-mode accessset interfaces interface-range wireless_access_points unit 0 family ethernet-switching port-mode trunk
Configure port to VLAN.
root@EX4200VC-2a# set vlans data_wired_1a interface wired_access_portsset vlans voip_wired_1a interface wired_voice_ports
the ports for the Wlas require a trunking configuration and require a native VlaN (access_points_1a) be configured in
order for the access point to boot up. When configuring a native VlaN you cannot configure the port VlaN members
with this same VlaN or it will ignore the native VlaN configuration and will not work as expected.
root@EX4200VC-2a# set interfaces interface-range wireless_access_points unit 0 family ethernet-switching vlan members data_wireless_1aset interfaces interface-range wireless_access_points unit 0 family ethernet-switching vlan members voip_wireless_1aset interfaces interface-range wireless_access_points unit 0 family ethernet-switching native-vlan-id access_points_1a
Configure layer 3 settings.layer 3 configuration for the access switch involves setting a default route in the case of the tested network. In this
case, it points to 10.10.28.1 which is the core switch Ip interface on the management VlaN.
set routing-options static route 0.0.0.0/0 next-hop 10.10.51.1
Commit the configuration.
commit
Verify IP reachabilityNext, you need to verify Ip reachability by “pinging” the core switch management Ip address from the access switch.
this also indicates that trunking is configured properly on the interface and working properly.
root@EX4200VC-2a> ping 10.10.51.1PING 10.10.51.1 (10.10.51.1): 56 data bytes64 bytes from 10.10.51.1: icmp_seq=0 ttl=64 time=2.717 ms64 bytes from 10.10.51.1: icmp_seq=1 ttl=64 time=1.887 ms64 bytes from 10.10.51.1: icmp_seq=2 ttl=64 time=2.198 ms
Verify VLANs and trunking.to verify that the proper VlaNs are configured for trunking on the ae0 interface, you can use the show ethernet-
switching interfaces ae0 command.
root@EX4200VC-2a> show ethernet-switching interfaces ae0Interface State VLAN members Tag Tagging Blockingae0.0 up access_points_1a 54 tagged unblocked data_wired_1a 12 tagged unblocked data_wireless_1a 36 tagged unblocked management_1a 51 tagged unblocked voip_wired_1a 24 tagged unblocked voip_wireless_1a 42 tagged unblocked
to see what ports are configured for specific VlaNs use the show vlans command.
NOTE: Because of the large number of ports in eX4200VC-2a, the show command output below show the first VlaN’s
output.
root@EX4200VC-2a> show vlansName Tag Interfacesaccess_points_1a 54 ae0.0*, ge-0/0/0.0, ge-0/0/1.0, ge-0/0/2.0, ge-0/0/3.0, ge-0/0/4.0
Configure Class of Servicethe basic Class of service configuration used is almost identical across core and access platforms in the tested
network example.
We will configure Class of service on the core eX4500VC-1a. the configuration of Cos is done in five steps the first four
define what the Cos service will look like and the last step applies Cos to specific interfaces.
• Forwarding Classes
• Classifiers
• schedulers
• scheduler-maps
• rewrite rules
• Configuring Interfaces
Configuring forwarding classes.First we will configure the forwarding classes, this step also defines what queues are used as well.
root@EX4200VC-2a# set class-of-service forwarding-classes class control queue-num 7set class-of-service forwarding-classes class voice queue-num 5set class-of-service forwarding-classes class business-app queue-num 3set class-of-service forwarding-classes class server-bulk queue-num 1set class-of-service forwarding-classes class best-effort queue-num 0
Configuring classifiers.Next we will create the classifiers. In the tested network example we are only using DsCp marking for our classification
of traffic. the classifiers map the different DsCp marked packets to the correct queue; if the traffic is not marked – or
marked with a DsCp value not listed – it will be considered best-effort traffic and treated accordingly.
Wireless LAN ConfigurationIn this example we will step through all the essential steps in setting up wireless for corporate users and wireless Guest access.
WlCs will be clustered to provide Ha and load balancing of aps dynamically.
the guest access is for external access only it will provide guest users the ability to connect to the internet and is
isolated from the corporate network.
the setup process assumes your WlC is running the factory default configuration.
We will configure the Wireless laN Controllers in two steps.
1. Configure WlC2800-1b and WlC2800-2b with a base configuration providing Ip reachability using the quick start
configuration script.
2. Complete the configuration (clustering, ap specifics, VlaNs) of the WlCs using ringmaster.
Pre-requisites for WLAN ConfigurationIn order to complete the WlaN configuration section you will need to have the following software components
installed a network reachable server.
• ringmaster
• raDIus server
• DHCp server that supports option 43
Running Quick start on WLC2800-1bWe will use the quick start configuration script; it will guide you through the initial setup of WlC2800-1. It’s possible to
configure more items in quick start than we will be doing here, but this example steps through the process manually —
it allows more control and it will be easier to make changes later if needed.
NOTE: as we go through the Quick start pay close attention to vlan names, VlaN-IDs and password you select. these
items are all device independent and if they are out of sync with the other WlCs it can result in some seemingly
inconsistent behavior. also we will need the enable password for ringmaster to talk with the WlC.
• Connect to the console port of the WlC using settings 9600-8-N-1-None
• Hit the enter key a few times until you get a prompt.
• login with no username/password.
• enter “enable” at the prompt. No password is configured by default so just hit enter when prompted for a password.
• enter “quickstart” at the prompt.
WLC2800-0801B0# quickstart This will erase any existing config. Continue? [n]: yAnswer the following questions. Enter ‘?’ for help. ^C to break outSystem Name [WLC2800]: WLC2800-1bCountry Code [US]:System IP address []: 10.10.50.100System IP address netmask []: 255.255.255.0Default route []: 10.10.50.1Do you need to use 802.1Q tagged ports for connectivity on the default VLAN? [n]:Enable Webview [y]:Admin username [admin]:Admin password [mandatory]:Enable password [optional]:Do you wish to set the time? [y]:Enter the date (dd/mm/yy) []: 24/10/12Enter the time (hh:mm:ss) []: 13:21:00Enter the timezone []: PSTEnter the offset (without DST) from GMT for ‘PST’ in hh:mm [0:0]: -08:00Do you wish to configure wireless? [y]: nsuccess: created keypair for sshsuccess: Type “save config” to save the configurationsuccess: change accepted.
Now save your configuration.
WLC2800-1b# save configsuccess: configuration saved
Now connect port 8 on WLC-1 to EX8200VC-1B port ge-4/0/0.
Configuring VLANs and 802.1q trunking for WLC2800-1bIt is assumed that the associated switch port configuration on the eX8200VC-1B has already been done. If this is not
the case, please review the eX8200VC-1B configuration section and configure the associated ports for the WlCs.
the next configuration item is the system Ip address and VlaN that will be used and enable them on the trunk port.
the WlCs will be configured as part of the following VlaNs.
NOTE: the WlCs can be configured with a different vlan-id from the actual 802.1q tag this is specific to the WlC and
should not be confused with the 802.1q tag. For example you could have a vlan-id of 5 on the WlC, but it’s sent out as
802.1q tag 13 so to the network it is vlan-id 13. there can be advantages to this in more complex deployments, but that
is outside the scope of this document. to make things easier to understand we will configure the internal vlan-id the
same as the 802.1q tag that the rest of the network uses.
We will configure the following VlaN on WlC2800-1b
management vlan-id 50
Creating VLANs
set vlan 50 name management
Assigning VLANs to ports
set vlan 50 port 8 tag 50
Assigning IP interfaces to VLANsBy default the WlC will allocate the first Ip address (“system Ip address”) to VlaN 1. In our case we want this to be
VlaN 50 the management VlaN so we will first delete the Ip address association with VlaN 1 and then we will add it
to VlaN 50. NOte: this will still be the system address which has a special meaning to the WlC. the system Ip address
is the source Ip address the WlC uses to communicate with the access points to.
clear interface 1 IP
set interface management IP 10.10.50.100/24
Save your configuration.
save config
You should now be able to ping the Ip address of the eX8200VC-1B on the management VlaN.
WLC2800-1b# ping 10.10.50.1PING 10.10.50.1 (10.10.50.1) from 10.10.50.100 : 56(84) bytes of data.64 bytes from 10.10.50.1: icmp_seq=1 ttl=64 time=5.666 ms64 bytes from 10.10.50.1: icmp_seq=2 ttl=64 time=1.925 ms64 bytes from 10.10.50.1: icmp_seq=3 ttl=64 time=2.302 ms64 bytes from 10.10.50.1: icmp_seq=4 ttl=64 time=2.508 ms64 bytes from 10.10.50.1: icmp_seq=5 ttl=64 time=2.386 ms--- 10.10.50.1 ping statistics ---5 packets transmitted, 5 packets received, 0 errors, 0% packet loss
NOTE: you may notice we have configured the Ip address 10.10.50.100 twice. actually we configured this as the system
Ip address earlier now we are just assigning it to a VlaN. the system Ip address needs to reside on the management
network since that is the address that will be used to communicate to the aps and with other WlCs.
Running Quickstart on WLC2800-2bWe will use the quick start configuration script will guide you through the initial setup of WlC2800-1b. It’s possible to
configure more items in quick start than is done in this example, but we will step through the process manually – we
will have more control and it will be easier to make changes later if needed.
• Connect to the console port of the WlC using settings 9600-8-N-1-None.
• Hit the enter key a few times until you get a prompt.
• login with no username/password.
• enter enable at the prompt. By default, no password is configured. Just press enter when prompted for a password.
• enter “quickstart” at the prompt.
WLC2800-08033C# quickstartThis will erase any existing config. Continue? [n]: yAnswer the following questions. Enter ‘?’ for help. ^C to break outSystem Name [WLC2800]: WLC2800-2bCountry Code [US]:System IP address []: 10.10.50.101System IP address netmask []: 255.255.255.0Default route []: 10.10.50.1Do you need to use 802.1Q tagged ports for connectivity on the default VLAN? [n]: nEnable Webview [y]:Admin username [admin]:Admin password [mandatory]:Enable password [optional]:Do you wish to set the time? [y]:Enter the date (dd/mm/yy) []: 24/10/12Enter the time (hh:mm:ss) []: 13:30:00Enter the timezone []: PSTEnter the offset (without DST) from GMT for ‘PST’ in hh:mm [0:0]: -08:00Do you wish to configure wireless? [y]: nsuccess: created keypair for sshsuccess: Type “save config” to save the configurationsuccess: change accepted..
Save your configuration.
WLC2800-2b# save configsuccess: configuration saved
Connect port 8 on WLC2800-2 to EX8200VC-1B port ge-20/0/0
Configuring VLANs and 802.1q trunking for WLC2800-2bthis section assumes that the associated switch port configuration on the eX8200VC-1b has already been done. If this
is not the case please review the eX8200VC-1B configuration section and configure the associated ports for the WlCs.
Next we will configure the system Ip address and VlaN that will be used and enable them on our trunk port. the WlCs
will be configured as part of the following VlaNs.
the WlCs can be configured with a different vlan-id from the actual 802.1q tag. this is specific to the WlC and should
not be confused with the 802.1q tag. For example, you could have a vlan-id of 5 on the WlC, but it’s sent out as 802.1q
tag 13, so to the network it is vlan-id 13. there can be advantages to this in more complex deployments, but that is
outside the scope of this document. to make things easier to understand we will configure the internal vlan-id the
same as the 802.1q tag that the rest of the network uses.
We will configure the following VlaN on WlC2800-1b.
Uploading WLC2800-1b into RingMaster1. select the Configuration Navigation Bar button.
2. In the tasks panel, select upload WlC.
3. In the Ip address field, type the Ip address for WlC2800-1b.
4. In the enable password field, type the enable password for WlC2800-1b. this password must match the enable
password defined using the ClI command set enablepass. For more information, see the Juniper mobility system
software Configuration Guide.
5. Click Next. the uploading progress is shown.
6. after the successfully uploaded device message is displayed, click Finish.
7. If ringmaster displayed error or warning messages, select the Verification Navigation Bar button and go to Verifying
Configuration Changes.
Uploading WLC2800-2b into RingMaster1. select the Configuration Navigation Bar button.
2. In the tasks panel, select upload WlC.
3. In the Ip address field, type the Ip address for WlC2800-2b.
4. In the enable password field, type the enable password for WlC2800-2b. this password must match the enable
password defined using the ClI command set enablepass. For more information, see the Juniper mobility system
software Configuration Guide.
5. Click Next. the uploading progress is shown.
6. after the successfully uploaded device message is displayed, click Finish.
7. If ringmaster displayed error or warning messages, select the Verification Navigation Bar button and go to Verifying
Configuration Changes.
ringmaster starts with a default Network plan called “default” when we will first import the WlCs they will be
part of this Network.
Creating a Mobility Domain 1. First we will create a mobility domain.
2. select the Configuration Navigation Bar button.
3. select the Create mobility Domain task in the tasks panel. the setup mobility Domain wizard is displayed.
4. In the Name field, type the name for the mobility Domain (1 to 16 characters, with no spaces or tabs).
In our example we will call it “xyzcompany-HQ” Click Next.
5. From the available Devices list, select WlC2800-1b and WlC2800-2b to add to the mobility Domain.
6. Click Next.
7. select WlC2800-1b to act as the primary seed WlC for the mobility Domain.
8. to provide mobility domain redundancy, select WlC2800-2b to act as secondary seed. Click Finish.
Activating Changes from the cluster wizardthe wizard makes the appropriate changes in the individual WlCs, but does not activate these changes. this must
be done manually on both WlCs. ringmaster also provides the ability to review the changes on the device before
deploying them. If you would like to view the changes first you can select “review” from the tasks panel.
1. select the Configuration Navigation Bar button
2. select WlC2800-1b
3. In the tasks panel select “Deploy”, once deploy is completed press “close”
4. select WlC2800-2b
5. In the tasks panel select “Deploy” once deploy is completed press “close”
Creating a Cluster in the Mobility DomainWe will now create a cluster inside the mobility domain. When device are in a cluster the majority of configuration is
shared between the devices in the cluster – but some things are not; for example, items that are locally significant like
Ip addresses and local VlaNs. an easy way to understand what is shared and what is not between WlCs is to select
configuration from the toolbar in ringmaster and click on cluster configuration. all the items there are shared between
devices in the cluster. If you select one of the individual WlCs you will see the items that are specific to that WlC.
1. In the Organizer pane select “xyzcompany-HQ”
2. From the tasks pane select “setup Cluster”
3. Next
4. You should see both the WlCs displayed
5. Check the merge checkbox
6. press “Deploy Changes”
7. Next
8. everything should now complete, when overall progress is 100% press “Finish”
9. You should now see a cluster under “xyzcompany-HQ” called “xyzcompany-HQ Cluster” that contains both
WlC2800-1b and WlC2800-2b when expanded
Configuring VLANs We configured the system Ip address and VlaN id using the ClI already, but we need to add an additional VlaN for
Guest access to the WlCs. each of the WlCs will be configured to sit on the management and guest_wireless VlaNs.
later we will configure the individual Wlas for local switching and configure their VlaN mapping separately.
We have already configured the management VlaN and Ip so we will now configure the remaining VlaN that the WlC
will use.
NOTE: in the tested network example both WlCs are located in the same subnet and have the same VlaNs. You
should be careful when making device specific changes that have local significance like VlaN membership, etc… as
these are NOt sYNCrONIZeD between the WlCs in the cluster. make sure you pay attention as you configure the VlaN
information. For example: if you have one WlC configured with a VlaN called guest_wireless and the other configured
with one called wireless_guest by mistake, you will have some users that will not connect properly to the wireless
network – and some that will – because we load balance Wlas between controllers. On the surface it may seem like
random behavior when one user can connect and another in the same building cannot.
WLC2800-1b VLAN Configuration1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain
2. select WlC2800-1b
3. select the system-> VlaNs item
4. From the tasks pane select “Create VlaN”
5. set VlaN name and VlaN ID
• VlaN name: wireless_guest
• VlaN id: 60
6. Next
7. add WlC port(s) to the VlaN
• add port 8 to the VlaN wireless_guest
8. Next
Configure WLC IP address for VLAN 1. Ip address: 10.10.60.100/24
2. select “Interface enabled”
3. Finish
4. From the tasks pane select “Deploy”
5. select “close”
to verify the configuration you can select the VlaN you just configured and click properties. this will include the
information you just entered and some additional configuration panes that we will ignore for now.
Cluster Guest Wireless Authentication ConfigurationNow we will configure the smartpass server for the guest wireless users
1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain
2. select “xyzcompany-HQ Cluster”
3. select aaa -> raDIus
4. In the tasks pane select “Create raDIus server”
5. Name: smartpass_Guest_access_server
6. enter the Ip address of the raDIus server
• 10.10.64.100
7. enter the raDIus Key
• <radius key>
8. Next
9. Do not add this raDIus server to the existing raDIus group we will create a new one for it later
10. Finish
Configuring the RADIUS Authentication OptionsDepending on the setup of your raDIus server you may need to change the authentication protocol option of your
server or the authentication port.
1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain
2. select “xyzcompany-HQ Cluster”
3. select aaa -> raDIus
4. select the server “enterprise_raDIus_server”
5. press the “properties” button
6. select the authentication protocol pull-down menu and select the appropriate option for your raDIus server.
In the tested network we used msCHap-V2, but this could be different for your raDIus server configuration.
Creating a RADIUS Server Group for guest users1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain
2. select “xyzcompany-HQ Cluster”
3. select aaa -> raDIus
4. In the tasks pane select “Create raDIus server Group”
5. Name: “smartpass_Guest_access-GrOup”
6. Next
7. select the smartpass_Guest_access_server and add it to the group
8. Finish
Configuring the SmartPass authentication optionsDepending on the setup of your raDIus server you may need to change the authentication protocol option of your
server or the authentication port.
1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain
2. select “xyzcompany-HQ Cluster”
3. select aaa -> raDIus
4. select the server “smartpass_Guest_access_server”
5. press the “properties” button
6. select the authentication protocol pull-down menu and select the appropriate option for your smartpass server.
In the tested network we used NONe, but this could be different for your smartpass server configuration.
Activating changes1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain
VLAN Profile Building B1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain
2. select “xyzcompany-HQ Cluster”
3. select local switching
4. In the tasks pane select “Create VlaN profile”
5. Name: “Building_B”
6. Next
7. select the “add VlaN” button
8. We will configure the data_wireless_1b network first
• Name: data_wireless_1b
• Check “Is VlaN tagged”
• tag value 32
9. Click OK
10. Now click “add VlaN” again and add the voice wireless
• Name: voip_wireless_1b
• Check “Is VlaN tagged”
• tag value 40
11. Click OK
12. Next
13. We have not configured any Wlas yet so we will skip this step for now.
14. Finish
Activating changes1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain
2. select “xyzcompany-HQ Cluster”
3. select “Cluster Configuration”
4. select “Deploy”
Radio ProfilesCreating Radio Profiles for building A and Building Bradio profiles allow you to manage groups of Wlas easily in one spot. this is very handy when you need to configure
your channel plan and other features after the infrastructure has been deployed. In this tested network example
we have two simple plans – one for each building – but this could be more complex depending on the specific
requirements.
1. In the Organizer pane, select the “xyzcompany-HQ” mobility domain
2. select “xyzcompany-HQ” Cluster
3. select Wireless -> radio profiles
4. In the tasks pane select “Create radio profile”
5. enter “Building_a” for name
6. Next
7. We will skip adding radio profile members for the moment because we have not configured any Wlas yet.
8. Next
9. We will add service profiles in the next section so skip this for now
10. Finish
11. In the tasks pane select “Create radio profile”
12. enter “Building_B” for name
13. Next
14. We will skip adding radio profile members for the moment because we have not configured any Wlas yet.
15. Next
16. We will add service profiles in the next section so skip this for now
Preparing Clients for Wireless Connectivitymss uses 802.1X for access to secure (encrypted) ssIDs, like xyzcompany_internal, using dynamic keys. to allow a
wireless client access on an encrypted ssD with dynamic keys, 802.1X must be configured on the client.
time to set up that laptop.
Configuring a Client for Guest Accesslet’s configure a Windows laptop for guest access to the public network and see if things are working from this
perspective. the exact procedure, of course, depends on your operating system and hardware:
1. On your Windows 7 pC, right-click the Wireless icon on the toolbar at the bottom right of the screen.
2. select xyzcompany_guest from the list of available wireless networks.
3. Double-click and wait for a successful connection.
4. Once you’re connected, the Web portal page is displayed.
5. log in using the configured username and the password
Configuring a Client for Corporate AccessNow let’s configure a Windows 7 client for access to an encrypted ssID. the exact procedure, of course, depends on
your operating system and hardware:
1. In Windows 7, go to Control panel > Network and Internet >Network and sharing Center.
2. under Change Your Network settings, click Manually to connect to a wireless network.
3. enter acme-corp as the Network name.
4. From the security type list, select Wpa2-enterprise.
5. leave the encryption type as aes.
6. the default authentication method is microsoft:protected eap (peap).
7. Click settings.
8. Clear the Validate server certificate check box.
9. under select authentication method, the default method is secured password (eap-msCHapv2).
10. Click Configure.
11. Clear the automatically use my Windows logon name and password (and domain if any) check box. Click OK.
12. Click OK, and then click Close.
13. Click the Wireless icon in the toolbar, and select xyzcompany_internal from the list of available wireless networks. and
let’s connect to the xyzcompany_internal ssID; this is really easy!
If your laptop doesn’t automatically find the ssID, open Network Connections, and then right-click the Wireless
Connection icon. select View available Wireless Networks to display the list of networks in the area.
In Figure 18, three ssIDs are displayed. Double-click xyzcompany_internal to get connected.
Configuring the SRX Clusterto configure the srX series Gateway devices for the tested network, you must first perform the following setup
procedure for both srX series devices that will make up the cluster.
to perform the initial setup for the srX650 devices:
Unpack the SRX650 and connect a console cable to the serial port with the following settings: 9600, 8, 1 and none.
To access the SRX650 using the Junos OS CLI:1. Connect one end of the console cable to the serial port adapter, plug the adapter into a serial port on the pC or laptop,
and plug the other end of the cable into the console port on the srX series device.
2. start the terminal emulation program on the pC or laptop, select the COm port, and configure the following port
settings: 9600 (bits per second), 8 (data bits), none (parity), 1 (stop bits), and none (flow control).
3. press the pOWer button on the router, and verify that the pOWer leD turns green.
4. log in as root, and press enter at the password prompt. (When booting the factory default configuration, you do not
need to enter a password.)
5. enter the uNIX shell after you are authenticated through the ClI:
Amnesiac (ttyu0)login: rootPassword:- - - JUNOS 12.1R9 built 2011-11-16 09:23:09 UTC
6. at the % prompt, type “cli” to start the ClI and press enter. the prompt changes to an angle bracket (>) when you enter
ClI operational mode.
root@%cli root>
7. at the (>) prompt, type “configure” and press enter. the prompt changes from > to # when you enter configuration mode.
the cluster ID is the same on both devices, but the node ID should be different, with the node ID as node0 on one
device, at node1 on the other device.
this command should be issued on both devices at the same time so that they boot up together.
the range for the Cluster ID is 0–15. setting it to 0 effectively disables cluster mode.
after rebooting, the ge-0/0/0 and ge-0/0/1 interfaces become as fxp0 and fxp1, respectively.
Check both srX series devices to ensure that the cluster is active and that the primary and secondary devices are both
active.
NOTE: It may take a minute or two for the status to complete after booting, so you may need to enter this command
more than once. the prompt on each srX series device displays the status and node information for the respective
device.
{primary:node0}root> show chassis cluster statusCluster ID: 1Node Priority Status Preempt Manual failoverRedundancy group: 0 , Failover count: 1node0 1 primary no nonode1 1 secondary no no
{secondary:node1}root> show chassis cluster statusCluster ID: 1Node Priority Status Preempt Manual failoverRedundancy group: 0 , Failover count: 0node0 1 primary no nonode1 1 secondary no no
When the primary and secondary status is confirmed, move to the next step. If you encounter any problems during this
step, the following KB articles may be of use in diagnosing clustering problems: KB–15503, KB–20672 and KB–20641.
Configure the SRX Series cluster.
NOTE:
• the following steps are all performed on the primary srX series device. the configuration is automatically copied over to
the secondary srX series device when a configuration is committed.
• We use the Junos Os group configuration feature for this operation. For more information on the group configuration
feature, see the Day One book, Configuring Junos Basics.
• Configuring device-specific properties using the group command: set up device-specific settings such as hostnames
and management Ip addresses. this is specific to each device and is the only part of the configuration that is unique to
specific nodes. this is done by entering the following commands (all on the primary node):
On device srx650-1b: Enter configuration mode
root# configroot# set group node0 system host-name srx650-1bset group node0 interfaces fxp0 unit 0 family inet address 10.94.188.103/24set group node1 system host-name srx650-2bset group node1 interfaces fxp0 unit 0 family inet address 10.94.188.104/24
NOTE: the apply groups command is set so that the individual configurations for each node set by the above
root# commitYou should see the configuration applied to node0 and node1 when you issue a commit{primary:node0}[edit]root# commitnode0:configuration check succeedsnode1:commit completenode0:commit complete
Configure the Fabric Link Create FAB links (data plane links for RTO sync, etc).You need to first delete any specific configuration related to the interfaces. In this case ge-0/0/2 has an address
assigned by default so we will delete it.
root@srx650-1# set interfaces fab0 fabric-options member-interfaces ge-0/0/2 set interfaces fab1 fabric-options member-interfaces ge-9/0/2
Configuring Redundancy Groupsset up the redundancy Group 0 for the routing engine failover properties. also setup redundancy Group 1 (all the
interfaces will be in one redundancy Group in this example) to define the failover properties for the reth interfaces.
NOTE: If you want to use multiple redundancy Groups for the interfaces, refer to the Junos documentationSecurity Configuration Guide.
Configuring Interface Monitoring set up the Interface monitoring. monitoring the health of the interfaces is one way to trigger redundancy group failover.
NOte: Interface monitoring is not recommended for redundancy-group 0.
Configure VLANs and IP interfaces on the reth interface
root@srx650-1b# set interfaces reth0 vlan-taggingset interfaces reth0 redundant-ether-options redundancy-group 1set interfaces reth0 unit 0 description “Unit 0 must be given a VLAN tag so using a dummy tag to align units to tags”set interfaces reth0 unit 0 vlan-id 1set interfaces reth0 unit 44 description internet_edgeset interfaces reth0 unit 44 vlan-id 44set interfaces reth0 unit 44 family inet address 10.10.44.254/24set interfaces reth0 unit 50 description managementset interfaces reth0 unit 50 vlan-id 50set interfaces reth0 unit 50 family inet address 10.10.50.254/24set interfaces reth0 unit 60 description guest_wirelessset interfaces reth0 unit 60 vlan-id 60set interfaces reth0 unit 60 family inet address 10.10.60.254/24
Commit the configuration to activate it.
commit
Configure the Internet connections
root@srx650-1b# set interfaces ge-2/0/1 description “Primary Internet Connection”set interfaces ge-2/0/1 unit 0 family inet address 10.94.44.2/30set interfaces ge-11/0/2 description “Backup Internet Connection”set interfaces ge-11/0/2 unit 0 family inet address 10.94.44.6/30
Commit the configuration.
root@srx650-1b# commit
NOTE: even though we have configured interfaces, we will not have reachability because no security policies are in
place yet.
Configuring Security Zonesthe srX series services Gateways use a zone-based model for security. the most basic configurations typically have
just two zones: trust (the inside) and untrust (the outside). In our case we have four: untrust, guest, management, and
internet_edge.
NOTE: the security policies shown here are meant to be a starting point and may need to be adjusted to your specific
network. For example, the voice networks can talk to all devices in the intranet and internet currently, but you may want
to restrict the type of traffic allowed to only voice and signaling.
Configure the untrust security zone.the untrust zone is where the srX series devices connect to the Internet. this is considered the least trusted zone. We
have configured our internet-facing ports in this zone.
root@srx650-1b# set security zones security-zone untrust screen untrust-screenset security zones security-zone untrust interfaces ge-11/0/2.0set security zones security-zone untrust interfaces ge-2/0/1.0
root@srx650-1b# set security zones security-zone guest address-book address guest_wireless 10.10.60.0/24set security zones security-zone guest host-inbound-traffic system-services pingset security zones security-zone guest host-inbound-traffic system-services tracerouteset security zones security-zone guest interfaces reth0.60 host-inbound-traffic system-services dhcpset security zones security-zone guest interfaces reth0.60 host-inbound-traffic system-services bootp
Configure the Management security zone.
root@srx650-1b# set security zones security-zone management address-book address management_1a 10.10.51.0/24set security zones security-zone management address-book address management_1b 10.10.50.0/24set security zones security-zone management host-inbound-traffic system-services sshset security zones security-zone management host-inbound-traffic system-services httpset security zones security-zone management host-inbound-traffic system-services httpsset security zones security-zone management host-inbound-traffic system-services pingset security zones security-zone management host-inbound-traffic system-services snmpset security zones security-zone management host-inbound-traffic system-services tracerouteset security zones security-zone management interfaces reth0.50
Configure the Internet Edge security zone.the majority of the networks are contained in the internet_edge zone. We use a feature called address-book to map
our networks in this zone to user-friendly names for easier management. that should be easier to understand when
we configure our policies that just use subnet designations. We also need to allow OspF in this zone, because we will
communicate routing information with the eX series switch in this zone.
root@srx650-1b# set security zones security-zone internet_edge address-book address data_wired_1b 10.10.8.0/22set security zones security-zone internet_edge address-book address data_wired_1a 10.10.12.0/22set security zones security-zone internet_edge address-book address voip_wired_1b 10.10.20.0/22set security zones security-zone internet_edge address-book address voip_wired_1a 10.10.24.0/22set security zones security-zone internet_edge address-book address data_wireless_1b 10.10.32.0/22set security zones security-zone internet_edge address-book address data_wireless_1a 10.10.36.0/22set security zones security-zone internet_edge address-book address voip_wireless_1b 10.10.40.0/23set security zones security-zone internet_edge address-book address voip_wireless_1a 10.10.42.0/23set security zones security-zone internet_edge address-book address server_1b 10.10.46.0/24set security zones security-zone internet_edge address-book address server_2b 10.10.48.0/24set security zones security-zone internet_edge host-inbound-traffic system-services pingset security zones security-zone internet_edge host-inbound-traffic system-services tracerouteset security zones security-zone internet_edge host-inbound-traffic protocols ospfset security zones security-zone internet_edge interfaces reth0.44
{primary:node0}root@srx650-1> show routeinet.0: 32 destinations, 35 routes (32 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[Static/10] 6w1d 23:50:07 > to 10.94.44.1 via ge-2/0/1.0 [Static/20] 00:03:53 > to 10.94.44.5 via ge-11/0/2.010.10.8.0/22 *[OSPF/10] 1w2d 20:45:10, metric 2 > to 10.10.44.1 via reth0.4410.10.12.0/22 *[OSPF/10] 1d 04:12:46, metric 3 > to 10.10.44.1 via reth0.4410.10.20.0/22 *[OSPF/10] 1w2d 20:45:10, metric 2 > to 10.10.44.1 via reth0.4410.10.24.0/22 *[OSPF/10] 1d 04:12:46, metric 3 > to 10.10.44.1 via reth0.44…
For readability the remainder of the show route output not shown.
Verifying internal reachability.use the ping command to verify basic reachability to the internal gateway and external interface.
Configuring NATConfigure the Guest NAT policy.
root@srx650-1b# set security nat source rule-set Guest-to-untrust from zone guestset security nat source rule-set Guest-to-untrust to zone untrustset security nat source rule-set Guest-to-untrust rule Guest-source-nat match source-address 0.0.0.0/0set security nat source rule-set Guest-to-untrust rule Guest-source-nat then source-nat interface
Configure the Internet Edge NAT policy.
root@srx650-1b# set security nat source rule-set internet_edge-to-untrust from zone internet_edgeset security nat source rule-set internet_edge-to-untrust to zone untrustset security nat source rule-set internet_edge-to-untrust rule internet_edge-source-nat match source-address 0.0.0.0/0set security nat source rule-set internet_edge-to-untrust rule internet_edge-source-nat then source-nat interface
Configuring DHCP services for guest VLANsTo configure DHCP services for guest VLANS:
root@srx650-1b# set system services dhcp pool 10.10.60.0/24 address-range low 10.10.60.11set system services dhcp pool 10.10.60.0/24 address-range high 10.10.60.250set system services dhcp pool 10.10.60.0/24 domain-name xyzcompany.comset system services dhcp pool 10.10.60.0/24 name-server 208.67.222.222set system services dhcp pool 10.10.60.0/24 name-server 208.67.220.220set system services dhcp pool 10.10.60.0/24 router 10.10.60.254
Configuring general settings.set the date and time in the format: YYYYmmDDhhmm.ss
root@srx650-1> set date 201201220830.00Enter configuration modeConfigure the time zone.root@srx650-1# set system time-zone America/Los_Angeles
Configure DNS.
root@srx650-1# set system name-server 10.10.24.100set system domain-name xyzcompany.com
Configure management access.
root@srx650-1# set system services web-management https system-generated-certificateset system services sshdelete system services telnetdelete system services web-management http
Configure LLDP.
root@srx650-1# set protocols lldp interface ge-2/0/0.0set protocols lldp interface ge-11/0/0.0
Appendix A: Virtual Chassis Virtual Chassis for fixed configuration EX series switchesthe Virtual Chassis flexible scaling solution allows users to connect two or more individual switches together to form
one unit that is managed as a single chassis. Virtual Chassis is supported on the Juniper Networks eX3300, eX4200,
eX4500, and eX8200 series ethernet switches. In this section, however, we discuss only the eX3300, eX4500 and
eX4200 switches.
eX4200 and eX4500 series switches can be interconnected into a Virtual Chassis using the dedicated Virtual Chassis
ports (VCps) on the rear panel of the eX4200 switches, and the dedicated VCps on the Virtual Chassis modules in
the eX4500 switches. You can easily expand the Virtual Chassis configuration to include more member switches.
additional switches are added to an eX4200 or eX4500 Virtual Chassis by cabling together the dedicated VCps.
You can also expand a Virtual Chassis configuration beyond a single wiring closet. Interconnect switches located in
multiple wiring closets or in multiple data center racks by installing sFp, sFp+, or XFp uplink modules, the connect the
uplink module ports on eX4200 member switches or connect the 10-Gigabit ethernet sFp+ network interfaces on the
eX4500 member switches.
Types of Virtual ChassisWe assume that you are configuring at least two or more eX series switches as a single Virtual Chassis. If you are
configuring a standalone eX series switch, then you can perform the basic setup as listed in the Quick start guide that
comes with the switch. after setup, go to the section “Global setup for eX series switches.”
• Dedicated mode
• extended mode
• mixed mode
Dedicated Modethe dedicated mode is the most common method of connecting adjacent eX4500 or eX4200 series switches into a
single Virtual Chassis. Dedicated mode involves interconnecting the switches using the special Virtual Chassis ports
(VCps) at the back of the switch. the two commonly-used methods of cabling when connecting eX series switches
together are: daisy chained and braided ring.
NOTE: although Juniper Networks recommends using one of these two switch topologies; other topologies are
supported (but that is beyond the scope of this document.)
Extended Modethe extended Virtual Chassis method enables switches to be part of a single Virtual Chassis even when the switches
are far apart. You can use the optional uplink modules on the eX4200 switch to connect multiple switches, using
1-Gigabit ethernet and 10-Gigabit ethernet links to provide great flexibility in how a network is configured.
For example, you could have multiple wiring closets on a single floor managed as a single device. this simplifies many
operational tasks, because this reduces the number of individual devices that must be managed.
the eX3300 only uses 10Gbe ports to create a Virtual Chassis, so it is an extended type of Virtual Chassis by default
when compared to the eX4200/eX4500 series products. However, the eX3300 does not require purchase of uplink
modules, instead it has four fixed 10Gbe ports and two of these are already configured to support Virtual Chassis.
eX3300s are typically connected together using DaC cables because of their low cost as a short distance network
medium.
Mixed Modethe mixed -mode Virtual Chassis enables you to interconnect more than one type of switch to act as a single Virtual
Chassis. this is currently only supported between the eX4500 and eX4200 series switches, and provides the ability
to have high-density 10-Gigabit ethernet and 1-Gigabit ethernet in the same Virtual Chassis. this topic provides
configuration examples for each of these Virtual Chassis types.
Virtual Chassis tips for Fixed Configuration eX series switches:
• When you have a two-member Virtual Chassis, we recommend that you disable split detection.
• When you have three or more members in a Virtual Chassis, we recommend that you do not place uplinks on the master
routing engine.
Pre-provisioning of the Virtual ChassisIt is often desirable to deterministically control the role and member ID assigned to each member switch in a Virtual
Chassis. this is accomplished by creating a pre-provisioned configuration. switches can be pre-provisioned by using
the auto provisioning feature to automatically configure the uplink ports as VCps on the switches to be added.
although it is not mandatory to pre-provision each Virtual Chassis, we recommend it, and this is the process we use in
this guide.
NOTE: If you do not pre-provision the Virtual Chassis, the devices are numbered in the order in which they come up. For
example, if you have five switches in a Virtual Chassis and you turn on the middle switch, say #3, this will be member/
card 0, then you turn on the top switch next, and that will be member/slot 1 and you turn on the other switches at
about the same time the rest of the cards will be randomly filled so you may end up with chassis numbering something
like this.
member 1
member 4
member 0
member 3
member 2
although this is confusing, it is completely operational. You can re-assign slots later to make a more logical chassis, but
it is easier to avoid this in the first place.
prerequisites: the switches need to be set at factory defaults to follow this process.
To pre-provision the Virtual Chassis:1. understand what type of Virtual Chassis you will be setting up: Dedicated, extended or mixed. If you are unsure, see
“types Of Virtual Chassis”.
2. unpack and power up the switch you intend to be member 0. Go through the initial setup process for the switch.
3. Identify the serial numbers of the other switches that will be part of this Virtual Chassis. then decide what their function
will be—either routing engine or line card. You can only have two switches configured as routing engines and one will
be member 0 (the first device we booted up). You can change the roles for devices later if required.
the following is a sample set of configuration statements for a four-member Virtual Chassis, specifying each
member role and slot by serial number.
root@EX4500VC-1a# set virtual-chassis preprovisionedset virtual-chassis member 0 role routing-engineset virtual-chassis member 0 serial-number GX0211411253set virtual-chassis member 1 role routing-engineset virtual-chassis member 1 serial-number GX0211411250set virtual-chassis member 2 role line-cardset virtual-chassis member 2 serial-number FP0211333181set virtual-chassis member 3 role line-cardset virtual-chassis member 3 serial-number FP0211333260
4. Determine if you need to disable split detection.
• If your Virtual Chassis has only two members go to step 5: Disable split detection.
• If your Virtual Chassis has more than two members, go to step 6, step 7, or step 8, as appropriate for the type of
Virtual Chassis you want to set up (dedicated mode, extended mode, or mixed mode).
5. Disable split detection if desired or needed.
NOTE: Virtual Chassis split Detection
split detection is designed to avoid possible dual active-or split-brain conditions. this happens when the chassis
loses multiple Virtual Chassis connections and becomes partitioned into two separate Virtual Chassis. the default
behavior is for the primary routing engine to disable itself and the backup routing engine (re) to promote itself to
master.
In a two-switch Virtual Chassis this is not desirable. For example, if the backup re is powered off, the master re
will stop forwarding traffic. therefore we recommend disabling this feature in a two-switch configuration. For more
information, read about Virtual Chassis in the Junos Os documentation for Juniper Networks eX series ethernet
switches.
the below command disables split detection:
root@EX4500VC-1a# set virtual-chassis no-split-detection
Appendix B: Configuring DHCP on EX Series Ethernet SwitchesIf you do not have a central DHCp server or need a temporary DHCp solution, you can configure the eX series ethernet
switches to act as a DHCp server.
NOTE: the srX series firewalls are configured to provide DHCp information to guest wireless users in the tested
Network.
In the tested network design presented in this document, the core switches would be used as DHCp servers because it
has Ip addresses on each of the subnets in the network.
to enable the eX series to act as a DHCp server you need the following:
• Ip interface configured on each VlaN to receive DHCp
• Ip address pool and pool range to be allocated to users on each VlaN to receive DHCp
• Default gateway for users on each VlaN
• Domain name for users
• Name server for users
the sample that follows shows DHCp configured for the management VlaN presented in this guide. We already have
the Ip address configured as 10.10.28.1 for this VlaN.
set system services dhcp pool 10.10.28.0/24set system services dhcp pool 10.10.28.0/24 address-range low 10.10.28.11 high 10.10.28.250set system services dhcp pool 10.10.28.0/24 router 10.10.28.1set system services dhcp pool 10.10.28.0/24 domain-name xyzcompany.comset system services dhcp pool 10.10.28.0/24 name-server 10.10.24.100
Appendix C: EX8200 Virtual Chassis Overviewthe eX8200 Virtual Chassis is similar to the extended Virtual Chassis. this section details the connections and
processes required to set up the eX8200 Virtual Chassis for Building B. For more information, see Best Practice Guidelines for Deploying EX8200 Virtual Chassis Configurations.
Virtual Chassis technology was first introduced on the Juniper Networks eX4200 line of ethernet switches. Virtual
Chassis technology allows up to 10 interconnected eX4200 switches to operate as a single, unified, high bandwidth
device. these interconnections can be made using any combination of dedicated high-speed Virtual Chassis ports
(VCps) on the switch’s rear panel or front panel gigabit ethernet (Gbe) or 10Gbe fiber links.
eX8200 Virtual Chassis technology was first introduced with the Juniper Networks Junos® operating system 10.4
release, enabling up to two eX8200 chassis to be interconnected as a single logical device – with the ability to expand
to four.
the eX8200 Virtual Chassis architecture consists of redundant external routing engines – the Xre200 external
routing engine – capable of managing up to four eX8200 line Card Chassis (lCCs) connected using 1Gbe or 10Gbe
VCps and operating as a single chassis. unlike other virtual system technologies, eX8200 Virtual Chassis technology
separates the controller of the virtual system from the chassis routing engine. the Xre200s connect to the eX8200
chassis via the 1Gbe out-of-band
management ports on the routing engine modules are installed in the modular switch, forming a single Virtual Chassis
configuration as shown in Figure 24. these interconnections, known as dedicated VCp links, constitute the control
plane connection and do not carry data traffic.
Intra-XRE Connection for HA (1GbE)
XRE-LCC — Active XRE to Internal Routing Engine Connection (1GbE)
XRE-LCC — Standby XRE to Internal Routing Engine Connection (1GbE)
Intra-VC — 10GbE LAG Connection
ActiveXRE200
StandbyXRE200
EX8200Virtual Chassis
LAG
Figure 24: EX8200 Virtual Chassis with XRE200 Connected to Each Member
Figure 24 shows a fully meshed two-member Virtual Chassis configuration with two Xre200s and a single 10Gbe link
aggregation Group (laG) between lCCs. In an eX8200 Virtual Chassis configuration, each eX8200 chassis becomes
an lCC and are interconnected through eX8200-8Xs line cards using either a 10Gbe link or a laG bundle with up
to twelve 10Gbe line-rate links. this connectivity serves two functions: to allow data traffic between lCCs for single
homed access devices, and to pass control traffic between the eX8200 chassis in case of the failure of all dedicated
VCp links. the eX8200-8Xs line cards use small form-factor pluggable transceivers (sFp+) that can support
connections up to 40 km in distance. eX8200-based Virtual Chassis configurations can span a large metropolitan area.
If the Virtual Chassis members are located in the same or adjacent racks, low-cost direct attach cables (DaCs) can be
used as the interconnect mechanism. members of an eX8200 Virtual Chassis configuration can include a mix of the
Virtual Chassis Ports on the XRE200 External Routing Engineall Gbe ports on the Xre200 Virtual Chassis Control Interface (VCCI) modules are VCps. any of the VCps can be used
to connect eX8200 switches to the Xre200 to form a Virtual Chassis configuration and also to connect Xre200s
together to provide redundancy within the Virtual Chassis configuration. any link connecting an Xre200 to an eX8200
switch or to another Xre200 is a VCp link. No user configuration is required to configure these VCp links. all VCp links
on the Xre200 only carry Virtual Chassis Control protocol traffic.
Virtual Chassis Ports on EX8200 Member Chassisan eX8200 switch in standalone mode has no VCps. When a standalone eX8200 switch is enabled to function as a
Virtual Chassis switch, the management ports on the switch’s routing engines are converted into dedicated Xre-lCC
Virtual Chassis ports that carry the Virtual Chassis Control protocol traffic over the Xre-lCC VCp links. No further
configuration is required to configure these VCp links.
lastly, the intra-Virtual Chassis ports, which can only reside on the eX8200 switches, can only be configured on the
10Gbe eX8200-8Xs line cards. VCps on the 10Gbe eX8200-8Xs line card are enabled in pairs, i.e., ports that reside
on the same packet Forwarding engine (pFe). the eX8200-8Xs line card offers eight ports—0 through 7—with two
contiguous ports residing on the same pFe. If port 0 is enabled as a VCp, Junos Os will automatically enable port 1 as a
VCp. Intra-Virtual Chassis links between member switches in Virtual Chassis configuration are automatically configured
to form a single laG; no further user configuration is required. It is possible to configure up to 12 ethernet ports as VCps
to form a laG between member switches in a Virtual Chassis configuration.
For highest availability it is recommended to have a two-member laG at a minimum. However, a four-member laG
with two pairs of port members residing on different line cards is preferred.
table 16 provides a summary of differences between the eX8200VC and the eX4500/eX4200 Virtual Chassis
implementation.
Table 16: EX4200/4500 and EX8200 Side by Side Comparison
Member ID FPC Numbering Network Port Interface Range
0 0 through 15 for eX8216 0 through 7 for eX8208
xe-0/0/0 to xe-15/0/7 xe-0/0/0 to xe-7/0/7
1 16 through 31 for eX8216 16 through 23 for eX8208
xe-16/0/0 to xe-31/0/7 xe-16/0/0 to xe-23/0/7
2 32 through 47 for eX8216 32 through 39 for eX8208
xe-32/0/0 to xe-47/0/7 xe-32/0/0 to xe-39/0/7
3 48 through 63 for eX8216 48 through 55 for eX8208
xe-48/0/0 to xe-63/0/7 xe-48/0/0 to xe-55/0/7
For more details on the eX8200 Virtual Chassis please see the implementation guide Best Practice Guidelines for Deploying EX8200 Virtual Chassis Configurations or the operators manual located at www.juniper.net
Copyright 2013 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. 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.