Remote Location Testing? Transmit WiFi Traffic at a Remote Site for 12 Hours with LANforge WiFIRE

CT523-328-2ac-1n-bat LANforge WiFIRE 802.11a/b/g/n/ac 3 radio WiFi Traffic Generator (with Battery) Supporting 328 Virtual STA Interfaces

The CT523-328-2ac-1n-bat wireless traffic generator is an excellent choice for testing Access Points and other WiFi networks. The CT523-328-2ac-1n-bat uses a modified Wireless driver for WiFi NICs based on the Atheros chipset. The ath9k (a/b/g/n) chipset NICs can support up to 200 stations per radio. The ath10k (a/b/g/n/ac) chipset NICs can support up to 64 stations per radio. Each of the Virtual Stations has its own IP address, IP port space, MAC address and routing table. The Virtual Stations can be assigned to communicate to a particular Access Point, use a particular SSID, and Open or WPA/WPA2 authentication assigned. More advanced 802.1X authentication is also included. Each radio can be configured idependently of the other. Transmit power and channel/frequency is configured on a per-radio basis. Most other settings are configurable per virtual station.

There are two ath10k a/b/g/n/ac and one ath9k a/b/g/n WiFi radios per CT523-328-2ac-1n-bat and multiple LANforge systems can be clustered together for even more realistic radio interference patterns and increased traffic generation capability.

All virtual stations on the same radio must be on the same frequency, but as long as the protocol supports that fequency, the multiple protocols can be used concurrently. For instance, if the radio is configured for a 2.4Ghz channel, the stations can be /b, /g, /n, or /ac. If the radio is on a 5Ghz channel, the stations can be /a, /n or /ac. The bandwidth can be configured for all protocols. For 802.11n, configuring the MCS rates also determines the number of streams (1×1, 2×2, 3×3, etc.).

NOTE: ath10k 802.11ac radios and stations may be more limited in rate selection and other features for the initial release.

The Virtual Stations may be configured with all of the virtual interfaces on the same subnet, or different subnets, depending on the testing requirements. When used with something like VoIP, it allows all of the VoIP calls to use the standard IP ports (with one call per virtual interface).

The CT523-328-2ac-1n-bat has no fans and is silent. It has 9 antenna. It will fit into a small travel bag or briefcase for easy portability. No additional hardware or software is required, but it is suggested that you manage the system using the LANforge GUI on a separate machine. The CT523-328-2ac-1n-bat can also be managed over a serial console in text mode or through directly connected monitor, mouse and keyboard.

Remote Location Testing? Transmit WiFi Traffic at a Remote Site for 12 Hours with LANforge WiFIRE

Remote Location Testing? Transmit WiFi Traffic at a Remote Site for 12 Hours with LANforge WiFIRE

Quick Start Guide

  1. Connect Management Ethernet port to Management network or management PC. If connecting directly to a PC, an Ethernet cross-over cable should be used.
  2. Connect eth1 wired Ethernet interface to wired Ethernet interface on the AP or network under test. This usually is considered the ‘server’ side of the network.
  3. The Client side of the network will be the Virtual Stations configured on the CT523-328-2ac-1n WiFi NIC(s).
  4. Connect power brick to standard US or European AC power source. If using external battery pack, then connect to that instead.
  5. Install the LANforge-GUI on a separate management PC or Laptop. Windows and Linux GUIs are supported: Select the correct one from the CDROM or Candela Technologies Download page and install it. The CT523-328-2ac-1n appliance has a web server that also provides the LANforge GUIs.
  6. The CT523-328-2ac-1n should now boot. If DHCP is enabled on the Management network, the CT523-328-2ac-1n will automatically acquire an IP address. If DHCP is not available, the IP address will be set to 192.168.1.101 by the LANforge scripts.
  7. Start the LANforge-GUI on the management PC and click the ‘Discover’ button. It should find the CT523-328-2ac-1n appliance and add the IP address to the drop-down box in the Connect widget. Press ‘Connect’ and you will be connected to the CT523-328-2ac-1n.
  8. Select the Port Mgr tab in the GUI. Double-click on the device called ‘wiphy0’. This is the Radio device, and should be configured for the correct, channel, country-code, etc. Next, select one or more of the Virtual Station interfaces and click ‘Modify’. Enter the correct IP address information, SSID and WEP or WPA/WPA2 key (if Enabled). After applying these changes, the Virtual Station interface should associate with the AP and be ready to send traffic. You may create up to 328 Virtual Station interfaces per CT523-328-2ac-1n with the ‘Create’ button.
  9. Once the interfaces are configured correctly, you can click on the Layer 3, VOIP/RTP and other LANforge-FIRE related GUI tabs and configure/modify/start/stop particular traffic patterns that utilize the virtual stations and wired Ethernet interface. In most cases, you will want one of the FIRE endpoints to be on the wired interface and the other to be on the WiFi Virtual Station interface. It is also valid to generate traffic between two Virtual Station interfaces. The GUI Plugins menu (and right-click on some tables) provides some plugins to do automated testing and reporting. Contact support if you have suggestions for improvements.
  10. Any GUI modifications take place immediately after you click ‘Submit’.

LANforge WiFIRE Related Images
Virtual Station Configuration Screen

Remote Location Testing? Transmit WiFi Traffic at a Remote Site for 12 Hours with LANforge WiFIRE

Layer 3 (Ethernet, UDP, TCP) Connections

Remote Location Testing? Transmit WiFi Traffic at a Remote Site for 12 Hours with LANforge WiFIRE

Layer 3 Create/Modify Screen

Remote Location Testing? Transmit WiFi Traffic at a Remote Site for 12 Hours with LANforge WiFIRE

Software Features

  • Supports real-world protocols:
    • Layer 2: Raw-Ethernet.
    • 802.1Q VLANs.
    • PPPoE: Integrated PPPoE support.
    • Layer 3: IPv4, IPv6, UDP/IP, IGMP Multicast UDP, TCP/IP.
    • Layer 4: FTP, HTTP, HTTPS, TFTP, SFTP, SCP
    • 802.11a/b/g/n Wireless Station (up to 200 per machine).
    • 802.11a/b/g/n/ac Wireless Station (up to 128 per machine).
    • Layer 4: TELNET, PING, DNS, SMTP, NMAP (via add-on script).
    • File-IO: NFSv3, NFSv4, CIFS, iSCSI.
  • Supports up to 1000 concurrent TCP connections with base license package.
  • The CT523-328-2ac-1n-bat is able to push up to 345Mbps through an AP, depending on the protocols mix, wireless mode and environment, and speed of the network under test. Supports at least 60 VoIP (SIP, RTP) calls if appropriate licenses are purchased. When all two ath10k a/b/g/n/ac and one ath9k a/b/g/n radios are configured on different channels, combined maximum upload speed exceeds 625Mbps (NOTE: Tested with 802.11a/b/g/n NICs. The ath10k a/b/g/n/ac chipset NICs have not been performance tested yet.) More powerful systems are also available.
  • Supports real-world compliance with ARP protocol.
  • Supports ToS (QoS) settings for TCP/IP and UDP/IP connections.
  • Uses publicly available Linux and Windows network stacks for increased standards compliance.
  • Utilizes libcurl for FTP, HTTP and HTTPS (SSL), TFTP and SCP protocols.
  • Supports file system test endpoints (NFS, CIFS, and iSCSI file systems, too!). File system mounts can use the virtual interface feature for advanced testing of file server applications.
  • Supports custom command-line programs, such as telnet, SMTP, and ping.
  • Comprehensive traffic reports include: Packet Transmit Rate, Packet Receive Rate, Packet Drop %, Transmit Bytes, Receive Bytes, Latency, Jitter, various Ethernet driver level counters, and much more.
  • Supports generation of reports that are ready to be imported into your favorite spread-sheet.
  • Allows packet sniffing and network protocol decoding with the integrated Wireshark protocol sniffer.
  • GUI runs as Java application on Linux, Solaris and Microsoft Operating Systems (among others).
  • GUI can run remotely, even over low-bandwidth links to accommodate the needs of the users.
  • Central management application can manage multiple units, tests, and testers simultaneously.
  • Includes easy built-in scripting for iterating through rates and packet sizes, with automated reporting. Also supports scriptable command line interface (telnet) which can be used to automate test scenarios. Perl libraries and example scripts are provided!
  • Automatic discovery of LANforge data generators simplifies configuration of LANforge test equipment.
  • LANforge traffic generation/management software is supported on Linux, Solaris and MS Windows.

Hardware Specification

  • High-End Appliance with no fans.
  • Operating System: Fedora Linux with customized 64-bit Linux kernel.
  • Two 1Gbps Ethernet ports, room for three wifi NICs.
  • Intel i7-2655LE 2.2 GHz processor.
  • RJ45 Serial console (115200 8 N 1) for console management & initial configuration.
  • VGA/DVI-D, USB ports for desktop usage.
  • 8 GB RAM.
  • 40 GB Solid State Hard Drive.
  • Larger storage drives available.
  • 9-30v 4AMP external power supply (brick).
  • Weight: 8 lbs
  • Dimensions: 11 x 8 x 2.6 inches Metric: 277 x 194 x 67 mm.
  • Operating Temperature: -20 ~ 55°C.
  • Certification: CE Emission, FCC Class A, RoHS Compliant.
  • UPS-500AD External battery with 12+ hours runtime.
    • Capacity:Lithium battery 12v 26Ah 288Wh; Total Efficiency: Rated 500W, Peak 1000W; Output Waveform: Modified Sine Wave
    • AC Input Voltage:110-220V 50/60Hz
    • AC Output Voltage:110V 60Hz or 220V 50Hz
    • DC Output(4 barrel ports):12V/8A (10A MAX);
    • USB Output(4 ports):5V/ 6.2A
    • LED Light:1W,Max 3W
    • Solar Input Charging Panel (Panel Not Included): Voltage 18V 20-100W
    • Overload, Short circuit protection
    • Size:12.60 x 5.91 x 8.66in
    • Weight:3.2 kgs

Additional Feature Upgrades

Unless otherwise noted in the product description, these features usually cost extra:

  • WanPaths (LANforge-ICE feature set)
  • Virtual Interfaces: MAC-VLANs, 802.1Q VLANs, WiFi stations, etc
  • FIRE Connections: Base FIRE license includes 1000 active connections.
  • WiFi RF Attenuator: Adjust WiFi signal strength in a controllable manner.
  • SMA RF Cable Bundle: Used to cable LANforge WiFIRE radios to device-under-test.
  • LANforge-ICE Network Emulation.
  • VOIP: Each concurrent call over the included package requires a license.
  • Armageddon: Each pair of ports requires a license if not already included.

Thanks to Candela for the article.

Candela Tech Releases LANforge 5.3.2!

This release provides Linux 4.0 kernel support, HotSpot 2.0-r2 authentication, and improves 802.11AC support.

Release 5.3.2 (July 31, 2015)
New Features & Improvements

  • Layer-3: Support ‘AUTO’ payload size. This will select MTU sized frames for UDP, and will use 64k payloads for TCP and SCTP.
  • Update to latest lib-curl and c-ares libraries (Feb 24, 2015)
  • Update to latest iw, hostap, iproute2, iptables and related tools/libraries.
  • Support Linux 4.0 kernel for latest drivers and features.
  • Support Fedora-21 OS for latest applications and bug fixes.
  • WiFi-HotSpot 2.0-R2: Support OSEN authentication methods.
  • WiFi-HotSpot 2.0-R2: Support acting as HS20-R2 server-side. This requires Fedora 17 or higher OS, as well as some manual configuration.
  • WiFi-HotSpot 2.0-R2: Support manual connection to HS20-R2 APs, including OSEN encryption, OSU display and selection, and 802.1x authentication with production AP.
  • WiFi 802.11AC: Add support for tx/rx bps stats for 802.11AC Radio. Improve stat collection in general to better deal with firmware resetting the stats to zero when firmware restarts.
  • WiFi 802.11AC: Improve WiFi channel activity reporting (requires 4.0 kernel).
  • Support running radius server (using hostapd) on non-VAP interfaces. This helps make it easier to have LANforge manage some of the HS20 server side features. The .conf file must be hand-created by the user, and must be named: /home/lanforge/wifi/hostapd_.conf, for instance: /home/lanforge/wifi/hostapd_eth0#0.conf Select the ‘RADIUS’ service in the Port-Modify to enable.
  • WiFi: Show 802.11AC and OSEN capabilities in the scan results table.
  • WiFi: Support ADHOC (IBSS) mode with RSN encryption. Tested in both ath9k a/b/g/n radios and ath10k a/b/g/n/AC radios.
  • WiFi: Support 801.11AC LANforge vAP in 40Mhz channel mode. For some reason, it often takes a second port reset 10+ seconds after changing after changing the vAP from HT80 to HT40 before the vAP works properly.
  • WiFi: Fix problem where 802.11AC stations did not properly detect that an AP has become un-available.
  • WiFi capacity plugin: Support concurrent UDP + TCP connections, add latency report graph, allow hiding most graphs for more concise reports.
  • NFS: Attempt to cleanup stuck mount points. LANforge will kill any still-alive processes after 30 seconds of stopping the endpoints, and the same check will be made on (re)starting an Endpoint as well.
  • This still does not fix all hangs, but it cleans up some of the problems at least.
  • File-IO: Support opening files for writing with O_APPEND (instead of always using O_TRUNC). Default is still to use O_TRUNC.
  • 2544 script: Enable ‘pps’ rate setting for Layer-3 connections. Previously, these only supported ‘bps’ rates. Configured speed is ‘low-level’ and tries to estimate the number of frames sent over the network device. This is often different from the ‘PDU per second’.
  • Layer3 traffic: Fix tx/rx bytes and other counters when an endpoint using multi-conn > 0 is restarted due to network interface restart (or change of IP, etc).
  • DHCP-Client: Add support for vendor-id (Option 60) for dhcp client requests. Also allow user to create custom dhcp client config files if more flexibility is needed.
  • WiFi Capacity plugin: Add latency graphs, enable save/restore for configurations, enable UDP + TCP mix, enable ‘AUTO’ settings for most configurables.
  • WiFi-Attenuator: Add plugin to programatically change attenuations to emulate a device moving relative to APs (ie, walking down the street). Includes reports from the LANforge AP on the station’s signal strength, tx/rx rates, and the configured attenuation. This should be helpful when testing how mobile phones deal with migrating from one AP to another, for instance.

Bug Fixes

  • Fix UDP connections to properly auto-configure a reasonable sized send/receive buffer when ‘OS Default’ is selected. This worked long ago, but was broken when the ‘Same’ option was added for maximum-tx-rate. Tune the settings to work better with today’s networks and update GUI mouse-over to explain things better.
  • Fix ANQP/GAS queries on 802.11ac (ath10k) wifi interfaces. The problem was a bug in the ath10k firmware that has now been fixed.
  • Fix bug that broke multi-conn Layer-3 connections on the Management port.
  • Fix Port-Reset plugin in LANforge-GUI.
  • Fix bug where endpoints would not properly quiesce if a GUI was not connected. Endpoints now push a notification to controlling process if they quiesce, so the GUI polling is no longer required to propagate the state.

Thanks to Candela Tech for the article. 

Release Notes for LANforge FIRE & ICE 5.2.13

Candela Lanforge FireCandela Lanforge Ice

New Features & Improvements:

  • WiFi: Enforce licensing for 802.11AC NICs. LANforge will now only allow WiFi stations to be used if there is an 80211AC license key for the wiphy device. Customers that have previously purchased 802.11AC should request a new license from their sales contact before upgrading to LANforge 5.2.13. There will be no charge for the new key in this case. 
  • Improve Layer-3 UDP performance, especially with smaller packets. Testing shows about double the number of packets-per-second when compared to previous LANforge releases. Should be able to generate near Gbps speed with MTU sized PDUs on moderately powerful hardware now.
  • Add CLI script to stop Layer-4 connections after a number of URL requests or time has elapsed.
  • Add Rate vs Attenuation graphs to 2544 and Hunt scripts.
  • 802.11AC: Allow faster connection rate for 802.11AC stations. It was kept slow to work around some crashes seen in earlier kernels/firmware, but these problems are now fixed.
  • 802.11AC: Ensure we do not pass un-encrypted frames with FCS errors up the stack. This may help with problems where LANforge received corrupted UDP frames and reset the connection, causing throughput glitches.
  • 802.11AC: Support up to 64 vdevs (virtual stations). If sniffing, a separate monitor interface may be preferred, and in that case only 63 stations can be configured.
  • Layer-4: Allow explicit enabling and disabling of FTP PASV ane EPSV options. PASV works better through firewalls and NAT than does PORT (which is used if PASV is disabled).
  • Layer-4: Improve rate-control when using bits-per-second limit. Now, the bits-per-second rate will be adhered to across URLs instead of just when processing a single URL. The rate will be the lesser of the urls-per-second and the bits-per-second configuration.
  • WiFi: WiFi capacity plugin now supports cloning a Layer-4 (http, ftp, etc) connection in order to do the capacity testing. This should help test scenarios where it is not convenient to have a LANforge machine on the upstream side of the network: Any web/ftp server can now be the upstream side.
  • Support 4-module Attenuator.
  • Scripts: Add ability to create, start, stop, and delete multicast endpoints using the lf_firemod.pl script. Add lf_mcast.bash to show how this might be used.
  • WiFi: Improve RTS Threshold (RTS/CTS) and Fragmentation Threshold support. Values are set properly now, configured on the wiphyX radio devices. Note that even when disabled, RTS/CTS will be used when the network adapter has to retry sending a packet. This is due to an optimization in the Linux rate control algorithm.
  • WiFi (802.11AC): Add Alert to let user know when the ath10k 802.11AC firmware has crashed and requires reboot to recover. Check the Alerts tab if your 802.11AC system is not able to bring up stations or APs, and reboot the LANforge if the “FW-FAIL” alert is listed.

Bug Fixes:

  • Fix ‘radvd’ IPv6 router-advertisement daemon usage in Netsmith. This probably doesn’t affect anyone or we would have found the problem sooner!
  • Fix potential kernel corruption related to ARP.
  • Hunt-Script: Report best rate, not just the last successful rate.
  • Fix ToS problem in Armageddon feature: Could not set ToS to values less than 0x10 due to kernel bug.
  • Fix WEP authentication when 802.1x configuration was previously configured for the station. The 802.1x config options are now properly ignored when WEP is enabled.
  • Fix some issues with DHCPv6. Re-order the dhclient program’s socket code a bit to bind to device before binding socket. This appears to fix problem where only the first dhclient process could reliably receive leases from the server.
  • Fix Netsmith problem with saving DHCPv6 client information if DHCPv6 DNS address was not configured.

Thanks to Candela for the update.

 

Release Notes for LANforge FIRE & ICE 5.2.12

candela-lanforgefirecandela-lanforgeice

 

Release 5.2.12

New Features & Improvements:

  • Support 802.11AC (ath10k) hardware, with customized firmware. This enables basic 802.11AC features with up to 36 stations per NIC. Some instability remains when using this hardware, so reboots may be required to recover.
  • Improve CLI scripts, especially lf_portmod.pl, lf_firemod.pl and the new NFS testing script: lf_nfs_io.pl
  • Add ‘set_flag stream_events’ CLI command to enable CLI to receive events (as seen in GUI Event tab) as they are created.
  • Add Thresholds for Layer-3 and Armageddon endpoints. Allows user to set min/max tx and rx rate bounds and if the connection throughput is outside of that an alert and/or event will be created. Good for longer term throughput tests.
  • full support for Layer-3, Armageddon endpoints.
  • Only tx/rx rate and no-rx-since supported on File-IO endpoints.
  • Add option to verify file-system remains mounted on expected file-system type for File-IO endpoints. See ‘Use FSTATFS’ checkbox in the File-IO modify window.
  • WiFi: Enable support for configuring IEEE80211w (Management Frame Protection) for Virtual Station interfaces.
  • WiFi: Support 802.11r combined with 802.11u (HS20/Passpoint)
  • Support Ubuntu 14.04 with automated lf_kinstall.pl script.
  • Update LANforge Live-CD image to be Lubuntu 14.04 (lightdm desktop Ubuntu) based system.
  • GUI: Add plugin to automate resetting ports (network interfaces).

Bug Fixes:

  • WiFi: Fix setting regulatory domain so that it works independently of the time-zone configured in the operating system.
  • Fix issue with configuring randomized MACs when creating interfaces on the Port-Mgr GUI screen, and similar fix to Port batch-modify logic.
  • Make sure GUI’s global-stats never includes stats from stopped endpoints.
  • Fix memory consumption problem where Layer-3 TCP endpoints would get confused and think they need to buffer up to 16MB before completing the receive of the frame. LANforge now detects the corrupted header and automatically re-starts the connection when this error hits. Root cause of the corruption is not known at this time: It could be kernel and/or ath9k (wifi a/b/g/n) driver related, or could be bug in how LANforge processes the Layer-3 TCP connection logic. It could also be expected behaviour related to LANforge disabling the ‘time-wait’ state for TCP connections in order to re-use IP ports faster. To date, this has only been reproduced when running stress-tests on Layer-3 connections on ath9k station interfaces.

The only work-around for earlier releases is to manually stop, delete, and re-create connections in this state.

The root cause will be further investigated.

Thanks to Candela for the article.

Making the Most of Public WAN for Private Cloud Applications

Sometimes clouds mean storms. The enterprise cloud is no different.

Cloud-hosted applications create a number of challenges for network administrators, especially when they run over a public wide area network, as most do. Today’s delivery chain for applications is somewhat decoupled, with the WAN carrying data from enterprises to apps housed in offsite data centers outside of the enterprises’ purview. The public WAN’s performance is absolutely crucial to application delivery, but the public WAN doesn’t provide much visibility into those applications.

Further compounding the challenges, even small changes in the network can magnify application performance problems. And poor network performance is more than just a nuisance for business-critical applications like video, VoIP, unified communications and virtual desktops, all of which are creeping ever more into the cloud.

How do you detect and resolve issues in the network if it’s not actually your network?

The WAN Plays a Critical Role in Application Delivery

Packet loss within a WAN can occur for many reasons, including network congestion or protection events such as route reconvergence and network misconfigurations. Furthermore, most WANs are oversubscribed and leverage network statistics to maximize available capacity. Data traffic is unpredictable, so wide area networking equipment, such as switches, routers and gateways, can react to network congestion by selectively discarding certain packets.

And don’t be fooled by low packet loss numbers. Even in the 1 to 2 percent range, packet loss’s effects on application performance are often disproportionately large, causing effects ranging from jitter on a phone call to the crash of a virtual application. Packet loss often equals application throughput decrease or outright failure. It’s further compounded by a significant increase in latency.

Getting ahead of the curve is critical. Administrators must be able to pinpoint the location and source of latency and determine beforehand what the implications to specific applications could be.

The chart below shows the effect of packet loss and application latency for applications using TCP/IP.

WAN Emulation

The Situation Today

Full network visibility and understanding of the innards of an application require more than simply keeping an eye on bandwidth consumption per protocol. HTTP traffic has very diverse levels of business priority. Without sufficient application-level visibility, it’s difficult for enterprises to make sure their available network resources are, for example, bolstering ROI sufficiently.

But today there exists no simple way to measure user-application response times end-to-end throughout the entire service delivery network, since the network involves both proprietary and external networks. In order to understand and manage user experiences, isolate the sources of performance impairments, and make the necessary adjustments to network settings and policies in real time, enterprises need to employ new strategies.

Distributed applications require distributed data-capture strategies in order to be able to isolate issues. Although an increasing number of network devices provide embedded traffic classification and monitoring capabilities, the implementations often result in performance-impacting consequences, cost more, and often lack the ability to look beyond packet headers.

An effective solution must look deep into the content within the applications. The growing mobile-user presence and the increased complexity of network environments means that users typically pick up IP addresses dynamically. For this reason, a user could have several IP addresses during a single session. This evolution of the network makes it nearly impossible to monitor, secure, and manage solely by IP address.

Requirements for New WAN Monitoring Solutions

A truly network-wide monitoring solution, extending to remote branch offices, must provide access to key performance information, including

  • Measurement and analysis of application performance for all transactions
  • Comparisons of response times against intelligent baselines and thresholds
  • Identification of abnormal latencies in the network
  • Isolation of a problem to a specific link or application server, or the application itself
  • Delivery of alerts on any performance deterioration

An effective monitoring solution must also provide a scalable approach to pervasive monitoring, management, and troubleshooting, with an architecture that decouples data collection from management, aggregation, and analysis. This approach allows a highly scalable, distributed, cost-effective method to add visibility throughout the network, reducing the complexity of capturing rich intelligence from the network, the content, and the end-user experience.

Outsourcing WAN Monitoring and Management

Unfortunately, many enterprises lack the funds to deploy a sophisticated, ubiquitous WAN monitoring strategy to each remote branch office. Others lack the in-house expertise. That’s where outsourcing comes in. Providing enhanced WAN traffic visibility creates opportunities for service providers and options for enterprise IT administrators.

It’s a win-win for service providers and enterprises. The enterprise gets better network visibility and response to network issues. The service provider becomes a more trusted and valuable resource for the enterprise, rather than a simple middleman between application and end user.

Outsourcing eliminates hardware maintenance and support staff costs associated with on-premises technology. The managed service provider can also take advantage of economies of scale to use the most sophisticated WAN monitoring and management products on the market and employ people with the expertise to more effectively assess the data collected. To deliver these types of services, network operators need to have visibility into their network’s capacity use, application performance, and bottleneck locations.

Service providers must be able to quickly isolate the sources of issues, indemnify their services should problems arise, and provide the information enterprise IT administrators require about network performance. Some questions enterprises should consider when assessing managed network services include:

  • Does the service provider possess the necessary technical and business expertise to adapt to the enterprise’s evolving needs?
  • Are the provider’s services customizable to the enterprise’s specific needs?
  • Does the service provider offer a real-time network view?
  • Is application and/or network performance backed with specific service level agreements?

The Value of Effective Monitoring

Industry studies show that just a half-second delay in generating search results worsens the user experience and, in effect, sheds a significant portion of a company website’s traffic. Poor business-critical application performance can also hinder productivity and damage reputations and relationships. Clearly, proactive and real-time monitoring to improve the quality of the end-user experience offers huge benefits.

With effective monitoring, those dark stormy enterprise clouds will begin to lighten.

Thanks to Enterprise Networking Planet for the article.

Release 5.2.11 Notes for LANforge FIRE & ICE

Candela LANforge Fire Stateful Network Traffic GeneratorCandela LANforge ICE WAN Emulator

Release 5.2.11

New Features & Improvements:

  • Estimate and report low level (on the wire) packets and byte counts. For UDP and Ethernet protocols, this will be quite accurate. For TCP, it should be a fairly close estimate.
  • HuntScript: Add graphs for low-level bits-per-second, improve reports for certain configurations.
  • Add Port-Monitor plugin for simple graphical view of tx and/or rx rates on network interfaces. This was added at the request of a company needing a nice and simple display for a trade show.
  • Add cx-detected-dropped packet counter to Layer-3 and Armageddon endpoint CSV files. Requested by Boeing.
  • GUI: Add right-click option to view logs for selected Layer-3 (multi-conn only), Layer-4, File-IO, and VOIP endpoints. Right-click on Resource tab to view main LANforge server process logs. Right-click click on Port-Mgr tab to view supplicant and hostapd logs for selected wiphy and vap interfaces.
  • FileIO: Add FORCE and LAZY unmount options. This can help when testing with non-responsive NFS servers. Using the ‘soft,timeo=15’ option also also helps in this case.
  • Disable most console logging by default. This significantly improves wifi association times.
  • Improve 802.11r (roaming) support. The GUI gets a plugin to automate roaming and reporting, and the CLI gets the ‘wifi_cli_cmd’ option to send commands directly to the supplicant. This is how we tell the suplicant to roam. Tested with Cisco Aeronet APs and 2504 controller configured for 802.11r.
  • Add CLI script with some examples of wifi station creation and Layer-3 connection creation (/home/lanforge/scripts/lf_associate_ap.pl).
  • Add option to disable re-acquisition of DHCP lease on wifi (re)connect. This aids wifi roaming tests where the IP addresses do not need to change as stations roam between APs.
  • Add option to acquire DHCP lease, but only print the info to the LANforge CLI instead of configuring the interface. Can be useful when using LANforge WiFi stations in bridge mode with certain third-part traffic generators.
  • Remove DHCP client lease files when deleting non-management ports. This ensures a newly created port of the same name will not use an old lease file.
  • Add option to have LANforge answer ARP for bridged wifi station interfaces. See the part about LF_STA_BR_ANSWER_ARP in the LANforge FAQ.
  • Support EAP-AKA authentication. Tested with ‘hostapd’ as the RADIUS server and a third-party RADIUS server.
  • Compile hostapd and wpa_supplicant with openssl and other options for better authentication support and additional features such as the ability for hostapd to act as a stand-alone RADIUS server. Add hlr_auc_gw program to LANforge-Server package for use as RADIUS authenticator for EAP-AKA. Custom configuration files are needed to enable these features.

Bug Fixes:

  • FileIO: Fix regression that caused FileIO unmounts to hang forever when NFS server died. This is a kernel fix. The problem was introduced in LANforge 5.2.9 with the 3.9.Y kernels.

Thanks to Candela Technologies for the article.

The Net Optics Phantom Virtualization Tap™ captures data passing between virtual machines (VMs) and sends traffic of interest to virtual and physical monitoring tools of choice.

Net Optics and VMware

The Virtual Monitoring Challenge

Enterprises have been utilizing Tap solutions for network traffic access for many years. Traffic capture, analysis, replay, and logging are now part of every well-managed network environment. In recent years, the significant shift to virtualization—with penetration exceeding 50%—is yielding great benefits in efficiency. However, today’s virtualization-based deployments create challenges for network security, compliance, and performance monitoring. This is because Inter-VM traffic is optimized to speed up connections and minimize network utilization. This imposes invisibility on physical tools unable to extend easily into the new environments. Costly new virtualization-specific tools plus training can affect the economic benefits and cost-savings of virtualizing. Currently, many tools suffer from limited throughput, hypervisor incompatibility, and excessive resource utilization.

Virtual infrastructures use hypervisor technology to deploy multiple computing environments on a single physical (hardware) server, or across a group of physical servers. Traditional Taps cannot see the traffic between the VMs that reside on the same hypervisor, nor can they “follow” specific VMs as automation moves them from one hypervisor to another to optimize efficiency and availability.

Visibility is further reduced by the complexity of blade servers: with each blade running multiple VMs on a hypervisor. Traffic between the blades running on a dedicated backplane is also invisible to the physical network and its attached tools.

The Phantom Virtualization Tap Solution

The Phantom suite of software products provides 100% visibility of virtual network traffic, including the unseen inter-VM traffic on ESXi Stack. This milestone solution has now expanded to support the industry’s leading hypervisor. The Phantom Monitor installs in the hypervisor kernel above the virtual switch. It is a software implementation of a switching mechanism that manages communications between virtual network devices and works identically to the physical switch. The Phantom Monitor can replicate all traffic within the virtual switch, apply smart TapFlow™ filtering, and send traffic of interest to any monitoring tools of choice. It can even pass the replicated traffic to a physical port so physical tools can monitor the data. Virtual traffic is bridged to the physical world in an encapsulated tunnel that can be terminated by a Net Optics xFilter™, Phantom HD™ or at any capable termination point of your choosing.

Solution Highlights

  • 100 percent visibility of traffic between Virtual Machines (VMs) and inter-blade visibility
  • Installs in hypervisor kernel for full traffic visibility
  • Enables visibility and control of network traffic in VMware vSphere ESX/ESXi Server 4.X/5.X
  • Generates Layer 2-4 statistics (packet count, utilization, etc.)
  • TapFlow™ multi-layer L2-4 filtering engine
  • Extends monitoring and access into the Inter-VM networking layer (East-West Traffic)
  • Applies existing physical monitoring tools, processes, and procedures to the virtual network
  • No interference with the data stream or VMs (no agents or services on VMs)
  • No modifications needed in VMs
  • Replicates Inter-VM traffic to virtual and physical monitoring tools of choice
  • Sends mirrored traffic out physical NICs in encapsulated tunnels

Net Optics Phantom Virtualization Tap

Net Optics and VMware Team Up to Deliver Full Visibility, Automation, Flexibility and Scalability for Comprehensive Monitoring for Virtual Environments.

Unique Capabilities

Net Optics Phantom GraphThe Phantom Virtualization Tap provides these unique capabilities to your VMware virtual computing environment:

  • A solution that performs network monitoring at the hypervisor kernel level providing full view of the traffic flowing between VMs, regardless of their current physical locations
  • Implemented at the kernel; delivers the ability to differentiate between specific VM instances in replicated environments, and keep monitoring and logging the VMs even as they are moved between hypervisors (different physical servers or locations)
  • The industry’s only integrated solution for converged (virtual and physical) environments. Fully hypervisor-agnostic and virtual switch-agnostic, the Phantom Virtualization Tap works seamlessly with Net Optics’ Director series of data monitoring switches
  • Net Optics Indigo Pro™—a unified network management tool —provides an easy-to-use, Web-based GUI interface

Thanks to Net Optics for the article.