Application Notes for Configuring Juniper Networks
Total Page:16
File Type:pdf, Size:1020Kb
Avaya Solution & Interoperability Test Lab Application Notes for Configuring Juniper Networks “Simply Connected Network for Unified Services and Collaboration” utilizing Avaya Aura® Telephony Environment – Issue 1.0 Abstract These Application Notes describe the steps for configuring Juniper Networks “Simply Connected Enterprise network for Unified Services and Collaboration”. The sample configuration presented in these Application Notes provides an IP Infrastructure to support Avaya Aura® Communication Manager, Avaya Aura® Session Manager, One-X Communicators, Avaya Flare and Avaya WiFi Phones. Information in these Application Notes has been obtained through DevConnect compliance testing and additional technical discussions. Testing was conducted via the DevConnect Program at the Avaya Solution and Interoperability Test Lab. CRK; Reviewed: Solution & Interoperability Test Lab Application Notes 1 of 103 SPOC 8/16/2012 ©2012 Avaya Inc. All Rights Reserved. Juniper-Data.doc 1. Introduction These Application Notes describe the steps for configuring Juniper Networks “Simply Connected Enterprise network for Unified Services and Collaboration”. The sample configuration presented in these Application Notes provides an IP Infrastructure to support Avaya Aura® Communication Manager, Avaya Aura® Session Manager, One-X Communicators, Avaya Flare and WiFi Phones. Juniper Networks “Simply Connected Network for Unified Services and Collaboration” provides reference architecture for enterprises that wish to deploy Unified Communications (UC) services such as real-time voice, video and collaboration on a Juniper network. The architecture provides a converged IP Infrastructure to support the demands of UC on both the wired and wireless local area networks as well as across the WAN or public Internet. This application note documents a tested configuration for running Avaya-based Unified Communications across a campus, large branch or small branch environment using Juniper Networks EX-Series PoE Ethernet Switches, Branch SRX-Series Security Gateways and WLC/WLA-Series Wireless Controllers and Access Points. The environment was tested using Avaya Aura® Communication Manager, Avaya Aura® Session Manager, various 9600-Series endpoints, Avaya one-X® Communicator, Avaya Flare and Avaya wireless endpoints. 1.1. Highlights The sample network provided in these Application Notes implements the following features to provide a reliable and robust converged network for unified communications. Quality of Service QoS is required in converged networks to prioritize real-time latency sensitive traffic such as voice or video appropriately over other enterprise or internet-destined traffic that does not have such a strict real-time requirement. The design uses DSCP-based classification from the UC endpoints to provide 5 levels of service Chassis Clustering UC requires an always-on network with high-9s uptime. Deploying redundant devices in a Chassis Cluster to provide additional device-level resiliency in the event of a failure can ensure this. The design uses VirtualChassis Clustering on EX-Series Switches which allows you to extend a single switching infrastructure across up to 10 physical switches, in addition to providing sub-second failover of both forwarding and routing engines. The campus and large branch designs use SRX Clustering, which provides for stateful failover of IP and VPN traffic between two SRX Devices. This ensures rapid failover- times without impacting existing sessions or VPNs in the event of a failure of an SRX device. Link Aggregation To provide additional active paths between the access switch and the core switch, Link Aggregation (LAG) was used in the campus design. LAG links provide additional CRK; Reviewed: Solution & Interoperability Test Lab Application Notes 2 of 103 SPOC 8/16/2012 ©2012 Avaya Inc. All Rights Reserved. Juniper-Data.doc bandwidth and redundancy by load-balancing traffic at Layer 2 across all active links. If a link or device fails, LACP automatically detects this failure and re-directs traffic over the other links, providing for sub-second failover. LAG was also used between the access switch and the core firewall in the large branch configuration to provide additional link-redundancy and sub-second failover between the access layer and firewall layer. Redundant WAN Interfaces / VPN Tunnels Redundant WAN interfaces on the SRX series, as well as multihoming with more than one service provider, dramatically increase the reliability of the connection between a branch and the centralized locations from which the UC service is provided. Adding redundant interfaces allows you to preserve the full UC user experience in the event of an outage, without deploying a separate survivable branch service and dedicated PSTN connections at each branch. Examples for this approach include a managed service provider WAN with Internet access as a backup, or a DSL broadband connection to the Internet with a wireless WAN (3G/4G/LTE) connection for backup. LLDP-MED / Voice-VLAN Assignment Most enterprises wish to connect IP Phones to the network without any special switchport configuration; LLDP-MED helps facilitate that by identifying the type of device connected to the network, and assigning the Voice VLAN to media endpoint devices such as IP phones, video phones and conferencing systems. This eliminates the need for static port configurations on access switches for UC devices. DHCP Server with Options The JunOS DHCP Server was used to provide IP address assignment and custom DHCP options to Avaya endpoints. These simplified provisioning by allowing new or factory- default devices to bootup and obtain their initial configuration from the Avaya provisioning server by passing a custom DHCP options message. Wireless Multi-Media (WMM) WMM provides bandwidth allocation for voice and video traffic across the wireless LAN. Bandwidth can be allocated as a percentage of total bandwidth for voice or video calls, and call admission control can be enforced at the WLC controller. The UC Endpoints must support WMM Application-Layer Gateways (ALGs) SIP and H323 traffic traversing a firewall requires special consideration, ALGs help facilitate the opening and closing of pinholes as the protocol requires, and for example when a SIP INVITE is responded to, the corresponding RDP pinholes must be opened in the stateful firewall. When the SIP BYE message is received, the pinholes must be closed for that session. This allows the firewall to dynamically allocate sessions for corresponding RTP flows for both SIP and H323 traffic traversing the device. CRK; Reviewed: Solution & Interoperability Test Lab Application Notes 3 of 103 SPOC 8/16/2012 ©2012 Avaya Inc. All Rights Reserved. Juniper-Data.doc 2. General Test Approach and Test Results All test cases were performed manually. The general approach was to place various types of calls (SIP, H.323, wireless, oneX-Communicator w/ video, and Flare) to and from stations through the VPN tunnel. For feature testing, the types of calls included inbound and outbound calls through the VPN tunnel, transferred calls, conference calls, MWI and voicemail. For serviceability testing, failures such as cable pulls, and resets were applied. All test cases passed. Note: All Juniper devices were preconfigured by a Juniper engineer, before the actual test. The configuration Notes on Juniper devices were provided by the Juniper engineer, and included in Appendix. 2.1. Interoperability Compliance Testing The interoperability compliance test included feature and serviceability testing. The feature testing evaluated the VPN tunnel between SRXs with inbound, outbound, transfer, conference, MWI, and voicemail. The serviceability testing introduced failure scenarios to see if Juniper devices could resume operating after failure recovery. The following features were tested: 1) VPN Failover 2) Wireless through VPN tunnel 3) Wireless Roaming 4) Link Level Resiliency 5) Device Level Resiliency 6) Quality of Service end to end 7) POE / LLDP-MED / Voice VLAN DevConnect Compliance Testing is conducted jointly by Avaya and DevConnect members. The jointly-defined test plan focuses on exercising APIs and/or standards-based interfaces pertinent to the interoperability of the tested products and their functionalities. DevConnect Compliance Testing is not intended to substitute full product performance or feature testing performed by DevConnect members, nor is it to be construed as an endorsement by Avaya of the suitability or completeness of a DevConnect member’s solution. 2.2. Test Results All test cases were executed and verified. 2.3. Support Technical support on Juniper Network devices can be obtained through the following: Phone: (888) 314-5822 Web: http://www.juniper.net/support/requesting-support.html CRK; Reviewed: Solution & Interoperability Test Lab Application Notes 4 of 103 SPOC 8/16/2012 ©2012 Avaya Inc. All Rights Reserved. Juniper-Data.doc 3. Reference Configuration The sample network implemented for these Application Notes is shown in Figure 1 and Figure 2. Three office locations are included, a “Campus” a “Large Branch” and a “Small branch” The Main Campus consists of two Juniper SRX240s, named “SRX240-A” and “SRX240-B” operating in a chassis cluster and functioning as perimeter security devices and IPSec VPN head- ends. Juniper Networks SRX Cluster connect to a Juniper EX4500 Virtual Chassis, named “EX4500-A” and “EX4500-B” which provides core switching and routing within the campus and acts as the default route for all LAN