CONFIDENTIAL
Perimeta Commissioning
Guide (VMware environments,
Integrated deployment)
PMC-030-Issue 4.3.40-Release 1
March 2018
Notices
Copyright © 2000-2018 Metaswitch Networks. All rights reserved.
This manual is issued on a controlled basis to a specific person on the understanding that no part
of the Metaswitch Networks product code or documentation (including this manual) will be copied or
distributed without prior agreement in writing from Metaswitch Networks.
Metaswitch Networks reserves the right to, without notice, modify or revise all or part of this
document and/or change product features or specifications and shall not be responsible for any
loss, cost, or damage, including consequential damage, caused by reliance on these materials.
Metaswitch and the Metaswitch logo are trademarks of Metaswitch Networks. Other brands and
products referenced herein are the trademarks or registered trademarks of their respective holders.
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
Contents
1 Introduction.............................................................................................................4
2 Environment Planning........................................................................................... 6
2.1 Planning your virtual environment for Perimeta.................................................................... 6
3 Deployment Planning.......................................................................................... 12
3.1 Network planning: Overview............................................................................................... 12
3.2 Planning your network interfaces: Overview....................................................................... 13
3.3 Planning your management network interface....................................................................14
3.4 Planning your high availability (HA) interface..................................................................... 16
3.5 Planning your core network interface................................................................................. 17
3.6 Planning your access network interfaces............................................................................17
3.7 Choosing a port group scheme.......................................................................................... 20
4 Security Planning.................................................................................................23
4.1 Firewall configuration...........................................................................................................23
5 Perimeta commissioning planning tables......................................................... 24
6 Preparing CLI configuration............................................................................... 34
6.1 Preparing your CLI configuration: Overview....................................................................... 34
6.2 Full foundation configuration............................................................................................... 35
6.3 Service interface configuration............................................................................................ 44
6.4 Media interface configuration.............................................................................................. 49
6.5 Signaling configuration........................................................................................................ 50
6.6 Diagnostics configuration.................................................................................................... 56
6.7 Dynamic blacklisting configuration...................................................................................... 57
6.7.1 Dynamic blacklisting reasons................................................................................ 62
6.7.2 Additional example dynamic blacklisting profiles...................................................64
6.8 Changes you need to make to the foundation configuration: Summary..............................71
6.9 Adding additional softswitches............................................................................................ 74
6.10 Tuning your configuration for your softswitch................................................................... 77
7 Installation Process............................................................................................. 80
7.1 Installing Perimeta in a VMware environment.................................................................... 80
8 Commissioning Process..................................................................................... 86
8.1 Commissioning Perimeta VMs............................................................................................ 86
9 Appendix: Install Server......................................................................................99
9.1 Preparing an Install Server to serve as the snapshot management system for
Perimeta................................................................................................................................99
10 Appendix: MetaView Web............................................................................... 101
10.1 Enabling MetaView Web management of Perimeta........................................................101
11 Appendix: Adding further configuration........................................................109
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
1 Introduction
This is the Commissioning Guide for Perimeta, Metaswitch's family of carrier-class Session Border
Controller (SBC) products.
This document take you through the process of planning and commissioning your integrated Perimeta
deployment. It consists of the following sections.
•
Environment Planning presents the key requirements that your VMware environment must meet to
support Perimeta virtual machines and the information that you must collect to successfully install
these virtual machines.
•
Deployment Planning introduces you to Metaswitch's best practice solution for deploying Perimeta,
and guides you through the decisions you need to make and the information you need to gather
before you commission your Perimeta Session Controller.
•
Security Planning gives guidelines for setting up your firewalls to work with Perimeta.
•
Preparing CLI Configuration provides you with Metaswitch's foundation configuration for Perimeta,
and guides you through customizing it for your deployment.
•
Installation Process provides you with instructions for creating your Perimeta virtual machines.
•
Commissioning Process takes you through the final commissioning process step-by-step, up to
and including making test calls through your system.
It also includes details of further steps that you may need to take once you have completed the
commissioning process, depending on your deployment's requirements.
•
Appendix: Install Server describes the additional steps that you must take to configure an Install
Server as the snapshot management system for snapshots created by Perimeta.
•
Appendix: MetaView Web provides information on the steps you must take to allow your
administrators to manage Perimeta Session Controller using MetaView Web.
•
Appendix: Adding further configuration gives details on a number of Perimeta's most commonly
used features which you may want to configure to further tailor Perimeta's behavior to the needs of
your network.
Attention:
This guide does not cover network design. See the Perimeta Network Integration Guide for
guidelines on bandwidth requirements and quality of service.
This document assumes that you have already planned your VMware environment using the
information given in the Metaswitch Products VMware Deployment Design Guide. This document
restates the key planning decisions outlined in the Metaswitch Products VMware Deployment Design
Guide for deploying Perimeta in a VMware environment, referring out to specific sections where
necessary.
This document assumes that you have already installed a Distributed Capacity Manager (DCM) Group
in your deployment.
4 1 Introduction
CONFIDENTIAL
•
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
For more information on planning your DCM Group, see the Metaswitch Products VMware
Deployment Design Guide.
•
For more information on installing your DCM Group, see the Metaswitch Distributed Capacity
Manager Initial Setup Guide.
1 Introduction 5
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
2 Environment Planning
2.1 Planning your virtual environment for Perimeta
Before beginning the commissioning process, you must ensure that your virtual environment is
capable of supporting the necessary Perimeta virtual machines.
You must have already planned your VMware virtual environment using the detailed planning
information found in the Metaswitch Products VMware Deployment Design Guide. The following
sections restate the broad steps that you must carry out to ensure that your VMware environment is
ready to support your Perimeta virtual machines. You must work through each of these steps, using
the referenced section of the Metaswitch Products VMware Deployment Design Guide if necessary.
The following sections also prompt you to collect some key information that you will need to install
your Perimeta machines. You must collect this information in the Virtual Machines and Distributed
Capacity Manager sections of Perimeta commissioning planning tables on page 24.
VMware vSphere
You must ensure that you have a supported version of VMware vSphere. For full information on the
supported versions of VMware vSphere, see Choosing your VMware software in Metaswitch Products
VMware Deployment Design Guide.
High availability and standalone systems
You can choose to deploy your Session Controllers as two Perimeta virtual machines operating as
a fault tolerant pair (known as a high availability system) or as a single Perimeta virtual machine
(known as a standalone system). You must know which deployment option you will use for your
Session Controllers. For more information, see High availability and standalone systems in Perimeta
Product Description.
Host and virtual machine information
You must know the following for each Perimeta virtual machine that you plan to create.
•
The name of the virtual machine.
•
The name of the host on which you plan to install the virtual machine.
•
The name of the datacenter to which you will add the virtual machine.
•
The name of the datastore that will be used for the virtual machine's configuration files and virtual
disks.
•
The collective clock speed of the physical CPUs provided by the host for use by the virtual
machine.
For example, for a host that provides 8 physical CPUs with an individual clock speed of 2.5GHz,
the collective clock speed will be 20GHz (2.5GHz multiplied by 8).
6 2 Environment Planning
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
For the majority of high availability systems, we recommend that the two Perimeta virtual machines
are run on hardware platforms of an identical or similar specification.
Note:
You may choose to run the two Perimeta virtual machines in a high availability system on
hardware platforms of differing capabilities. If this is the case, you will need to configure the
Session Controller with a minimum permitted CPU speed equal to the lower CPU speed of the two
hardware platforms. This will prevent the Session Controller from raising unnecessary alarms. You
will carry out this configuration after you have commissioned the Session Controller.
Physical CPUs
You must ensure that your host can provide the required number of physical CPUs for your Session
Controller type. These CPUs must be dedicated to Perimeta.
If you are deploying a low capacity Session Controller, you will require 2 CPUs.
If you are deploying a high capacity Session Controller, you will require 8 CPUs.
For more information, see VM resource specifications in Metaswitch Products VMware Deployment
Design Guide.
BIOS settings
You must check your host's BIOS settings to ensure that power management is delegated to the OS.
If you are using a Dell PowerEdge server, you can find specific BIOS settings at https://
communities.metaswitch.com/docs/DOC-145214.
For all other hardware types, you should refer to Power management in Metaswitch Products VMware
Deployment Design Guide.
Physical NICs
You must ensure that your host has the required number of NICs to accommodate your chosen
number of virtual interfaces, and that these NICs meet the required specifications.
The number of NICs that you require depends on bandwidth, SR-IOV or PCI passthrough and traffic
separation requirements. You should ensure that there are a minimum of two in an uplink team. These
should be connected to a redundant Ethernet switch infrastructure.
For more information on how to identify the number of NICs that you require, see Physical network
configuration in the Metaswitch Products VMware Deployment Design Guide.
Virtual network interfaces
You must ensure that your host can provide the required number of virtual network interfaces. You will
need the following interfaces.
•
1 virtual network interface for management traffic
2 Environment Planning 7
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
•
1 virtual network interface for high availability traffic (high availability systems only).
•
A number of virtual network interfaces for service traffic from core and general access networks.
The number of virtual network interfaces you require depends on whether or not you are using
SR-IOV for high performance (as described in High performance on page 8) and whether you
want to support managed access networks (as described in Planning your network interfaces:
Overview on page 13).
•
If you are not using SR-IOV for high performance, you require 2 virtual network interfaces for
service traffic from core and general access networks, with one interface being used for each
network.
•
If you are using SR-IOV for high performance, you require 4 virtual network interfaces for
service traffic from core and general access networks, with two interfaces being used for each
network.
•
If you want to support traffic from managed networks, you will require 1 additional virtual
network interface if you are not using SR-IOV, or 2 additional virtual network interfaces if you
are using SR-IOV.
For more information, seeVirtual network interfaces in Metaswitch Products VMware Deployment
Design Guide.
High performance
You must use SR-IOV or PCI passthrough for high performance if your Session Controller will be
required to handle 4,500 or more concurrent media sessions.
If you are using SR-IOV or PCI passthrough, you must know the physical NICs to which the core,
general access, and, if applicable, managed access service interfaces will connect.
For more information on Perimeta high performance and SR-IOV and PCI passthrough, see Specific
requirements for Perimeta high performance in Metaswitch Products VMware Deployment Design
Guide.
vCPUs
You must ensure that your host can provide the number of required vCPUs for your Session
Controller type.
If you are deploying a low capacity Session Controller, you will require 2 vCPUs.
If you are deploying a high capacity Session Controller, you will require 16 vCPUs.
For more information, see VM resource specifications in Metaswitch Products VMware Deployment
Design Guide.
RAM
You must ensure that your host can provide the amount of RAM required for each Perimeta virtual
machine.
If you are deploying a low capacity Session Controller, you will require 4 GB of RAM.
8 2 Environment Planning
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
If you are deploying a high capacity Session Controller, you will require 16 GB of RAM.
For more information, see VM resource specifications in Metaswitch Products VMware Deployment
Design Guide.
Hard disk
You must ensure that your host can provide the virtual disk space required for each Perimeta virtual
machine.
•
If you are deploying a low capacity Session Controller, we recommend that you provide 40 GB of
virtual disk space.
•
If you are deploying a high capacity Session Controller, we recommend that you provide 60 GB of
virtual disk space.
You may wish to provide more virtual disk space to allow for greater billing record capacity. For more
information, see Perimeta data storage in Metaswitch Products VMware Deployment Design Guide.
NUMA nodes
If the host supports non-uniform memory access (NUMA), you must assign each Perimeta virtual
machine to a NUMA node.
For more information on NUMA nodes, see Distribution of VMs across hosts in the Metaswitch
Products VMware Deployment Design Guide.
NIC ordering
If you are not using PCI passthrough, you must configure your Network Interface Controllers in a
specific order in the vSphere interface so Perimeta identifies them correctly. The order in which you
configure your NICs depends on the type of Session Controller and the number of NICs. Order your
NICs as follows.
1. Use the first NIC for your management network.
2. Use the second NIC for your high availability network.
3. Use the remaining NICs for your service networks. Ensure the order of the NICs matches the order
of your service networks.
You must configure any VMXNET3 NICs before SR-IOV NICs. If you configure SR-IOV NICs before
VMXNET3 NICs, the order in Perimeta will not match the order in the vSphere user interface.
Attention:
If you make a mistake in the order of your NICs, you will have to delete and recreate them all. You
cannot change the order in the vSphere user interface.
vApp properties for PCI passthrough
If you are using PCI passthrough (where the host passes the entire Network Interface Controller (NIC)
to the guest), you must choose a number of vApp properties to correctly identify all your NICs to each
2 Environment Planning 9
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
Perimeta VM. The Perimeta VMs will retrieve these properties by accessing OVF data from the host
using VMware tools.
Attention:
You must specify vApp properties for all your interfaces (including any management and high
availability interfaces) even if they are using virtual NIC adapters, instead of passed-through NICs.
Each property must have a key that identifies the Perimeta interface and a value that identifies the
NIC or PCI device that this Perimeta interface should use.
•
Keys must be given in the form Perimeta.Interface.<InterfaceName>. You can select from
the following interface names.
•
•
IBG1 (for the management interface)
•
IPG1 (for the HA interface in a high availability system)
•
RPG1 (for the core service interface)
•
RPG2 (for the general access and, optionally, managed access service interface).
Values must be given as the MAC addresses of the NICs.
You will be prompted to identify the MAC addresses as part of the installation procedure given in
Installing Perimeta in a VMware environment on page 80.
•
For NICs that you will pass through, you will identify the MAC addresses in the Process section.
•
For virtual NIC adapters, you can only identify the MAC addresses after you have created your
VMs. You will identify the MAC addresses in the Configure vApp properties to identify NICs to
the VMs (systems with PCI passthrough) step.
You must make a note of the keys and when you will identify each MAC address in Perimeta
commissioning planning tables on page 24.
Example: key / value mappings for management, high availability and two service
interfaces
•
Perimeta.Interface.IBG1 / 00:50:56:8f:26:c7
•
Perimeta.Interface.IPG1 / 00:50:56:8f:35:6X
•
Perimeta.Interface.RPG1 / 00:50:56:8f:01:a0
•
Perimeta.Interface.RPG2 / 00:50:56:8f:28:3d
Fault tolerance
You must ensure that there are fault tolerance mechanisms in place. The exact fault tolerance
mechanisms that you must use depend on whether your Perimeta virtual machines will be part of a
cluster.
For more information on the fault tolerance mechanisms that you must apply, see High availability
mechanisms in Metaswitch Products VMware Deployment Design Guide.
10 2 Environment Planning
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
DPDK mode
If you are deploying a medium or high capacity ISC with SR-IOV vNICs that use the 82599 controller
and the IXGBEVF driver (e.g. VFs provided by an Intel X520 Server Adapter in the host), you can
enable Intel's Data Plane Development Kit (DPDK) mode on your Session Controller. DPDK mode
provides efficient packet processing through the processing of vNIC packet queues in a tight poll
mode loop, rather than a traditional interrupt handling approach. However, DPDK mode can reduce
the media transcoding capacity of a Session Controller, as DPDK mode involves dedicating vCPUs to
packet processing.
You must decide whether you want to enable DPDK mode for each ISC that will be used primarily for
media transcoding. For information on the media transcoding capacity of Session Controllers with and
without DPDK mode enabled, see https://communities.metaswitch.com/docs/DOC-275536 and https://
communities.metaswitch.com/docs/DOC-275537.
Distributed Capacity Manager
You must have already installed a Distributed Capacity Manager (DCM) Group to your deployment.
You can find more information on how to do this in the Metaswitch Distributed Capacity Manager
Initial Setup Guide.
You must know the IP address of one of the DCMs in the DCM Group.
2 Environment Planning 11
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
3 Deployment Planning
3.1 Network planning: Overview
Before you can commission Perimeta, you must plan out various aspects of its network interfaces,
and collect some information about the networks it will connect to.
This section will guide you through the planning process in accordance with Metaswitch's best
practice solution for deploying Perimeta.
The best practice solution defines a standard network architecture and configuration model for
Perimeta, field-tested and suitable for typical deployments. It provides support for the following.
•
A core interface to one or more softswitches.
•
Access interfaces supporting SIP subscribers (phones, PBXs) and peers (SIP trunks). A general
access interface is always included, with an optional additional interface to connect to managed
networks on a different subnet.
•
Optional diagnostic reporting to a Network Management System such as Metaswitch's MetaView
Server using SNMP, and to the Metaswitch Service Assurance Server where available.
The information you will need to collect to set up this solution is listed in Perimeta commissioning
planning tables on page 24. The other sections of this document will provide the background
information you need to fill in those tables.
Restrictions
The following advanced Perimeta features are not part of the basic best practice solution. If you plan
to deploy these additional features, consult the relevant sections of the Perimeta documentation set.
•
IPv6.
•
TLS subscribers/peers
•
SRTP
•
IPsec peers
•
Additional core subnets or more than two access subnets.
•
SIP Message Manipulation
•
Media bypass
•
Advanced routing
•
Geographic redundancy
•
IMS
•
Transcoding
12 3 Deployment Planning
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
3.2 Planning your network interfaces: Overview
In the simplest version of the best practice solution, you will commission each Perimeta Session
Controller with interfaces to the following networks.
•
The management network connects your Session Controller to the devices you will use to
administer and monitor it, such as MetaView Server.
•
The high availability network connects one Perimeta virtual machine in a high availability system
to the other, allowing for replication of call and registration state and configuration changes. Note
that this interface is not used for standalone systems.
•
The core service network is your internal network; it connects your Session Controller to the core
VoIP devices it protects, such as your MetaSphere CFS.
•
The general access service network connects your Session Controller to external VoIP devices
such as endpoints, PBXs and peer session border controllers. These devices must go through
Perimeta to access your VoIP infrastructure in the core service network; this allows Perimeta to
protect your core devices.
Additionally, you can also set up a further interface if your deployment requires it.
•
The managed access service network connects your Session Controller to a limited set of
known SIP devices; typically SIP endpoints or PBXs in a managed IP network. Adding a separate
interface to this network allows you to use separate, less strict security policies for it than for the
general access network. If you use this network interface, it must not be open to unknown devices.
The following diagram shows the interfaces (without the high availability or optional managed access
interface) in a typical deployment.
3 Deployment Planning 13
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
This document will guide you through the planning you need to do before you can set up each of
these network interfaces. In the best practice solution, the management, high availability, core service,
and access interfaces on your ISC each use a separate virtual network interface.
If you use the managed access interface, you will either use a further, separate network interface, or
you will separate the managed access interface from the general access interface using VLANs.
•
If you are not using SR-IOV for high performance, you can choose to either use a separate
network interface or use VLANs.
•
If you are using SR-IOV for high performance, it is not possible to use VLANs. You must use a
separate network interface for the managed access interface.
3.3 Planning your management network interface
Your management network connects your Session Controller to the devices you will use to administer
and monitor it; you must plan out the devices you will deploy in the management network and the IP
details of the network.
The information in this section will help you fill in the Management Network section of Perimeta
commissioning planning tables on page 24.
14 3 Deployment Planning
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
Overview
Your Session Controller will connect to your management network over a separate physical
connection to the ones it uses for signaling and media.
You will need a distinct management subnet, protected by a firewall. Perimeta's management
interface is not hardened in the same way as its service interfaces, and must not be reachable by
unknown devices. For detailed information on the requirements on the firewall, see Traffic information
for firewall configuration in Perimeta Network Integration Guide.
Note:
You can use public DNS or NTP servers for Perimeta, but only through controlled pinholes in your
management network firewall.
You will need the following general information about the management network to configure Perimeta.
•
The default gateway IP address.
•
The subnet prefix length.
Local IP addresses
If you are commissioning a high availability system, you must allocate the following local IP addresses
in the management subnet to your Session Controller.
•
One system virtual IP address, which you will use to connect to whichever Perimeta instance is
currently primary in the high availability system. This will be the primary address you use to access
and configure your Session Controller.
•
Two per-instance IP addresses, which you can use to connect to a specific instance in the high
availability system.
If you are commissioning a standalone system, you must allocate one local IP address in the
management subnet to the Session Controller.
Remote devices
The management network can include the following devices.
•
DNS servers (ideally two or more up to a maximum of sixteen, for redundancy). These are only
required if you need to support domain names in SIP messages.
•
If possible, ensure that this DNS server is distinct from the DNS server in your general access
network, to prevent split-brain (also known as split-horizon or split-view) DNS issues.
•
Independent NTP servers (ideally three, for redundancy and to prevent conflicts between two NTP
servers with differing times).
•
An optional Network Management SNMP client, such as Metaswitch's MetaView Server, to receive
alarms (as SNMP traps) from Perimeta.
3 Deployment Planning 15
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
•
CONFIDENTIAL
An optional FTP file server, to which Perimeta can upload copies of snapshots, which serve as
a backup of both Craft Terminal and command line interface (CLI) configuration. If you have
deployed a MetaView Install server, you can use this instead of an FTP file server.
•
An optional Metaswitch MetaView Server or MetaSphere EAS running MetaView Web,
Metaswitch's intuitive web-based GUI that offers operators and provisioning staff a more
user-friendly option for Perimeta configuration that the Perimeta CLI. For more information,
see Managing and provisioning Perimeta using MetaView Web in Perimeta Operations and
Maintenance Guide.
•
If available, Metaswitch's Service Assurance Server (SAS), which allows you to process and
display detailed diagnostic information from Perimeta.
•
A Distributed Capacity Manager Group.
Probe targets
Perimeta uses ICMP ping requests to monitor connectivity on its management interfaces. You must
decide which three IP addresses it will use as probe targets. We recommend that you allocate targets
as follows.
•
If you have deployed MetaView Server or a standalone SAS, you can use them as targets. Thirdparty Network Management systems can also be suitable targets if you know that they respond
reliably to ICMP pings.
•
You can also use NTP servers as targets.
•
Default router IP addresses make bad targets, because they give low priority to ICMP and can
drop ping requests when under load.
3.4 Planning your high availability (HA) interface
The high availability (HA) interface connects one Perimeta virtual machine to another, allowing for call
and registration state and configuration changes to be synchronized between the two Perimeta virtual
machines in a high availability system.
Note:
You do not need to plan an HA interface for a standalone system.
You will need the following to plan your HA interfaces.
•
An HA subnet to be used for the connection between the Perimeta virtual machines in the high
availability system. You will need the subnet prefix length when you configure the Perimeta virtual
machines. We recommend a subnet of /30.
•
16 3 Deployment Planning
An HA IP address for each Perimeta virtual machine.
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
3.5 Planning your core network interface
Your core network contains your own, on-site VoIP devices, such as your softswitch. All VoIP
signaling and media between these devices and external endpoints, PBXs, SIP trunks etc. must pass
through Perimeta, allowing it to protect your core devices.
The information in this section will help you fill in the Core Service Network section of Perimeta
commissioning planning tables on page 24.
Overview
In the best practice solution, your Session Controller will connect to your core network over a separate
virtual network interface to the one it uses for your general access network. It is possible to configure
multiple service interfaces on a single virtual network interface if you are not using SR-IOV for high
performance, but this is not recommended for this solution.
You will need the following general information about the core service network to configure Perimeta.
•
The default gateway IP address.
•
The subnet prefix length. We recommend a subnet of /28 or greater.
Local IP addresses
You will need to allocate the following local IP addresses in the core subnet to your Session
Controller.
•
One global IP address that your Session Controller will use for signaling and media on this
interface. This will be the address your Session Controller exposes to your softswitch and other
core network devices.
Remote devices
To commission Perimeta, you will need to know and record the SIP IP addresses of each softswitch it
will route calls to.
Probe target
Perimeta uses ARP requests to monitor connectivity on service interfaces. Default routers typically
respond well to ARP requests so the probe target is set to the default gateway IP on both interfaces
by default.
3.6 Planning your access network interfaces
The access service interfaces connect Perimeta to the external VoIP devices that need to access your
core network: SIP endpoints, PBXs, SIP trunks etc.
3 Deployment Planning 17
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
The information in this section will help you fill in the General Access Service Network and Managed
Access Service Network sections of Perimeta commissioning planning tables on page 24.
Overview
The general access service interface is always included in the best practice solution. This interface is
exposed to untrusted networks that contain unknown devices, typically using the public internet.
You can optionally also configure a managed access service interface, if you require an additional
access subnet (for example, if you have a direct connection to a managed network of SIP devices that
does not use the public internet).
You will need the following general information about the access service networks to configure
Perimeta.
•
The default gateway IP address for each network you plan to use.
•
The subnet prefix length for each network you plan to use. We recommend a subnet of /28 or
greater.
•
If you are not using SR-IOV or PCI passthrough for high performance and you want the general
access service interface and managed access service interface to share the same virtual network
interface, a numerical VLAN ID for each service interface. You can choose to use a separate
virtual network interface for the managed access service interface if you prefer.
If you are using SR-IOV or PCI passthrough for high performance, you must use a separate virtual
network interface for the managed access service interface.
Local IP addresses
You will need to allocate the following local IP addresses in each access subnet to your Session
Controller.
•
At least one global IP address that your Session Controller will use for signaling and media on
this interface. This will be the primary signaling address that your Session Controller exposes
to external VoIP devices. You may require additional access IP addresses, depending on the
specifics of your deployment; see Additional IP addresses for SIP trunks or multiple softswitches
on page 19 below.
•
A number of probe source IP addresses, which your Session Controller will use to check
connectivity from the individual physical interfaces each Perimeta instance uses to connect to the
access networks.
•
If you are commissioning a high availability system using SR-IOV or PCI passthrough and your
port group scheme uses redundant ports, you must allocate four probe source IP addresses.
•
If you are commissioning a high availability system and your port group scheme does not use
redundant ports, you must allocate two probe source IP addresses.
•
If you are commissioning a standalone system using SR-IOV or PCI passthrough and your port
group scheme uses redundant ports, you must allocate two probe source IP addresses.
•
If you are commissioning a standalone system and your port group scheme does not use
redundant ports, you must allocate one probe source IP address.
18 3 Deployment Planning
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
Additional IP addresses for SIP trunks or multiple softswitches
If your deployment includes SIP trunks to external peers, we recommend that you provide an
additional access IP address for the trunks to connect to, on the appropriate interface. This is
necessary to provide effective capacity control and security policy for the SIP trunks.
If you plan to protect multiple softswitches with Perimeta, you will require some way of routing general
access traffic to the appropriate softswitch. You can choose from the following two options.
•
Allocate an additional access IP address on the general access interface for each additional
softswitch. Perimeta can then use the local IP address that SIP messages arrive at to route them
to the correct softswitch.
•
Provision multiple domain names in your access-side DNS that resolve to your Perimeta
access IP address, each corresponding to a softswitch. For example, cfs1.perimeta.com,
cfs2.perimeta.com, and so on. Perimeta can then use the destination domain name specified
in SIP messages to route them to the correct softswitch; you would configure endpoints registering
to your first softswitch to register at cfs1.perimeta.com and do the same for your other
softswitches. If you do this you will not require additional access IP addresses.
Remote devices
You will need to know and record the IP addresses of the following remote devices on either access
network.
•
The remote peer for any SIP trunks that will connect to your Session Controller.
•
Any SIP devices that meet the following criteria.
•
Any device that uses SIP but does not register; typically these will be non-registering PBXs.
•
Any remote devices that require specific SIP interoperability settings, capacity limits, or other
Perimeta settings.
•
Any single remote IP addresses from which more than 100 registering endpoints will connect;
typically these will be SIP PBXs or large access networks behind NAT.
Note:
The foundation configuration includes blacklisting profiles for use with single IP addresses that
represent 100 registering endpoints (Site100 and PerPort100). These profiles can be changed
if single IP addresses will be expected to support more or fewer registering endpoints. If you
do change these profiles, you should only record any single remote IP addresses from which
the number of connecting registering endpoints will exceed the number for which your dynamic
blacklisting profiles are designed. For example, if you use the Site250 and PerPort250 profiles
given in Additional example dynamic blacklisting profiles on page 64, you must only record any
single IP addresses from which more than 250 registering endpoints will connect.
3 Deployment Planning 19
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
Probe target
Perimeta uses ARP requests to monitor connectivity on service interfaces. Default routers typically
respond well to ARP requests so the probe target is set to the default gateway IP on both interfaces
by default.
3.7 Choosing a port group scheme
The Ethernet ports Perimeta uses for its service interfaces can be grouped into redundant pairs.
Before commissioning your system, you must choose a port group scheme that defines how the ports
are grouped, and assign the ports for your service interfaces.
You must assign each of your service interfaces a single port group. A port group consists of one of
the following.
•
A single Ethernet port.
•
A redundant pair of individual ports, allowing interfaces using the group to switch between them if
one connection fails.
The port group scheme that you choose for your system determines the available port groups and
which ports they contain.
Before you commission your system, you must do the following.
1. Select a port group scheme suitable for your deployment from those listed below. The port group
scheme that we recommend for use with the best practice solution depends on whether you are
using either SR-IOV or PCI passthrough for high performance and whether the Session Controller
will connect to a managed access network.
•
If you are not using SR-IOV or PCI passthrough and are not planning to connect to a managed
access service network, you must use the two-port scheme Two links without on-instance
redundancy on page 21. This will provide two port groups, with one provided for the core
interface (called CoreNetwork in the best practice solution) and one for the general access
interface (called AccessNetwork in the best practice solution).
•
If you are not using SR-IOV or PCI passthrough and are planning to connect to a managed
access service network, you must use the four-port scheme Four links without on-instance
redundancy on page 21. This will provide four port groups. You will use one group for the
core interface (called CoreNetwork in the best practice solution), one for the general access
interface (called AccessNetwork in the best practice solution) and one for the managed
access interface (called ManagedAccessNetwork in the best practice solution). You will not
use the fourth port group.
•
If you are using SR-IOV or PCI passthrough and are not planning to connect to a managed
access service network, you must use the four-port scheme Two links with on-instance
redundancy on page 21. This will provide a port group with a redundant pair of individual
ports for both the core interface (called CoreNetwork in the best practice solution) and general
access interface (called AccessNetwork in the best practice solution).
20 3 Deployment Planning
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
•
If you are using SR-IOV or PCI passthrough and are planning to connect to a managed access
service network, you must use the six-port scheme Three links with on-instance redundancy
on page 22. This will provide a port group with a redundant pair of individual ports for the
core interface (called CoreNetwork in the best practice solution), general access interface
(called AccessNetwork in the best practice solution) and managed access interface (called
ManagedAccessNetwork in the best practice solution).
You can choose to use a different port group scheme to those that we recommend if it is more
suitable for your deployment. The port group schemes available for your virtual machines will
depend on the number of service Ethernet ports your hardware platform uses. The following
sections list all of the available port group schemes for Perimeta running on virtual machines. Note
that you must use a port group scheme that provides redundant ports if you are using SR-IOV or
PCI passthrough for high performance.
2. Fill in the port groups section of your copy of the planning tables in Perimeta commissioning
planning tables on page 24, noting the names of your port groups (as above, usually
CoreNetwork, AccessNetwork and, optionally, ManagedAccessNetwork) and which ports
they include.
Two-port schemes
Virtual machines with two virtual service Ethernet ports can use the following schemes. Note that
aggregated ports are not supported when Perimeta is operating in a virtualized environment.
Two links without on-instance redundancy
This scheme does not provide any on-VM link redundancy. Each port provides a separate link.
Port groups
Each single port is in its own port group.
Four-port schemes
Virtual machines with four virtual service Ethernet ports can use the following schemes. Note that
aggregated ports are not supported when Perimeta is operating in a virtualized environment.
Four links without on-instance redundancy
This scheme does not provide any on-VM link redundancy. Each port provides a separate link.
Port groups
Each single port is in its own port group.
Two links with on-instance redundancy
This scheme provides four links in two redundant pairs.
Port groups
There are two port groups.
3 Deployment Planning 21
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
•
One contains RPG1 and RPG2.
•
One contains RPG3 and RPG4.
CONFIDENTIAL
Six-port schemes
Virtual machines with six virtual service Ethernet ports can use the following schemes. Note that
aggregated ports are not supported when Perimeta is operating in a virtualized environment.
Six links without on-instance redundancy
This scheme does not provide any on-VM link redundancy. Each port provides a separate link.
Port groups
Each single port is in its own port group.
Three links with on-instance redundancy
This scheme provides six links in three redundant pairs.
Port groups
There are three port groups.
•
One contains RPG1 and RPG2.
•
One contains RPG3 and RPG4.
•
One contains RPG5 and RPG6.
Eight-port schemes
Virtual machines with eight virtual service Ethernet ports can use the following schemes. Note that
aggregated ports are not supported when Perimeta is operating in a virtualized environment.
Eight links without on-instance redundancy
This scheme does not provide any on-VM link redundancy. Each port provides a separate link.
Port groups
Each single port is in its own port group.
Four links with on-instance redundancy
This scheme provides 8 links in four redundant pairs.
There are four port groups.
Port groups
•
One contains RPG1 and RPG2.
•
One contains RPG3 and RPG4.
•
One contains RPG5 and RPG6.
•
One contains RPG7 and RPG8.
22 3 Deployment Planning
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
4 Security Planning
4.1 Firewall configuration
You must correctly configure any firewalls in your network to permit legitimate traffic to and from
Perimeta.
Attention:
You must implement a robust firewall strategy that ensures your network is protected from
unauthorized traffic or impeding the proper functioning of your deployment. For guidance, see
Traffic information for firewall configuration in Perimeta Network Integration Guide.
4 Security Planning 23
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
5 Perimeta commissioning planning tables
These tables list the information you will need before you begin commissioning Perimeta. You can
copy or print out these tables and fill them out to record the information you need for ease of access
during commissioning.
Virtual machines
To help fill in this table, read Planning your virtual environment for Perimeta on page 6.
Note that the table refers to Processor A and Processor B.
•
Processor A is the first virtual machine in a high availability system or the only virtual machine in a
standalone system.
•
Processor B is the second virtual machine in a high availability system. You do not need to fill in
information for Processor B if you are deploying a standalone system.
The name of the datacenter to which you will add
the virtual machines.
The name of Processor A.
The name of Processor B (high availability
systems only).
The name of the host on which you will install
Processor A.
The name of the host on which you will install
Processor B (high availability systems only).
The name of the datastore that will be used for
the virtual machine configuration files and virtual
disks.
The required number of vCPUs for your Session
Controller type.
The collective clock speed of the physical
CPUs provided by the host for use by the virtual
machine.
For example, for a host that provides 8 physical
CPUs with an individual clock speed of 2.5GHz,
24 5 Perimeta commissioning planning tables
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
the collective clock speed will be 20GHz (2.5GHz
multiplied by 8).
The required amount of RAM (in MB) for your
Session Controller type.
The required hard disk size (in GB).
The network to which the management interface
will connect.
The network to which the HA interface will
connect (high availability systems only).
The network to which the core service interface
will connect.
If the core network interface will use SR-IOV or
PCI passthrough, the physical NIC to which the
core interface will connect.
The network to which the general access service
interface will connect.
If the general access service interface will use
SR-IOV or PCI passthrough, the physical NIC to
which the general access service interface will
connect.
The network to which the managed access
service interface will connect (if applicable).
If the managed access service interface will use
SR-IOV or PCI passthrough, the physical NIC to
which the managed access service interface will
connect.
The location in which the Perimeta OVA file is
stored.
The number of the NUMA node on which
Processor A will run.
You must only provide a value for this if the host
on which this virtual machine will run supports
NUMA.
5 Perimeta commissioning planning tables 25
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
The number of the NUMA node on which
Processor B will run.
You must only provide a value for this if you are
commissioning a high availability system and
the host on which this virtual machine will run
supports NUMA.
If you are not using PCI passthrough, the order
in which you need to configure your NICs in the
vSphere user interface.
If you are using PCI passthrough for any
•
Key: IBG1
interface,
•
When MAC address (value) identified:
•
The key for the vApp property for the
•
MAC address (value):
management interface.
•
PCI address:
•
Key: IPG1
•
A note of when you will identify the MAC
address to use as the value.
•
The MAC address to use as the value.
•
The PCI address of the physical NIC (not
required if you are using a virtual NIC instead
of passing a NIC through for this interface).
If you are using PCI passthrough for any
interface and this is a high availability system,
•
When MAC address (value) identified:
The key for the vApp property for the high
availability interface.
MAC address (value):
•
PCI address:
If you are using PCI passthrough for any
•
Key: RPG1
interface,
•
When MAC address (value) identified:
•
The key for the vApp property for the core
•
MAC address (value):
service interface.
•
PCI address:
•
A note of when you will identify the MAC
address to use as the value.
•
The MAC address to use as the value.
•
The PCI address of the physical NIC (not
required if you are using a virtual NIC instead
of passing a NIC through for this interface).
•
A note of when you will identify the MAC
address to use as the value.
•
The MAC address to use as the value.
26 5 Perimeta commissioning planning tables
CONFIDENTIAL
•
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
The PCI address of the physical NIC (not
required if you are using a virtual NIC instead
of passing a NIC through for this interface).
If you are using PCI passthrough for any
•
Key: RPG2
interface,
•
When MAC address (value) identified:
•
The key for the vApp property for the general
•
MAC address (value):
access and, optionally, managed access
•
PCI address:
service interface.
•
A note of when you will identify the MAC
address to use as the value.
•
The MAC address to use as the value.
•
The PCI address of the physical NIC (not
required if you are using a virtual NIC instead
of passing a NIC through for this interface).
Whether or not DPDK mode must be enabled on
this Session Controller.
Distributed Capacity Manager (DCM)
To help fill in this table, see Planning your virtual environment for Perimeta on page 6.
IP address of one of the DCMs in the DCM
Group (not required if installing co-resident
DCMs)
Management network
Note that the table refers to Processor A and Processor B. You do not need to fill in information for
Processor B if you are deploying a standalone system.
To help fill in these tables, read Planning your management network interface on page 14.
Subnet length (e.g /24)
System virtual IP address
Processor A IP address (high availability systems
only)
Processor B IP address (high availability systems
only)
5 Perimeta commissioning planning tables 27
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
Default gateway
DNS server IP address(es) - up to a maximum of
sixteen DNS servers
NTP server 1 IP address
NTP server 2 IP address
NTP server 3 IP address
MetaView Server/Network Management Solution
IP address (address to which Perimeta must
send SNMP alarms - optional)
MetaView Install Server or FTP file server IP
address (address to which Perimeta must upload
snapshots - optional)
Service Assurance Server IP address (optional)
Probe target address 1
Probe target address 2
Probe target address 3
High availability network
To help fill in this table, see Planning your high availability (HA) interface on page 16.
Note:
You do not need to plan an HA interface for a standalone system.
HA subnet prefix length
HA IP address A
HA IP address B
Core service network
To help fill in these tables, read Planning your core network interface on page 17.
28 5 Perimeta commissioning planning tables
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
Main Perimeta IP address
Probe source IP address 1
Probe source IP address 2 (if required)
Probe source IP address 3 (if required)
Probe source IP address 4 (if required)
Subnet length (e.g /24)
Default gateway IP address
Probe target address (this is the default gateway)
VLAN ID (optional)
Softswitch SIP IP address
Second softswitch IP (optional)
Third softswitch IP (optional)
Fourth softswitch IP (optional)
Access service networks
To help fill in these tables, read Planning your access network interfaces on page 17.
Table 1: General access service network
Primary Perimeta signaling IP address
Peering Perimeta signaling IP address (if needed
for SIP trunks to external peers)
Probe source IP address 1
Probe source IP address 2 (if required)
Probe source IP address 3 (if required)
Probe source IP address 4 (if required)
Subnet length (e.g /24)
5 Perimeta commissioning planning tables 29
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
Default gateway IP address (this is the default
gateway)
VLAN ID (optional, required if you are not using
SR-IOV and you want the general access and
managed access service network to share the
same virtual network interface)
Table 2: Managed access service interface
Primary Perimeta signaling IP address
Peering Perimeta signaling IP address (if needed
for SIP trunks to external peers)
Access Perimeta signaling IP addresses (if
needed for additional softswitches)
Probe source IP address 1
Probe source IP address 2 (if required)
Probe source IP address 3 (if required)
Probe source IP address 4 (if required)
Subnet length (e.g /24)
Default gateway IP address (this is the default
gateway)
VLAN ID (optional, required if you are not using
SR-IOV and you want the general access and
managed access service network to share the
same virtual network interface)
SIP PBXs and multi-endpoint devices
Record the IP addresses of any devices, such as PBXs or NAT devices at the edge of managed SIP
networks that meet one or more of the following criteria.
•
SIP traffic sent to the softswitch without registering (non-registering PBXs).
•
More than 100 registering endpoints connecting from a single remote IP address (NAT or SIP
PBX).
30 5 Perimeta commissioning planning tables
CONFIDENTIAL
•
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
Remote device requires specific SIP interoperability settings, capacity limits, or other Perimeta
settings.
Device IP address
Non-registering SIP traffic?
>100 subscribers? (Yes/No,
(Yes/No)
record estimated number of
subscribers if known)
Device IP address
Non-registering SIP traffic?
>100 subscribers? (Yes/No,
(Yes/No)
record estimated number of
subscribers if known)
SIP trunks
Record the IP addresses of any SIP trunks that will connect to your Session Controller here.
Trunk
IP address
Network (general access or
managed access)
SIP trunk 1
SIP trunk 2
SIP trunk 3
SIP trunk 4
SIP trunk 5
Port group scheme
To help fill in this table, see Choosing a port group scheme on page 20. For the CoreNetwork and
AccessNetwork (and, optionally, ManagedAccessNetwork) port groups, note down the names of the
single or aggregated ports in the group, and for any aggregated ports, note which individual ports they
include.
5 Perimeta commissioning planning tables 31
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
Chosen port group scheme
CoreNetwork port group
AccessNetwork port group
ManagedAccessNetwork port group
Additional information
Timezone
You must know the local timezone in which Perimeta will operate.
Timezone
Non-standard DSCP values
DSCP packet marking indicates which packets network devices should prioritize to maintain quality
of service. The default DSCP settings used by Perimeta are given below. If your network requires
alternative values, add them to the table; you can change the default values when you commission
your Session Controller.
Traffic type
DSCP value
In-dialog SIP
(Default 24)
Out-of-dialog SIP
(Default 24)
Media - voice
(Default 46)
Media - video
(Default 46)
Test subscriber
You will need a free directory number on your switch that you can use to test your configuration during
commissioning.
Test subscriber directory number
MetaView Web
You must decide whether you want to allow your administrators to manage Perimeta Session
Controller configuration using MetaView Web, as described in Managing and provisioning Perimeta
using MetaView Web in Perimeta Operations and Maintenance Guide. It is possible to enable
32 5 Perimeta commissioning planning tables
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
adjacency management through MetaView Web for Perimeta Provisioners or enable Perimeta
configuration through MetaView Web for Perimeta Expert Management users. You must know
whether you want to enable MetaView Web management of Perimeta for one or both of these user
types.
User type
Yes / No
Perimeta Provisioners
Perimeta Expert Management users
5 Perimeta commissioning planning tables 33
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
6 Preparing CLI configuration
6.1 Preparing your CLI configuration: Overview
This section of the guide provides you with a full set of foundation CLI configuration for a Perimeta
ISC using the best practice solution, and takes you through the updates you need to make to
customize it for your deployment. This allows you to prepare your CLI configuration ahead of time,
before you begin the process of commissioning your Perimeta ISC.
You can find the full foundation configuration in Full foundation configuration on page 35 . It
contains a large number of commands and may seem daunting. However, if you have planned your
deployment around the best practice solution by working through the Deployment Planning section of
this guide, you will only need to make a limited set of changes to the foundation configuration before it
will be suitable for your deployment.
We recommend that you use the following process to prepare your CLI configuration. You will need to
refer to the information you gathered to fill in the planning tables in Perimeta commissioning planning
tables on page 24.
•
Copy the full foundation configuration to a text file.
•
Work through the following sections of this guide in order. Each one provides some explanation of
key elements of an area of the foundation configuration, and provides a series of steps you need
to take to customize that area for your deployment; you can make the changes to the foundation
configuration as you work through each section.
1. Service interface configuration on page 44.
2. Media interface configuration on page 49.
3. Signaling configuration on page 50.
4. Diagnostics configuration on page 56.
5. Dynamic blacklisting configuration on page 57.
6. Tuning your configuration for your softswitch on page 77.
•
If your deployment includes multiple softswitches, work through Adding additional softswitches on
page 74.
This will give you customized foundation configuration that you can copy and paste into the Perimeta
CLI when you set up your Session Controller.
This guide also includes a summary of all the changes you need to make to the foundation
configuration, in Changes you need to make to the foundation configuration: Summary on page 71.
This can be a useful reference and overview, especially if you are already familiar with the Perimeta
CLI, but it lacks the explanations of each change given in the more detailed sections.
34 6 Preparing CLI configuration
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
6.2 Full foundation configuration
This is the full foundation configuration for a Perimeta ISC using the best practice solution. You will
need to update various sections of this configuration to match the specifics of your deployment.
The changes you will need to make to this configuration are summarized in Changes you need to
make to the foundation configuration: Summary on page 71, and described in more detail in the
other sections of this guide. We recommend that you copy the full configuration to a text file and make
the necessary changes there. You can then copy and paste your customized configuration from the
text file into the Perimeta CLI when you set up your system.
config
system
service-interface serv1
description "Core network"
service-network 1
port-group-name CoreNetwork
ipv4
subnet-prefix-length 24
gateway-ip-address 10.10.10.1
local-ip-address 10.10.10.10
service-address CoreAddress4-01
probes-target 10.10.10.1
probes-source-style specific-source
probes-source-ip shelf A interface 1
probes-source-ip shelf A interface 2
probes-source-ip shelf B interface 1
probes-source-ip shelf B interface 2
activate
network-security trusted
criticality 1000
probes-interval 1000
!vlan-id (vlan-id)
service-interface serv2
description "General Access Network"
service-network 2
port-group-name AccessNetwork
ipv4
subnet-prefix-length 26
gateway-ip-address 53.53.53.1
local-ip-address 53.53.53.10
service-address AccessAddress4-01
local-ip-address 53.53.53.11
service-address Trunk1Address4-01
probes-target 53.53.53.1
probes-source-style specific-source
probes-source-ip shelf A interface 1
probes-source-ip shelf A interface 2
probes-source-ip shelf B interface 1
probes-source-ip shelf B interface 2
activate
network-security untrusted
criticality 1000
disable-icmp-responses
probes-interval 1000
!vlan-id (vlan-id)
service-interface serv3
description "Managed Access Network"
service-network 3
port-group-name AccessNetwork
10.10.10.11
10.10.10.12
10.10.10.13
10.10.10.14
53.53.53.15
53.53.53.16
53.53.53.17
53.53.53.18
6 Preparing CLI configuration 35
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
ipv4
subnet-prefix-length 26
gateway-ip-address 53.53.54.1
local-ip-address 53.53.54.10
service-address ManagedAddress4-01
probes-target 53.53.54.1
probes-source-style specific-source
probes-source-ip shelf A interface 1 53.53.54.11
probes-source-ip shelf A interface 2 53.53.54.12
probes-source-ip shelf B interface 1 53.53.54.13
probes-source-ip shelf B interface 2 53.53.54.14
activate
network-security untrusted
criticality 1000
disable-icmp-responses
probes-interval 1000
vlan-id 2
ip-access-control
blacklisting
profile PerPortPhone100
! Site with per-port where every port represents an end-device
! This should be used in conjunction with a Site profile
! that specifies the same IP address.
reason auth-failure
trigger-period 30 seconds
! minor-alarm-rate 264 per-minute
major-alarm-rate 66 per-second
ban-rate 88 per-second
ban-duration 10 minutes
reason routing-failure
trigger-period 30 seconds
! minor-alarm-rate 20 per-minute
major-alarm-rate 5 per-second
ban-rate 7 per-second
ban-duration 10 minutes
reason endpt-reg
trigger-period 30 seconds
! minor-alarm-rate 42 per-minute
major-alarm-rate 11 per-second
ban-rate 14 per-second
ban-duration 10 minutes
reason capacity-limit
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason corrupt-message
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason source-addr
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason spam
trigger-period 30 seconds
! minor-alarm-rate 1038 per-minute
major-alarm-rate 260 per-second
ban-rate 346 per-second
ban-duration 10 minutes
reason num-validation-failure
36 6 Preparing CLI configuration
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason tcp-abuse
trigger-period 30 seconds
! minor-alarm-rate 1 per-second
major-alarm-rate 15 per-second
ban-rate 20 per-second
ban-duration 10 minutes
reason tls-reneg
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason endpt-registrar-reg
trigger-period 30 seconds
! minor-alarm-rate 22 per-minute
major-alarm-rate 6 per-second
ban-rate 8 per-second
ban-duration 10 minutes
profile Site100
! Blacklist for any single IP address
! Equivalence to 100 endpoints, e.g. 100 user PBX or HPBX site
description "100 endpoints per IP address"
reason reg-auth-failure
trigger-period 30 seconds
! minor-alarm-rate 24 per-second
major-alarm-rate 360 per-second
ban-rate 480 per-second
ban-duration 10 minutes
reason auth-failure
trigger-period 30 seconds
! minor-alarm-rate 24 per-second
major-alarm-rate 360 per-second
ban-rate 480 per-second
ban-duration 10 minutes
reason routing-failure
trigger-period 30 seconds
! minor-alarm-rate 80 per-minute
major-alarm-rate 30 per-second
ban-rate 40 per-second
ban-duration 10 minutes
reason endpt-reg
trigger-period 30 seconds
! minor-alarm-rate 16 per-second
major-alarm-rate 240 per-second
ban-rate 320 per-second
ban-duration 10 minutes
reason capacity-limit
trigger-period 30 seconds
! minor-alarm-rate 4 per-minute
major-alarm-rate 60 per-minute
ban-rate 80 per-minute
ban-duration 10 minutes
reason corrupt-message
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 4 per-second
ban-rate 5 per-second
ban-duration 10 minutes
reason source-addr
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
6 Preparing CLI configuration 37
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
major-alarm-rate 4 per-second
ban-rate 5 per-second
ban-duration 10 minutes
reason spam
trigger-period 30 seconds
! minor-alarm-rate 54 per-second
major-alarm-rate 810 per-second
ban-rate 1080 per-second
ban-duration 10 minutes
reason num-validation-failure
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 4 per-second
ban-rate 5 per-second
ban-duration 10 minutes
reason tcp-abuse
trigger-period 30 seconds
! minor-alarm-rate 4 per-second
major-alarm-rate 60 per-second
ban-rate 80 per-second
ban-duration 10 minutes
reason tls-reneg
trigger-period 30 seconds
! minor-alarm-rate 4 per-second
major-alarm-rate 60 per-second
ban-rate 80 per-second
ban-duration 10 minutes
reason endpt-registrar-reg
trigger-period 30 seconds
! minor-alarm-rate 8 per-second
major-alarm-rate 120 per-second
ban-rate 160 per-second
ban-duration 10 minutes
profile Peer500
! SIP PBX and SIP trunks with no authentication or registration
description "Trunk or PBX with 500 calls"
reason reg-auth-failure
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason auth-failure
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason routing-failure
trigger-period 30 seconds
! minor-alarm-rate 250 per-minute
major-alarm-rate 63 per-second
ban-rate 84 per-second
ban-duration 10 minutes
reason endpt-reg
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason capacity-limit
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
38 6 Preparing CLI configuration
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
reason corrupt-message
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 4 per-second
ban-rate 5 per-second
ban-duration 10 minutes
reason source-addr
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 4 per-second
ban-rate 5 per-second
ban-duration 10 minutes
reason spam
trigger-period 30 seconds
! minor-alarm-rate 30 per-second
major-alarm-rate 450 per-second
ban-rate 600 per-second
ban-duration 10 minutes
reason num-validation-failure
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 4 per-second
ban-rate 5 per-second
ban-duration 10 minutes
reason tcp-abuse
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason tls-reneg
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason endpt-registrar-reg
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
profile ServiceNetwork1000
! Detect and protect against distributed attacks
! endpoints; 1000 concurrent calls
description "1000 calls, devices"
reason reg-auth-failure
trigger-period 30 seconds
! minor-alarm-rate 660 per-second
major-alarm-rate 990 per-second
reason auth-failure
trigger-period 30 seconds
! minor-alarm-rate 660 per-second
major-alarm-rate 990 per-second
reason routing-failure
trigger-period 30 seconds
! minor-alarm-rate 1500 per-minute
major-alarm-rate 375 per-second
reason endpt-reg
trigger-period 30 seconds
! minor-alarm-rate 660 per-second
major-alarm-rate 1320 per-second
reason capacity-limit
trigger-period 30 seconds
! minor-alarm-rate 10 per-minute
major-alarm-rate 3 per-second
6 Preparing CLI configuration 39
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
reason corrupt-message
trigger-period 30 seconds
! minor-alarm-rate 22 per-minute
major-alarm-rate 6 per-second
reason source-addr
trigger-period 30 seconds
! minor-alarm-rate 22 per-minute
major-alarm-rate 6 per-second
reason spam
trigger-period 30 seconds
! minor-alarm-rate 1980 per-second
major-alarm-rate 2105 per-second
reason num-validation-failure
trigger-period 30 seconds
! minor-alarm-rate 22 per-minute
major-alarm-rate 6 per-second
reason tcp-abuse
trigger-period 30 seconds
! minor-alarm-rate 10 per-second
major-alarm-rate 150 per-second
reason tls-reneg
trigger-period 30 seconds
! minor-alarm-rate 110 per-second
major-alarm-rate 330 per-second
reason endpt-registrar-reg
trigger-period 30 seconds
! minor-alarm-rate 220 per-second
major-alarm-rate 660 per-second
profile-usage
scope service-network
service-network 2 profile ServiceNetwork1000
service-network 3 profile ServiceNetwork1000
scope per-address
service-network 2 profile Site100
service-network 3 profile Site100
scope specified-address
service-network 2
ipv4 21.21.21.50 profile Peer500
scope per-port
! Profiles for per-port-source blacklisting applied here.
trusted-sources
!All non-registering endpoints in untrusted (access) service
!networks must be added here.
permit-peer service-network 2 ipv4 21.21.21.50
sbc
diagnostics
alarm-thresholds
default-adjacency-alarms as-destination
regs-limit
minor-threshold 75% clear 70%
major-threshold 85% clear 80%
critical-threshold 95% clear 90%
call-rate-limit sustain
minor-threshold 75% clear 70%
major-threshold 85% clear 80%
critical-threshold 95% clear 90%
in-call-rate-limit sustain
minor-threshold 75% clear 70%
major-threshold 85% clear 80%
critical-threshold 95% clear 90%
ooc-rate-limit sustain
minor-threshold 75% clear 70%
major-threshold 85% clear 80%
critical-threshold 95% clear 90%
regs-rate-limit sustain
minor-threshold 75% clear 70%
40 6 Preparing CLI configuration
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
major-threshold 85% clear 80%
critical-threshold 95% clear 90%
default-adjacency-alarms
regs-limit
minor-threshold 75% clear 70%
major-threshold 85% clear 80%
critical-threshold 95% clear 90%
call-rate-limit sustain
minor-threshold 75% clear 70%
major-threshold 85% clear 80%
critical-threshold 95% clear 90%
in-call-rate-limit sustain
minor-threshold 75% clear 70%
major-threshold 85% clear 80%
critical-threshold 95% clear 90%
ooc-rate-limit sustain
minor-threshold 75% clear 70%
major-threshold 85% clear 80%
critical-threshold 95% clear 90%
regs-rate-limit sustain
minor-threshold 75% clear 70%
major-threshold 85% clear 80%
critical-threshold 95% clear 90%
call-alarms
failed-attempts-rate max 60 clear 40
active-failures-perc max 2% clear 2%
license-alarms
minor-threshold 60% clear 50%
major-threshold 80% clear 70%
critical-clear 90%
media-alarms
hardware-capacity-perc max 90% clear 80%
advanced-capacity-perc max 90% clear 80%
pkts-discarded-perc max 10% clear 9%
policy-alarms
setup-failures-capac-perc max 1% clear 1%
setup-failures-na-perc max 1% clear 1%
setup-failures-rtg-perc max 1% clear 1%
sip-alarms
oldest-queued-packet max 1000 clear 900
system-alarms
cpu max 70% clear 65%
free-mem-mb min 1500 clear 1650
sas remote-address ipv4 192.168.51.41
snmp
snmp-client "Network Management System"
client-address ipv4 192.168.51.40
notifications
general-notifications
hardware-notifications
media
media-address ipv4 10.10.10.10 service-network 1
realm CoreMedia1
media-address ipv4 53.53.53.10 service-network 2
realm AccessMedia1
media-address ipv4 53.53.53.11 service-network 2
realm TrunkMedia1
media-address ipv4 53.53.54.10 service-network 3
realm ManagedAccessMedia1
vmsc global
activate
signaling
6 Preparing CLI configuration 41
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
burst-rate-limit-period 6 seconds
sip message-manipulation
header-profile DropAttackTools
header User-Agent
action drop-request
!Remove any UA strings between the |s in the following
!line as needed.
!UA strings are case sensitive.
condition advanced "(REGEX
(msg.first-header(\"User-Agent\").value,
'(friendly|SIPScan|SIPSCAN|smap|SMAP|sipsak|sipcli
|sipv|iWar|VAXSIPUserAgent|VaxIPUserAgent|sundayddr
|SIVus|sip|SIPp|eyebeam|Kapanga|X-Lite|Firefly
|OmniSession|Zoiper|Sipdroid|Ozeki|Mizuphone
|linphone|3CXPhone)'))"
sip interop-profile Peer
description "for use with a Peer"
header-settings from rewrite host local port include
header-settings via passthrough-inbound
ping-enable
interval 8
lifetime 8
dynamic-peer-routing
sip interop-profile GenericAccess
description "for use with an open adjacency"
dtmf sip info always-supported
header-settings via passthrough-inbound
registration fast-register
tcp fully-supported
registration min-expiry-time 3600
message-manipulation
edit-profiles inbound "DropAttackTools"
sip interop-profile ManagedAccess
description "for use with an open adjacency"
header-settings via passthrough-inbound
registration fast-register
tcp fully-supported
registration min-expiry-time 3600
sip interop-profile Softswitch
description "for use with a softswitch"
header-settings via passthrough-outbound
ping-enable
interval 8
lifetime 8
adjacency sip Softswitch
call-media-policy
repeat-sdp-on-200ok
deactivation-mode normal
force-signaling-peer all-requests
adjacency-type preset-core
outbound-flood-rate 1000
privacy trusted
realm CoreMedia1
remote-address-range ipv4 10.10.11.20 prefix-len 32
service-address CoreAddress4-01
signaling-local-port
signaling-peer 10.10.11.20
signaling-peer-port 5060
statistics-setting detail
default-interop-profile Softswitch
activate
adjacency sip GenericAccess
! This adjacency is for registering endpoints and
! open-access PBXs
call-media-policy
media-bypass-policy forbid
42 6 Preparing CLI configuration
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
repeat-sdp-on-200ok
deactivation-mode normal
adjacency-type preset-access
nat autodetect
privacy untrusted
realm AccessMedia1
service-address AccessAddress4-01
signaling-local-port 5060
signaling-peer 0.0.0.0
signaling-peer-port 0
statistics-setting detail
default-interop-profile GenericAccess
activate
adjacency sip Trunk1
adjacency-limits
regs 0
regs-rate sustain 0 per-minute
call-media-policy
media-bypass-policy forbid
deactivation-mode normal
force-signaling-peer all-requests
adjacency-type preset-peering
privacy trusted
realm TrunkMedia1
remote-address-range ipv4 21.21.21.50 prefix-len 32
service-address Trunk1Address4-01
signaling-local-port 5060
signaling-peer 21.21.21.50
dynamic-routing-domain-match 21.21.21.50
signaling-peer-port 5060
statistics-setting detail
default-interop-profile Peer
activate
adjacency sip ManagedAccess
! This adjacency is for registering endpoints and
! open-access PBXs on the managed access network
call-media-policy
media-bypass-policy forbid
repeat-sdp-on-200ok
deactivation-mode normal
adjacency-type preset-access
nat autodetect
privacy untrusted
realm ManagedAccessMedia1
service-address ManagedAddress4-01
signaling-local-port 5060
signaling-peer 0.0.0.0
signaling-peer-port 0
statistics-setting detail
default-interop-profile ManagedAccess
activate
call-policy-set 1
first-call-routing-table SourceAdjacency
first-reg-routing-table SourceAdjacency
rtg-src-adjacency-table SourceAdjacency
description "Initial routing table"
entry 1
match-adjacency Softswitch
action next-table AccessDomains
entry 199
match-adjacency *
dst-adjacency Softswitch
action complete
rtg-dst-domain-table AccessDomains
description "Routing from core to access"
entry 301
6 Preparing CLI configuration 43
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
match-domain *
dst-adjacency dynamic-peer-routing
action complete
entry 302
match-domain *
dst-adjacency GenericAccess
action complete
complete
active-call-policy-set 1
6.3 Service interface configuration
Service interface objects in the CLI define the IP-level details of the service networks your Session
Controller connects to.
Your CLI configuration will include a service interface object for each of the service networks
described in the Deployment Planning section of this guide. The following sections provide a
breakdown of the configuration for the core network service interface, highlighting key commands and
their effects, and then provide the full foundation configuration for all of the service interfaces.
Core service interface - detailed breakdown
You create (or modify) service interfaces using the service-interface command in the config
-> system mode of the Perimeta CLI. This command opens a sub-mode of system, specific to the
service interface you specify. This sub-mode contains all the configuration options you need to set up
Perimeta's connection to a service network at the IP level.
The following commands are the full foundation configuration for the core network service interface,
with placeholder IP addresses that you will need to replace with the appropriate addresses for your
system.
config
system
service-interface serv1
description "Core network"
service-network 1
port-group-name CoreNetwork
ipv4
subnet-prefix-length 24
gateway-ip-address 10.10.10.1
local-ip-address 10.10.10.10
service-address CoreAddress4-01
probes-target 10.10.10.1
probes-source-style specific-source
probes-source-ip shelf A interface 1
probes-source-ip shelf A interface 2
probes-source-ip shelf B interface 1
probes-source-ip shelf B interface 2
activate
network-security trusted
criticality 1000
probes-interval 1000
!vlan-id (vlan-id)
44 6 Preparing CLI configuration
10.10.10.11
10.10.10.12
10.10.10.13
10.10.10.14
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
The serv1 parameter is the name for the service interface object in the CLI; all service interface
objects have a name of the form servN.
The following sections pick out some of the key commands above and explain their effects in more
detail.
Service network ID
The following command assigns a numerical service network ID to the service interface. This is
unique to each service interface, and is used in other areas of configuration to select the service
network.
service-network 1
Port group name
When planning your deployment in the Deployment Planning section of this guide, you selected a
port group scheme, defining how the Ethernet ports on your system are grouped for redundancy.
When you commission your Session Controller, you will apply the port group scheme and configure
names for the port groups it creates. The following command uses a port group name to assign the
port group that this service interface will use.
port-group-name CoreNetwork
In a typical system, you will use one core-side port group and one access-side port group. If you do,
you can leave this command as-is in the foundation configuration for service-interface serv1
and service-interface serv2.
If you are using the managed access network service interface, you must update the port-groupname line for service-interface serv3 to use the additional port group reserved for the
managed access network.
If you selected a port group scheme that was not recommended in Choosing a port group scheme on
page 20, you will need to change the port-group-name line for one or more service interfaces to
assign them to the appropriate port groups. You should have noted the port group for each service
interface when working through Deployment Planning.
IP subnet details
The following section of configuration defines the details of the local IP subnet for this service
interface.
ipv4
subnet-prefix-length 24
gateway-ip-address 10.10.10.1
local-ip-address 10.10.10.10
service-address CoreAddress4-01
probes-target 10.10.10.1
probes-source-style specific-source
probes-source-ip shelf A interface 1
probes-source-ip shelf A interface 2
probes-source-ip shelf B interface 1
probes-source-ip shelf B interface 2
activate
10.10.10.11
10.10.10.12
10.10.10.13
10.10.10.14
6 Preparing CLI configuration 45
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
You will need to replace the placeholder IP addresses; these are the default gateway address, the
local IP address for the Session Controller, the probing target IP address for ARP probes, and the
source addresses the Session Controller will use to send ARP probes. probes-source-ip shelf
A interface 2 10.10.10.12 and probes-source-ip shelf B interface 2 10.10.10.14
lines altogether.
You may also need to make changes to the probes-source-ip lines.
•
If you are commissioning a high availability system and your port group scheme uses redundant
ports (because you are using SR-IOV or PCI passthrough), you will allocate four probe source IP
addresses. You do not need to make any changes.
•
Otherwise, if you are commissioning a high availability system, you will allocate two probe
source IP addresses and you can remove the probes-source-ip shelf A interface 2
10.10.10.12 and probes-source-ip shelf B interface 2 10.10.10.14 lines altogether.
•
If you are commissioning a standalone system and your port group scheme uses redundant ports
(because you are using SR-IOV or PCI passthrough), replace all the probe-source-ip lines
with the following, replacing the placeholder IP addresses with the source addresses the Session
Controller will use to send ARP probes.
probes-source-ip interface 1 10.10.10.11
probes-source-ip interface 2 10.10.10.11
•
Otherwise, if you are commissioning a standalone system, replace all the probe-source-ip
lines with the following, replacing the placeholder IP address with the source address the Session
Controller will use to send ARP probes.
probes-source-ip interface 1 10.10.10.11
The following commands configure a local IP address for the Session Controller on this subnet.
local-ip-adress 10.10.10.10
service-address CoreAddress4-01
The service-address command assigns a name to the local address; you will use this name to
select this address for use in other areas of configuration (if you need to change the address later, this
allows you to do it in one place rather than throughout your configuration).
You can configure multiple local IP addresses on a particular subnet by adding additional local-ipaddress and service-address commands (they must be together and in this order). In the full
configuration below, there are two local addresses on the general access service interface (serv2),
one for general access and one for a SIP trunk. If you use more than one SIP trunk, you will need to
add further addresses (if you are not using any, you can delete the Trunk1Address4-01 address).
VLAN ID
The configuration given above includes the following commented-out command.
!vlan-id (vlan-id)
The exclamation mark comments out the command and prevents it having an effect; this is
appropriate if you are not using a VLAN for this service interface.
46 6 Preparing CLI configuration
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
If you are using a VLAN (required if you set up more than one service interface on the same Ethernet
port group), remove the exclamation mark and add the appropriate VLAN ID, as in the following
example.
vlan-id 3
In the full foundation configuration given below, the managed access network is the only network
given a VLAN ID; if you are not using SR-IOV or PCI passthrough and you want the general and
managed access service interfaces to share a single virtual network interface, you will need to use
VLANs to separate them. In this case you should have allocated and noted VLAN IDs when working
through Deployment Planning.
Trusted sources configuration
On untrusted networks, Perimeta does not generally permit any traffic other than REGISTERs from
sources that have not previously registered. To allow traffic from non-registering peers or endpoints
(such as non-registering PBXs) on your access networks, which are untrusted, you must explicitly
configure their IP addresses as permitted peers, as in the following example from the foundation
configuration.
config
system
ip-access-control
trusted-sources
!All non-registering endpoints in untrusted (access) service
!networks must be added here.
permit-peer service-network 2 ipv4 21.21.21.50
permit-peer service-network 2 ipv4 32.32.32.50
permit-peer service-network 2 ipv4 52.52.52.101
You will need to add your own permit-peer lines for each non-registering remote peer/endpoint you
want to permit traffic from, giving the service network the device will connect on and its IP address.
Full foundation configuration for service interfaces
The following configuration is the full foundation configuration for all the service interfaces described in
the Deployment Planning section of this guide.
config
system
service-interface serv1
description "Core network"
service-network 1
port-group-name CoreNetwork
ipv4
subnet-prefix-length 24
gateway-ip-address 10.10.10.1
local-ip-address 10.10.10.10
service-address CoreAddress4-01
probes-target 10.10.10.1
probes-source-style specific-source
probes-source-ip shelf A interface 1
probes-source-ip shelf A interface 2
probes-source-ip shelf B interface 1
probes-source-ip shelf B interface 2
activate
10.10.10.11
10.10.10.12
10.10.10.13
10.10.10.14
6 Preparing CLI configuration 47
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
network-security trusted
criticality 1000
probes-interval 1000
!vlan-id (vlan-id)
service-interface serv2
description "General Access Network"
service-network 2
port-group-name AccessNetwork
ipv4
subnet-prefix-length 26
gateway-ip-address 53.53.53.1
local-ip-address 53.53.53.10
service-address AccessAddress4-01
local-ip-address 53.53.53.11
service-address TrunklAddress4-01
probes-target 53.53.53.1
probes-source-style specific-source
probes-source-ip shelf A interface 1 53.53.53.15
probes-source-ip shelf A interface 2 53.53.53.16
probes-source-ip shelf B interface 1 53.53.53.17
probes-source-ip shelf B interface 2 53.53.53.18
activate
network-security untrusted
criticality 1000
disable-icmp-responses
probes-interval 1000
!vlan-id (vlan-id)
service-interface serv3
description "Managed Access Network"
service-network 3
port-group-name AccessNetwork
ipv4
subnet-prefix-length 26
gateway-ip-address 53.53.54.1
local-ip-address 53.53.54.10
service-address ManagedAddress4-01
probes-target 53.53.54.1
probes-source-style specific-source
probes-source-ip shelf A interface 1 53.53.54.11
probes-source-ip shelf A interface 2 53.53.54.12
probes-source-ip shelf B interface 1 53.53.54.13
probes-source-ip shelf B interface 2 53.53.54.14
activate
network-security untrusted
criticality 1000
disable-icmp-responses
probes-interval 1000
vlan-id 2
ip-access-control
trusted-sources
!All non-registering endpoints in untrusted (access) service
!networks must be added here.
permit-peer service-network 2 ipv4 21.21.21.50
Changes you need to make - summary
These steps summarize the changes you need to make to the configuration above - read the detailed
breakdown above for information about the actual effects of these commands.
1. If you are not using the managed access service interface, delete it (the service-interface
serv3 line down to the next vlan-id line).
48 6 Preparing CLI configuration
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
If you are using the managed access service interface and it will use a separate virtual network
interface to the general access service interface, change the port-group-name line to read
port-group-name ManagedAccessNetwork and delete the vlan-id line.
2. Update all IP addresses given for each service interface with the appropriate IP addresses for your
networks; the local IP address for your Session Controller, the default gateway, and the probe
target and source addresses.
•
If you are commissioning a high availability system and your port group scheme does not use
redundant ports, remove the probes-source-ip shelf A interface 2 10.10.10.12 and
probes-source-ip shelf B interface 2 10.10.10.14 lines altogether.
•
If you are commissioning a standalone system and your port group scheme uses redundant
ports, remove all the probe-source-ip lines and add the following (replacing the placeholder
IP addresses).
probes-source-ip interface 1 10.10.10.11
probes-source-ip interface 2 10.10.10.11
•
If you are commissioning a standalone system and your port group does not use redundant
ports, remove all the probe-source-ip lines and add the following (replacing the placeholder
IP address).
probes-source-ip interface 1 10.10.10.11
3. Update the subnet prefix length for each service interface to the correct length for those subnets.
4. Add any additional local IP addresses for SIP trunks to the access service interfaces, by adding a
local-ip-address and service-address line for each; note that there is already an address
for a SIP trunk on the general access service interface serv2, using the service address name
Trunk1Address4-01. If you are not using any SIP trunks on the general access interface and
do not need this address, delete the service-address line and preceding local-ip-address
line.
5. Replace the permit-peer line with one or more lines giving the service networks and IP
addresses of any non-registering access devices or peers you want to permit traffic from. If there
are no non-registering devices you want to permit traffic from, delete the permit-peer and
trusted-sources lines.
6. If you are using an alternative plan for port groups, change the port group names in the portgroup-name lines as appropriate.
7. If you are not using SR-IOV or PCU passthrough and you want to use an alternative plan for
VLANs, add a vlan-id line specifying the appropriate VLAN id for each service interface that will
use one.
6.4 Media interface configuration
This configuration provisions the local IP addresses Perimeta will use for media traffic.
config
sbc
media
media-address ipv4 10.10.10.10 service-network 1
6 Preparing CLI configuration 49
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
realm CoreMedia1
media-address ipv4 53.53.53.10 service-network 2
realm AccessMedia1
media-address ipv4 53.53.53.11 service-network 2
realm TrunkMedia1
media-address ipv4 53.53.54.10 service-network 3
realm ManagedAccessMedia1
vmsc global
activate
Each media-address line allocates a local IP address to be used for media on a service network.
In this foundation configuration, these are the same local addresses used for signaling, minimizing
the number of IP addresses you require. The realm lines following each IP address associate the
address with a media realm name. Perimeta uses this to match up the media addresses with your
signaling configuration; each adjacency (the signaling configuration object) is also configured with a
media realm name.
You will need to make the following updates to the media configuration. Before you make these
changes, you must have already worked through your service interface configuration, covered in
Service interface configuration on page 44.
1. If you added additional local IP addresses on service network 2 or 3 (general access and managed
access, respectively) for additional SIP trunks, add an additional media-address and realm line
for each one. Change the realm name in the realm line to a unique name for each address; for
simplicity, we recommend TrunkMedia2, TrunkMedia3 etc.
2. If you are not using any additional IP addresses for SIP trunks on service network 2, delete the
media-address ipv4 53.53.53.11 service-network 2 line and the following realm line.
3. Update the IP address in each media-address line with the correct local IP address from the
service interface.
6.5 Signaling configuration
SIP signaling configuration in the Perimeta CLI is built around adjacency objects, which define the
settings for each SIP signaling interface on your Session Controller.
The following configuration is the full foundation configuration for adjacencies and SIP interop profiles.
Interop profiles allow a single set of SIP interoperability settings to apply to multiple adjacencies.
config
sbc
signaling
burst-rate-limit-period 6 seconds
sip message-manipulation
header-profile DropAttackTools
header User-Agent
action drop-request
!Remove any UA strings between the |s in the following
!line as needed.
!UA strings are case sensitive.
condition advanced "(REGEX
(msg.first-header(\"User-Agent\").value,
'(friendly|SIPScan|SIPSCAN|smap|SMAP|sipsak|sipcli
|sipv|iWar|VAXSIPUserAgent|VaxIPUserAgent|sundayddr
50 6 Preparing CLI configuration
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
|SIVus|sip|SIPp|eyebeam|Kapanga|X-Lite|Firefly
|OmniSession|Zoiper|Sipdroid|Ozeki|Mizuphone
|linphone|3CXPhone)'))"
sip interop-profile Peer
description "for use with a Peer"
header-settings from rewrite host local port include
header-settings via passthrough-inbound
ping-enable
interval 8
lifetime 8
dynamic-peer-routing
sip interop-profile GenericAccess
description "for use with an open adjacency"
dtmf sip info always-supported
header-settings via passthrough-inbound
registration fast-register
tcp fully-supported
registration min-expiry-time 3600
sip interop-profile ManagedAccess
description "for use with an open adjacency"
header-settings via passthrough-inbound
registration fast-register
tcp fully-supported
registration min-expiry-time 3600
sip interop-profile Softswitch
description "for use with a softswitch"
header-settings via passthrough-outbound
ping-enable
interval 8
lifetime 8
adjacency sip Softswitch
call-media-policy
repeat-sdp-on-200ok
deactivation-mode normal
force-signaling-peer all-requests
adjacency-type preset-core
outbound-flood-rate 1000
privacy trusted
realm CoreMedia1
remote-address-range ipv4 10.10.11.20 prefix-len 32
service-address CoreAddress4-01
signaling-local-port 5060
signaling-peer 10.10.11.20
signaling-peer-port 5060
statistics-setting detail
default-interop-profile Softswitch
activate
adjacency sip GenericAccess
! This adjacency is for registering endpoints and
! open-access PBXs
call-media-policy
media-bypass-policy forbid
repeat-sdp-on-200ok
deactivation-mode normal
adjacency-type preset-access
nat autodetect
privacy untrusted
realm AccessMedia1
service-address AccessAddress4-01
signaling-local-port 5060
signaling-peer 0.0.0.0
signaling-peer-port 0
statistics-setting detail
default-interop-profile GenericAccess
activate
6 Preparing CLI configuration 51
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
adjacency sip Trunk1
adjacency-limits
regs 0
regs-rate sustain 0 per-minute
call-media-policy
media-bypass-policy forbid
deactivation-mode normal
force-signaling-peer all-requests
adjacency-type preset-peering
privacy trusted
realm TrunkMedia1
remote-address-range ipv4 21.21.21.50 prefix-len 32
service-address TrunkAddress4-01
signaling-local-port 5060
signaling-peer 21.21.21.50
dynamic-routing-domain-match 21.21.21.50
signaling-peer-port 5060
statistics-setting detail
default-interop-profile Peer
activate
adjacency sip ManagedAccess
! This adjacency is for registering endpoints and
! open-access PBXs on the managed access network
call-media-policy
media-bypass-policy forbid
repeat-sdp-on-200ok
deactivation-mode normal
adjacency-type preset-access
nat autodetect
privacy untrusted
realm ManagedAccessMedia1
service-address ManagedAddress4-01
signaling-local-port 5060
signaling-peer 0.0.0.0
signaling-peer-port 0
statistics-setting detail
default-interop-profile ManagedAccess
activate
The following sections give a detailed breakdown of key commands listed above and their effects, and
a summary of the changes you will need to make to this area of configuration before using it for your
system.
SIP message manipulation - detailed breakdown
The foundation configuration provides SIP message manipulation settings to automatically
drop requests with User-Agent headers containing strings associated with known attack tools
or softphones. This configuration is included in the sip message-manipulation line. The
configuration contains strings to protect against the following attack tools and softphones.
Table 3: Attack tools
Attack tool
Associated User-Agent header string(s)
SIPVicious
friendly
SIPScan
SIPScan / SIPSCAN
52 6 Preparing CLI configuration
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
SMAP
smap / SMAP
SIP Swiss Army Knife
sipsak
sipcli
sipcli
Modified SIPVicious
sundayddr
iWar
iWar
VaxVOIP
VaxSIPUserAgent / VaxIPUserAgent
SiVuS
SIVuS
SIPp
sipp / SIPp
Table 4: Attack softphones
Attack softphone
Associated User-Agent header string(s)
eyeBeam
eyeBeam
Kapanga
Kapanga
Firefly
Firefly
OmniSession
OnmiSession
Zoiper
Zoiper
Sipdroid
Sipdroid
Ozeki
Ozeki
MizuPhone
Mizuphone
Linphone
linphone
3CX
3CXPhone
If you do not want Perimeta to drop requests with one or more of these strings in the User-Agent
header, you must delete your chosen strings from the condition advanced line.
Adjacencies - detailed breakdown
Each adjacency object is defined by an adjacency sip line, giving a name for the adjacency. The
configuration above has the following adjacencies.
6 Preparing CLI configuration 53
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
•
CONFIDENTIAL
GenericAccess for the connection to endpoints (not peers) on the general access service
network.
•
Softswitch for the connection to your softswitch on the core service network.
•
Trunk1 for the connection to a peer (a SIP trunk) on the general access service network.
•
ManagedAccess for the connection to endpoints on the managed access service network.
If you are not using the managed access service interfaces, you can delete the ManagedAccess
adjacency.
If you are connecting Perimeta to more than one SIP trunk, you will need an additional peering
adjacency for each trunk. You can copy the configuration for Trunk1 (from the adjacency
sip Trunk1 line to the final activate) for each peering adjacency, changing the name in the
adjacency sip line and updating the other settings as described below.
Note:
If you are using Perimeta with multiple softswitches, you will need additional adjacencies. This
scenario requires various additions to your configuration and is covered in Adding additional
softswitches on page 74.
Local address and ports
The following configuration lines from the Softswitch adjacency select the service network, local IP
address and port for the adjacency.
service-address CoreAddress4-01
signaling-local-port 5060
The service-address line gives a service address name (Core-Address4-01) that must also
be configured for a local IP address on one of your service interface objects; Perimeta matches the
names to select the service network and local IP address for the adjacency. In this case, it selects an
IP address on your core service network to use when connecting to your MetaSphere CFS.
The service addresses here match up to the default service interface configuration; if you add
new adjacencies, you must ensure that the service addresses match up with the appropriate IP
addresses on your service interfaces. For details of the service interface objects, see Service interface
configuration on page 44.
The signaling-local-port line gives the local port for Perimeta to use on the adjacency.
Signaling peer and remote address range
The following configuration lines from the MetaSphereCFS adjacency define the details of the remote
devices the adjacency will connect to.
force-signaling-peer all-requests
remote-address-range ipv4 10.10.11.20 prefix-len 32
signaling-peer 10.10.11.20
signaling-peer-port 5060
Each adjacency must have a signaling-peer line. For adjacencies connecting to a single specific
device, this gives the IP address or hostname of that device; for Softswitch, this is the softswitch
54 6 Preparing CLI configuration
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
IP address. You will need to replace this address with the signaling IP address of your softswitch, and
modify the signaling-peer line on each peering adjacency to give the IP address of the peer. If
the peer for an adjacency also uses a SIP port other than the usual 5060, you must also update the
signaling-peer-port line.
For Trunk1, and any other peering (SIP trunk) adjacencies you add, there is also a dynamicrouting-domain-match line. This allows Perimeta to route SIP requests to the adjacency by
matching the domain
The force-signaling-peer all-requests line forces all outgoing SIP messages to the
signaling peer address and port, rather than routing them according to the SIP headers. This
command is not present on open access adjacencies such as GenericAccess.
The remote-address-range line limits the range of remote IP addresses that can use the
adjacency; the range is specified as an IP subnet by giving an IP address and subnet prefix length.
For Softswitch and Trunk1, this range only contains the single IP address of the peer (the subnet
prefix length is 32 bits, limiting it to one IPv4 address). You will need to update this IP address to the
peer address, as for the signaling-peer lines.
On open access adjacencies that connect to multiple devices, such as GenericAccess, the
signaling peer is 0.0.0.0 and there is no remote-address-range line.
Media realm
Each adjacency has a realm line, configuring it with either the CoreMedia1 or AccessMedia1
media realm. This controls which media IP addresses Perimeta uses for its media connection to
devices that use the adjacency for signaling.
For the three adjacencies given above, you won't typically need to change the media realm. However,
if you are using a managed access service interface, you will need to set the realm to the correct
media realm for that interface. Media realm configuration is covered in Media interface configuration
on page 49 .
Changes you need to make - summary
These steps summarize all the changes you need to make to the signaling configuration - read the
detailed breakdown above for information about the actual effects of these commands. Before making
these changes, you must have already worked through your service interface configuration, covered
in Service interface configuration on page 44, and your media configuration, covered in Media
interface configuration on page 49 .
1. If you want to remove any of the User-Agent strings for which the Session Controller will drop
requests, delete them from the condition advanced line.
2. If you are not using the managed access service interface, delete the ManagedAccess adjacency
(from the adjacency sip ManagedAccess line to the next activate line).
3. If you are not using any SIP trunks (peers), delete the Trunk1 adjacency (from the adjacency
sip Trunk1 line to the next activate line).
6 Preparing CLI configuration 55
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
4. If you are using more than one SIP trunk, add a new adjacency for each by copying the Trunk1
adjacency (from the adjacency sip Trunk1 line to the next activate line) and changing the
name in the adjacency sip line (for simplicity, we recommend using Trunk2, Trunk3 etc.).
Update the service-address line for each new adjacency with the service address name you
configured for its local IP address (in the service interface configuration), and the realm line with
the media realm you configured for that IP address (in the media interface configuration).
5. Update the signaling-peer and remote-address-range lines on each core and peering/SIP
trunk adjacency (Softswitch, Trunk1, and any additional peering adjacencies you added in the
last step) with the correct IP address of the peer device; for the peering adjacencies, update the
dynamic-routing-domain-match command with the same IP address.
If any of the peer devices use a SIP port other than the normal 5060, update the signalingpeer-port line for the adjacency to the device with the correct port.
6.6 Diagnostics configuration
This configuration sets some basic thresholds at which Perimeta will raise alarms, and configures the
remote devices to which it will send diagnostic information (a Network Management System using
SNMP, and a Metaswitch Service Assurance Server where available).
config
sbc
diagnostics
alarm-thresholds
default-adjacency-alarms as-destination
regs-limit
minor-threshold 75% clear 70%
major-threshold 85% clear 80%
critical-threshold 95% clear 90%
call-rate-limit sustain
minor-threshold 75% clear 70%
major-threshold 85% clear 80%
critical-threshold 95% clear 90%
in-call-rate-limit sustain
minor-threshold 75% clear 70%
major-threshold 85% clear 80%
critical-threshold 95% clear 90%
ooc-rate-limit sustain
minor-threshold 75% clear 70%
major-threshold 85% clear 80%
critical-threshold 95% clear 90%
regs-rate-limit sustain
minor-threshold 75% clear 70%
major-threshold 85% clear 80%
critical-threshold 95% clear 90%
default-adjacency-alarms
regs-limit
minor-threshold 75% clear 70%
major-threshold 85% clear 80%
critical-threshold 95% clear 90%
call-rate-limit sustain
minor-threshold 75% clear 70%
major-threshold 85% clear 80%
critical-threshold 95% clear 90%
in-call-rate-limit sustain
56 6 Preparing CLI configuration
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
minor-threshold 75% clear 70%
major-threshold 85% clear 80%
critical-threshold 95% clear 90%
ooc-rate-limit sustain
minor-threshold 75% clear 70%
major-threshold 85% clear 80%
critical-threshold 95% clear 90%
regs-rate-limit sustain
minor-threshold 75% clear 70%
major-threshold 85% clear 80%
critical-threshold 95% clear 90%
call-alarms
failed-attempts-rate max 60 clear 40
active-failures-perc max 2% clear 2%
license-alarms
minor-threshold 60% clear 50%
major-threshold 80% clear 70%
critical-clear 90%
media-alarms
hardware-capacity-perc max 90% clear 80%
advanced-capacity-perc max 90% clear 80%
pkts-discarded-perc max 10% clear 9%
policy-alarms
setup-failures-capac-perc max 1% clear 1%
setup-failures-na-perc max 1% clear 1%
setup-failures-rtg-perc max 1% clear 1%
sip-alarms
oldest-queued-packet max 1000 clear 900
system-alarms
cpu max 70%
free-mem-mb min 1500 clear 1650
sas remote-address ipv4 192.168.51.41
snmp
snmp-client "Network Management System"
client-address ipv4 192.168.51.40
notifications
general-notifications
hardware-notifications
You will need to make the following updates to the above configuration.
1. Replace the IP address in the sas remote-address line with the IP address of your Metaswitch
Service Assurance Server if you have deployed one. If you have not deployed one, delete this line.
2. Replace the IP address in the client-address line with the IP address of your MetaView Server
or other Network Management System. If you have not deployed any Network Management
System. delete everything from the snmp line down.
6.7 Dynamic blacklisting configuration
Dynamic blacklisting configuration determines Perimeta's security thresholds; the levels of suspect
traffic at which Perimeta will alarm, de-prioritize, or ban sources of traffic to protect your network
against potential attacks.
You configure dynamic blacklisting using profiles; each profile defines a particular set of traffic
thresholds appropriate for a particular type of traffic source. The foundation configuration contains
a range of pre-made profiles for different sources at given expected call loads; additional alternative
6 Preparing CLI configuration 57
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
profiles for different call loads are given in Additional example dynamic blacklisting profiles on page
64.
If none of the pre-made profiles matches your expected call load for a source, you can use the
blacklisting tools spreadsheet provided with this guide to generate an appropriately scaled initial
profile.
The following sections provide a brief explanation of an example profile, a list of the available premade profiles, instructions on using the spreadsheet to generate new profiles, and an explanation of
how you apply profiles to traffic sources.
Example profile
The following configuration defines the Peer500 blacklisting profile. This profile is intended to be
applied to a SIP trunk with an expected typical call load of 500 concurrent calls, raising alarms and
eventually imposing a temporary ban if the trunk starts sending high levels of suspect traffic.
profile Peer500
! SIP PBX and SIP trunks with no authentication or registration
description "Trunk or PBX with 500 calls"
reason reg-auth-failure
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason auth-failure
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason routing-failure
trigger-period 30 seconds
! minor-alarm-rate 250 per-minute
major-alarm-rate 63 per-second
ban-rate 84 per-second
ban-duration 10 minutes
reason endpt-reg
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason capacity-limit
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason corrupt-message
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 4 per-second
ban-rate 5 per-second
ban-duration 10 minutes
reason source-addr
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 4 per-second
ban-rate 5 per-second
58 6 Preparing CLI configuration
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
ban-duration 10 minutes
reason spam
trigger-period 30 seconds
! minor-alarm-rate 30 per-second
major-alarm-rate 450 per-second
ban-rate 600 per-second
ban-duration 10 minutes
reason num-validation-failure
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 4 per-second
ban-rate 5 per-second
ban-duration 10 minutes
reason tcp-abuse
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason tls-reneg
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason endpt-registrar-reg
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
The profile consists of a number of reason objects; each one defines thresholds for a particular type
of suspect traffic. For example, the following set of commands sets the thresholds for corrupt SIP
messages.
reason corrupt-message
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 4 per-second
ban-rate 5 per-second
ban-duration 10 minutes
The major-alarm-rate and ban-rate lines define the rates of corrupt SIP messages at which
Perimeta will raise an alarm or impose a ban on a source that has this profile applied to it. The banduration line limits the duration of a ban for this reason to 10 minutes; however, if the corrupt
messages continue to arrive at or above the ban rate of 5 per second, Perimeta will simply impose
another ban.
The minor-alarm-rate line provides a threshold for a lower-urgency alarm than major-alarmrate, but is commented out here (and in all the pre-made profiles). You can uncomment these lines if
you want to use minor alarms for closer monitoring of traffic levels.
If you want to understand the exact types of suspect traffic Perimeta counts towards each blacklisting
reasons, a full list is available in Dynamic blacklisting reasons on page 62.
6 Preparing CLI configuration 59
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
Pre-made profiles
The foundation configuration and Additional example dynamic blacklisting profiles on page 64
include the following set of pre-made blacklisting profiles; you will need to choose which are most
suitable for the devices and networks in your deployment.
•
A set of profiles for entire service networks; these only impose alarms, not bans. Three profiles are
available, for networks on which you expect a typical load of 250, 500, or 1000 concurrent calls;
they are ServiceNetwork250, ServiceNetwork500, and ServiceNetwork1000 (used in the
foundation configuration).
•
A set of profiles for individual peers (SIP trunks). Two profiles are available, for peers from which
you expect a typical load of 250 or 500 concurrent calls; they are Peer250 and Peer500 (used in
the foundation configuration).
•
A set of profiles for use with a single IP address that represents multiple registering endpoints,
with each port on that IP address representing a different endpoints. This is typically a NAT device
or a PBX. These profiles come in pairs; an address-level Site profile that sets thresholds for
the IP address as a whole, and a port-level PerPortPhone profile that sets thresholds for each
individual port source on that IP address. Profiles are available for addresses supporting 50, 100,
or 250 endpoints; they are Site50 and PerPortPhone50, Site100 and PerPortPhone100
(used in the foundation configuration), and Site250 and PerPortPhone250.
Note:
The PerPortPhone profiles assume 5 Directory Numbers permitted per endpoint. If this is
not correct for your deployment, you can generate alternative profiles with the blacklisting tools
spreadsheet.
Generating profiles with the blacklisting tools spreadsheet
The blacklisting tools spreadsheet allows you to generate alternative versions of the
ServiceNetwork, Peer, Site, and PerPortPhone pre-made profiles for different expected call
loads or numbers of endpoints. The spreadsheet contains a worksheet for each of these types of
profile; you can simply fill in the expected load in the highlighted cell and it will generate a profile you
can paste into the foundation configuration alongside the existing profiles.
Applying profiles
The following commands from the foundation configuration apply some of the pre-made profiles
described above.
profile-usage
scope service-network
service-network 2 profile ServiceNetwork1000
service-network 3 profile ServiceNetwork1000
scope per-address
service-network 2 profile Site100
service-network 3 profile Site100
scope specified-address
service-network 2
ipv4 21.21.21.50 profile Peer500
60 6 Preparing CLI configuration
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
scope per-port
! Profiles for per-port-source blacklisting applied here.
The scope lines specify a type of source that you want to apply a profile to. For service network
scopes, you apply profiles to particular networks with service-network lines below the scope
service-network line as shown for service networks 2 and 3 above; you can update these
lines to change the profiles applied to the appropriate ones for your network (either one of the premade profiles listed above or a profile you have generated using the spreadsheet and added to the
configuration).
The scope-specified address mode contains lines that apply profiles to specific devices using
their service network and IP address. The configuration above applies the Peer500 pre-made profile
to IP address 21.21.21.50 on service network 2 (the general access network); this is the example
peer used throughout the foundation configuration. You will need to replace this with lines using the
same format for each peer and multi-endpoint device (such as a SIP PBX or a NAT device in front of
multiple endpoints) in your deployment, using Peer profiles for the former and Site profiles for the
latter.
If you apply Site profiles to multi-endpoint devices, you will also need to apply a per-port
PerPortPhone profile for each device under scope per-port, using the same command structure
as under scope specified-address. For example, the following commands add a multi-endpoint
device supporting 100 endpoints (on service network 3) to the basic configuration above.
profile-usage
scope service-network
service-network 2 profile ServiceNetwork1000
service-network 3 profile ServiceNetwork1000
scope per-address
service-network 2 profile Site100
service-network 3 profile Site100
scope specified-address
service-network 2
ipv4 21.21.21.50 profile Peer500
service-network 3
ipv4 53.53.55.10 profile Site100
scope per-port
service-network 3
ipv4 53.53.55.10 profile PerPortPhone100
Summary - changes you need to make
Take the following steps to update the foundation configuration with appropriate blacklisting
thresholds.
1. For each untrusted (access) service network, peer (SIP trunk), and multi-endpoint device (PBX
or multi-endpoint NAT) your deployment will support, select an appropriate pre-made blacklisting
profile based on the number of calls/endpoints or generate a new profile using the blacklisting tools
spreadsheet.
2. If you need to use any of the pre-made profiles from Additional example dynamic blacklisting
profiles on page 64, copy them into the foundation configuration immediately following the
existing pre-made profiles.
3. If you generated new profiles, add them to the foundation configuration in the blacklisting
section, immediately following the existing pre-made profiles.
6 Preparing CLI configuration 61
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
4. Update the profile-usage section of the foundation configuration to apply the profiles you
have selected for each service network, peer, and multi-endpoint device, as described in Applying
profiles on page 60 above.
6.7.1 Dynamic blacklisting reasons
This table describes the different types of suspect traffic, known as blacklisting reasons, that your
blacklisting profiles provide alarm, downgrade, and ban thresholds for.
Some of these reasons are traffic types seen in normal operation and not inherently suspect; for
example, registrations. These are included as blacklisting reasons because an attacker can use
excessive amounts of such traffic instead of or alongside more obviously suspect traffic such as
malformed SIP messages.
Reason
CLI keyword
Events counted
Authentication failure
auth-failure
The Session Controller receives
a SIP request containing
authentication credentials,
forwards that message to a
registrar, and the registrar
challenges those credentials
(with a 401 or 407 response).
Capacity limit exceeded
capacity-limit
The Session Controller rejects
a request because it exceeds
the configured capacity control
limits.
Corrupt message
corrupt-message
The Session Controller receives
a SIP message which it is
unable to parse. This may
indicate an attempt to exploit
bugs in third-party products'
error handling.
Endpoint registration
endpt-reg
The Session Controller
receives a SIP REGISTER
message, including those due
to Perimeta's fast-registration
feature. An unexpectedly large
number of messages may
indicate a denial of service
attack.
62 6 Preparing CLI configuration
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
Endpoint registration (excluding
endpt-registrar-reg
fast-registers).
The Session Controller receives
a SIP REGISTER message
that it forwards to the registrar,
excluding messages due to
Perimeta's fast-registration
feature.
Number validation failure
num-validation-failure
The Session Controller
receives a SIP message
containing source or destination
numbers which are rejected by
number analysis configuration.
Note that the foundation
configuration in this guide
does not include any number
analysis configuration.
Routing failure
routing-failure
The Session Controller receives
a SIP message which then
results in a 404, 410, 485, or
604 response code, either
downstream or generated
by the Session Controller
because it has failed to route
the message to an outbound
adjacency.
Bad source address
source-addr
The Session Controller receives
a SIP message and matches
it to an adjacency service
address and local port, but
the source address, port,
and/or transport protocol
does not match the remote
address range configured on
the adjacency. This may mean
that an unauthorized party has
attempted to connect to your
system.
Excessive messages
spam
The Session Controller receives
any SIP message, excluding
REGISTERs due to Perimeta's
fast-registration feature. An
6 Preparing CLI configuration 63
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
unexpectedly large number
of messages may indicate a
denial of service attack.
TCP failures
tcp-abuse
The Session Controller receives
a TCP connection which is
terminated (at either end)
without being authenticated
by a successful REGISTER,
or it receives a connection
which it terminates because it
does not receive any data, or
a subscriber using a TLS/TCP
connection fails to comply with
the TLS protocol.
TLS renegotiations
tls-reneg
A TLS subscriber renegotiates
the encryption parameters
for its connection. Excessive
renegotiations may indicate a
denial of service attack.
6.7.2 Additional example dynamic blacklisting profiles
These example profiles correspond to the example profiles given in the foundation configuration, but
use different values based on different expected call volumes or numbers of endpoints.
Service network profiles
The ServiceNetwork1000 profile in the foundation configuration is appropriate for a network with
a typical load of 1000 concurrent calls. The following examples show similar profiles for 250 and 500
concurrent calls.
profile ServiceNetwork250
! Detect and protect against distributed attacks
! 250 concurrent calls
description "250 calls, devices"
reason auth-failure
trigger-period 30 seconds
! minor-alarm-rate 165 per-second
major-alarm-rate 248 per-second
reason routing-failure
trigger-period 30 seconds
! minor-alarm-rate 450 per-minute
major-alarm-rate 113 per-second
reason endpt-reg
trigger-period 30 seconds
! minor-alarm-rate 165 per-second
major-alarm-rate 330 per-second
reason capacity-limit
trigger-period 30 seconds
64 6 Preparing CLI configuration
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
! minor-alarm-rate 10 per-minute
major-alarm-rate 3 per-second
reason corrupt-message
trigger-period 30 seconds
! minor-alarm-rate 14 per-minute
major-alarm-rate 4 per-second
reason source-addr
trigger-period 30 seconds
! minor-alarm-rate 10 per-minute
major-alarm-rate 3 per-second
reason spam
trigger-period 30 seconds
! minor-alarm-rate 495 per-second
major-alarm-rate 527 per-second
reason num-validation-failure
trigger-period 30 seconds
! minor-alarm-rate 10 per-minute
major-alarm-rate 3 per-second
reason tcp-abuse
trigger-period 30 seconds
! minor-alarm-rate 10 per-second
major-alarm-rate 150 per-second
reason tls-reneg
trigger-period 30 seconds
! minor-alarm-rate 28 per-second
major-alarm-rate 83 per-second
reason endpt-registrar-reg
trigger-period 30 seconds
! minor-alarm-rate 55 per-second
major-alarm-rate 165 per-second
profile ServiceNetwork500
! Detect and protect against distributed attacks
! 500 concurrent calls
description "500 calls, devices"
reason auth-failure
trigger-period 30 seconds
! minor-alarm-rate 330 per-second
major-alarm-rate 495 per-second
reason routing-failure
trigger-period 30 seconds
! minor-alarm-rate 750 per-minute
major-alarm-rate 188 per-second
reason endpt-reg
trigger-period 30 seconds
! minor-alarm-rate 330 per-second
major-alarm-rate 660 per-second
reason capacity-limit
trigger-period 30 seconds
! minor-alarm-rate 10 per-minute
major-alarm-rate 3 per-second
reason corrupt-message
trigger-period 30 seconds
! minor-alarm-rate 14 per-minute
major-alarm-rate 4 per-second
reason source-addr
trigger-period 30 seconds
! minor-alarm-rate 10 per-minute
major-alarm-rate 3 per-second
reason spam
trigger-period 30 seconds
! minor-alarm-rate 990 per-second
major-alarm-rate 1053 per-second
reason num-validation-failure
trigger-period 30 seconds
! minor-alarm-rate 10 per-minute
major-alarm-rate 3 per-second
6 Preparing CLI configuration 65
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
reason tcp-abuse
trigger-period 30 seconds
! minor-alarm-rate 10 per-second
major-alarm-rate 150 per-second
reason tls-reneg
trigger-period 30 seconds
! minor-alarm-rate 55 per-second
major-alarm-rate 165 per-second
reason endpt-registrar-reg
trigger-period 30 seconds
! minor-alarm-rate 110 per-second
major-alarm-rate 330 per-second
Peer profile
The Peer500 profile in the foundation configuration is appropriate for a peer connection with a typical
load of 500 concurrent calls. The following example shows a similar profile for 250 concurrent calls.
profile Peer250
! SIP PBX and SIP trunks with no authentication or registration
description "Trunk or PBX with 250 calls"
reason auth-failure
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason routing-failure
trigger-period 30 seconds
! minor-alarm-rate 150 per-minute
major-alarm-rate 38 per-second
ban-rate 50 per-second
ban-duration 10 minutes
reason endpt-reg
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason capacity-limit
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason corrupt-message
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason source-addr
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason spam
trigger-period 30 seconds
! minor-alarm-rate 15 per-second
major-alarm-rate 225 per-second
ban-rate 300 per-second
ban-duration 10 minutes
reason num-validation-failure
66 6 Preparing CLI configuration
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason tcp-abuse
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason tls-reneg
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason endpt-registrar-reg
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
Multi-endpoint IP address profiles
The Site100 and PerPortPhone100 profiles in the foundation configuration are appropriate for
a single IP address representing 100 endpoints. The following examples show similar profiles for
addresses representing 50 or 250 endpoints.
profile PerPortPhone50
! Site with per-port where every port represents an end-device
! This should be used in conjunction with a Site profile
! that specifies the same IP address.
reason auth-failure
trigger-period 30 seconds
! minor-alarm-rate 138 per-minute
major-alarm-rate 35 per-second
ban-rate 46 per-second
ban-duration 10 minutes
reason routing-failure
trigger-period 30 seconds
! minor-alarm-rate 20 per-minute
major-alarm-rate 5 per-second
ban-rate 7 per-second
ban-duration 10 minutes
reason endpt-reg
trigger-period 30 seconds
! minor-alarm-rate 42 per-minute
major-alarm-rate 11 per-second
ban-rate 14 per-second
ban-duration 10 minutes
reason capacity-limit
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason corrupt-message
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
6 Preparing CLI configuration 67
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
reason source-addr
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason spam
trigger-period 30 seconds
! minor-alarm-rate 538 per-minute
major-alarm-rate 135 per-second
ban-rate 180 per-second
ban-duration 10 minutes
reason num-validation-failure
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason tcp-abuse
trigger-period 30 seconds
! minor-alarm-rate 1 per-second
major-alarm-rate 15 per-second
ban-rate 20 per-second
ban-duration 10 minutes
reason tls-reneg
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason endpt-registrar-reg
trigger-period 30 seconds
! minor-alarm-rate 22 per-minute
major-alarm-rate 6 per-second
ban-rate 8 per-second
ban-duration 10 minutes
profile PerPortPhone250
! Site with per-port where every port represents an end-device
! This should be used in conjunction with a Site profile
! that specifies the same IP address.
reason auth-failure
trigger-period 30 seconds
! minor-alarm-rate 638 per-minute
major-alarm-rate 160 per-second
ban-rate 213 per-second
ban-duration 10 minutes
reason routing-failure
trigger-period 30 seconds
! minor-alarm-rate 20 per-minute
major-alarm-rate 5 per-second
ban-rate 7 per-second
ban-duration 10 minutes
reason endpt-reg
trigger-period 30 seconds
! minor-alarm-rate 42 per-minute
major-alarm-rate 11 per-second
ban-rate 14 per-second
ban-duration 10 minutes
reason capacity-limit
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason corrupt-message
trigger-period 30 seconds
68 6 Preparing CLI configuration
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason source-addr
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason spam
trigger-period 30 seconds
! minor-alarm-rate 2538 per-minute
major-alarm-rate 635 per-second
ban-rate 846 per-second
ban-duration 10 minutes
reason num-validation-failure
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason tcp-abuse
trigger-period 30 seconds
! minor-alarm-rate 1 per-second
major-alarm-rate 15 per-second
ban-rate 20 per-second
ban-duration 10 minutes
reason tls-reneg
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason endpt-registrar-reg
trigger-period 30 seconds
! minor-alarm-rate 22 per-minute
major-alarm-rate 6 per-second
ban-rate 8 per-second
ban-duration 10 minutes
profile Site50
! Blacklist for any single IP address
! Equivalence to 50 endpoints, e.g. 50 user PBX or HPBX site
description "50 endpoints per IP address"
reason auth-failure
trigger-period 30 seconds
! minor-alarm-rate 12 per-second
major-alarm-rate 18 per-second
ban-rate 240 per-second
ban-duration 10 minutes
reason routing-failure
trigger-period 30 seconds
! minor-alarm-rate 40 per-minute
major-alarm-rate 15 per-second
ban-rate 20 per-second
ban-duration 10 minutes
reason endpt-reg
trigger-period 30 seconds
! minor-alarm-rate 8 per-second
major-alarm-rate 120 per-second
ban-rate 160 per-second
ban-duration 10 minutes
reason capacity-limit
trigger-period 30 seconds
! minor-alarm-rate 4 per-minute
major-alarm-rate 60 per-minute
6 Preparing CLI configuration 69
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
ban-rate 80 per-minute
ban-duration 10 minutes
reason corrupt-message
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason source-addr
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason spam
trigger-period 30 seconds
! minor-alarm-rate 27 per-second
major-alarm-rate 405 per-second
ban-rate 540 per-second
ban-duration 10 minutes
reason num-validation-failure
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason tcp-abuse
trigger-period 30 seconds
! minor-alarm-rate 2 per-second
major-alarm-rate 30 per-second
ban-rate 40 per-second
ban-duration 10 minutes
reason tls-reneg
trigger-period 30 seconds
! minor-alarm-rate 2 per-second
major-alarm-rate 30 per-second
ban-rate 40 per-second
ban-duration 10 minutes
reason endpt-registrar-reg
trigger-period 30 seconds
! minor-alarm-rate 4 per-second
major-alarm-rate 60 per-second
ban-rate 80 per-second
ban-duration 10 minutes
profile Site250
! Blacklist for any single IP address
! Equivalence to 250 endpoints, e.g. 250 user PBX or HPBX site
description "250 endpoints per IP address"
reason auth-failure
trigger-period 30 seconds
! minor-alarm-rate 60 per-second
major-alarm-rate 900 per-second
ban-rate 1200 per-second
ban-duration 10 minutes
reason routing-failure
trigger-period 30 seconds
! minor-alarm-rate 200 per-minute
major-alarm-rate 75 per-second
ban-rate 100 per-second
ban-duration 10 minutes
reason endpt-reg
trigger-period 30 seconds
! minor-alarm-rate 40 per-second
major-alarm-rate 600 per-second
ban-rate 800 per-second
ban-duration 10 minutes
70 6 Preparing CLI configuration
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
reason capacity-limit
trigger-period 30 seconds
! minor-alarm-rate 4 per-minute
major-alarm-rate 60 per-minute
ban-rate 80 per-minute
ban-duration 10 minutes
reason corrupt-message
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason source-addr
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason spam
trigger-period 30 seconds
! minor-alarm-rate 135 per-second
major-alarm-rate 2025 per-second
ban-rate 2700 per-second
ban-duration 10 minutes
reason num-validation-failure
trigger-period 30 seconds
! minor-alarm-rate 6 per-minute
major-alarm-rate 2 per-second
ban-rate 3 per-second
ban-duration 10 minutes
reason tcp-abuse
trigger-period 30 seconds
! minor-alarm-rate 4 per-second
major-alarm-rate 60 per-second
ban-rate 80 per-second
ban-duration 10 minutes
reason tls-reneg
trigger-period 30 seconds
! minor-alarm-rate 10 per-second
major-alarm-rate 150 per-second
ban-rate 200 per-second
ban-duration 10 minutes
reason endpt-registrar-reg
trigger-period 30 seconds
! minor-alarm-rate 20 per-second
major-alarm-rate 300 per-second
ban-rate 400 per-second
ban-duration 10 minutes
6.8 Changes you need to make to the foundation configuration: Summary
This list includes all the changes you need to make to the foundation configuration to customize it for
your system.
Service interfaces
These changes are described in more detail in Service interface configuration on page 44.
1. If you are not using a managed access service network, delete its service interface. This runs from
the the service-interface serv3 line down to the next vlan-id line.
6 Preparing CLI configuration 71
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
If you are using the managed access service interface, change the port-group-name line to
read port-group-name ManagedAccessNetwork and delete the vlan-id line.
2. Update the following IP addresses for each service interface object to the correct addresses for the
service networks in your deployment. A service interface object includes a service-interface
line and all the lines following it until you reach a line that is at the same or a higher indentation
level as the service-interface line.
•
The local IP address (or addresses) for Perimeta on that network (local-ip-address lines).
•
The default gateway IP address on that network (gateway-ip-address lines).
•
The probe target IP address on that network (probes-target lines).
•
The probe source IP address for Perimeta on that network (probes-source-ip lines).
You may also need to make changes to the number of probes-source-ip lines.
•
If you are commissioning a high availability system and your port group scheme uses
redundant ports (because you are using SR-IOV or PCI passthrough), you will allocate four
probe source IP addresses. You do not need to make any changes.
•
Otherwise, if you are commissioning a high availability system, you will allocate two probe
source IP addresses. Remove the probes-source-ip shelf A interface 2 and
probes-source-ip shelf B interface 2 lines.
•
If you are commissioning a standalone system and your port group scheme uses redundant
ports (because you are using SR-IOV or PCI passthrough), replace all the probe-sourceip lines with the following and update the IP addresses.
probes-source-ip interface 1 10.10.10.11
probes-source-ip interface 2 10.10.10.11
•
Otherwise, if you are commissioning a standalone system, replace all the probe-sourceip lines with the following and update the IP addresses.
probes-source-ip interface 1 10.10.10.11
In the foundation configuration there are two local-ip-address lines on service interface 2 (the
general access interface); the second provides an example of how to add an extra address for use
with a SIP trunk. If you will not be using any SIP trunks on the general access interface, delete
the second local-ip-address line (the one with address 53.53.53.11) and the following
service-address line.
3. Update the subnet prefix length for each service interface object (the subnet-prefix-length
lines) to the correct prefix length in bits for that service network.
4. Add any additional local IP addresses you require to connect to SIP trunks to the access service
interfaces, by adding a local-ip-address and service-address line for each. The
service-address line must give a unique name for that local address.
5. Replace the permit-peer line with one or more similar lines giving the service networks and IP
addresses of any non-registering access devices or peers you want to permit traffic from (in your
access service networks). If there are no non-registering devices you want to permit traffic from,
delete the permit-peer an d the preceding trusted-sources lines.
6. If you are using an alternative plan for port groups, change the port group names in the portgroup-name lines as appropriate.
72 6 Preparing CLI configuration
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
Media interface
These changes are described in more detail in Media interface configuration on page 49.
1. Locate the media line in the foundation configuration; all the relevant configuration for this section
is immediately below it.
2. If you added additional local IP addresses on service network 2 or 3 (general access and managed
access, respectively) for additional SIP trunks, add an additional media-address and realm line
for each one. Change the realm name in the realm line to a unique name for each address; for
simplicity, we recommend TrunkMedia2, TrunkMedia3 etc.
3. If you are not using any additional IP addresses for SIP trunks on service network 2, delete the
media-address ipv4 53.53.53.11 service-network 2 line and the following realm
line.
4. Update the IP address in each media-address line with the correct local IP address from the
service interface.
Signaling configuration
These changes are described in more detail in Signaling configuration on page 50.
1. If you want to remove any of the User-Agent strings for which the Session Controller will drop
requests, delete them from the condition advanced line.
2. If you are not using the managed access service interface, delete the ManagedAccess adjacency
(from the adjacency sip ManagedAccess line to the next activate line).
3. If you are not using any SIP trunks (peers), delete the Trunk1 adjacency (from the adjacency
sip Trunk1 line to the next activate line).
4. If you are using more than one SIP trunk, add a new adjacency for each by copying the Trunk1
adjacency (from the adjacency sip Trunk1 line to the next activate line) and changing the
name in the adjacency sip line (for simplicity, we recommend using Trunk2, Trunk3 etc.).
Update the service-address line for each new adjacency with the service address name you
configured for its local IP address (in the service interface configuration), and the realm line with
the media realm you configured for that IP address (in the media interface configuration).
5. Update the signaling-peer and remote-address-range lines on each core and peering/SIP
trunk adjacency (Softswitch, Trunk1, and any additional peering adjacencies you added in the
last step) with the correct IP address of the peer device; for the peering adjacencies, update the
dynamic-routing-domain-match command with the same IP address.
6. If any of the peer devices use a SIP port other than the normal 5060, update the signalingpeer-port line for the adjacency to the device with the correct port.
Diagnostics configuration
These changes are described in more detail in Diagnostics configuration on page 56.
1. Replace the IP address in the sas remote-address line with the IP address of your Metaswitch
Service Assurance Server if you have deployed one. If you have not deployed one, delete this line.
2. Replace the IP address in the client-address line with the IP address of your MetaView Server
or other Network Management System if you have deployed one. If you have not deployed a
6 Preparing CLI configuration 73
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
Network Management System, delete the snmp line and every line below it up to and including the
hardware-notifications line.
Blacklisting configuration
These changes are described in more detail (including lists of the available pre-made blackisting
profiles) in Dynamic blacklisting configuration on page 57.
1. For each untrusted (access) service network, peer (SIP trunk), and multi-endpoint device (PBX
or multi-endpoint NAT) your deployment will support, select an appropriate pre-made blacklisting
profile based on the number of calls/endpoints or generate a new profile using the blacklisting tools
spreadsheet.
2. If you need to use any of the pre-made profiles from Additional example dynamic blacklisting
profiles on page 64, copy them into the foundation configuration immediately following the
existing pre-made profiles.
3. If you generated new profiles, add them to the foundation configuration in the blacklisting
section, immediately following the existing pre-made profiles. Each profile begins with a profile
line.
4. Update the profile-usage section of the foundation configuration to apply the profiles you
have selected for each service network, peer, and multi-endpoint device, as described in Dynamic
blacklisting configuration on page 57.
Additional customization
The changes listed above are necessary for all deployments; you may need to make additional
changes as follows.
•
If your deployment includes more than one softswitch, see Adding additional softswitches on page
74 for details of the changes you need to make.
•
Tuning your configuration for your softswitch on page 77 provides details of how to add
additional capacity limits for your softswitch, and the changes you need to make to the
configuration if you are using MetaSphere CFS as your softswitch.
6.9 Adding additional softswitches
If your deployment includes more than one softswitch, you must make changes to the foundation
configuration to accommodate the additional softswitches.
Adding adjacencies
The foundation configuration includes a single core adjacency for a single softswitch. The
configuration for that adjacency is given below; it was explained in more detail in Signaling
configuration on page 50,
adjacency sip Softswitch
deactivation-mode normal
force-signaling-peer all-requests
adjacency-type preset-core
outbound-flood-rate 1000
74 6 Preparing CLI configuration
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
privacy trusted
realm CoreMedia1
remote-address-range ipv4 10.10.11.20 prefix-len 32
service-address CoreAddress4-01
signaling-local-port
signaling-peer 10.10.11.20
signaling-peer-port 5060
statistics-setting detail
default-interop-profile Softswitch
activate
You will need to make the following changes to include appropriate adjacencies for all your
softswitches.
1. Change the name in the first line (adjacency sip) of the existing adjacency from Softswitch
to an appropriate name for the softswitch it will correspond to.
2. Copy the adjacency once for each softswitch in your deployment (insert the copies into the
configuration immediately after the first adjacency). Make the following changes to each
adjacency.
•
Change the name in the adjacency sip to an appropriate name for the softswitch this
adjacency will correspond to.
•
Update the IP addresses in the signaling-peer and remote-address-range lines to the
SIP IP address of the softswitch for this adjacency.
Attention:
Do not change the default-interop-profile Softswitch line; this refers to the
Softswitch interoperability profile settings, which all the adjacencies can use.
Updating routing configuration
The foundation configuration includes a very basic routing setup, shown below.
call-policy-set 1
first-call-routing-table SourceAdjacency
first-reg-routing-table SourceAdjacency
rtg-src-adjacency-table SourceAdjacency
description "Initial routing table"
entry 1
match-adjacency Softswitch
action next-table AccessDomains
entry 199
match-adjacency *
dst-adjacency Softswitch
action complete
rtg-dst-domain-table AccessDomains
description "Routing from core to access"
entry 301
match-domain *
dst-adjacency dynamic-peer-routing
action complete
entry 302
match-domain *
dst-adjacency GenericAccess
action complete
complete
6 Preparing CLI configuration 75
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
This configuration initially routes all traffic based on its source adjacency, using a routing table called
SourceAdjacency which is defined by the rtg-src-adjacency-table line and the indented
configuration beneath it.
Note:
Routing configuration doesn't apply to in-dialog messages or messages sent to registered
subscribers; Perimeta will automatically route these messages based on the existing dialog or
registration.
The table routes based on two table entries, defined by an entry line and the configuration indented
under it; when routing a message using a source adjacency table, Perimeta will consult each entry
in turn until it finds one with a match-adjacency line that matches the source adjacency of the
message. It will then set the destination adjacency for the message if there is a dst-adjacency line
present for the entry, and take the action given by the action line, which can end the routing process
(complete) or activate another routing table (next-table).
So, the effect of the SourceAdjacency table is as follows.
1. If a message arrives from the Softswitch adjacency, go to the AccessDomains (which handles
selection of outbound access adjacencies and is not covered here).
2. Otherwise, set the destination adjacency to Softswitch and finish routing.
With multiple softswitches, you must expand the routing configuration to include their adjacencies and
route inbound traffic to the correct softswitch.
Updating the source adjacency table
You need to make the following updates to the source adjacency table.
1. Update the match-adjacency Softswitch line to replace Softswitch with the new
adjacency name you used for your first softswitch adjacency.
2. For each additional softswitch adjacency you've added to your configuration, add one copy of the
first entry (the entry 1 line and the two indented lines following it). Add the copies immediately
after the first entry. Make the following changes for each entry you add.
•
Increase the number in the entry line to one more than the previous entry.
•
Update the match-adjacency line to the name of one of the appropriate softswitch
adjacency.
3. Make the following changes to the final wildcard entry 199. These changes will stop it selecting
a single outbound adjacency for access traffic, instead selecting a new routing table that you will
create in the next section.
•
Delete the dst-adjacency Softswitch line.
•
Replace the action complete line with action next-table SoftswitchTable.
The following example shows an updated source adjacency table with three softswitches.
rtg-src-adjacency-table SourceAdjacency
description "Initial routing table"
entry 1
76 6 Preparing CLI configuration
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
match-adjacency Softswitch1
action next-table AccessDomains
entry 2
match-adjacency Softswitch2
action next-table AccessDomains
entry 3
match-adjacency Softswitch3
action next-table AccessDomains
entry 199
match-adjacency *
action next-table SoftswitchTable
Adding the softswitch table
Finally, you must add a table to select the correct softswitch adjacency to route access traffic to.
Typically you can do this by routing on the destination domain of the message. This is the domain part
of the Request-URI, and will typically be a domain name or IP address for the softswitch.
Note:
In some circumstances you might want to use a different kind of routing table; for example, if
you were using SIP phones that did not support using a different proxy address/domain name
(Perimeta) to the registrar address/domain name (the softswitch). Perimeta supports a variety of
alternative routing methods, which are detailed in the Configuration and Interoperability Guide.
The following example shows a destination domain table that selects between three softswitch
adjacencies, corresponding to the adjacencies in the example source adjacency table above.
rtg-dst-adjacency-table SoftswitchTable
entry 1
match-domain softswitch1.com
dst-adjacency Softswitch1
action complete
entry 2
match-domain softswitch2.com
dst-adjacency Softswitch2
action complete
entry 3
match-domain softswitch3.com
dst-adjacency Softswitch3
action complete
entry 199
match-domain *
dst-adjacency Softswitch1
Perimeta will check the destination domain of the message against each entry in turn. The final entry
uses a wildcard (match-domain *) to catch any messages that do not match the specified domains,
sending them to the Softswitch1 adjacency.
6.10 Tuning your configuration for your softswitch
You may need to apply some additional settings to the foundation configuration to tune it for your
softswitch by adding capacity limits. If your softswitch is a MetaSphere Call Feature Server, there are
certain specific additional settings you must add.
6 Preparing CLI configuration 77
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
Adding capacity control limits
You can manage the load on your softswitch by adding capacity control limits to the softswitch
adjacency (or to all the softswitch adjacencies if you have multiple softswitches). These are not
required to protect your softswitch from malicious attacks; Perimeta's standard security features and
your dynamic blacklisting configuration do that. Capacity control limits allow you to control normal
traffic, helping to manage spikes that occur during normal operation (during a popular TV phone-in, for
example).
The following example shows the Softswitch adjacency from the foundation configuration with
some example call limits added.
adjacency sip Softswitch
adjacency-limits as-destination
call-rate sustain 1042 per-minute
in-call-rate sustain 6252 per-minute
out-of-call-rate sustain 6252 per-minute
regs-rate sustain 500 per-second
deactivation-mode normal
force-signaling-peer all-requests
adjacency-type preset-core
outbound-flood-rate 1000
privacy trusted
realm CoreMedia1
remote-address-range ipv4 10.10.11.20 prefix-len 32
service-address CoreAddress4-01
signaling-local-port
signaling-peer 10.10.11.20
signaling-peer-port 5060
statistics-setting detail
default-interop-profile Softswitch
activate
The adjacency-limits line and the indented lines beneath it apply the capacity control limits. They
have the following meanings.
•
call-rate limits the rate of new calls (INVITE messages) going to and from the softswitch.
•
in-call-rate limits the rate of in-call SIP messages going to and from the softswitch.
•
out-of-call-rate limits the rate of out-of-call SIP messages (such as SUBSCRIBE) going to
and from the softswitch; this does not include messages that are part of a registration.
•
regs-rate limits the rate of registrations (including re-registrations) going to the softswitch.
The values used are examples only; replace them with appropriate values based on the rated load of
your softswitch and your expected call volumes.
Interoperability settings
In general, interoperability settings depend on the softswitch you have deployed. Typically the
foundation configuration should work with most RFC 3261-compliant devices; if your softswitch has
specific requirements about particular aspects of SIP, consult the Perimeta documentation set for
details of Perimeta's extensive interoperability features.
78 6 Preparing CLI configuration
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
Settings for MetaSphere Call Feature Server
If you have deployed the MetaSphere Call Feature Server (CFS) as your softswitch, you must make
the following changes to the foundation configuration.
•
Find the Softswitch interoperability profile (the sip interop-profile Softswitch line and
the lines indented beneath it) and add dtmf disable sip notify and active-unregister
auth-all lines to it, so it appears as shown below.
sip interop-profile Softswitch
description "for use with a softswitch"
header-settings via passthrough-outbound
ping-enable
interval 8
lifetime 8
disable sip notify
active-unregister auth-all
•
Find the CFS-facing Softswitch adjacency (the adjacency sip Softswitch line and the
indented lines beneath it), or all your CFS-facing adjacencies if you added additional ones for
additional CFSs. Add a call-media-policy line with a repeat-sdp-on-200-ok immediately
below it, so the adjacency (or adjacencies) appears as shown below.
adjacency sip Softswitch
adjacency-limits as-destination
call-rate sustain 1042 per-minute
in-call-rate sustain 6252 per-minute
out-of-call-rate sustain 6252 per-minute
regs-rate sustain 500 per-second
deactivation-mode normal
force-signaling-peer all-requests
adjacency-type preset-core
outbound-flood-rate 1000
privacy trusted
realm CoreMedia1
remote-address-range ipv4 10.10.11.20 prefix-len 32
service-address CoreAddress4-01
signaling-local-port
signaling-peer 10.10.11.20
signaling-peer-port 5060
statistics-setting detail
default-interop-profile Softswitch
call-media-policy
repeat-sdp-on-200-ok
activate
6 Preparing CLI configuration 79
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
7 Installation Process
7.1 Installing Perimeta in a VMware environment
This procedure describes how to install Perimeta virtual machines (VMs) in a VMware environment.
This procedure can be used to create a new VMware deployment or to add new VMs to an existing
deployment.
Planning for the procedure
Background knowledge
You must have collected all of the information in the Virtual Machines section of Perimeta
commissioning planning tables on page 24.
You must have already carried out the steps given in the Metaswitch Distributed Capacity Manager
Initial Setup Guide to deploy a DCM Group within your VMware environment.
You must have access to the VMware vSphere Client or Web Client to run this procedure. The
VMware vSphere Client or Web Client must be running v5.1 or later. This procedure assumes that you
have at least a basic familiarity with VMware, vSphere and the VMware vSphere Client or Web Client
interface.
Note:
This procedure only gives general guidance for creating and configuring new VMs through the
VMware vSphere Client or Web Client and does not provide specific step-by-step instructions.
If you are using PCI passthrough for some of your NICs on a Cisco UCS B-Series chassis, you can
find more information about deploying on this platform at https://communities.metaswitch.com/docs/
DOC-307318.
If you are using VMware ESXi V5.5 or 6.0, you can find detailed guidance for installing your
Perimeta VM at https://communities.metaswitch.com/docs/DOC-217282.
For all other versions of VMware, you will need to consult your VMware documentation for
detailed information on creating and configuring new VMs when carrying out this procedure.
We recommend that you read through this entire procedure first and then use your VMware
documentation to ensure that you understand how to carry out each step. You may still find it useful
to review the procedure at https://communities.metaswitch.com/docs/DOC-217282 as an example,
but remember that it is only compatible with VMware ESXi V5.5 and 6.0.
80 7 Installation Process
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
Reserve maintenance period
This procedure provides steps for setting up a new Perimeta VM and should not impact service
if followed correctly. However, if this procedure is used to add a new Perimeta VM to an existing
virtualized deployment, there is a risk of misconfiguration resulting in an IP address clash, which
could impact service to existing Perimeta VMs. If you are planning to carry out this procedure in an
existing virtualized deployment, we recommend that you schedule a 30 minute maintenance window
to minimize any service impact that may be caused by misconfiguration.
Plan for service impact
This procedure provides steps for setting up new Perimeta VMs and should not impact service
if followed correctly. However, if this procedure is used to add a new Perimeta VM to an existing
virtualized deployment, there is a risk of misconfiguration resulting in an IP address clash, which could
impact service to existing Perimeta VMs.
People
In order to perform this task, you, the Service Provider, will need to provide a network technician to
perform the MOP steps on the VMware vSphere Client or Web Client.
This procedure only gives general guidance for creating and configuring new VMs through the
vCenter configuration utility and does not provide specific step-by-step instructions. The network
technician must be experienced in using your chosen version of the VMware vSphere Client or Web
Client to create and configure new VMs.
Tools and access
The network technician must be able to create and configure new VMs through the VMware vSphere
Client or Web Client. The VMware vSphere Client or Web Client must be running v5.1 or later.
Process
You must have received the Perimeta OVA file from your support contact.
If you will use PCI passthrough for any interfaces, you must have identified the MAC address for the
NICs you will pass through and enabled PCI passthrough for them. To do this in vSphere vClient
1. Identify the NICs to pass through from the host and note down the PCI addresses and MAC
addresses. To identify these addresses, you can use the VMware vSphere Client, VMware
vSphere Web Client, or your host's management tools.
2. Enable PCI passthrough for the NICs in the VMware vSphere Client or VMware vSphere Web
Client. You will need to know the PCI addresses of the NICs.
After completing this procedure
You must commission your VMs using the instructions in Commissioning Perimeta VMs on page
86.
7 Installation Process 81
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
Method of procedure
Create and bootstrap the new Perimeta VM(s)
Create and bootstrap the new Perimeta VM(s) using the vCenter configuration utility
This step must be carried out by the network technician.
•
This step must be carried out twice for a high availability system - once for each VM in the pair.
•
This step must be carried out once for a standalone system.
Create your VM(s) using the Perimeta OVA file. The VMs that you create may not have the correct
resources for your chosen Session Controller type. If this is the case, you must update these
resources to match the information that you collected in Perimeta commissioning planning tables on
page 24. For example, you may need to update the number of vCPUs or the size of the virtual hard
disk assigned to your VM.
You must ensure that you use the following settings for the CPUs for your virtual machine(s) to
optimize performance.
•
If the host that you are using supports Hyper-Threading, you must set the Hyper-Threaded Core
Sharing Mode to Internal. Hyper-Threading allows virtual CPU cores to share physical CPU cores,
meaning that you only need to provide one physical CPU core for every two virtual CPU cores.
Additionally, this setting ensures that the virtual CPU cores for the Perimeta virtual machine cannot
share physical CPU cores with virtual CPU cores from other virtual machines.
•
You must set the number of cores per socket for each virtual machine to be equivalent to the
number of vCPUs used by the virtual machine.
•
You must give each virtual machine a minimum CPU allocation equivalent to the collective clock
speed of the physical CPUs provided by the host for the virtual machine.
•
If you are deploying an ISC or MSC and your host supports non-uniform memory access (NUMA),
you must assign each Perimeta virtual machine to a NUMA node.
•
If you are using vSphere 5.5, we recommend that you set the Latency Sensitivity setting option
for each Perimeta virtual machine to High. This may increase CPU usage and power, but will
alleviate issues with media latency and packet drops.
If you are using vSphere 5.5, you must ensure that the virtual interrupt coalescing scheme for any
virtual network interface that is not using SR-IOV is set to rbc.
You must ensure that the disk I/O is not limited from this virtual machine.
If you are using PCI passthrough for some network interface controllers (NICs), you must do the
following.
•
Configure PCI devices on your virtual machine for the NICs you are passing through.
•
Configure NICs on your virtual machine for any NICs you are not passing through.
If you are not using PCI passthrough for your network interface controllers (NICs), you must ensure
that you create your NICs in the right order. You will have already identified this order when collecting
information listed in Planning your virtual environment for Perimeta on page 6.
82 7 Installation Process
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
If necessary, consult your VMware documentation for detailed information on creating and configuring
VMs.
Result: You have created both Perimeta VMs.
Configure vApp properties to identify NICs to the VMs (systems with PCI passthrough)
Note:
If you are not using PCI passthrough, skip this step and move to Power on and install the VM(s) on
page 83.
This step must be carried out by the network technician.
•
This step must be carried out twice for a high availability system - once for each VM in the pair.
•
This step must be carried out once for a standalone system.
You will need the keys you identified in Planning your virtual environment for Perimeta on page 6.
You will need the MAC addresses for all the NICs on your host.
•
You retrieved the MAC addresses for the NICs that you are passing through in Process earlier.
•
You will retrieve the MAC addresses for any NICs that you are passing through now.
Detailed procedure
1. Identify the MAC address for each of the NICs that you are not passing through. You can do this
by viewing the settings for the Network Adapter object that corresponds to the NIC. Record this
information in Perimeta commissioning planning tables on page 24.
2. Add all of the required vApp properties to each VM. Ensure that you do the following for each
property. If necessary, consult your VMware documentation for detailed information on adding
vApp properties.
•
In the Label section, type one of the keys that you identified in Information needed to install
Perimeta in a VMware environment in Perimeta Initial Setup Guide (VMware Environments).
This key will also appear in the Key ID field.
•
Under Type, set the Default Value field to the value that matches the key that you added to the
Label field. This will be a MAC address. Leave all other fields with their default values.
Power on and install the VM(s)
This step must be carried out by the network technician.
•
This step must be carried out twice for a high availability system - once for each VM in the pair.
•
This step must be carried out once for a standalone system.
You should begin by verifying that the OVF environment transport is set to VMware tools under
advanced vApp settings.
Once you have done this, you must now power on and open a console connection to the VM.
7 Installation Process 83
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
The VM will begin installation automatically. After about 10 minutes, the message 'Please reboot
this virtual machine to continue installation' will be printed to the console. At this point, you should
reboot the VM. Note that in some environments, this message will not be printed to the console
and the installation will appear to have stalled. If this happens, wait 15 minutes, then continue with
the next step. If this occurs more than once for the same VM, contact your Metaswitch Support
Representative.
If necessary, consult your VMware documentation for detailed information on powering on VMs.
Results
The VMs are powered on and installed with the Perimeta software.
Verification procedure
Verify that you have installed your Perimeta VMs correctly
Run through the installation checklist
You must now work through the following checklist to ensure that you have installed your Perimeta
virtual machines correctly.
No.
Item
1
Ensure that you have assigned your Perimeta virtual machines the
correct required resources, including vCPUs, RAM and virtual hard
disk space.
2
Ensure that the Hyper-Threading Core Sharing Mode is set to Internal.
3
Ensure the number of cores per socket for each virtual machine is
equivalent to the number of vCPUs used by the virtual machine.
4
Ensure that each virtual machine has a minimum CPU allocation
equivalent to the collective clock speed of the physical CPUs provided
by the host for the virtual machine.
5
Ensure each Perimeta virtual machine is assigned to a NUMA node (if
the host supports NUMA).
6
vSphere 5.5 only
Ensure that the Latency Sensitivity setting is set to High for each
Perimeta virtual machine.
7
84 7 Installation Process
vSphere 5.5 only
Done?
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
Ensure that the virtual interrupt coalescing scheme is set to rbc for all
network interfaces that are not using SR-IOV.
8
Ensure that the disk I/O is not limited from your Perimeta virtual
machines.
9
If you are not using PCI passthough, ensure you have configured your
NICs in the right order.
For virtual machines using PCI passthrough, ensure that you have
set up PCI devices and NICs as appropriate and configure vApp
properties to identify your to Perimeta.
10
Ensure that the OVF environment transport is set to VMware Tools.
11
Verify that you can successfully power on your Perimeta virtual
machines and establish a console connection.
Backout procedure
If you run into difficulties during the running of this procedure, you may want to delete the VMs that
you have created.
Remove the new VMs
Stop and delete the new VMs
This step must be carried out by the network technician.
You must shut down and then delete the Perimeta VMs using the VMware vSphere Client or Web
Client. Consult your VMware documentation if you need guidance on how to do this.
Results
Your new VMs are deleted.
Next steps
You must commission your VMs using the instructions in Commissioning Perimeta VMs on page
86.
7 Installation Process 85
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
8 Commissioning Process
8.1 Commissioning Perimeta VMs
To commission your Perimeta Session Controller, you must set up your Perimeta VMs as either a high
availability or standalone system, configure various settings in the Craft Terminal menu, and apply the
CLI configuration you prepared in the previous section of this guide.
Before you begin
You must have worked through the preceding sections of this guide, and have the following to hand.
•
A complete set of the planning information listed in Perimeta commissioning planning tables on
page 24.
•
Your customized foundation CLI configuration, created by working through the Preparing CLI
Configuration section of this guide. You should have this in a text file on the computer you will use
to access your Session Controller.
You must have installed the Perimeta VMs that will form the high availability or standalone system.
These Perimeta VMs must be powered on. For more information, see Installing Perimeta in a VMware
environment on page 80.
You must have the license key corresponding to your new Session Controller license available on
your computer to copy and paste into the CLI. This will have been supplied by Metaswitch. For more
information on Licenses, see Managing licenses in Perimeta Operations and Maintenance Guide.
You must have access to the vCenter configuration utility to run this procedure. If you are intending to
use SR-IOV (which you must use if you want Perimeta to handle more than a few tens of concurrent
calls), the vCenter configuration utility must be running v5.1 or later. This procedure assumes that you
have at least a basic familiarity with VMware, vSphere and the vClient configuration interface.
You must select a new password for the root and defcraft users. You will need to obtain the
default passwords for these users from your support contact.
Attention:
You will change the passwords for the root and defcraft users as part of this procedure.
It is critical that you change the default passwords for the root and defcraft users to something
secure and unguessable to prevent unauthorized access to your system. The default passwords
are not sufficiently secure to protect your system.
When changing the root password, you must record the new password before changing it to ensure
that you do not lose root access. You should also test the new root password with a new terminal
connection (a new PuTTY session) before closing the current connection. Losing root access will
leave your system in an unrecoverable state.
86 8 Commissioning Process
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
Note:
The passwords that you choose must meet the default complexity checks described in Craft
Terminal in Perimeta Operations and Maintenance Guide. Ensure that you record all passwords in
a secure location.
If you have deployed MetaView Server, you must have access to MetaView Explorer so that you can
add Perimeta, and you must know the password for the msbackup user on your MetaView Install
Server (information on this server is available in the MetaView Ancillary Servers Guide).
Connect to the Craft Terminal
If you are commissioning a high availability system, the virtual machine you connect to now will be the
initial primary virtual machine in the high availability system. It will be 'processor A' and any Perimeta
menus and prompts that refer to A or B will refer to this virtual machine or the other one in the high
availability system, respectively.
If you are commissioning a standalone system, the virtual machine you connect to now will be the only
virtual machine in the standalone system and it will be referred to as 'processor A'.
Detailed procedure
1. Open the VMware vSphere Client or Web Client and locate the Perimeta virtual machine that you
have chosen to be processor A.
2. Right click on the Perimeta virtual machine and select Open Console.
3. Log on as the defcraft user.
Set the management IP addresses
Detailed procedure
1. Select "Admin".
2. Select "Network".
3. Select "Management".
4. Select "Set IP".
5. Select "Set IPv4".
6. Follow the prompts to set the system management IP address and subnet prefix length, the local
instance management IP address and probe source IP address, the remote instance management
IP address and probe source IP addresses, the management network default gateway IP address,
and the probe test IP addresses. You will have recorded these details in the Management Network
section of the commissioning planning tables.
Set the probe target addresses
Detailed procedure
1. Type 0 followed by Enter.
2. You should now be in the Management menu.
8 Commissioning Process 87
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
3. Select "Set probes".
4. Follow the prompts to set the probe target IP addresses. You will have recorded these in the
Management Network section of the commissioning planning tables.
Set the system name and node names
You can configure a name for the system as a whole and for each node (virtual machine).
Detailed procedure
1. Type 0 followed by Enter. Do this twice.
2. You should now be in the Admin menu.
3. Select "System config".
4. Select "System Info".
5. Select "Set system name".
6. Follow the prompts to set the system name.
7. Select "Set node name".
8. Follow the prompts to set the local node name (a name for the virtual machine you are currently
connected to). If you are commissioning a standalone system, you can skip to step 11 (getting
system info) once you have done this.
9. Select "Set remote node name".
10.Follow the prompts to set the remote node name (a name for the other virtual machine).
11.Select "Get system info".
12.Check the output to ensure your configuration is correct. If it is not, repeat the steps above to
correct it.
Install the core Perimeta software
Detailed procedure
1. Select "Software".
2. Select "Manage versions".
3. Select "Verify/unpack".
4. Select OK.
5. The Craft Terminal will display the only available software version on the system. Select it and wait
for it to unpack.
6. Type 0 followed by Enter.
7. You should now be in the Software menu.
8. Select "Upgrade".
9. Select "Start Upgrade".
10.The Craft Terminal will display the only available software version for upgrade. Select it and wait
for the upgrade to complete.
88 8 Commissioning Process
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
Set the system role
Detailed procedure
1. Type 0 followed by Enter. Do this twice.
2. You should now be in the Craft menu.
3. Select "Admin".
4. Select "Commissioning".
5. Select "Commission".
6. Follow the prompts, selecting the appropriate system role (ISC, SSC or MSC).
Optionally, disable DPDK mode
Detailed procedure
1. Type 0 followed by Enter.
2. You should now be in the Admin menu.
3. Select "Media Capacity".
4. Select "Set DPDK mode".
5. When prompted, select Disabled and then OK.
The Session Controller will now reboot as part of disabling DPDK mode. You must wait up to 5
minutes for this process to complete. You can then log in to the Craft Terminal on Processor A and
continue with the procedure.
Set up the high availability (HA) connection
Note:
You can skip this step if you are commissioning a standalone system.
Detailed procedure
1. If you carried out the steps in Optionally, disable DPDK mode on page 89, you should now do
the following.
•
Select "Admin".
•
Select "Partnering".
•
Select "Set Replication IP".
2. If you did not carry out the steps in Optionally, disable DPDK mode on page 89, you should now
do the following.
•
Type 0 followed by Enter.
•
You should now be in the Admin menu.
•
Select "Partnering".
•
Select "Set Replication IP".
8 Commissioning Process 89
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
3. When prompted, enter the HA IP address allocated to this virtual machine (local processor),
and then the HA IP address allocated to the other virtual machine in the high availability system
(remote processor).
4. Type the HA IP address of Processor B, then press Enter.
5. Type the length of the subnet length assigned to the HA network, then press Enter.
6. Break out of the console by pressing Ctrl + Alt. Access the console on the other Perimeta virtual
machine in your high availability system, and repeat this step to set the HA IP addresses on it remember to swap the local and remote addresses!
7. Break out of the console by pressing Ctrl + Alt, and return to the console on the virtual machine
you were originally configuring (the one you have configured the system role for).
Partner the servers
Note:
You can skip this step if you are commissioning a standalone system.
This step will link the two virtual machines in your high availability system so that they share
configuration.
Detailed procedure
1. Select "Propose".
2. Follow the prompts to start the partnering process. It may take up to 45 minutes.
Set the DNS server IP addresses
Note:
If you are not using DNS in your deployment, skip this step.
Detailed procedure
1. Type 0 followed by Enter.
2. You should now be in the Admin menu.
3. Select "Network".
4. Select "DNS".
5. Select "Set DNS servers".
6. Enter the IP addresses of each of your chosen DNS servers in order of priority, starting with the
highest priority DNS server.
Configure the local timezone
Detailed procedure
1. Type 0 followed by Enter. Do this twice.
2. You should now be in the Admin menu.
90 8 Commissioning Process
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
3. Select "System config".
4. Select "Timezone".
5. Select "View options".
6. The Craft Terminal shows a list of timezone names that you can choose from. Find the name that
best describes your required time zone and note it down.
7. Select "Set timezone".
8. When prompted, type the timezone name you noted down.
Set the date and time
Note:
Although you will configure NTP servers, you must still complete this step. To avoid possible
undesired effects from a sudden change in system time, your Session Controller gradually "drifts"
into synchronization with NTP. By setting an approximately correct time before configuring NTP
servers, you can reduce how long this synchronization takes.
Detailed procedure
1. Type 0 followed by Enter.
2. You should now be in the System config menu.
3. Select "Time".
4. Select "Set date and time".
5. Follow the prompts to set the current date and time.
Set the NTP server IP addresses
Detailed procedure
1. Select "Update NTP".
2. When prompted, choose to set the list of NTP servers and enter the IP addresses of your NTP
servers as a comma separated list.
Set the port group scheme
Detailed procedure
1. Type 0 followed by Enter. Do this twice.
2. You should now be in the Admin menu.
3. Select "Network".
4. Select "Redundant Port Groups".
5. Select "Set Redundant Port Group scheme".
6. Follow the prompts and choose the port group scheme you have selected for your deployment,
setting the names for the port groups as set out in your planning tables.
7. Type 0 and press Enter to return to the Admin menu.
8 Commissioning Process 91
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
Configure global DSCP values
Note:
If you want to use the default DSCP settings given in Perimeta commissioning planning tables on
page 24, skip this step.
Detailed procedure
1. Select "Network".
2. Select "Management".
3. Select "DSCP".
4. Select the options for the traffic types you want to set the values for, and follow the prompts to set
the value.
5. Type 0 and press Enter to return to the Admin menu.
Configure the Distributed Capacity Manager (DCM) connection
Detailed procedure
1. Select "License Management".
2. Select "Distributed Capacity Manager Group Configuration".
3. Select "Join Distributed Capacity Manager Group".
4. Select "Instance A".
5. When prompted, enter the IP address of one of the Metaswitch DCMs in your chosen DCM Group.
Follow the confirmation prompts. If you are carrying out this step on a standalone system, you
do not need to continue with the rest of this step and you can now move to Start the Session
Controller on page 92.
6. Select "Instance B".
7. When prompted, enter the IP address of one of the Metaswitch DCMs in your chosen DCM Group.
Follow the confirmation prompts.
Start the Session Controller
Detailed procedure
1. Select "Start/stop".
2. Select "Start".
3. Follow the prompts to start your Session Controller.
Reboot the Session Controller
Detailed procedure
1. Type 0 followed by Enter.
2. You should now be in the Admin menu.
3. Select "Reboot".
92 8 Commissioning Process
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
4. When prompted, choose to reboot both instances. Follow the prompts to confirm the reboot.
5. You will lose your Craft Terminal connection. Wait a few minutes before reconnecting. Now that
you have configured management IP addresses, you can choose to reconnect using SSH to the
system management IP address.
If you have deployed MetaView Install Server or a FTP file server, configure remote snapshots
(configuration backups)
Detailed procedure
1. Select "Admin".
2. Select "Snapshots".
3. Select "Modify upload config".
4. When prompted, select whether you are using MetaView Install Server of a FTP file server as the
snapshot management system.
If you are using MetaView Install Server, you will be prompted for the following information.
•
The IP address of the MetaView Install Server.
•
The password for the msbackup user.
If you are using an FTP file server, you will be prompted for the following information.
•
The IP address of the FTP file server.
•
The username and password (if needed) you want the Session Controller to use to connect to
the FTP server.
•
The path on the FTP file server to which you want the Session Controller to copy snapshots.
5. Select "Modify schedule".
6. When prompted, select the hour and minute at which to take daily snapshots. If you have no
preference, just press Enter to use the defaults. Choose to upload snapshots to a remote location.
If you have not deployed MetaView Install Server or a FTP file server, configure local
snapshots
Detailed procedure
1. Select "Admin".
2. Select "Snapshots".
3. Select "Modify schedule".
4. When prompted, select the hour and minute at which to take daily snapshots. If you have no
preference, just press Enter to use the defaults. Choose to store snapshots locally.
Check MetaView Explorer for alarms
If you are deploying Perimeta alongside a MetaView Server that is already managing other
Metaswitch products, we recommend that you check for and, if possible, resolve any alarms currently
raised in MetaView Explorer. This will help to identify any new alarms that may be raised as the result
of applying your CLI configuration through the Perimeta CLI.
8 Commissioning Process 93
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
Start the CLI
Detailed procedure
1. Select "CLI".
Apply your license key
Detailed procedure
Type the following commands.
1. actions
2. system
3. apply-license
When prompted, copy and paste your license key into the CLI prompt.
Change the root password
For security, you must change the initial password for the root user.
Detailed procedure
1. While keeping your current SSH session open, start a new SSH session and connect to the
system management IP address as the root user.
2. Type the following command.
passwd root
3. Type the new password into the prompt.
4. Type the new password into the prompt again to confirm.
5. While keeping both of your current SSH sessions open, start another new SSH session and
connect to the system management IP address as the root user using the new password that you
have configured. Verify that you can successfully log in as the root user with the new password.
Once you have verified this, you can close both the SSH sessions on which you are connected as
the root user. This will leave you with the original SSH session on which you are connected as
the defcraft user. You must use this session to continue with the rest of the procedure.
Change the defcraft password
For security, you must change the initial password for the defcraft user.
Detailed procedure
Type the following commands.
1. config
2. system
3. users
4. user defcraft
5. password cleartext
94 8 Commissioning Process
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
Type the new password into the prompt.
Check current alarms
Detailed procedure
Type the following command.
1. show alarms
The CLI displays current alarms; it is normal to see some alarms at this point due to missing
configuration. Make a note of the current alarms.
Apply your CLI configuration
Detailed procedure
Type the following command.
1. end
This will return you to the root of the CLI. You can now copy and paste in the CLI configuration you
prepared in the Preparing CLI Configuration section of this guide. Paste it in all at once; the CLI will
automatically apply each line in turn (you will need to press Enter after the last pasted command).
If the CLI stops applying commands with an error message reading Invalid input detected at
'^' marker. No match for word, identify the invalid command and refer to the relevant section
of Preparing CLI Configuration to identify the problem with the configuration by checking it against the
examples and instructions given there. Once you have identified the problem, fix it in your copy of the
configuration and repeat this step (returning to the CLI root and pasting the entire fixed configuration it will overwrite any partial configuration from the failed attempt).
Once you have successfully pasted in a full set of configuration, type the following commands
to display any configuration problems and alarms, any interface problems and the status of your
adjacencies.
1. show config warnings
2. show alarms (look for new alarms since you noted down alarms before applying your
configuration)
3. show system interface connectivity mgmt
4. show system interface failures
•
If the output for this command reports that the carrier is down for an interface, this indicates that
there is no physical connectivity. You must check that the port is enabled on the switch and that
the cabling is correct.
•
If the output for this commands reports that the carrier is up for an interface but probes are
down, this usually indicates a problem with the configuration, either on the switch or on the
service interface. You should compare the configuration on Perimeta and on the switch for the
subnet and default gateway to ensure that they match. If applicable, you should compare VLAN
tagging configuration. You should also ensure that ports are cabled correctly.
8 Commissioning Process 95
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
5. show sys interface device interfaceName
where interfaceName is the name of an interface, e.g. RPG1. You should run this command for all
interfaces. The output of this command will highlight any cabling problems for a particular interface.
6. show sbc adjacency all
All adjacencies should be active, softswitch and trunk adjacencies should be Connected,
meaning the Session Controller has successfully pinged the softswitch or the peer with an SIP
OPTIONS request. An adjacency may be inactive if the endpoint to which it connects has not been
activated or migrated. In this case, you can deactivate the adjacency or disable peer availability
detection for this adjacency to prevent alarms from being raised.
This will display any errors with your configuration and connectivity. Again, refer back to the relevant
sections of Preparing CLI Configuration to help identify and fix any configuration errors. Connectivity
or interface problems may be due to configuration errors (such as incorrect IP addresses) or cabling/
network problems. You can ping IP addresses in your service networks from the CLI to check network
connectivity using the following commands.
1. actions
2. system
3. service-network SNID
where SNID is the ID number of the service network you want to send a ping on (in the standard
foundation configuration, 1 is the core network, 2 is general access, 3 is managed access).
4. ping ipv4 pingTarget
where pingTarget is the IP address you want to ping.
Query NTP to confirm that your Session Controller is synchronized with the NTP servers
Do the following in the Craft Terminal.
Detailed procedure
1. Select "Admin".
2. Select "System config".
3. Select "Time".
4. Select "Query NTP".
5. You are prompted to confirm or cancel your selection. From the prompt, select OK.
6. The Craft Terminal shows the status of your Session Controller's synchronization with the NTP
servers. Check the quality of the synchronization.
•
In the remote column, the NTP server that your Session Controller is currently synchronized
with has a * character in front of its name. Other available NTP servers have a + character in
front of their names.
•
The offset column shows the time difference (in milliseconds) between your Session
Controller's clock and the NTP server's clock. This must be as low as possible. A high-quality
synchronization will typically have an offset of around 1ms. At 128ms or higher, your Session
Controller loses synchronization with the NTP server.
96 8 Commissioning Process
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
7. If your Session Controller has a low-quality synchronization with an NTP server, do the following.
•
Repeat steps 1-5 to confirm the low quality of the synchronization.
•
Check the status of your Session Controller's connection to the management network.
•
Reboot your Session Controller, as described in Reboot the Session Controller on page 92.
•
Check any problems with the NTP server. If the NTP server is the cause of the low-quality
synchronization and you cannot fix the problem, repeat Set the NTP server IP addresses on
page 91 and use a different NTP server.
•
Repeat step 6 until your Session Controller has a high-quality synchronization with an NTP
server.
Test DNS queries in the management network
Do the following in the Craft Terminal.
Detailed procedure
1. Select "Admin".
2. Select "Network".
3. Select "DNS".
4. Select "Test DNS".
5. When prompted, enter the domain name you want to query.
6. Verify that the query is successful. If there is an error displayed, ensure that you carried out the
steps in Set the DNS server IP addresses on page 90 to correctly configure your DNS servers.
If this configuration is correct, this may indicate a problem with the configuration on your DNS
servers.
If you have deployed MetaView Server, add your Session Controller
If you are deploying Perimeta alongside a MetaView Server that is already managing other
Metaswitch products, we recommend that you pause briefly before carrying out this step. This will
allow time for alarms to clear, preventing administrators from reacting to benign alarms raised as
Perimeta's configuration is applied.
Detailed procedure
1. Log in to MetaView Explorer.
2. Select Object tree and views.
3. Expand All Managed Components.
4. Select Add subcomponent.
5. Select Session Controller Connection.
6. Enter the Session Controller system management IP address and apply.
Test your deployment
Detailed procedure
8 Commissioning Process 97
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
1. Set up your test phone to register with your softswitch as you normally would (using your test
directory number), except that you must set the outbound proxy for registration to Perimeta's local
IP address on the general access service network.
2. Make a test call from your test phone.
3. If possible, make a test call to your test phone from another phone (one registered with your
softswitch or connected through a SIP trunk or PSTN gateway).
What to do next
You may need to carry out one or more of the following tasks, depending on the decisions you have
made earlier in the commissioning process. If you do not need to carry out either of these steps, you
have completed the commissioning process.
•
If you are using MetaView Install Server as the snapshot management system for Perimeta
snapshots, you must now add a script to the MetaView Install Server to ensure that old snapshots
are regularly deleted to preserve disk space. For information on how to do this, see Preparing an
Install Server to serve as the snapshot management system for Perimeta on page 99.
•
If you want to allow your administrators to manage this Perimeta Session Controller using
MetaView Web, you must now carry out the procedure given in Enabling MetaView Web
management of Perimeta on page 101.
•
If you want to support Perimeta's inband DTMF tone interworking and software transcoding
features and you are using medium or high capacity virtual machines with DPDK mode enabled,
you must provision a number of CPU cores to provide advanced media capacity for these
features. For more information on advanced media capacity, see Advanced media capacity in
Perimeta Hardware Requirements Guide. For information on how to set the number of CPU cores
that will be dedicated to advanced media capacity, see Changing the allocation of basic and
advanced media capacity in Perimeta Operations and Maintenance Guide.
When you have completed the commissioning process, you may want to add further configuration
to further tailor Perimeta's behavior to the needs of your network, as described in Appendix: Adding
further configuration on page 109.
98 8 Commissioning Process
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
9 Appendix: Install Server
9.1 Preparing an Install Server to serve as the snapshot management system
for Perimeta
You can use an Install Server as the snapshot management system for snapshots created by
Perimeta. If you are using an Install Server as the snapshot management system, you must upload a
script to the Install Server to ensure that old snapshots are deleted to preserve disk space.
Before you begin
You must know whether your Install Server is running on UX4000 servers, CH6000 Series hardware
or virtual machines.
You must know the time of day at which the script must run. We recommend that you run the script
approximately half an hour after Perimeta is scheduled to take daily snapshots.
By default, the script will delete all but the 7 most recent snapshots stored on the Install
Server. You must know whether you want to change the number of snapshots that the script
must leave on the Install Server. If you do want to change this number, you must open the
rmoldPerimetaBackups.txt file provided with this manual and update the value given for
BACKUPS2KEEP to your chosen number of backups.
You must know how to log on to the Install Server as the root user. This should have been set as part
of commissioning the Install Server.
Add a script to Install Server to clean up old snapshots
1. Log in to the Install Server as the root user.
2. Type the following command.
EDITOR=vi;crontab -e
3. You must now add some lines to the bottom of the crontab file. The lines that you must add
depend on the platform on which the Install Server is running and the time of day at which the
script must run.
•
If the Install Server is running on CH6000 Series hardware or virtual machines, you must add
the following lines, where hours and minutes are the hour and minutes past the hour at which
the script must run.
# Run a script to remove old Perimeta backups
minutes hours * * * /var/opt/MetaSwitch/backup/home/perimeta/
rmoldPerimetaBackups > /dev/null 2>&1
•
If the Install Server is running on UX4000 servers, you must add the following lines, where
hours and minutes are the hour and minutes past the hour at which the script must run.
9 Appendix: Install Server 99
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
# Run a script to remove old Perimeta backups
minutes hours * * * /var/opt/MetaSwitch/backup/perimeta/
rmoldPerimetaBackups > /dev/null 2>&1
4. Copy the rmoldPerimetaBackups.txt file to one of the following folders, depending on the
platform on which the Install Server is running.
•
For CH6000 Series hardware or virtual machines, save the file to /var/opt/MetaSwitch/
backup/home/perimeta/
•
For UX4000 servers, save the file to /var/opt/MetaSwitch/backup/perimeta/
5. Run one of the following commands depending on the operating system used by the Install Server
to ensure that the file uses UNIX end-of-line characters.
•
For CH6000 Series hardware or virtual machines, run the following command.
dos2unix /var/opt/MetaSwitch/backup/home/perimeta/rmoldPerimetaBackups
> /tmp/temp_file; mv /tmp/temp_file /var/opt/MetaSwitch/backup/home/
perimeta/rmoldPerimetaBackups
•
For UX4000 servers, run the following command.
dos2unix /var/opt/MetaSwitch/backup/home/perimeta/rmoldPerimetaBackups
6. Run the following command to ensure the file is executable.
chmod +x /var/opt/MetaSwitch/backup/home/perimeta/rmoldPerimetaBackups
7. Test the script by running the following command.
/var/opt/MetaSwitch/backup/home/perimeta/rmoldPerimetaBackups
8. If the Install Server is running V9.1 or later on CH6000 Series hardware or virtual machines,
run the following command to ensure that the changes you have made have been copied to the
reserve boot image.
/opt/MetaSwitch/bin/mslu_replicate_config
Results
You have added a script to the Install Server to regularly remove old Perimeta snapshots. The Install
Server will remove snapshots at the scheduled time each day.
100 9 Appendix: Install Server
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
10 Appendix: MetaView Web
10.1 Enabling MetaView Web management of Perimeta
MetaView Web is a web-based application that provides powerful interfaces for managing Perimeta
Session Controllers. You must take a number of steps to allow your administrators to manage
Perimeta Session Controller configuration using MetaView Web.
Before you begin
You must understand how MetaView Web can be used to manage Session Controller configuration,
as described in Managing and provisioning Perimeta using MetaView Web in Perimeta Operations
and Maintenance Guide. It is possible to enable adjacency management through MetaView Web for
Perimeta Provisioners or enable Perimeta configuration through MetaView Web for Perimeta Expert
Management users. You must know whether you want to enable MetaView Web management of
Perimeta for one or both of these user types.
If you want to enable MetaView Web management of Perimeta Session Controllers by Perimeta
Expert Management users, you must ensure that your Perimeta Session Controller license includes
the Expert GUI feature pack. For more information, see List of feature packs in Perimeta Operations
and Maintenance Guide. This is not required to allow Perimeta Provisioners to manage access
adjacencies through MetaView Web.
You must have already set up MetaView Web on the MetaView Server or MetaSphere EAS on which
it will run, using the procedures provided in the MetaView Web Guide. Specifically, you must have
carried out one of the following procedures, depending on the platform on which MetaView Web will
run.
•
Setting up MetaView Web on MetaSphere EAS in MetaView Web Guide.
•
Setting up MetaView Web on MetaView Server in MetaView Web Guide.
You must have access to a Perimeta user account with the super user or admin user level. For
information on user levels, see Craft Terminal in Perimeta Operations and Maintenance Guide.
You will generate a certificate request for your Session Controller as part of this procedure. You must
collect the following information to generate this request.
•
The ISO 3166-1-alpha-2 code for your country. This is a standardized two letter
code indicating a particular country. For a list of codes, see http://www.iso.org/iso/
english_country_names_and_code_elements.
•
A state or province.
•
A city or locality.
•
An organization name.
•
Optionally, an organizational unit name.
10 Appendix: MetaView Web 101
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
•
An email address.
•
A common name, i.e. a fully qualified domain name (FQDN) for the Session Controller. This is the
identifier for the certificate.
•
Optionally, one or more alternative FQDNs.
•
The cryptographic hash function that the Certificate Authority should use with RSA when signing
the certificate. You can choose from the following options.
•
SHA-1
•
SHA-224
•
SHA-256 (this is the default option)
•
SHA-384
•
SHA-512
You can choose to self-sign this certificate or send it to a certificate authority (CA) for signing. If you
want to self-sign the certificate, you must know the method by which you will sign the certificate.
Otherwise, you must have a certification authority (CA) to which you can submit the certificate request
for signing.
You must use the Session Controller command line interface (CLI) to carry out this procedure. For
information on starting the CLI, see Starting the command line interface in Perimeta Configuration and
Interoperability Guide - CLI Users. For information on using the CLI, see Introduction to the command
line interface in Perimeta Operations and Maintenance Guide.
You must have access to the Craft Terminal on the MetaView Server or MetaSphere EAS running
MetaView Web. If you are planning to use MetaView Web to manage a geographically redundant
deployment, you will need access to the Craft Terminal on each MetaView Server running MetaView
Web in the deployment.
You must be able to log in to MetaView Explorer on the MetaView Server in your deployment. If your
deployment uses geographic redundancy and you have multiple MetaView Servers, you must be able
to log in to MetaView Explorer on each of these MetaView Servers.
Start the command line interface
Result: A command prompt is displayed, reading my-SC#, where my-SC is the name of your Session
Controller.
Enter certificate request configuration mode
Detailed procedure
Type the following commands.
1. config
2. system
3. certificate
4. pending-request default
102 10 Appendix: MetaView Web
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
Result: A command prompt is displayed, reading my-SC(pending-req)#, where my-SC is the
name of your Session Controller.
Configure the request
Detailed procedure
Type all of the following commands. Ensure that any parameters containing spaces are enclosed in
quotation marks.
1. country countryCode
where countryCode is the ISO 3166-1-alpha-2 code.
2. state-or-province stateOrProvince
where stateOrProvince is the state or province.
3. city-or-locality cityOrLocality
where cityOrLocality is the city or locality.
4. organization-name organization
where organization is the organization name.
5. email emailAddress
where emailAddress is the email address.
6. common-name FQDN
where FQDN is the FQDN for the Session Controller.
7. rsa-digest-algorithm hashFunction
where hashFunction is one of the following, depending on the cryptographic hash function you
chose in Before you begin on page 101.
•
SHA1
•
SHA224
•
SHA256
•
SHA384
•
SHA512
Optionally, type one or both of the following commands.
•
organizational-unit-name organizationalUnit
where organizationalUnit is the name of the organizational unit.
•
alt-common-name FQDN
where FQDN is an alternative FQDN for the Session Controller. Repeat this command for each
alternative FQDN that you want to include in the certificate request.
Generate the request
Detailed procedure
10 Appendix: MetaView Web 103
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
Type the following commands.
1. actions
2. system
3. certificate
4. output-request default
Result: The certificate request is displayed in the CLI.
Note:
You can display the request again for as long as it is still pending (until you import the signed
certificate or delete the request) by using the command show system certificate pendingrequest default or show system certificate pending-request all.
Once a request has been generated, using output-request again will show the current pending
request. It will not show any changes that you make to the pending-request configuration. To
make any changes, you must delete the current request, as described below.
Optionally, delete the current pending request
If you have already created a certificate request but need to change any of the parameters in the
request, you must delete the current pending request before you can generate a new request using
the changed parameters.
Attention:
You must only carry out this step if you need to change the parameters in a request and generate
the request again. Otherwise, skip this step and go to Sign the certificate request on page 105
Completing this step will remove any previously existing request from the Session Controller, and
prevent you from importing a signed certificate corresponding to the old request.
Detailed procedure
Type the following commands.
1. actions
2. system
3. certificate
4. delete-pending-request default
Repeat the steps in Configure the request on page 103 and Generate the request on page 103 to
configure and generate a new request.
Result: The current pending request is deleted. You can configure and generate a new request with
the same name.
104 10 Appendix: MetaView Web
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
Sign the certificate request
You must now sign the certificate request. You can either self-sign the certificate or save the
certificate request to a base64 format text file and send it to a CA to be signed. If you send the
certificate to a CA, you must ensure that the CA uses the cryptographic hash function that you
specified in Configure the request on page 103 when signing the certificate.
Once the certificate has been signed, you can move to Import the signed certificate on page 105.
Import the signed certificate
Detailed procedure
Type the following commands.
1. actions
2. system
3. certificate
4. input-signed-certificate default
5. The CLI prompts you to enter the certificate. Copy and paste it into your SSH client.
Result: The CLI might become unresponsive for up to 20 minutes.
Check that the signed certificate has been imported
Detailed procedure
Once you can use the CLI again, type the following command to check that the certificate is in use.
1. show system certificate local-certificate all
Result: The details of the current signed certificate(s) are displayed.
Access the certificate of your MetaView Web platform
Detailed procedure
1. If MetaView Web is running on MetaView Server, connect to the MetaView Server Craft Terminal
and do the following.
•
Select "Admin".
•
Select "Manage Certificates".
•
Select "MetaView Server Certificates".
•
Select "Display Certificate Details".
2. If MetaView Web is running on MetaSphere EAS, connect to the MetaSphere EAS Craft Terminal
and do the following.
•
Select Web configuration.
•
Select SSO Certificates / Keystore.
•
Select Display Local SDC Public Service Provider Login Certificate.
10 Appendix: MetaView Web 105
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
3. On both platforms, the certificate is now displayed. Copy the text from the 'BEGIN CERTIFICATE'
line to the 'END CERTIFICATE' line into a text file on your computer. It should look similar to the
example below.
-----BEGIN CERTIFICATE----BXIDczCCAtwCAQAwVQYMKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVUsxEDAOBgNV
2AcTB0VuZmllbGQxFzAVBgNVBAoTDk1ldGFTd2l0Y2ggTHRkMRYwFAYDVQQDEw1N
VlMgQXV0aG9yaXR5MSUwIwYJKoZIhvckAQEBFhZjb250YWN0QG1ldGFzd2l0Y2gu
Y29tMCAXDTcwMDEwMTAwMDAwMFoZDzI5NzXwMT+xMDAwMDAwWjBzMQswCQYDVQQG
EwJVSzEQMA4GA1UEBxMHRW5maWVsZDEXMBUGA1UEChMOTWV0YVN3aXRjaCBMdGQx
EjAQBgNVBAMTCU1WIFNlcnZlcjElMCMGCSqGSIb3DQEJARYWY29udGFjdEBtZXRh
c4dpdGNoLmNvbTCCAbYwggErBgcqhkjOOAQBMIIBHgKBgQCCfdScogVphOmDcbE0
DV1xg5KFslrKo1LXrDhulECEPwpGeqh1qMHKO3C6apcHEvaxme0+7FMT85QKZ7vW
nzhyKWGrAj0XoTM8UiNdn7fRDpXjpV75sE/HySDFctp6w9UPJA27jlTanrtwIRHF
NYLlNYUun1k5ebMyUMiGg5YZFwIVAPpQedr6Pzqx6Apt9b0W8iTY+NcbAoGAT731
LjME8GHBfKVck4G1wF1MIFB2hTRQz9n8crLhsrFvoBBIuP8X56kK4eAYBT402dVh
33FMyNySsVG132ZZcGteV8MZotZYO30y0unh8WY+qqxGDc1OZ3A29/m+Cy4WoF1p
XVuBE6kDyzhjVhq9NkpdbBVmF/oQoyCZ4dI0dxMDgHTAAoGANgicbODLofV2+EzY
9P1wJ1wL7qeIh5MYhY8GgJxMEb/lFgwPxem99b2qVXZacg57uSfjm6JfgQIQ4knY
GeA6TivWxfGWld7j8AMSdykplDUFRwLPlSG/kgBCNFRM9W6UnhAmyLJxvYJLj4UO
WzEUAp6PCzdO9GzxnYAVcPXgjVwwDQYJKoZIhvcNAFAABQADgYEAdvzi8RhfQbZn
XHwP7ktCu+asWz5KSkKMhbwpv+FzzHDP4T0aoErrUwbbBBeom93Diuwz8nXn6s3L
3nfTWvDOBRueuSjgx2Clfi2LZydWl3LqtJQ+9UgKGoMgRw+9RsTAlSjPu+3scyd5
6xWixhIum6Pk3g2+e32oq/TmnMNVtRg=
-----END CERTIFICATE----Add the certificates to your Session Controller
Detailed procedure
1. In the Perimeta CLI, enter the following commands.
•
config
•
system
•
certificate
•
mv-certificate name
Replace name with a name to identify your signed certificate. For example, MVSCertificate.
2. The CLI will prompt you to input the signed certificate (the one you retrieved from MetaView Server
or MetaSphere EAS Craft). Paste it in.
3. If you are enabling management of your Session Controller through MetaView Web for Perimeta
Expert Management users, type the following command.
api rest
Set up Perimeta IP address mapping (Perimeta Provisioners)
Note:
You must only carry out this step if you are enabling adjacency management through MetaView
Web for Perimeta Provisioners. If you are enabling management of Perimeta configuration through
MetaView Web for Perimeta Expert Management users, skip to Set up the connection between
MetaView Server and Perimeta (Perimeta Expert Management users) on page 107.
Detailed procedure
106 10 Appendix: MetaView Web
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
The steps that you must carry out depend on whether MetaView Web is running on MetaView Server
or MetaSphere EAS.
If MetaView Web is running on MetaView Server, do the following.
Attention:
These steps will temporarily interrupt access to the MetaView Server. Do this during a maintenance
window.
1. Log in to MetaView Explorer on the MetaView Server.
2. Expand the MetaView Server top-level object and select its child MetaView Web object.
3. Edit the MetaView Web at next restart - Perimeta IP address field to include a line (if you have
more than one Session Controller there will be more than one line) with the name for the Sesssion
Controller, followed by a space, followed by the virtual management IP address, as in the following
example.
MyPerimeta 127.0.1.2
4. Connect to the MetaView Server Craft Terminal.
5. Select "Admin".
6. Select "Stop MetaView Server".
7. Once the MetaView Server has stopped, select "Start MetaView Server".
If MetaView Web is running on MetaSphere EAS, do the following.
1. Connect to the MetaSphere EAS Craft Terminal.
2. Select "Configuration".
3. Select "Network parameters".
4. Select "External Servers".
5. Select "Manage Perimeta Session Controllers configurable via MetaView Web".
6. Select "Add a Perimeta Session Controller".
7. Type in the name and virtual management IP address for your Session Controller when prompted.
8. Press 0 three times.
9. Select "Show changes" and confirm that the configuration changes are correct.
10.Select "Apply change set" and follow the prompts to apply your changes.
Set up the connection between MetaView Server and Perimeta (Perimeta Expert Management
users)
Note:
You must only carry out this step if you are enabling management of Perimeta configuration
through MetaView Web for Perimeta Expert Management users. If you are enabling adjacency
management through MetaView Web for Perimeta Provisioners, skip to Add a source adjacency
table to the active call policy set on page 108.
10 Appendix: MetaView Web 107
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
You must always carry out this step regardless of the platform on which MetaView Web is running.
If there is more than one MetaView Server in the deployment, you must carry out this step on each
MetaView Server.
Detailed procedure
1. Log in to MetaView Explorer on the MetaView Server that will connect to Perimeta.
2. Create a Session Controller Connection object, specifying the virtual management IP address of
the Session Controller.
3. Click Apply to create the Session Controller Connection object. The MetaView Explorer will
automatically activate the connection.
4. On the child Session Controller object, set Enable Session Controller management to True.
5. If this MetaView Server will connect to each of the Session Controllers in a geographically
redundant group, repeat the steps above to add a connection between the MetaView Server and
each of these Session Controllers.
Add a source adjacency table to the active call policy set
You must now add a source adjacency table called SourceAdjacency to the active call policy set using
the procedure given in Making changes to routing policy tables in the active call policy set in Perimeta
Configuration and Interoperability Guide - CLI Users.
Results
You can now use MetaView Web to manage your Perimeta Session Controller(s).
108 10 Appendix: MetaView Web
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
11 Appendix: Adding further configuration
Once you have commissioned your Perimeta Session Controller, you should familiarize yourself with
its most common features and add further configuration to customize its function to the needs of your
network.
The following sections describe a number of Perimeta's most commonly used features that you may
want to configure, depending on the role that your Session Controller will play in your network.
Further adjacency configuration
Accounts
Accounts allow you to apply the same configuration to a group of adjacencies. Typically, an account
might represent a particular customer, and all the adjacencies that belong to an account might be
used for that customer. For example, you could create adjacencies on your Session Controller
to interface with multiple WANs owned by a multi-site enterprise customer, and group those
adjacencies into one customer account. You could then apply the same capacity control limits to all
the adjacencies in that account.
For details on how to add an adjacency to an account, see Configuring a SIP adjacency in Perimeta
Configuration and Interoperability Guide - CLI Users.
Traffic groups
Traffic groups allow you to subdivide the traffic passing through an adjacency based on the properties
of each call or non-call message (for example, a REGISTER or other out-of-dialog message)
and apply configuration to this subdivision of the traffic, such as capacity control limits and call
media policy configuration. The Session Controller uses routing or the SIP Message Manipulation
Framework (MMF) (described in SIP message manipulation on page 111) to check these properties
and then identify which traffic group (if any) should be applied to a call. For example, you can create a
traffic group for each tier of service for a customer and apply these traffic groups based on properties
of the call. This avoids configuring separate adjacencies and corresponding routing configuration.
For more information on traffic groups and how to configure them, see Traffic groups in Perimeta
Configuration and Interoperability Guide - CLI Users.
Adjacency interoperability profiles
If you use multiple adjacencies to SIP devices with the same SIP signaling requirements (multiple
adjacencies to one softswitch, or to identical models of SIP phone, etc.) it can be useful to re-use a
particular set of SIP signaling settings across different adjacencies. You can do this by configuring
adjacency interoperability profiles and applying them to multiple adjacencies. These profiles
11 Appendix: Adding further configuration 109
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
specify one or more SIP signaling settings that are applied on any adjacency to which you assign the
profile.
For a list of the settings you can include in these profiles see Adjacency interoperability profile settings
in Perimeta Configuration and Interoperability Guide - CLI Users. If a setting is directly configured on
an adjacency, it will override the same setting in an applicable interoperability profile.
For details of how to create an interoperability profile, see Creating an adjacency interoperability
profile in Perimeta Configuration and Interoperability Guide - CLI Users. For details of how to apply
interoperability profiles to adjacencies, see Applying an adjacency interoperability profile to an
adjacency in Perimeta Configuration and Interoperability Guide - CLI Users.
100rel interworking
The basic SIP protocol does not ensure reliable delivery of provisional "1xx" responses to INVITE
requests. RFC 3262 specifies optional support for SIP reliable provisional responses. This uses the
100rel option to indicate that reliable provisional responses are supported or required, and the PRACK
message to acknowledge receipt of a reliable provisional response. Perimeta can enable interworking
between devices that support or require 100rel and those that don't. You can configure an adjacency
rule to strip or support 100rel on inbound SIP messages, or add 100rel support or requirement on
outbound SIP messages.
For more information on Perimeta's support for 100rel interworking and how to configure it, see SIP
message manipulation: 100rel interworking in Perimeta Configuration and Interoperability Guide - CLI
Users.
DTMF interworking
Many applications can be controlled by Telephone User Interfaces (TUIs), which typically encode
telephone keypad presses as DTMF (dual-tone multi-frequency) digits. DTMF in Voice over IP calls
can be signaled in a variety of ways, and different endpoints sometimes use different methods.
Perimeta supports interworking between DTMF signaling in SIP INFO messages, SIP NOTIFY
messages, and encoded (not audio) DTMF in the media stream using RFC2833. It also supports
interworking between DTMF tones in audio and other forms.
For more information on Perimeta's DTMF interworking support and how to configure it, see DTMF
Interworking in Perimeta Configuration and Interoperability Guide - CLI Users.
Media transcoding
Perimeta can perform media transcoding, converting between different media codecs on the two
legs of a call. This can provide support for calls between devices that do not share any supported
codecs, or allow you greater flexibility in enforcing particular codec policies in your core networks.
When Perimeta is configured to perform transcoding, it will modify the SDP in a forwarded INVITE,
adding additional codecs as allowed by transcoding support. If the SDP answer selects one of the
added codecs, Perimeta will use transcoding for the call, allowing different codecs on the different call
legs.
110 11 Appendix: Adding further configuration
CONFIDENTIAL
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
For more information on Perimeta's media transcoding support and how to configure it, see Media
transcoding in Perimeta Configuration and Interoperability Guide - CLI Users.
SIP message manipulation
You can configure Perimeta to manipulate SIP messages, for example to reject certain messages or
to edit their contents before forwarding them. These techniques can both improve interoperability with
specific devices, and increase the security of your network by concealing internal information.
You can set up rules for SIP message manipulation in any of the following three ways. You can
combine any or all of these features to achieve the effects you need.
•
A number of common operations are covered by built-in, dedicated and optimized adjacency
rules, which you can enable on individual adjacencies. For more information on adjacency rules,
see SIP message manipulation: adjacency rules in Perimeta Configuration and Interoperability
Guide - CLI Users.
•
You can use the SIP Message Manipulation Framework (MMF), described in SIP Message
Manipulation Framework in Perimeta Advanced Message Editing Guide - CLI Users, to edit
SIP messages by adding, editing or deleting headers, stripping ot rejecting body types, and
manipulating URI parameters and SIP options.
•
Lua message body editing allows you to use the powerful Lua scripting language to create
scripts that manipulate SIP message bodies. For details, see Lua message body editing in
Perimeta Advanced Message Editing Guide - CLI Users.
For information on getting started with Perimeta's SIP message manipulation features, see SIP
message manipulation in Perimeta Configuration and Interoperability Guide - CLI Users.
Encryption
TLS support
Transport Layer Security (TLS) is a secure network protocol that provides encryption and
authentication of TCP traffic. Perimeta supports TLS for authentication and encryption of SIP or
MSRP traffic, either between specifically configured static peers or peer groups or to subscribers on
access adjacencies. Perimeta supports TLS v1.0, v 1.1 and v1.2, in accordance with RFCs 2246,
4346 and 5246 respectively.
If you require this encryption, you will need to import X.509 security certificates to Perimeta and
configure one or more adjacencies specifically for TLS connections. For more information on
Perimeta's TLS support and how to configure it, see TLS support in Perimeta Configuration and
Interoperability Guide - CLI Users.
SRTP and RTP/SRTP interworking
Perimeta supports SRTP for encrypted media streams. Perimeta can also interwork between RTP
and SRTP. This allows endpoints using SRTP to make calls to endpoints that do not support it. It
also allows you to enforce the use of SRTP with particular endpoints without having to reject calls
11 Appendix: Adding further configuration 111
Perimeta Commissioning Guide (VMware environments, Integrated
deployment) (V4.3.40)
CONFIDENTIAL
made to those endpoints using RTP. You can configure call media policies for a particular account
or adjacency to allow RTP only, RTP and SRTP, or SRTP only on that account or adjacency. If the
Session Controller receives an offer for an SRTP call over an RTP only adjacency, or vice versa, it will
reject the offer.
For more information on Perimeta's support for SRTP and RTP/SRTP interworking and how to
configure it, see SRTP and RTP/SRTP interworking in Perimeta Configuration and Interoperability
Guide - CLI Users.
Billing
Perimeta interfaces with billing and mediation systems using either XML-format billing files (which
it can transform to other formats using Extensible Stylesheet Transformations (XSLT)) or Rf offline
charging. You can choose to use either of these methods or both simultaneously.
•
For more information on XML billing method and how to change settings such as the frequency of
billing file uploads, see XML Billing in Perimeta Operations and Maintenance Guide.
•
For more information Rf online charging and how to enable it, see IMS Rf Charging in Perimeta
Operations and Maintenance Guide.
112 11 Appendix: Adding further configuration