I'm setting up a SPAN session to enable Cisco Unified Communications monitoring with CA Unified Communications Monitor. What data does the Collector need to see?
To monitor in a Cisco VoIP environment, you must connect a Collector to a SPAN (Switched Port Analyzer) or mirror port on all switches carrying VoIP traffic on your network. A SPAN session on a switch allows network traffic from designated ports (or all ports) to be copied and sent to a single port on that switch (called the destination port or monitor port). The Collector does some filtering on its own and ignores data that isn't related to UC or VoIP. However, when you set up the SPAN, you should still take care not to flood it with unnecessary data and to avoid packet duplication. And you need to take extra care when spanning call server traffic if your call servers are running in clusters.
First, select a switch with maximum visibility into call server traffic. The Collector needs to see and inspect traffic flows between the IP phones and their call servers, and between any voice gateways and call servers. The ideal location would be a core switch in a network operations or data center, but any switch that carries call server traffic is acceptable. Be careful not to oversubscribe the SPAN port output capacity. If possible, you should SPAN or mirror only VoIP traffic. The Collector only inspects VoIP-related packets, so any extraneous traffic just creates extra load.
For example, add any VLANs dedicated to voice traffic to the list of SPANned ports. VACLs are a useful tool for filtering out unnecessary data. If you set up access lists, make sure the following traffic is being sent to the SPAN port:
TCP traffic on Port 2000 (SCCP flows)
TCP and UDP traffic on Port 5060 (SIP flows)
UDP traffic on Port 2427 (MGCP flows)
TCP traffic on Port 2428 (PRI backhaul)
Note: In Cisco's implementation, raw ITU Q.931 Call Setup traffic is backhauled over a TCP connection to the Cisco Unified Communications Manager so that it can directly control the Voice Gateway's ISDN PRI. Cisco calls this feature 'PRI Backhaul.' The Collector needs to be able to see the Q.931 Setup/Alerting messages on the PRI Backhaul connection as part of call setup monitoring.
Avoid situations in which a large-capacity switch is sending data from all ports to a single SPAN or mirror port; data will be lost. Make sure all call server traffic is being spanned. When they are part of a cluster, Cisco Unified Communications Manager (Call Manager) servers can act in multiple roles to provide failover and load balancing capabilities. As a result, you need to configure the SPAN port so that VoIP-related traffic to and from all call servers is captured. That is, SPAN the network traffic associated with both Call Manager Publishers and Subscribers.
Similar advice applies to voice gateway devices and their interactions with call servers. Voice gateways may register with either the Cisco Unified Communications Manager Publisher or Subscriber. Like the call servers, gateways are often configured to perform failover duties. The key point to remember is that any signaling between a voice gateway and a call server in both directions needs to reach the Collector to ensure monitoring of all call traffic on the network. If your situation makes it difficult to span both Publishers and Subscribers, you should focus on spanning the component that is doing the call processing, usually the Subscriber. With this configuration, you would miss some data in a failover situation.
When determining where UC Collectors should be installed, select switches that are as close to the monitored call server(s) or voice gateways as possible. Server response times (for delay to dial tone, for example) are calculated based on the assumption that the Collector and the monitored server receive an inbound packet at approximately the same time.
Similarly, traceroute baselines and investigations provide the most accurate path results when the Collector is located close to the call server. The Collector and call server should share a router to ensure that the paths returned from traceroute testing reflect the path taken by packets sent to and from the call server. (Keep in mind that the Collector itself launches the traceroute test.) Once you have enabled the SPAN port and are beginning to collect UC-related data, check the dropped packets statistics on the switch SPAN port where you have connected the Collector to make sure it isn't congested or misconfigured.