Deploying Juniper Networks EX Series Ethernet Switches … · Port Connection ... Deploying Juniper Networks EX Series Ethernet Switches in ... which represent two different ...
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.
DEPLOYING JUNIPER NETWORKS EX SERIES ETHERNET SWITCHES IN BRANCH OFFICES
Although Juniper Networks has attempted to provide accurate information in this guide, Juniper Networks does not warrant or guarantee the accuracy of the information provided herein. Third party product descriptions and related technical details provided in this document are for information purposes only and such products are not supported by Juniper Networks. All information provided in this guide is provided “as is”, with all faults, and without warranty of any kind, either expressed or implied or statutory. Juniper Networks and its suppliers hereby disclaim all warranties related to this guide and the information contained herein, whether expressed or implied of statutory including, without limitation, those of merchantability, fitness for a particular purpose and noninfringement, or arising from a course of dealing, usage, or trade practice.
IMPLEMENTATION GUIDE - Deploying Juniper Networks EX Series Ethernet Switches in Branch Offices
Step 1: Define the number of LAG groups in the system.
root@access# set chassis aggregated-devices ethernet device-count 1
Step 2: Delete interfaces.
root@access# delete interfaces ge-0/1/2
Step 3: Configure interfaces to be part of a LAG.
root@access# set interfaces ge-0/1/2 ether-options 802.3ad ae0
Step 4: Configure LACP.
root@access# set interfaces ae0 aggregated-ether-options lacp active
Step 5: Configure the LAG interface as a Layer 2 trunk port and members to all VLANs.
root@access# set interfaces ae0.0 family ethernet-switching port-mode trunk vlan members all
The following show commands can be used to confirm that the LAG is up and running.
root@access> show lacp interfaces ae0 Aggregated interface: ae0 LACP state: Role Exp Def Dist Col Syn Aggr Timeout Activity ge-0/1/2 Actor No No Yes Yes Yes Yes Fast Active ge-0/1/2 Partner No No Yes Yes Yes Yes Fast Active ge-0/1/3 Actor No No Yes Yes Yes Yes Fast Active ge-0/1/3 Partner No No Yes Yes Yes Yes Fast Active LACP protocol: Receive State Transmit State Mux State ge-0/1/2 Current Fast periodic Collecting distributing ge-0/1/3 Current Fast periodic Collecting distributing
Virtual Chassis Technology
EX4200 switches may accommodate greater port densities by adding additional EX4200 switches to form a Virtual
Chassis configuration. Virtual Chassis configurations can be created either by connecting EX4200 switches with the
dedicated rear-panel Virtual Chassis ports (VCPs) or through the optional front-panel two-port 10 Gigabit Ethernet
or four-port Gigabit Ethernet uplink module. To enable VCP on the uplink ports, the following command is required on
both switches in Junos operational mode.
root> request virtual-chassis vc-port set pic-slot 1 port 3 member 0
A single Virtual Chassis configuration allows up to 10 EX4200 switches to be interconnected and managed as a single unit.
root> show virtual-chassis status Virtual Chassis ID: 0019.e250.8240 Mastership Neighbor List Member ID Status Serial No Model priority Role ID Interface0 (FPC 0) Prsnt BM0207431981 ex4200-24t 128 Master* 1 vcp-0 1 vcp-255/1/31 (FPC 1) Prsnt BP0207452211 ex4200-48t 128 Backup 0 vcp-0 0 vcp-255/1/3Member ID for next new member: 2 (FPC 2)
2. Master in previous boot among eligible switches
3. Uptime of the eligible masters (if uptime difference is more than 1 minute)
4. Lowest switch-based MAC address
root# set virtual-chassis member 0 mastership-priority 250
Preprovisioning
The preprovisioning feature is a deterministic way of predefining a switch member role (Routing Engine or line card)
prior to joining the Virtual Chassis configuration. The entire configuration is done under the master RE. Any member
that is not pre-provisioned will not be part of the Virtual Chassis configuration upon connection.
Step 1: Enable preprovisioning on the master Routing Engine.
root# set virtual-chassis preprovisioned
Step 2: Configure members’ roles on the master Routing Engine (all members need to be defined, including the master
Routing Engine).
root# set virtual-chassis preprovisioned member 0 serial-number xxxxxxxxxxxx role routing-engineroot# set virtual-chassis preprovisioned member 0 serial-number xxxxxxxxxxxx role routing-engineroot# set virtual-chassis preprovisioned member 0 serial-number xxxxxxxxxxxx role line-cardStep 3: Connect the members.
IMPLEMENTATION GUIDE - Deploying Juniper Networks EX Series Ethernet Switches in Branch Offices
GRES
Graceful Routing Engine switchover is a Junos feature that facilitates seamless failover between the master and
backup Routing Engines. When graceful Routing Engine switchover is enabled, the kernel and certain tables (MAC
address, route tables, port states, and so on) are synchronized between the master and the backup Routing Engine,
eliminating the need for the backup Routing Engine to relearn states and routes should the master Routing Engine fail.
Minimal packet loss should be expected during master failover when graceful Routing Engine switchover is configured.
root@coreB# set chassis redundancy graceful-switchover
VRRP
Virtual Router Redundancy Protocol (VRRP) is for routers and/or L3 switches acting as a default gateway to hosts on a
LAN network. Through an election process, VRRP assigns a master to the router/switch of the VRRP virtual router and
is responsible for routing traffic to and from the LAN segment. The VRRP backup router/switch is on standby, waiting to
take over in the event of a master failure (see Figure 9).
Figure 9: Logical representation of VRRP between L3 switches
VRRP is supported on all Juniper platforms running Junos and may be configured on a Layer 3 interface. EX Series
switches support up to 256 VRRP groups.
It is recommended that VRRP be configured on both core switches in a large branch office. The master VRRP should
align with the Multiple Spanning Tree Instance (MSTI) root bridge. A priority can be configured for the VRRP group to
ensure mastership. Additionally, Juniper recommends that preemption be configured in conjunction with the master
virtual router. Preemption ensures the device will always be the master virtual router if it is operational and active.
VirtualChassis
Root Bridge forVLAN Data
Virtual Router - 010.1.5.254
VRRP 0VRRP 0
VirtualChassis
Host 1IP: 10.1.5.252GW: 10.1.5.254
VLAN Data
coreA10.1.5.253Backup VRRP 0
coreB10.1.5.252Master VRRP 0
root@coreB# set interfaces vlan.5 family inet 10.1.5.252/24 vrrp-group 0 virtual-address priority 250 10.1.5.254 accept-data preempt
The following output shows a summary of VRRP groups, VR state, and local and virtual IP addresses.
root@coreB> show vrrp summary Interface State Group VR state Type Addressvlan.1 up 0 backup lcl 10.1.1.252 vip 10.1.1.254 vlan.5 up 0 master lcl 10.1.5.252 vip 10.1.5.254 vlan.10 up 0 backup lcl 10.1.10.252 vip 10.1.10.254
IMPLEMENTATION GUIDE - Deploying Juniper Networks EX Series Ethernet Switches in Branch Offices
Static Routes (Small and Medium Branch Offices)
In the small and medium branch office, the access switch typically will not be routing data traffic. Routing functionality
will be provided by the SRX Series. However, a static route is needed for management protocols—FTP, SSH, SNMP, and
so on. Although not covered here, the SRX Series will need to do some route distribution for the management traffic.
root@access# set routing-options static route 0.0.0.0/0 next-hop 10.1.1.254The “show route” command will display all the active routes.root@access> show route
inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[Static/5] 00:00:05 > to 10.1.1.254 via vlan.110.1.1.0/24 *[Direct/0] 00:00:05 > via vlan.110.1.1.1/32 *[Local/0] 00:02:44 Local via vlan.1
OSPF (Large Branch Office)
OSPF is a two-tier hierarchical link state routing protocol. The backbone area (area 0.0.0.0) must border every area in
its autonomous system. The backbone distributes routing information between areas. The routing table is based on the
shortest path tree in each area.
The core switches in the large branch office are responsible for routing data traffic to and from users to other locations
via the WAN. Therefore, OSPF will be enabled on the core devices (both core routers and switches). The following
configuration shows the commands for area 0.0.0.0. Customer-specific requirements may differ.
Step 1: Enable OSPF on the interface connecting to the J Series routers, assign the interface to an area 0.0.0.0, and
configure for authentication.
root@coreB# set protocols ospf area 0.0.0.0 interface ae0.0 authentication md5 1 key peerless
If the authentication fails, then the interface will not establish adjacency with the neighboring OSPF router.
Step 2: Advertise the VLAN networks (data, voice, server, and management) to corporate without enabling OSPF on
the RVI.
root@coreB# set protocols ospf area 0.0.0.0 interface vlan.1 passive
The following output can be used to confirm that OSPF has established a full adjacency with its neighbor.
root> show ospf neighbor Address Interface State ID Pri Dead10.1.3.2 ae0.0 Full 10.1.2.1 1 3010.1.3.6 ae1.0 Full 10.1.2.1 1 30
Step 3: Configure two multicast dense groups, 224.0.1.39 and 224.0.1.40.
Auto-RP requires multicast flooding to announce potential RP candidates and to discover the elected RPs in the
network. Multicast flooding occurs through a PIM dense mode model where group 224.0.1.39 is used for announce
messages and group 224.0.1.40 is used for discovery messages.
root@coreB# set protocols pim dense-groups 224.0.1.39root@coreB# set protocols pim dense-groups 224.0.1.40
Step 4: RP is like the multicast gatekeeper. All PIM sparse mode routers must determine where the RP is located. RP
information can either be configured statically or learned dynamically. From a manageability perspective, dynamically
is preferable to static.
root@coreB# set protocols pim rp auto-discovery
The following command is used to detect the RP information.
root@coreB> show pim rpsInstance: PIM.masterAddress family INETRP address Type Holdtime Timeout Groups Group prefixes10.255.14.144 auto-rp 0 None 1 224.0.0.0/4
Address family INET6
Spanning Tree Protocol
Spanning Tree is a Layer 2 protocol ensuring a loop-free network by blocking redundant Layer 2 paths in the LAN. The
EX Series switches support IEEE 802.1D (STP), 802.1s (Rapid Spanning Tree Protocol or RSTP) and 802.1w (Multiple
Spanning Tree Protocol or MSTP). On the EX Series switches, RSTP is enabled by default.
Note: For a better understanding of Spanning Tree, please refer to the implementation guide “Spanning Tree Protocol
IMPLEMENTATION GUIDE - Deploying Juniper Networks EX Series Ethernet Switches in Branch Offices
RSTP (Ideal for Small/Medium Branch Offices)
Even though there is typically a single switch/Virtual Chassis group in small and medium branch-office deployments,
it is recommended to enable some loop prevention feature such as RSTP. New features such as Edge Port in RSTP
improve convergence time over the IEEE 802.1D STP. The Edge Port feature allows a port to transition to a forwarding
state without the 30-second delay found in 802.1D STP. Edge Port is ideal for ports that are connected to PCs, IP
phones or any terminating devices. To be automatically classified as an Edge Port, the port must be in full-duplex
mode where no BPDU has been detected. Optionally, Edge Port may be manually configured for an interface that is in
half-duplex mode.
root# set protocols rstp interface ge-0/0/1.0 edge
The following command lists all the spanning-tree properties for the specified interface.
root> show spanning-tree interface ge-0/0/0.0 detail
Spanning tree interface parameters for instance 0
Interface name : ge-0/0/0.0Port identifier : 128.513Designated port ID : 128.513Port cost : 20000Port state : ForwardingDesignated bridge ID : 8192.00:19:e2:51:49:00Port role : DesignatedLink type : Pt-Pt/EDGE <--- Edge PortBoundary port : Yes
MSTP (Ideal for Large Branch Office)
MSTP is best suited for large branch-office deployments where the LAN consists of core and access switches with
redundant links. It is an extension of RSTP—with many of the same features—with the added capabilities of Multiple
Spanning Tree Instances (MSTIs). RSTP supports only a single instance per switch or Virtual Chassis configuration,
whereas up to 64 MSTI may be configured per switch/Virtual Chassis. MSTI allows all links to be in a forwarding state
and still maintain a loop-free network.
Step 1: Prior to configuring MSTP, RSTP must first be disabled or deleted.
root@coreB# delete protocols rstproot@coreB# set protocols mstp
Step 2: Configure common spanning tree (CST) and MSTI bridge priorities on the core switches.
• coreA will be root for MSTI 1 and CST and backup for MSTI 2.
• coreB will be backup root for CST and MSTI 1 and root for MSTI 2.
root@coreB# set protocols mstp bridge-priority 8kroot@coreB# set protocols mstp msti 1 bridge-priority 8kroot@coreB# set protocols mstp msti 2 bridge-priority 4k
root@coreB> show spanning-tree bridge STP bridge parameters Context ID : 0Enabled protocol : MSTP
STP bridge parameters for CIST Root ID : 8192.00:19:e2:51:49:00 CIST regional root : 8192.00:19:e2:51:49:00 CIST internal root cost : 0 Hello time : 2 seconds Maximum age : 20 seconds Forward delay : 15 seconds Number of topology changes : 0 Local parameters Bridge ID : 8192.00:19:e2:51:49:00 Extended system ID : 0 Internal instance ID : 0
STP bridge parameters for MSTI 1 MSTI regional root : 8193.00:19:e2:51:49:00 Hello time : 2 seconds Maximum age : 20 seconds Forward delay : 15 seconds Local parameters Bridge ID : 8193.00:19:e2:51:49:00 Extended system ID : 0 Internal instance ID : 1
STP bridge parameters for MSTI 2 MSTI regional root : 4098.00:19:e2:51:49:00 Hello time : 2 seconds Maximum age : 20 seconds Forward delay : 15 seconds
IMPLEMENTATION GUIDE - Deploying Juniper Networks EX Series Ethernet Switches in Branch Offices
CoS
In the branch office, class of service (CoS) is critical to maintain a high-performance enterprise network and ensure
prioritization of business-critical traffic when congestion occurs, as well as to meet latency and jitter requirements for
specialized types of traffic. Under a high traffic load, voice, video, and other critical applications may be delayed by
less critical or latency-/jitter-sensitive traffic in a best-effort (FIFO) queue. CoS manages the switch’s resources based
on traffic profile. It is recommended CoS be implemented at the access ports and any internetworking links (that is,
routers and switches).
Figure 13: EX Series
switches CoS model for classification, queuing, and scheduling
EX Series switches classify traffic based on 802.1p, DCSP, or IP Prec code points and/or MAC, IP, and TCP/UDP fields.
Traffic can be mapped to one of eight egress queues per port. By default, four forwarding classes are predefined:
network-control, assured-forwarding, expedited-forwarding, and best-effort. They are mapped to
Queue 7, Queue 5, Queue 1, and Queue 0, respectively. Of the four, only two forwarding classes are being used—
network-control and best-effort. Network-control is allocated with a 5 percent buffer of the dedicated port buffer, and
serviced as strict-priority (SP) while best-effort is allocated the remaining 95 percent, and serviced as SDWRR.
Forwarding Classes (Queuing)
EX Series switches support up to 16 forwarding classes and are system wide, but Juniper recommends configuring at least
five forwarding classes: network-control, voice, video, business applications (mission critical), and best-effort. Juniper
also recommends that these forwarding classes be mapped to egress queues 7, 5, 4, 2, and 0, respectively. Queues can be
allocated and configured for either SP or SDWRR. This will be discussed further in the “Scheduling” section.
Step 1: Define three egress queues for voice, video, and mission critical.
Classification SchedulingQueuing
NetworkControl
NetworkControl
Note: This diagram is notdefault CoS behavior.Configuration is required.
Q7
Q6
Q5
Q4
Q3
Q2
Q1
Q0
root# set class-of-service forwarding-classes class voice queue-num 5root# set class-of-service forwarding-classes class video queue-num 4root# set class-of-service forwarding-classes class business_applications queue-num 2
IMPLEMENTATION GUIDE - Deploying Juniper Networks EX Series Ethernet Switches in Branch Offices
root# set forwarding-class voice loss-priority low code-points 101110root# set forwarding-class video loss-priority low code-points 100110root# set forwarding-class video loss-priority high code-points [100100 100010]root# set forwarding-class business_applications loss-priority low code-points [010010 011010]root# set forwarding-class business_applications loss-priority high code-points [010100 011100]
The following output shows the DSCP classifier just created.
Note: Just a snippet is provided.
root# run show class-of-service classifier name branch_classifiersClassifier: branch_classifiers, Code point type: dscp, Index: 39944 Code point Forwarding class Loss priority 000000 best-effort low 000001 best-effort low ... 010010 business_applications low 010011 best-effort low 010100 business_applications high ... 011010 business_applications low 011011 best-effort low 011100 business_applications high ... 100010 video high 100011 best-effort low 100100 video high 100101 best-effort low 100110 video low ... 101110 voice low ... 110000 network-control low 110001 network-control low 111111 network-control low
Scheduling
The next step is to allocate queue buffers and configure queue scheduling. Juniper recommends the following
configuration—network-control and voice traffic should have at least a 5 percent buffer allocation and be enabled as a
strict high-priority (SP) queue. The application queue should have between a 30 and 35 percent buffer allocation and
a transmit rate of 40 percent. The best-effort will have the remaining buffer and transmit-rate allocation.
IMPLEMENTATION GUIDE - Deploying Juniper Networks EX Series Ethernet Switches in Branch Offices
Step 2: Create scheduler profile for network-control, voice, video, business applications, and best-effort. Buffer size,
queue priority (low or strict-high), and transmit-rate (weight) can be defined within each profile.
root# set nc_scheduler buffer-size percent 5root# set nc_scheduler priority strict-highroot# set voice_scheduler buffer-size percent 5root# set voice_scheduler priority strict-highroot# set video_scheduler buffer-size percent 15root# set video_scheduler priority lowroot# set video_scheduler transmit-rate percent 50 root# set bapp_scheduler buffer-size percent 25root# set bapp_scheduler priority lowroot# set bapp_scheduler transmit-rate percent 35root# set be_scheduler buffer-size remainderroot# set be_scheduler priority lowroot# set be_scheduler transmit-rate remainder
Note: On the EX Series, the egress queues can either be a strict high-priority queue (SP) or a low-priority queue. Strict
high-priority queues must always be the highest numbered queues. Any queues that are not SP are considered low
priority, which are SDWRR.
Step 3: Enter the CoS scheduler map and create a profile.
root# top edit class-of-service scheduler-maps branch_scheduler
Step 4: Apply the scheduler to the appropriate egress queue.
root# set forwarding-class network-control scheduler nc_schedulerroot# set forwarding-class voice scheduler voice_schedulerroot# set forwarding-class video scheduler video_schedulerroot# set forwarding-class business_applications scheduler bapp_schedulerroot# set forwarding-class best-effort scheduler be_scheduler
Step 5: Enter the CoS interface stanza.
root# top edit class-of-service interfaces
Step 6: Apply the classifier profile and scheduler map profile to an interface. This should be done on both user-facing
and uplink ports.
root# set ge-0/0/0 scheduler-map branch_scheduler unit 0 classifiers dscp branch_classifiersroot# set ae0 scheduler-map branch_scheduler unit 0 classifiers dscp branch_classifiers
The following output is the CoS summary for the interface.
IMPLEMENTATION GUIDE - Deploying Juniper Networks EX Series Ethernet Switches in Branch Offices
Option: For devices such as IPT or printers that cannot authenticate via 802.1X, use mac-bypass as an alternative
authentication method.
root@access# set protocols dot1x authenticator static 0a:0a:0a:0a:0a interface ge-0/0/0.0
The following command is used to view the 802.1X authentication.
root@access> show dot1x interface 802.1X Information:Interface Role State MAC address Userge-0/0/0.0 Authenticator Authenticated 00:1C:C4:7E:9E:F1 No User ge-0/0/1.0 Authenticator Connecting ge-0/0/3.0 Authenticator Authenticated 00:11:25:16:A2:F4 Dustin
Access-Security
There are three access-security features that should be deployed on the access switches to prevent “man-in-the-
middle” spoofing attacks, DHCP snooping, dynamic ARP inspection, and IP source guard.
Figure 15: Hacker posing as the end device
DHCP Snooping
DHCP snooping prevents rogue DHCP servers by allowing the switch to become aware of DHCP packets. When
enabling DHCP snooping on a EX Series switch, the following assumptions are made.
1. All access ports are untrusted and trunk ports are trusted.
2. On untrusted ports, only DHCP requests/discoveries are allowed. All other DHCP packets are dropped. The switch
also builds a DHCP snooping database of MAC addresses, port locations, VLAN, and IP-binding from DHCP
exchanges between the client and server.
Email Server L2/L3 Switch
Victim
Attacker
root@access# set ethernet-switching-options secure-access-port vlan data examine-dhcp
If there is a local DHCP server connected to the switch, then the port characteristics need to be changed from
“untrusted” to “trusted.”
root@coreB# set ethernet-switching-options secure-access-port interface ge-/0/0.0 dhcp-trusted
IMPLEMENTATION GUIDE - Deploying Juniper Networks EX Series Ethernet Switches in Branch Offices
The following command is to configure static entry for the DHCP snooping database. This is for devices that have static
IP addresses and do not rely on DHCP.
root@core# set ethernet-switching-options secure-access-port interface ge-0/0/0.0 static-ip 10.1.4.10 mac 0b:0b:0b:0b:0b:0b vlan server
The following command shows the DHCP snooping table.
root@access> show dhcp snooping binding DHCP Snooping Information:MAC address IP address Lease (seconds) Type VLAN Interface0A:0A:0A:0A:0A:0A 10.1.5.10 67678 dynamic data ge-0/0/0.00C:0C:0C:0C:0C:0C 10.1.5.15 67678 static data ge-0/0/10.00D:0D:0D:0D:0D:0D 10.1.10.12 77478 dynamic voice ge-0/0/1.0
Dynamic Arp Inspection (DAI)
DAI validates ARP packets on the network. The switch will intercept ARP reply packets from access ports and check
them against the IP-MAC database populated by DHCP snooping. If a mismatch is found, then the ARP packet will be
dropped, preventing any “man-in-the–middle” attacks such as ARP spoofing/poisoning.
root@access# set ethernet-switching-options secure-access-port vlan data arp-inspection
IP Source Guard
IP Source Guard is dependent on the DHCP snooping binding database. It cross-checks the IP source address and the
port upon which it was received. If the packet does not match the DHCP snooping binding database, then the packet
is discarded.
root@access# set ethernet-switching-options secure-access-port vlan data ip source-guard
Switch Management
EX Series can be configured, managed, and monitored either through a GUI or central network management device.
J-Web: J-Web is a simple intuitive GUI application that helps administrators configure, monitor, and upgrade the router.
EX Series switches support HTTP and HTTPS. HTTPS provides a secured access and therefore it is recommended.
root# set system services web-management https
Network and Security Manager: NSM is a centralized management system that allows administrators to manage
multiple devices such as firewalls, IDPs, routers, and switches. Its key design philosophy is to reduce the complexity
of management and simplify security device administration while maintaining the flexibility to address each
organization’s diverse needs. NSM provides a single, integrated management interface that allows all device
parameters to be controlled in a centralized location. It utilizes a complete set of investigative tools that provide in-
depth network visibility and give users access to the information required to fulfill their job responsibilities.
NSM can auto-discover EX Series switches with the following configurations.
root# set system services ssh protocol-version v2root# set system services netconf sshroot# set snmp view abc oid .1 includeroot# set snmp community public view abcroot# set snmp community public authorization read-only
root@access# set policy-options policy-statement directly_connected from interface [lo0.0 vlan.5 vlan.10]root@access# set policy-options policy-statement directly_connected then accept
Step 2: Enter RIP hierarchy.
root@access# edit protocols rip
Step 3: Enable RIP on an interface.
root@access# set group rip_branch neighbor ae0.0
Step 4: Configure authentication and password for RIP.
root@access# set authentication-type md5root@access# set authentication-key peerless
If the neighboring RIP peer does not have authentication and/or the wrong password is entered, then the interface will
IMPLEMENTATION GUIDE - Deploying Juniper Networks EX Series Ethernet Switches in Branch Offices
8010010-002-EN Mar 2010
Copyright 2010 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.
EMEA Headquarters
Juniper Networks Ireland
Airside Business Park
Swords, County Dublin, Ireland
Phone: 35.31.8903.600
EMEA Sales: 00800.4586.4737
Fax: 35.31.8903.601
APAC Headquarters
Juniper Networks (Hong Kong)
26/F, Cityplaza One
1111 King’s Road
Taikoo Shing, Hong Kong
Phone: 852.2332.3636
Fax: 852.2574.7803
Corporate and Sales Headquarters
Juniper Networks, Inc.
1194 North Mathilda Avenue
Sunnyvale, CA 94089 USA
Phone: 888.JUNIPER (888.586.4737)
or 408.745.2000
Fax: 408.745.2100
www.juniper.net
To purchase Juniper Networks solutions,
please contact your Juniper Networks
representative at 1-866-298-6428 or
authorized reseller.
Printed on recycled paper
About Juniper Networks
Juniper Networks, Inc. is the leader in high-performance networking. Juniper offers a high-performance network
infrastructure that creates a responsive and trusted environment for accelerating the deployment of services and
applications over a single network. This fuels high-performance businesses. Additional information can be found at