Oracle® Communications Session Monitor Installation Guide Release 3.3.80 E57620-01 |
|
|
PDF · Mobi · ePub |
This chapter provides instructions for Oracle Communications Session Monitor post-installation tasks.
To authorize Oracle Support access to your Session Monitor servers, you must provide direct shell access using Secure Shell (SSH). Shared desktop access is not direct shell access.
Oracle Support provides you the SSH credentials for authentication and authorization. You configure the credentials on the Remote Access page in Platform Setup Application (PSA). You can modify the credentials or disable shell access at anytime in PSA.
Oracle Support connects to your Session Monitor server using a VPN connection. Ensure that a VPN connection is created and tested, in the event that Oracle Support needs to use the VPN connection for an urgent issue.
After you log in to the product interface, you can see the status of the system or update the system. A system update will update all applications as well as the Platform Setup Application itself.
The Software Version page shows the currently installed components and the software version.
To install a software update, go to the Software Version page and select the update file (file type .bin) that was provided by Oracle or your service provider. Click Apply to initiate the upload.
When the upload has finished, the page will show the version number and issue the date of the update. Click Install to proceed with upgrading the system. You can also abort the upgrade by clicking Clear.
Important:
Session Monitor or parts of it may not be available during the update process.Platform Setup Application will show the progress during the upgrade. You may click Close to hide the progress window.
Note:
If you have a setup with multiple servers (for example, one ME and multiple Probe servers), upgrade all of them at the same time. Running different servers of the Session Monitor at different versions is not supported.The Media page is only available after the installation process has finished and only for machines which have the probe type (that includes the machine type Mediation Engine with Probe).
Only traffic which doesn't match this will be passed on to the signaling protocols.
Check all traffic for signaling: When this check box is enabled, all the traffic (not only which doesn't match RTP filters) will be passed on to the signaling protocols. This may decrease performance.
BPF filter: This is used to identify the RTP traffic. Only the traffic matched by the given rule is considered.
For more information about filters, see "Filter Syntax".
Active streams: The number of RTP streams found. Only traffic matching the (applied) filters are counted.
Packets processed: The packets matched by the filter and successfully processed.
Packets dropped: The packets matched by the filter but not processed due to insufficient resources.
If the machine has a Napatech card installed, this card performs the filtering. Detection of this card is automatic and does not need to be configured.
The Signaling menu is only enabled after the installation process has finished and only for machines which have the probe type.
The Signaling page is used to configure the characteristics of the types of traffic the various probes (which sniff traffic) look for. Only the traffic matched by the given rule will be considered.
Reasons to configure tight rules:
All matching traffic will be processed by the probes. For most installations, the high volume of traffic makes inspecting every packet infeasible. Ignoring unnecessary packets, therefore, puts less stress on your system and makes subsequent analysis easier. For example, you may want to make sure the signaling probe, which monitors SIP, doesn't also get all the RTP traffic as well.
You might not be interested in certain sources of traffic, even though the machine would pick it up.
More complex VLAN configurations.
The default filters given should make sense and should at the very least be a sane starting point.
After applying the filters it takes a few seconds to reconfigure the probe(s). After that, the statistics on this page should count the new situation. Keeping an eye on the 'Packets processed' gives an idea of how the filters are performing.
For more information about filters, see "Filter Syntax".
Turn on packet deduplication for the associated traffic type. A time value in milliseconds must be provided if deduplication is turned on. The value should be greater than 0.
Packet deduplication is done at L3 and above and it is best effort. Some types of traffic might not get de-duplicated (duplicates on nested VLANs, ipv6, and so on).
There is a System Setting to enable Deduplication in the core, which should be enabled if there are multiple Probes connected to one ME, and seeing the same traffic. If traffic is seen without and with vlan tags, it is recommend to also disable VLAN awareness (System Setting).
Rate: This is the full amount of traffic this probe gets after the filtering.
Packets processed: This is the amount of packets in the last seconds. Only packets which match the filter can be processed.
Total sniffed: This is the amount of packets sniffed across all configured devices.
Total dropped: This is the amount of packets which should have been processed.Due to performance reasons they have been dropped by either the NICs or during processing. If possible, tighten the filters and disable the Check all traffic for signaling option (Signaling protocols) so the probe has less unnecessary work to do. If that's not possible, upgrade the machine.
Be sure to use vlan keywords in the filters when that's used on the network.
Be sure to change the default filters if you use non-standard ports or other options.
Traffic will first be filtered by the Media Protocols setting. Only traffic not matching there will be passed on to the signaling probes. Except if Check all traffic for signaling is enabled.
The System Diagnostics menu allows the creation of a report with information on the installation. This report may be requested by the support team in case of issues.
A report can be created by clicking Create. This may take several minutes to complete. Afterwards, the report can be downloaded as a file by clicking Download. This file can then be sent to the support team, for example by email.
If a report exists, its creation date will be shown. It can be downloaded as often as necessary, but there can be only one report at a time; creating a new report will overwrite any existing one.
Reports are deleted around midnight UTC.
The contents of a report include:
Information on the available hardware of the machine that the monitoring solution is running on
Log files
Configuration of the monitoring solution
Statistics about the performance and status of components of the system and of the monitoring solution
If the check box Include mysql dump... is checked, the report includes a dump of most of the database tables. Note that the respective tables might be huge.
If the check box Include mysql dump... is not checked, the report will include only minimal information about the database tables.
Note:
Sensitive information is removed before report creation, including, but not limited to, passwords, keys, and certificates.The filter syntax used is the same as tcpdump or libpcap. For an example, see http://wiki.wireshark.org/CaptureFilters
.
The following filters are also known as BPF filters:
(tcp port 5060)
((udp or tcp) and port 5060)
(vlan (udp or tcp) and port 5060)
(tcp portrange 5060-5070)
(not port 5060)
(host 10.10.0.5 and port 5060)
(not host 10.10.0.5 and port 5060)
(not ether dst 12:34:56:78:90:ab)
Entries with a vlan keyword must be included for networks using VLANs. It is harmless to include them on networks which don't use VLANs, but do make sure there is a separate identical filter without the vlan. For example, (tcp port 5060) or (vlan and tcp port 5060).