Juniper Networks EX Series Ethernet Switches/Cisco … · Juniper Networks EX Series Ethernet...

Juniper Networks EX Series Ethernet Switches/

Cisco VoIP Interoperability Test Results

September 25, 2009

Juniper Networks EX Series Ethernet Switches/Cisco VoIP Interoperability Test Results

2 Executive Summary Juniper Networks commissioned Network Test to assess interoperability between its EX Series Ethernet Switches and voice over IP (VoIP) telephony equipment from Cisco Systems. In all test cases attempted, the Juniper Networks switch infrastructure successfully delivered voice, video and E911 services. Notably, the test bed network used only open standards to transport VoIP traffic; no proprietary discovery mechanisms were required.

The following table summarizes the VoIP test cases and their outcomes.

Juniper / Cisco VoIP Interoperability Between Juniper EX Series Ethernet Switches and Cisco IP phones

Juniper EX Series Ethernet Switch function 7945 7960 7961 7970 7985 Basic transport: Registration, signaling, media

✔ ✔ ✔ ✔ ✔

IEEE 802.3af power over Ethernet ✔ ✔ ✔ ✔ ✔

Separate voice and data VLANs (static) ✔ ✔ ✔ ✔ ✔

Separate voice and data VLANs (dynamic, using LLDP / LLDP-MED)

✔ * ✔ ✔ *

QoS protection of VoIP traffic ✔ ✔ ✔ ✔ ✔

DHCP message forwarding ✔ ✔ ✔ ✔ ✔

802.1X authentication ✔ * ✔ ✔ *

MAC-based RADIUS authentication ✔ ✔ ✔ ✔ ✔

DHCP snooping ✔ ✔ ✔ ✔ ✔

Dynamic ARP inspection ✔ ✔ ✔ ✔ ✔

E911 new phone address/location discovery ✔ ✔ ✔ ✔ ✔

E911 phone movement ✔ ✔ ✔ ✔ ✔

*Not supported on phone; therefore not tested

Methodology and Results At a high level, the objective of all tests was to verify the ability of Juniper Networks EX Series Ethernet Switches to carry voice and video traffic between Cisco IP phones and a central communications controller. To meet this objective, Juniper and Network Test engineers constructed a test bed that modeled an enterprise setup with “headquarters” and “remote office” locations. In this scenario, the “headquarters” housed communications servers, in this case including:

• A Cisco Unified Communications Manager (Cisco UCM) that served as a private branch exchange (PBX) for all phones

• A RedSky Technologies, Inc. E911Manager Server for mapping locations to phone numbers for emergency services

• A Juniper Networks IC6000 appliance to provide authentication services for IEEE 802.1X testing


3 At the remote location, test engineers attached a variety of Cisco IP phones to the test bed, including a Cisco 7945; Cisco 7960; Cisco 7961; Cisco 7970; and a pair of Cisco 7985 video phones.

Figure 1 below illustrates the test bed.

Figure 1: The Juniper-Cisco VoIP Interoperability Test Bed

In this figure, a pair of Juniper EX Series Ethernet Switches connects headquarters and remote locations using IEEE 802.1Q virtual LAN (VLAN) tagging. Notably, the Cisco UCM and IP phones use different VLANs, as would commonly be the case in enterprises with multiple locations. Also using separate VLANs are the Juniper IC6000 authentication server and the Spirent TestCenter traffic generator/analyzer, used to create background traffic in QoS tests.

The EX4200 switch on the headquarters side of the test bed also used Juniper’s Virtual Chassis technology, allowing multiple switches to be interconnected and operate as a single, logical device to add more ports as they are needed. The headquarters side emulated a routed network that could include the wide-area network.

All Cisco VoIP equipment used Cisco’s Skinny Call Control Protocol (SCCP) to transport signaling messages between the IP phones and the Cisco UCM. However, SCCP transport required no special awareness or configuration on the Juniper EX Series Ethernet Switches.


4 Basic Transport: Registration, Signaling, Media Network Test made voice and video calls using Cisco VoIP equipment across a network consisting exclusively of Juniper Networks’ EX Series switches.

As shown in Figure 1 above, test engineers attached a Cisco UCM to one Juniper EX Series Ethernet Switch at “headquarters” and Cisco IP phones to another Juniper EX Series switch representing a remote location. The phones tested were Cisco 7945, 7960, 7961, 7970 and 7985 models; this last phone carried video as well as voice traffic.

For all combinations of phones, Network Test verified the ability of the phones to register with the Cisco UCM; to set up calls by exchanging signaling traffic with the Cisco UCM; and to carry media (voice and video) traffic between phones.

Power over Ethernet Juniper EX Series Ethernet Switches and most Cisco VoIP phones support the IEEE 802.3af specification for power over Ethernet (PoE). This method of delivering power speeds provisioning and simplifies cable management.

Network Test verified the ability of a Juniper EX Series Ethernet Switch to supply 802.3af power over Ethernet to all six phones tested. The Cisco 7985 phones used PoE for both video and voice, while all others used PoE for voice traffic.

Separate Voice and Data VLANs (Static) A best practice in network design is to allocate separate VLANs for voice and data traffic, helping to reduce jitter and latency for time-sensitive voice and video. This is especially important for IP phones with an integrated switch, allowing a PC to be attached.

Juniper EX Series Ethernet Switches support separation of voice and data traffic in both static and dynamically configured scenarios. To validate support for statically defined voice and data VLANs, test engineers configured the EX Series switches with the voip option, which accepts tagged voice traffic and untagged data traffic from each phone, and then manually set up separate voice and data VLANs on each phone.

To emulate PCs, Network Test attached the Spirent TestCenter traffic generator/analyzer to each phone’s data port and offered bidirectional streams of UDP traffic while concurrently attempting to make calls.

As in the base case above, all phones were able to call all other phones on the test bed. Further, test engineers noticed no degradation in audio quality compared with other tests without data traffic present.

Notably, the Juniper EX Series Ethernet Switches and Cisco phones used only standard IEEE 802.1Q VLAN tagging in this test; no proprietary mechanisms were required.


5 Separate Voice and Data VLANs (Dynamic) Although the previous scenario proved manual VLAN definition on each phone is possible, that approach will not scale as enterprises grow to support hundreds or thousands of phones. A more viable approach is for phones to dynamically learn VLAN configuration from switches, thus eliminating the need for manual phone setup.

To validate dynamic VLAN setup, Network Test began by restoring the Cisco phones to factory defaults. Next, engineers enabled the media endpoint discovery extensions to the IEEE’s link-layer discovery protocol with media endpoint discovery (LLDP-MED) on both the Juniper EX Series Ethernet Switches and the Cisco phones. This industry-standard protocol allows phones to learn configuration information and register with PBXs or proxies.

After enabling LLDP-MED on the Juniper EX Series switches (and, as before, the voip option for tagged voice and untagged data traffic), Network Test verified that the Cisco phones were able to make calls. As in the static configuration, the Spirent TestCenter traffic generator/analyzer offered UDP traffic to each phone’s data port, again with no perceived degradation in voice quality.

This test involved the Cisco 7945, 7961 and 7970 phones, which support LLDP-MED. Other phones tested do not support LLDP-MED and were not part of this scenario.

QoS Protection of VoIP Traffic Given the sensitivity of voice and video traffic to latency and jitter, it is essential to prioritize this traffic when congestion occurs. Experience in troubleshooting converged networks suggests that even small amounts of congestion can severely degrade voice and video quality and even lead to dropped calls.

Juniper EX Series Ethernet Switches can prioritize specific traffic classes based on multiple criteria, including 802.1p VLAN priority; diff-serv codepoint (DSCP) field value; source IP address; and other settings.

Network Test deliberately introduced congestion to validate that Juniper switches would protect voice and video traffic under overload conditions. As shown in Figure 2 below, four interfaces from a Spirent TestCenter traffic generator/analyzer offered bidirectional traffic at line rate across the test bed backbone, creating a 2:1 overload.


6

Figure 2: The QoS Enforcement Test Bed

This background traffic consisted of maximum-length 1,518-byte UDP/IP frames, the most stressful case possible for VoIP. Without prioritization enabled, relatively short (roughly 200-byte) voice frames would have to wait behind maximum-length frames, creating more delay on top of the loss induced by the overload condition.

Network Test validated the efficacy of the Juniper switches’ prioritization with “before” and “after” test scenarios. In the “before” case, with no prioritization configured on the EX Series switches, phones were unable to register with the Cisco UCM, let alone make calls.

In the “after” case, with Juniper EX Series switches configured to prioritize phone traffic based on 802.1p VLAN priority and source IP subnet, test engineers successfully placed calls among all phones. Engineers perceived no degradation in voice and video quality despite the 2:1 overload of background traffic.

As in previous tests, the Juniper EX Series Ethernet Switches relied solely on industry-standard mechanisms – in this case, IEEE 802.1p VLAN priority fields and source IP subnet addresses – to deliver phone traffic. No proprietary protocols were needed.


7 DHCP Message Forwarding In VoIP environments, it’s common practice for a PBX to serve as a dynamic host configuration protocol (DHCP server), giving phones IP networking information as well as telephony configuration. Since the DHCP exchange must take place first, before VoIP or other configuration occurs, a basic requirement for the switched infrastructure is the ability to pass DHCP messages.

To validate the ability of Juniper EX Series Ethernet Switches to forward DHCP traffic, Network Test enabled a DHCP server on the Cisco UCM and configured the Cisco IP phones to use DHCP on startup. Test engineers also used the JUNOS® Software analyzer feature to capture and verify the DHCP conversation.

In all cases, phones successfully requested and retrieved IP configuration information using DHCP. Examination of captured packets also validated a correct DHCP exchange.

802.1X Authentication Switch support for the IEEE 802.1X standard is a key requirement for network access control (NAC), a popular security framework in which a client’s identity determines which resources that client may reach over the network.

In the NAC model, an edge switch supporting 802.1X acts as a gatekeeper, passing messages between the client (or “supplicant”) and an authentication server. No access to the network is possible until the authentication server authorizes it. Although 802.1X support is relatively new in the telephony world (indeed, only three of six Cisco phones tested support it), it is likely to become increasingly important as enterprises recognize the need to secure voice and video on converged networks.

To validate correct operation of 802.1X authentication, Network Test constructed a test bed in which a Juniper EX Series Ethernet Switch acted as an authenticator and a Juniper IC6000 appliance acted as authentication server. This testing involved the Cisco 7945, Cisco 7961 and Cisco 7970 phones, which support 802.1X authentication; the other phones do not contain supplicant code and were not used for this test.

In an initial test to validate correct operation of the phones, engineers enabled 802.1X support on a Juniper EX Series Ethernet Switch but not on the phones. As expected, the switch did not grant network access to the phones, which in turn were unable to register with the Cisco CUCM or make calls.

Once engineers enabled 802.1X on the phones, the Juniper IC6000, a member of the Juniper Networks Unified Access Control (UAC) NAC solution, successfully authenticated the devices using the RADIUS protocol, and calls were possible as in the “Basic Transport” case above. Further, a status query via the switch’s command-line interface also showed correct operation of 802.1X authentication.

Because the 802.1X standard explicitly defines authentication of exactly one device per port, any attempt to authenticate multiple devices per switch port is by definition nonstandard. Nonetheless there may be scenarios – as with an IP phone with a PC


8 attached – where 802.1X authentication of multiple devices per port is highly desirable. Network Test validated the Juniper EX Series Ethernet Switch’s ability to perform 802.1X authentication for the phone alone; for the PC alone; and for a user-defined number of devices per port.

MAC-based RADIUS authentication While 802.1X-based authentication is a widely used access control mechanism, it also may be necessary to support MAC address-based authentication for clients that lack 802.1X supplicants. Examples of clients that may require MAC authentication include printers, web cameras, and many legacy IP phones (including three of the six Cisco IP phones tested in this project).

Network Test validated the ability of the Juniper EX Series switch to support MAC-based authentication in two modes: MAC only and combined MAC/802.1X mode. In the MAC-only scenario, engineers defined a MAC address as a “user” on the Juniper IC6000 authentication server and validated that a Juniper EX Series Ethernet Switch and authentication server granted access to that MAC address. In the combined mode, engineers verified that the switch granted access either via MAC address (as with the phone) or via 802.1X authentication (as with a supplicant running on the attached PC).

DHCP Snooping A key security requirement is to ensure clients using DHCP get their configurations from, and only from, authorized DHCP servers. Since DHCP itself provides no authentication capability, an attacker can easily attach a rogue DHCP server to the network, handing out unauthorized IP and VoIP configuration information. Even end-users in small-office, home-office (SOHO) settings may unknowingly deploy unauthorized DHCP services running on cable or DSL routers.

Juniper EX Series Ethernet Switches can protect against rogue DHCP servers, ensuring that IP phones and other devices learn configuration information only from authorized servers. To validate the correct operation of DHCP snooping, Network Test ran “before” and “after” scenarios involving a rogue server. In the “before” case, Network Test attached an unauthorized DHCP server to the Juniper EX Series Ethernet Switch, placing it in the same VLAN as the IP phones. In this case, the phones learned their configuration from the rogue server and not the authorized DHCP server across the network on the Cisco UCM.

In the “after” scenario, engineers enabled the JUNOS Software’s secure-access-port and examine-dhcp features for the IP phones’ VLAN. This time, packet captures validated that the phones learned configuration information from the authorized DHCP server running on Cisco UCM. There were no new entries in the rogue server’s log.


9 Dynamic ARP Inspection Poisoning of a switch’s address resolution protocol (ARP) cache is another common and dangerous form of attack; in a VoIP context, this attack can lead to intercepted or redirected calls. Many switches are subject to this vulnerability, in which an attacker sends a “gratuitous ARP” packet (an unsolicited ARP response message) containing a valid MAC and invalid IP address. The switch then will redirect traffic to and from a legitimate user’s MAC address. In a VoIP context, an attacker can capture entire VoIP phone calls with no awareness on the end-user’s part. Juniper EX Series Ethernet Switches have a “dynamic ARP inspection” (DAI) feature to guard against such attacks. As with previous security tests, Network Test validated correct DAI operation with “before” and “after” scenarios to determine whether the Juniper EX Series switches would guard against this vulnerability. In the “before” case, engineers attached a rogue PC to the same VLAN as the IP phones and ran a packet capture to intercept broadcast packets. These packets contained the MAC addresses of legitimate devices. Network Test then offered a gratuitous ARP packet from the rogue PC. Examination of packet captures and the Juniper EX Series switch’s ARP cache both confirmed that the rogue PC had successfully replaced a legitimate device’s ARP entry with its own. In the “after” case, engineers enabled the JUNOS Software’s secure-access-port, arp-inspection and examine-dhcp features for the IP phones’ VLAN. In this case, the switch built a table of authorized devices by watching legitimate DHCP exchanges, as in the DHCP snooping example above. When the rogue PC again tried to poison the ARP cache, the attempt was unsuccessful. A packet capture and the switch’s ARP cache display both showed that only the legitimate device had an ARP entry. E911 New Station Discovery Enhanced 911 (E911) systems associate a phone with a physical location, allowing emergency services personnel to pinpoint a caller’s location. The ability to pass phone-to-location mapping messages is a mandatory requirement for switches that support E911 services.

Juniper Networks asked Network Test to validate that its EX Series Ethernet Switches would support E911 services using vendor-neutral open standards. To do so, Juniper and Network Test partnered with RedSky Technologies Inc., the industry-leading supplier of E911 solutions.

RedSky’s E911Manager Server software requires only that switches use a read-only SNMP community name (via SNMPv1 or SNMPv2) to discover and perform location determination for new phones. A RedSky engineer preconfigured location information, such as floors within an office building, in the E911Manager Server software. After


10 Network Test enabled a read-only SNMPv1 community on the Juniper EX Series Ethernet Switches, each new phone successfully registered with the Cisco UCM. Network Test then verified phone-to-location mapping on the RedSky server. The RedSky server works by associating an Emergency Response Location (ERL) with an Emergency Location Identification Number (ELIN) from the phone. After a phone registers with the Cisco CUCM, the RedSky server then displays the ERL/ELIN mapping. In an actual emergency, the RedSky server would match the ERL/ELIN mapping against a pre-populated listing in an Automatic Location Information (ALI) database, which is usually maintained by the incumbent phone carrier. Notably, the Juniper EX Series Ethernet Switches did not require direct knowledge of the RedSky server. The only configuration needed on the switches was support for read-only SNMP communities, something that is commonly configured in enterprise settings even without E911 support. E911 Phone Mobility Unlike conventional phones, where number/location mapping typically does not change over time, IP phones may be mobile. IT staff may migrate IP phones as workgroups move to different offices, or phones may support Wi-Fi and roam among locations. In either case, continued E911 service requires that the switched infrastructure continue to pass ERL/ELIN mapping messages, even after the ERL part of the mapping changes. Network Test validated E911 mobility support by again enabling read-only SNMP communities on the Juniper EX Series Ethernet Switches. In this case, a RedSky engineer preconfigured the old and new location information in the vendor’s E911Manager Server software. After verifying the correct registration and ERL/ELIN mapping at the old location, test engineers then moved the phone to a new switch port. As before, engineers verified that the phone successfully registered with the Cisco UCM and also showed the new phone-to-location mapping on the RedSky E911Manager Server. Conclusion VoIP interoperability testing was successful in all test cases attempted. There were a few cases where some Cisco phones did not support LLDP-MED and/or 802.1X authentication; these phones were not used to test those protocols. However, interoperability worked as expected in all cases where a protocol was supported in all phones. Notably, the test network delivered all traffic – signaling, voice and video calls and E911 location services – using only open standards. This provides assurance to network professionals considering design or deployment of VoIP networks comprised of a mix of Juniper EX Series Ethernet Switches and Cisco telephony equipment.


11 Appendix A: Additional Resources Although this report focuses on VoIP interoperability, Network Test also has validated the interoperability of 15 common data networking protocols when connecting Juniper EX Series Ethernet Switches and Cisco switches. The following URL contains links to a report summarizing data networking interoperability; a “cookbook” with detailed configuration instructions for each protocol; and this report on VoIP interoperability: http://networktest.com/jnpriop

Appendix B: Software Versions Tested This appendix lists the software versions tested on all the test bed infrastructure devices used in this project. Juniper EX4200: JUNOS 9.5R2.1 Cisco Unified Communications Manager: 6.1.1.2000-3 RedSky E911Manager Server: 5.5.10.25043

Appendix C: Disclaimer Network Test Inc. has made every attempt to ensure that all test procedures were conducted with the utmost precision and accuracy, but acknowledges that errors do occur. Network Test Inc. shall not be held liable for damages which may result for the use of information contained in this document. All trademarks mentioned in this document are property of their respective owners. Version 2009092501. Copyright 2009 Network Test Inc. All rights reserved.

Juniper Networks EX Series Ethernet Switches/Cisco … · Juniper Networks EX Series Ethernet...

Documents

Transcript of Juniper Networks EX Series Ethernet Switches/Cisco … · Juniper Networks EX Series Ethernet...