In my last post I discussed some strategies to use with customers and management. I also posed the question: "Whatever happened to convergence?" Convergence isn't just about voice and data riding the same network; there's a large influx of endpoints connecting to it. We also know that networks don't remain static, and as bandwidth demands continue to grow, more endpoints will touch the network, and applications that reside locally may or may not move over to the cloud. Apps that reside on BYOD may or may not be supported--and where do you draw a line in the sand?
All of this brings challenges to network managers and administrators tasked with keeping the network viable.
Hardware--in addition to network hardware and systems, other gear connecting to the network includes:
* Network cameras and network DVR systems
* IP Paging
* SIP endpoints including conferencing equipment
* IP door access control
* WiFi and WiFi components for HVAC controls
* IP Clocks and alerting components
* IP monitoring and M2M components
* IP building management systems
* BYOD--smartphones, tablets, iPads, iPods and more
The impact of the above gear translates to having adequate information for the hardware, components, firmware and software versions and, importantly, all the contact information to gain service and/or support on the numerous systems reliant upon the network. Often, companies supporting the above hardware will require a support agreement or customer credentials.
The help desk or parties supporting the network will need to document and have contact information, including an inventory of the assets and relevant information. Without this basic info, time to resolution increases. Then, having credentials for the above systems and components may further reduce the time to resolution for minor issues, because without them, the Help Desk will be at a disadvantage to resolve minor issues quickly.
Many components and even systems hardware require rebooting, and this is a reality in any converged network. Case in point: a lone computer was connected to an IP phone port, and the switch serving this port began to fail other phones but not all phones; then other phones connected to other switches in other stacks began to fail.
All switch stacks are connected via fiber, and power transients do not traverse fiber--however, the switch can suffer from electro-static discharge (ESD) and it may begin to toss out frames; and seemingly, other switches in other closets seem to also learn or populate errors and other IP phones begin to fail sporadically. Rebooting all the switches seems to correct the issue in most cases, unless the switch port suffering ESD is damaged. We learned this in the early days of deploying 3Com NBXs. This also brings into discussion the bonding and grounding the racks of the converged cable plant.
Knowing what's connecting to the network may mean determining what gear needs support, and in what priority vs. BYOD; and how much support will be rendered to BYOD user gear. Administrators simply need to determine what they will support in the way of problem resolution of the BYOD population. Users may ask for support of applications, and this can be burdensome when a vast array of apps is available.
Another concern with BYOD is traffic demand, and here's another case in point: a multi-site and multi-state medical practice. At each location there are doctors who bring to work their personal smartphones, tablets and pads. They typically connect to the "Guest" SSID on the WLAN and expect access. All the employees also connect, and operational traffic can become disrupted for the practice. Assigning a lower priority to the Guest VLAN traffic will slow all these users down, giving priority to the operations traffic such as Electronic Medical Records (EMR) and back-office applications for scheduling and billing. Without infuriating doctors who demand access for their personal devices, what do you do?
Systems and components that support the company and connect to the network need to be adequately documented and inventoried, and relevant supporting contacts and credentials for access are needed to also keep firmware updated and software upgrades under control. All these systems are also powered, and they can act like a lightning rod, so electrical protection is wise--and knowing where the gear is housed and having both physical and command line access is important too.
Another common issue is network maintenance that requires switch firmware upgrades and then rebooting. For WiFi controllers: the reboot doesn't guarantee that the Access Points (APs) will come online. Administrators need to double-check that the APs do in fact restore after rebooting from maintenance efforts.
Other challenges may include determining which VLAN to place the supporting equipment and systems into, and the breadth of access they may need to access other VLANs. Policy changes in the firewall may need adjustment to allow these supporting systems and components the access they need to operate effectively.
Supporting these systems and components without the need to rally the troops to discover who to call for support or which version of firmware is running reduces delays in problem resolution. Awareness, documentation and basic steps can alleviate prolonged disruptions and outages.
Follow Matt Brunk on Twitter and Google+!
@telecomworx
Matt Brunk on Google+
