JDSU’s Network Instruments Unveils Observer Platform 17 for Simplified Performance Management and Application Troubleshooting

JDSU Network Instruments  Observer Platform 17

Network Instruments, a business unit of JDSU (NASDAQ: JDSU), has announced the latest edition of its cornerstone Observer® Performance Management Platform. Observer Platform 17 provides network managers and engineers a comprehensive, intuitive approach to:

  • Proactively pinpoint performance problems and optimize services.
  • Integrate monitoring into the deployment of IT initiatives, including cloud, service orchestration and security.
  • Easily manage access and share performance data with IT teams and business units.
  • Quickly assess and optimize user experience with web services.

This comprehensive performance management solution also features redesigned, easy-to-use interfaces and workflows, expanded web user visibility, increased transactional intelligence, and enhanced integration with third-party tools and applications.

“The Observer 17 release uniquely positions the Platform for the future of IT and the network manager’s evolving role as a primary enabler of technology adoption throughout the enterprise and as a key troubleshooter,” said Charles Thompson, chief technology officer for Network Instruments. “Other IT teams are looking to the network team for greater application troubleshooting and support. Utilizing the newest features in Observer, they are well prepared for their constantly changing role by achieving quicker root-cause analysis, understanding applications in-depth, and easily sharing performance data with non-network teams.”

Key enhancements include:

  • Intuitive, drag-and-drop interface and streamlined workflows transform Network Performance Management from an ad hoc practice to a proactive, collaborative process. IT can now manage, monitor, and assess performance in two clicks.
  • Third-party system integration via Representational State Transfer (RESTful) APIs facilitate easier sharing of performance intelligence with other groups, as well as integration of monitoring technologies for successful service orchestration for cloud, Software-Defined Networking (SDN) and virtual deployments.
  • Enhanced Web Services Analytics provide greater insight into how end users are experiencing web services through expanded client-based and comparative details.
  • Deeper transaction-level intelligence and correlative analysis allow for quicker and more effective application troubleshooting. With access to greater granularity, network teams are able to more easily assess relationships between transaction details and other performance variables for a higher degree of actionable insights.

The new Observer Platform features allow network professionals a more productive tool to stay on top of key IT trends and challenges such as:

IT Automation—As businesses increasingly transition to automated, self-service IT models involving the deployment of cloud, SDN and virtualized environments, these dynamic services are often being implemented without adequate monitoring. To minimize the ‘black holes’ created when users roll out or move IT services and resources without the network team’s knowledge, the new Observer Platform ties together the provisioning of IT resources with the automatic deployment of monitoring tools via RESTful API for complete visibility.

IT Alignment Across the Business—In delivering Unified Communications and Big Data initiatives, application teams now turn to network teams to lead the charge for metrics, intelligence and app problem solving, and troubleshooting. RESTful APIs and improvements in user management make it easier to integrate Observer 17 into external workflows and processes to help share network performance data with non-network teams.

Monitoring Mobile Experience—With movements to the cloud and increased access to web services by end users on mobile devices, Observer 17 brings a higher level of visibility and insight into how they are experiencing web services, regardless of the device. Observer now provides comparative visibility by browser type and operating system, alongside performance metrics, to determine if the user experience is the same via a desktop or mobile device.

Observer Platform 17 is currently available and includes Observer Apex™ (previously called Observer Reporting Server), Observer Management Server (formerly called Network Instruments Management Server), Observer GigaStor™, Observer Analyzer, and Observer Infrastructure products.

Thanks to JDSU Network Instruments for the article.

Exposing the Ghost in the Virtual Machine

Virtualization continues to be an important data center success story. This technology has reduced physical plant hardware footprints, power costs, and cooling costs – significantly improving the total cost of ownership for the data center. At the same time, however, virtualization technology has also introduced a set of problems.

These problems have decreased the visibility into what is happening within the virtual network, and can be summarized as follows:

  • Lack of visibility hides potential security and performance problems for a significant period of time
  • Added additional network and monitoring complexity
  • A lack of consistent monitoring policies between the physical and virtual networks

In case you think it’s just me saying this, Forrester Research performed a study for Cisco Systems on this subject and validated these three technology concerns, along with two additional concerns relating to manpower resourcing for virtualization technology. The chart below (from the Forrester virtualization security study) was a questionnaire that determined the actual virtualization issues and concerns for almost 80 IT decision makers.

Ixia's phantom vtap

The first concern for data center managers was security. This is for good reasons. There are malware threats like “Crisis” that are capable of targeting virtual environments. Without proper visibility, these threats can gain a foothold and then flourish within your data center and you won’t even know it – until it’s too late. Another item related to this, but not mentioned in the Forrester study, is that performance problems can also be hidden by this lack of visibility. Without proper monitoring of virtual equipment, your data center may experience performance problems without you even knowing about them. Common examples include: slow traffic and devices, unnecessary bandwidth consumption, intermittent issues that pop-up long enough to be noticed but then disappear quickly, etc. Once the problems become noticeable, it’s often too late as something bad is normally going to happen. Hopefully it’s not an outage.

While virtualization introduced the benefit of the flexibility to spin up new virtual machines (VMs) almost at will, it has also caused complexity. Since the VMs can be spun up and down so quickly, it can become difficult to know what VMs exist, if and where they might have been moved to (in the case of VMware vMotion) and what policies, especially security policies, were set up for the VM’s when they were created. This rapid pace can end up creating “holes” that can be exploited by malware.

In addition, because most of the traffic (up to 80% according to Gartner) in the virtual data center never reaches the top of the rack, there are few, if any, network monitoring policies in place for the virtual equipment. This creates a huge blind spot where security and performance issues can hide. In short, you can’t monitor what you can’t measure.

Lastly, without access to the proper data, it can become exceedingly difficult to audit data and security policies for various compliance regulations (FISMA, HIPAA, PCI, etc.). So, you may be compliant on the physical side of the network but non-compliant on the virtual side. In the end, this makes you non-compliant which can have financial penalties as well as legitimate security risks.

In addition, a lack of a consistent monitoring policy often results from the natural division that has occurred between the physical and virtual infrastructure. IT physical infrastructures have been around for long enough that implementation and network monitoring policies have been tried and tested. So much so that best practices are commonly available. This is not the case for virtualized data centers. Monitoring policies are often non-existent and when they do exist, they are usually not aligned with the policies of the physical infrastructure. This is partially due to the lack of technology to properly expose the virtual data but it also comes about because the virtual data center is often run by a different department than the person(s) monitoring the physical data center. This means that the monitoring tool engineers often have little or no access to the virtual data center and can’t fold those systems into the overall network monitoring strategy.

These are the ghosts that hide within the virtual machine. While knowing that the ghosts exist is a start to exposing them, the real elimination of the problem is accomplished by installing a virtual Tap. Like it’s physical counterpart, the hardware-based Tap, a virtual Tap is software that is installed into the virtual data center so that data can be exported northbound and out of the data center to network packet brokers and monitoring tools that can then process and analyze the data.

Virtual Taps (like the Ixia Phantom vTap) can be used to remediate the issues mentioned earlier:

  • Potential hidden security issues
  • Provide access to data for trending
  • Allow proper compliance policy tracking

At the same time, if the virtual Tap is integrated into a holistic visibility approach using a Visibility Architecture, you can streamline your monitoring costs because instead of having two separate monitoring architectures with potentially duplicate equipment (and duplicate costs), you have one architecture that maximizes the efficiency of all your current tools, as well any future investments. When installing the virtual Tap, the key is to make sure that it installs into the Hypervisor without adversely affecting the Hypervisor. Once this is accomplished, the virtual Tap will have the proper access to inter and intra-VMs that it needs, as well as the ability to efficiently export that information. After this, the virtual Tap will need a filtering mechanism so that exported data can be “properly” limited so as not to overload the LAN/WAN infrastructure. The last thing you want to do is to cause any performance problems to your network. Details on these concepts and best practices are available in the whitepapers Illuminating Data Center Blind Spots and Creating A Visibility Architecture.

As a side note, some people propose using the VMware vSphere “promiscuous mode” to get access to the data. This approach is fraught with danger as you expose the data to various security risks. In addition, using promiscuous mode might cause delays in transmitting data due to the overhead and summarizing processes. Normally, the best course of action is to use a dedicated Tap that can provide some level of QoS.

In my experience, bad things happen in blind spots and YOU don’t want to be the one to have to explain them to senior management. More information about the Ixia Phantom vTap and how it can help generate the insight needed for your business is available on the Ixia website.

Additional Resources:

Ixia Phantom vTap

White Paper: Illuminating Data Center Blind Spots

White Paper: Creating A Visibility Architecture

Thanks to Ixia for the article. 

Cogeco Would Consider MVNO Launch If regulator Helps

Canadian triple-play cableco Cogeco says it will consider launching a mobile virtual network operator (MVNO) service if the Canadian Radio-television and Telecommunications Commission (CRTC) implements stricter regulation regarding wholesale access to the infrastructure of national mobile network operators Rogers, Telus and Bell. As reported by Reuters, Cogeco’s CEO Louis Audet said that he hoped for new regulations to encourage MVNOs, in a statement to the press ahead of CRTC hearings on wholesale mobile services scheduled for next week. Audet told reporters that Cogeco would only move forward with an MVNO plan ‘if there is … an enforceable order to give [wholesale mobile network] access, and if the rates at which this access is provided are actually dictated by the regulator.’ However, the federal government has previously focused more heavily on encouraging facilities-based competition – aiming to have four viable network operators in every province – rather than boosting the MVNO sector.

Thanks to TeleGeography for the article.

BCE Concludes Initial Phase Of Aliant Share Offer; 100% Buyout Expected By End-October

Telecoms group Bell Canada Enterprises (BCE) and its subsidiary Bell Aliant yesterday announced in a press release the initial results of BCE’s offer to purchase all Bell Aliant’s outstanding publicly held common shares and to exchange all outstanding Bell Aliant preferred shares. BCE revealed in July that it would buy out all minority shareholders in Bell Aliant for a total consideration of approximately CAD3.95 billion (USD3.68 billion); sellers will receive cash and BCE common equity. 81.2% and 72.7% of the respective outstanding publicly held common and preferred shares had been validly tendered to BCE’s offer by 19 September, and BCE expects to pay for these common shares on 24 September, while on the same day it expects to issue the new BCE preferred shares which will commence trading on the Toronto Stock Exchange the following day. As all conditions of the common/preferred share offers have been satisfied, and all regulatory approvals have been received, BCE expects to take Bell Aliant private on or around 31 October 2014.

Additionally, BCE has extended the common share offer, in accordance with its terms, to 2 October 2014 in order to enable holders of common shares who have not yet tendered to deposit their shares to the offer prior to the completion of the privatisation (delisting) of Bell Aliant. BCE expects to pay for all such shares tendered in the extension period by 7 October 2014.

If at least 90% of the publicly held common shares of Bell Aliant are tendered to the offer following its extension, BCE intends to acquire the balance of the common shares not tendered through compulsory acquisition on or around 31 October. If less than 90% of the publicly held common shares are tendered by 2 October BCE intends to use its voting power to force through the acquisitions of the remaining common shares at a meeting of Bell Aliant shareholders on 31 October (while the same applies to all remaining preferred shares).

Thanks to TeleGeography 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.

 

Network Visibility Solutions- Solution Brief

Optimal Visibility and Control of Your Data Center

Ixia’s portfolio provides complete network visibility into physical and virtual networks, improves network security and optimizes monitoring tool performance. The Anue NTO ensures that each monitoring tool gets exactly the right data needed for analysis. This improves the way you manage your data center and maximizes return on investment.

What Our Customers Say

“The Anue NTO makes my life easier. It makes complex data monitoring simple and allows us to leverage existing network monitoring infrastructure.” Chris Lindner, Director, Tools & Engineering, Fiserv

Download the Solutions Brief here

Ixia Network Visibility Solutions

Additional Resources

7300 A New Perspective on Network Visibility

5260 Flexible Centralized or Distributed Monitoring

5268 Flexible Centralized or Distributed Monitoring

5293 High-Density, Carrier-Grade

5288 High-Density 10GE/401GE/100GE

5273 High-Availability, Carrier-Grade

5236 Enterprise Class

5204 Small Enterprise

 

 

Building a Better IVR: Some Tips for Success

The IVR is an integral part of any call center. Customers can call the center and get what they need without ever talking to a human, allowing agents greater availability to handle the more pressing calls. Yet despite their obvious advantages, most IVR systems aren’t perfect and can benefit from some improvements.

How do you know when your IVR is due for some revamping? One of the best ways is to dial the number yourself. By putting yourself in the shoes of the customer, you’ll get to experience the IVR just as they do. If you find the IVR confusing or feel the desire to hang up in frustration, there’s a good chance your customers feel the same way. And that means it’s probably time to build a better IVR.

So, where do you start? Elaine Cascio, Vice President of Vanguard Communications Corporation and an expert in customer experience, shares some tips for ways to improve your IVR.

Make it Familiar and Easy to Use – Cascio’s first suggestion is to make your IVR more inviting. Again, if you wouldn’t want to stay on the call with your own IVR, there’s little chance your customers are that fond of it either. Cascio suggests to “emulate the processes used by agents wherever possible.” Just as how an agent will try to keep the call as brief and efficient as possible, in order to meet service level and move on to the next call, the same theory should be in place for the IVR. You don’t want to overload the customer with too much information, have them listen to a long, drawn-out message or give them too many steps to get the information they need.

Be Conversational – While brevity is important when developing an IVR, you should still make your IVR conversational and easy to understand. Cascio says to focus on what is being said and how it is presented. She states, “Don’t use jargon – use clear, concise and commonly understood language and terminology.” Additionally, she recommends putting the time into creating a script that is not only easy to follow and inviting, but also reflects the character and services of your brand. Furthermore, it is a good idea to read the scripts aloud before putting them into production and conduct focus groups to see how people respond to the content. Cascio also suggests hiring experienced voice talent to record the messaging.

Leverage Data and Technology – Just as customers will be put off if they have to listen to more information than is necessary, they shouldn’t have to provide the same information each time they call. The IVR can be set up to recognize the number calling or ask callers for their unique pass code and use information already on file to speed the process along. Cascio recommends that IVR systems have the capability for callers to transfer to a live agent, in case they need further assistance. If so, the caller’s data should be easily transferrable from the IVR to the agent, so they don’t have to provide their information once again.

Manage and Measure – Cascio stresses that it is important to perform quality monitoring on calls handled by the IVR in addition to calls handled by live agents. Doing so will keep you informed about how your customers are handling the IVR, and allow you to make sure that it is working properly and helping the business meet its goals. Cascio adds, “Make sure that your measures of success are strategic, customer centric and make a difference in how your business operates.” Quality monitoring can also provide key insight into how successful the IVR is. If a large percentage of callers are hanging up or spending too much time on the IVR, then you’ll know that it may need some more work.

Test, Test and Test Again – Of course, once you’ve made the necessary improvements to the IVR system, you’ll want to make sure they are right. That’s where testing comes in. Cascio recommends setting up focus groups to see if the average caller will understand the language and processes presented by the IVR. Additionally, usability tests will let you know if the IVR is usable and intuitive, and comprehensive user acceptance tests should be conducted prior to deployment.

A good IVR will make the contact center’s operations more efficient and be more cost effective. On the other hand, a poorly developed or executed IVR can be inefficient and wasteful and might even scare your customers away. Since this is the first and often only interaction they’ll have with your business, you’ll want them to be greeted by a coherent and easy-to-use IVR system. By using these tips, you’ll be well on your way to creating a better IVR and, in time, enjoying increased operational efficiency and more customer loyalty.

Thanks to ICMI for the article.