AOS12 3 1 - Release Notes - v1r2

Software
Release Notes AOS v12.3.1

Revision 01.2 Release Notes
P/N D211113
This document details new features, known issues and clarifications concerning Allot
Operating System software version AOS12.3.1
Some of the features described in these Release Notes require a specific license.
Please check http://www.allot.com/support.html for any updates to this document.
This document contains Proprietary Trade Secrets of Allot Communications LTD and its
receipt or possession does not convey any right to reproduce, disclose its contents or to
manufacture, use or sell anything that it may describe.
Allot reserves the right to make changes, add, remove or change the schedule of any
element of this document.
Allot Operating System v12.3.1 Release Notes
Contents
1 Platform and Software Management ................................................................................. 4
1.1 Software Version Compatibility .......................................................................... 4
1.2 Protocols and Applications................................................................................... 4
1.3 Performance and Sizing ....................................................................................... 6
2 Enhancements ................................................................................................................... 6
2.1 New Features in AOS12.3 .................................................................................... 6
2.1.1 Tethering Detection ...................................................................................... 6
2.1.2 Inline DHCP Gleaning .................................................................................. 8
2.1.3 Increased number of Policy Elements........................................................... 9
2.1.4 Secure Data Enrichment in HTTP redirect ................................................... 9
2.1.5 HTTP Redirect to HTTPS ............................................................................. 9
2.1.6 IPv6 support .................................................................................................. 9
2.1.7 IPv6 Support in Steering to Value Added Services .................................... 12
2.1.8 DPI Improvements ...................................................................................... 13
2.1.9 Predictive DPI / Layer7 Traffic Steering from the First Packet ................. 13
2.1.10 Troubleshooting Improvements .................................................................. 14
2.1.11 Extended SNMP With Device Level Byte and Packet Count .................... 15
2.1.12 O&M improvements ................................................................................... 15
2.1.13 Support for Additional Features Added in SMP/NX12.3 ........................... 15
2.2 New Features in AOS12.2 .................................................................................. 15
2.2.1 Selective Bypass by VLAN Group ............................................................. 15
2.2.2 DPI capabilities – further inspection capability of SIP traffic .................... 16
2.2.3 Support for Additional Features Added in SMP/NX12.2 ........................... 16
2.3 New Features in AOS12.1 .................................................................................. 17
2.3.1 Real Time Usage Monitoring...................................................................... 17
2.3.2 Monitoring rules.......................................................................................... 18
2.3.3 Steering Enhancements ............................................................................... 18
2.3.4 VoIP minutes of use reporting .................................................................... 18
2.3.5 Embedded Service Protector Sensor ........................................................... 19
2.3.6 Teredo Tunneling ........................................................................................ 19
2.3.7 Raw HTTP Handling .................................................................................. 19
3 Resolved Issues .............................................................................................................. 20
3.1 Resolved in 12.3 ................................................................................................. 20
3.2 Resolved in 12.2 ................................................................................................. 23
© 2012 Allot Communications. All rights reserved. 2

3.3 Resolved in 12.1 ................................................................................................. 25

4 Known Issues .................................................................................................................. 26
5 Software Upgrade ............................................................................................................ 34
5.1 Accessing the Software ...................................................................................... 34

1 Platform and Software Management

1.1 Software Version Compatibility
AOS12.3.1 is available for AC-500, AC-1400 and AC-3000 products only. AOS12.3.0 is available
for SG-Sigma and SG-Sigma E only.
The table below presents the cross-compatibility between version 12.3 of the NX, AOS and SMP
software. In order to enable all of the new capabilities of this product it is recommended to install
12.3 on all of these components.
NX 12.3.0 AOS 12.3.1 SMP 12.3.0

NX - NX 12.3.0 NX 12.3.0
AOS AOS 11.1.X - AOS 12.0.X
AOS 12.0.X AOS 12.1.X
AOS 12.1.X AOS 12.2.X
AOS 12.2.X AOS 12.3.0
AOS 12.3.0 AOS12.3.1
AOS 12.3.1
SMP SMP 11.X.X SMP 12.3.0 -
SMP 12.1.X
SMP 12.2.X
SMP 12.3.0
Table 1 Version Cross-Compatibility
NOTE SMP 12.3 is considered limited availability for upgrade. If required please contact
Allot Customer Support.
A new license key is required when upgrading your AOS software version.
Please make sure you have a valid license for the AOS version you are installing
before starting the upgrade. However, Allot strongly recommends that after
upgrading, you retain the previous license key in a safe place in case you must
rollback to the previous version.
For more information about Allot license keys, see

https://c.eu1.visual.force.com/apex/KB?KBID=12681253
1.2 Protocols and Applications

AOS12.3.1 supports Allot Protocol Update package version 3.19 and above.
For a complete list of the supported protocols and applications and for details on upgrading your
protocols identification with the recent protocol pack, login into www.allot.com/support and point
your browser to the link below:
https://c.eu1.visual.force.com/apex/KB?KBID=11895137

In this location, you will also find the latest release notes for the protocol pack and its
predecessors, containing detailed information about the supported applications, as well as
information on resolved and known issues..

1.3 Performance and Sizing
Parameter AC-500 AC-1400 AC-3000

Lines 512 512 512
Active Pipes 4,096 40,000 40,000
Active VCs 32,768 80,000 80,000
Connections 256,000 2M 2M
Subscriber Updates 100 200 200
(START/STOP)
Registered Subscribers IPs 20,000 160,000 160,000
Active Subscribers 20,000 80,000 80,000
Monitoring Rules 120,000 320,000 320,000
2 Enhancements
2.1 New Features in AOS12.3
This section documents those AOS features which were first introduced in AOS12.3 and are
included in all subsequent versions.
2.1.1 Tethering Detection

Tethering Overview
Tethering is the method used to share the Internet connection of an Internet-
capable mobile phone. This sharing can be via a cable or wirelessly over
Bluetooth or Wi-Fi. If Wi-Fi is used, the tethering feature is often branded as a mobile
hotspot and can typically service several devices.
Figure 1: Tethering Example

Mobile operators may perform different charging schemes for tethering. Network level
identification, reporting and enforcement of tethering blocking are therefore important.

Data usage analysis of tethering devices is required by marketing departments in order to

define packages and prices for such offerings.
Allot Tethering Support
This tethering detection is used within the classification models to allow:
 Traffic classification to a policy element according to a tethering condition
 Usage monitoring of tethered traffic in the Gx interface
 Usage monitoring of tethered traffic in the Gy interface
 Usage monitoring of tethered traffic in CDRs (Gz interface)
 Creation of tethering use reports based on tethering policy definitions
The Policy editor is now enriched with options to classify traffic based on tethering or a
combination of tethering and a specific application services:
Figure 2: Tethering Support in NX Enforcement Policy Editor
Tethering Detection
The method of using a user-agent to identify laptop tethering with a smart phone (as
employed by some DPI vendors) is not considered resistant to fraud. Allot’s tethering
detection support is based on layer 3 IP characteristics, also known as OS fingerprinting
and is much more resilient.
The following matrix presents the test results for the “OS fingerprinting” method
(employed by Allot). The left column (“Tethering”) presents the operating system of the
mobile device used for tethering. The upper heading (“Tethered”) presents the operating
system or the tethered device (Windows, MAC or another Smartphone).
Tethered Windows MAC OS iOS Android WinPhone BlackBerry Symbian
Tethering
iOS Full Full Full Full Full Full Full

Android Full Full Full Full Full Full Full
BlackBerry Partial Full Full Full Partial Partial Full
WinPhone Partial Full Full Full Partial Partial Full
Symbian Full Full Full Full Full Full Partial
Table 2: Supported Operating Systems

Note: The results presented above are based on lab testing as well as live network trials.
As different networks may behave differently, customizations may be needed.

2.1.2 Inline DHCP Gleaning

Subscriber management solutions are increasingly visible in fixed network service
providers and MSOs, and these solutions bring many of their own challenges along.
DHCP-based IP allocation networks use subscriber-aware DHCP Relay Agents which
insert subscriber ID (or circuit ID in option 82) into intercepted IP requests. The requests
are then relayed to the DHCP server, inline (within the data plane).
From release 12.3, the in-line platform is able to capture, parse and deliver these DHCP
requests from the device to the SMP to enable subscriber management (retrieval of each
subscriber’s ID and his IP address). Allot’s fixed-line solutions now provide full support
for both in-line (in-band) as well as out-of-band DHCP gleaning.
The figure below depicts a Cable-based example of such a flow:
Cable Modem Configuration DHCP
DHCP
DHCP DHCP + Option 82
Relay
Agent
DHCP SG
VOIP
Internet
CM CMTS
DHCP + Opt 82 (copy)
PC/Router
MGMT
Network
SMP
Figure 3: In-Line DHCP Gleaning in a Cable Environment
The type of DHCP messages parsed by the gleaner is configurable. The user can select
one or more of the following options:
1. Parse All DHCP ACK messages (with or without OPTION 82)
2. Parse Only DHCP ACK messages with OPTION 82
3. Parse Only DHCP ACK messages without OPTION 82 – DHCPACK is message
type 5 (type defined in DHCP OPTION 53)
Performance:
Each DHCP gleaner (embedded in the SMP server) is able to parse 1000 DHCP messages
per second, for up to 10 in-line platforms per Gleaner
Each Core Controller is able to send/mirror 100 DHCP messages/second to gleaners.
Note: DHCP in-band gleaning is supported only in the SG-Sigma E platform.

2.1.3 Increased number of Policy Elements

The number of Line policy elements was doubled in all AOS platforms from 256 to 512.
2.1.4 Secure Data Enrichment in HTTP redirect

AOS supports redirection of HTTP traffic to a captive portal. This redirect URL can be
enriched with further data such as the user ID and original URI path. The user ID can
then be used by the portal to authenticate the user.
In version 12.3 this enriched data can be encrypted in order to prevent fraud and protect
customer privacy. The encryption passphrase can be set by the user through the
NetXplorer GUI.
2.1.5 HTTP Redirect to HTTPS

When redirecting traffic to a captive portal, redirection to an HTTPS URL is now
supported.
2.1.6 IPv6 support

While IPv6 support is increasingly required in today’s evolving networks, there is no
doubt that IPv4 will continue to exist for a long time while migration to IPv6 gradually
takes place. This means we are going to see the co-existence of IPv4 and IPv6 traffic in
most deployments.
Support of IPv6 in Allot systems requires software versions to be updated across all
system elements: In-line platforms (NetEnforcer or Service Gateways), SMP, NetXplorer
and Data Collectors. It also imposes changes on the system’s interfaces to external
elements in the network, e.g. PCRF/Gx, RADIUS or value added services connected via
steering.
Figure 4: Co-existance of IPv4 and IPv6 Networks
IPv6/IPv4 Dual Stack Support

If IPv4 is going to stay for the long-term and is required to coexist with IPv6, there will
still remain a need to support IPv4 subscribers and maintain communication with IPv4
servers.
“Dual Stack” is the classic way for IPv4 and IPv6 to co-exist. It simply means support for
both IPv4 and IPv6 at the same time. Dual stack hosts select which IP to use based on
application. For example: for web browsing, the destination is selected based on a DNS
query.
Dual stack subscribers with IPv4 and IPv6 addresses (at the same time) are managed by
Allot as a single subscriber with a unified QoS.

The table below describes the IPv6 support in all the different areas of the Allot solution.
Solution Area IPv6 Support in Allot Solution
1 Subscriber Data  Single IPv4 per APN *
Plane (QoS,  Single IPv6 per APN *
Reporting & Usage  Single IPv6 + IPv4 addresses per APN (IPv4v6 APN) *
Monitoring)
2 Identification  Protocol Identification capability for IPv6 Traffic
(application and  Protocol Identification capability for IPv4 and IPv6 Mixed
protocol traffic
recognition)
L7 protocol signature will not indicate whether the L3 protocol
used was IPv6 or IPv4. i.e. HTTP over IPv4 and HTTP over
IPv6 will both appear as HTTP)
3 Classification  Services Entry (Applications & Protocols)
(condition  Time Catalogue for IPv6 Traffic
catalogs)  classification based on IPv6 Traffic Class (ToS)
 IPv6 prefixes for dynamic host groups (service plans for
subscriber management)
4 Subscriber to IP  When User Equipment is assigned an IPv4 Only address*
Mapping (SMP)  When User Equipment is assigned an IPv6 Only interface
address (to be appended to a defined network prefix). A
user can be identified as prefix that can be /48 /56 or /64*
 When User Equipment is assigned an IPv4 and IPv6
addresses (uncorrelated) *
5 RADIUS Interface  Supports IPv6 Radius (RFC 3162) protocol with no change
(SMP) of functionality compared to how IPv4 Radius messages
are handled
6 PCRF Triggers  Service Plans based on PCRF Gx message (CCAi)
(SMP as PCEF)  Change of Service Plans based on PCRF triggers (RAR)
7 Integrated Services  HTTP Redirection to Captive Portal with IPv6 Traffic
 WebSafe (URL Filtering) with IPv6 Traffic
8 Traffic Statistics  Per Policy Element Statistics (Short Term & Long Term)
with IPv4 and IPv6 mixed traffic*
 Conversations Elements Statistics (Short Term & Long
Term) with IPv4 and IPv6 mixed traffic
 Most Active URL statistics with IPv4 and IPv6 mixed
traffic
9 Northbound API  Gx IPv6 specific AVP with no change of functionality
compared to how Gx messages are handled with IPv4
fields


 The above refers to data plane only. All communication with PCRF (control
plane) can manage all APN types (IPv4 only, IPv6 Only, IPv4v6)
2.1.7 IPv6 Support in Steering to Value Added Services

Steering is a set of functionalities which enables service deployment / enrichment on
traffic flowing through the in-line platform. Such services may be an Allot service
solution or a third party solution (e.g. video optimization platform).
In previous versions steering was supported only for IPv4 traffic. From AOS12.3 dual-
stack (IPv6, IPv4) steering is supported. The in-line platform will redirect IPv6 traffic to
a proxy based service only if this service interface has IPv6 support enabled (e.g. srv2
below). If the service is not supporting IPv6, such traffic will be redirect to the next hop,
while IPv4 traffic will continue to be steered to this service (e.g. srv1 below)
Figure 5: IPv6 Steering

Any proxy-based server that supports IPv6 could have an additional logical interface
including the definition of VLAN ID, MAC and IP. In the case of dual-stack interfaces
the VLAN and MAC could be shared for both IPv4 and IPv6 logical interfaces.
The in-line platform supports default gateway mapping of both IPv4 and IPv6 addresses.
NOTE: It is assumed that the server will have two IP interfaces: one for IPv4 and
one for IPv6. For switch connectivity these can be on the same physical

I/F or two physical interfaces, for directly connected servers these should
be on the same physical interface.
Interfaces can share the same VLAN or have separate VLANs. Health
checks will be performed only with the servers’ IPv4 interface. If the
service is activated as IPv4 /IPv6 capable, there will be only one unique
and common load balancing pool of servers. This means that IPv4 and
IPv6 flows will be sent to servers using load balancing methods and
therefore it is necessary for the same server part of the pool to be able to
handle both protocols.
2.1.8 DPI Improvements

The identification enhancements described below require both an AOS update (to
AOS12.3) and a protocol pack update (to PP3.19).
CDN traffic identification enhancement
The DPI engine was improved to support identification of CDN traffic data by correlating
it to the CDN control traffic identification. This is applicable for the identification of
Rhapsody music service.
Cloud services identification enhancement
Specific cloud services are now better identified. This is achieved by correlating the data
channel to the control. This will for example enable the distinction between Apple’s
iCloud, from the Amazon cloud or Microsoft’s Azure which constitutes the enabling
infrastructure.
2.1.9 Predictive DPI / Layer7 Traffic Steering from the First Packet
Predictive DPI was designed with two specific scenarios in mind. The first involves
redirecting HTTP Video for optimization or caching, while the second is used to ensure
that certain HTTP File Sharing protocols are excluded from redirection. In the case of
some proxy-based services (such as video Optimization and caching), the steering must
be from the first packet. Since usually a first packet is a TCP syn that cannot be
associated to any specific application using traditional DPI techniques, new methods are
required.
While other DPI vendors overcome this obstacle by implementing a broad classification
of steering all HTTP (port 80) traffic, Allot took a different approach in order to perform
optimal filtering of irrelevant connections and provide a cost-efficient solution. This
method, while not as accurate as traditional DPI, provides significant value in granular
filtering of video-only traffic as opposed to port-based steering. In addition, for a video
optimization service, the cost of a small percentage of false negative/positive results is
negligible.

Figure 6: PDPI Detection Flow
Allot’s Predictive DPI feature, enables the user to manually flag certain services
(protocols) for the system to study in order to predict when they are being employed, thus
ensuring that traffic using such services can be steered based service from the very first
packet.
In order to do this, all available data about a selected service is analyzed, including
Allot’s extensive library of protocol knowledge together with a history of previous
connections and a list of the active hosts serving this protocol, so that a NetEnforcer or
Service Gateway can predict when this service is being used in new sessions based on
that service’s recorded behavior.
This means that new sessions to the server will be identified and matched to the
corresponding service from the first packet of the session, i.e. from the initial TCP SYN
packet. This allows only the desired traffic to be sent to the proxy.
After several packets of the session are seen by the NetEnforcer/Service Gateway, if the
system makes a more accurate identification, the traffic is then reclassified and matched
to the correct service.
While the mechanism is designed for support of additional use cases and protocols, no
others have been tested at this stage.
2.1.10 Troubleshooting Improvements

When a recovery “rescue” operation takes place an SNMP alarm is issued. This alarm
will now include more details as to the reason for the failure that initiated the recovery
state.

2.1.11 Extended SNMP With Device Level Byte and Packet Count
Until now, Allot’s SNMP MIB enabled an in-line platform to be polled for information
per port. This information however was not aggregated per platform.The AOS SNMP
ifTable and related tables have now been enhanced to include a new row: a logical
interface representing an aggregate of all network ports. The new logical interface is
represented in the MIB as follows:
 All Counter32 and Counter64 columns in ifTable, ifXTable and alIfXTable
(including the newly added alIfXHCInTotalPkts and alIfXHCOutTotalPkts) were
populated with the corresponding sum of all network ports, i.e. all rows whose
alIfXType is internal(1) or external(2).
 Additional columns populated. See details in MIB document.
2.1.12 O&M improvements

 The “acmon” CLI command used to provide information only on network ports.
Now it shows all ports.
 The license key status is now printed to the screen during system install
 In case an in-line platform enters rescue mode, more accurate details in the system
alarm are now provided
2.1.13 Support for Additional Features Added in SMP/NX12.3

In addition to the above, the following new capabilities were added in SMP and
NetXplorer 12.3:
 Turbo Boost. An option to increase the subscriber bandwidth for a limited time is
now supported in SMP when working as a “subscriber manager”
 SMP Availability Improved. This was improved by adding support for
additional interface connectivity
 Separate Control Interfaces. It is now possible to separate the interfaces on the
SMP server between management and control (Diameter) interfaces

This section documents those AOS features which were first introduced in AOS12.2 and
are included in all subsequent versions.
2.2.1 Selective Bypass by VLAN Group

In certain cases, there may be no need to apply Allot’s actionable recognition technology
on all of the network traffic. Moreover an operator may wish to ensure that specific
traffic bypasses Allot’s DPI elements in order to reduce the computational load on the
system.
The meaning of “bypassing Allot’s DPI elements” is that traffic is forwarded through the
in-line platform without any processing. Until now, the “bypass” connection control

capability was used to achieve this aim, but in doing so, system resources were still
utilized (i.e: virtual channel, connection etc.)
This new capability performs selective bypass with minimal impact on Service Gateway
resources and performance. Configuration is performed independent of the policy so as
not to utilize policy elements. Traffic matching a predefined group of VLAN tags
bypasses the DPI elements of the system and hence does not utilize policy elements
resources or DPI resources that impact the Connection Establishment Rate (CER). Note
that forwarding resources, reflected in packet per second parameter (which affects
bandwidth) are still affected by bypassed traffic.
2.2.2 DPI capabilities – further inspection capability of SIP traffic

A new capability was added to the DPI engine software to allow for further inspection of
SIP traffic. This capability allows an easy addition of DPI signatures for specific
providers of VoIP using SIP. By adding this capability to the AOS, such new signatures
can now be added using simple protocol pack without further upgrade to the AOS.
Net2Phone VoIP traffic can now be supported from Protocol Pack 3.18.
2.2.3 Support for Additional Features Added in SMP/NX12.2

NX12.1 and SMP12.1 include several key new features which required the AOS software
to be adapted to enable their support. These features, which are fully described in the
NX/SMP12.2 Release Notes, are outlined briefly here:
 Mobile Analytics - Device Awareness Reports. Mobile Analytics allows a
mobile operator to gain further insight into the effect different devices have on his
network, including the effect on signaling load, congestion load etc. This
information can support both marketing and operational decision making. In
version 12.2 a set of new analytics was added to the NetXplorer designated for
mobile networks. These new reports include information regarding mobile
devices, active subscribers, session duration and more. 1
 Analytics Statistics Export. The export of analytics statistics allows carriers to
extract information based on Allot’s Dynamic Actionable Recognition
Technology (DART), and combine it with their databases and business
intelligence systems. These raw statistics are exported to Session Data Records in
CSV format. The following record types can be exported:
 Session Detail Records (SDR): Active subscriber’s Session metadata (IP,
session ID, GGSN IP, SGSN IP, Cell ID, etc.)
 Session Usage Data Records (SUD): Active subscriber’s Session metered
information
 VC Statistics Records: Active subscriber metered volume per VC (often
representing one or many application/s)
 Conversation Statistics Records: Global volume per service, per
subscribers.
1
Mobile analytics is a licensed add-on feature


This section documents those AOS features which were first introduced in AOS12.1 and
are included in all subsequent versions.
2.3.1 Real Time Usage Monitoring

AOS12.1, in conjunction with SMP 12.1, has revised the volume reporting granularity
from 5 minutes intervals to real time. In older versions, the volume data was delivered
from the in-line platform to the SMP in 5 minutes intervals. Volume was calculated and
compared to the requested volume thresholds in the SMP and then reported to
northbound applications such as the PCRF and OCS.
The new architecture is described below:
(1) At initial CCRi/CCAi, the PCRF returns a policy asking to report when a certain
threshold is reached
(2) The SMP provisions the in-line platform with volume reporting and threshold
(3) The in-line platform counts usage and compares it to the thresholds set by the SMP in
real-time.

(4) The in-line platform reports only once the volume threshold has been crossed or at
pre-defined reporting points (e.g: end of session)
(5) The SMP notifies the PCRF. The PCRF then provides a new threshold or a different
service plan.
In case the SMP is integrated with an Online Charging System (OCS), a similar flow of
messages will take place, based on a “grant” issued by the OCS to the SMP. The final
grant may be accompanied by an action (block or redirect)
2.3.2 Monitoring rules

From release 12.1 there is change in the way policy element resources are managed by
the AOS; this impacts the total policy elements available for use by the system.
The change in policy structure splits the resources between monitoring rules and policy
rules.
a) Monitoring rules (used for usage monitoring and charging)
b) Policy rules
Capacity of monitoring and policy rules are described in section 1.3
2.3.3 Steering Enhancements

The following enhancements were made to the steering functionality:
 Support for up to 128 servers: In previous versions the number of supported servers
per service was 25. This number was increased to 128.
 Proxy chaining support: Support for chaining of multiple proxy services is now
available.
2.3.4 VoIP minutes of use reporting

One of the most interesting metrics for Mobile operators is the amount of revenues lost in
voice traffic due to over-the-top VoIP services. AOS now supports a report of VoIP
minutes of use to answer this business critical question.
VoIP is identified in a heuristic manner in order to enable counting of compressed and
proprietary VoIP applications rather than only standard applications (e.g: SIP based).
VoIP reporting is therefore able to distinguish between VoIP and other usages such as file
transfer, instant messaging etc. even when both are using the same protocol (e.g. Skype).
VoIP data collection should first be enabled by configuration. This is performed from the
Service Activation tab in the NetXplorer user interface and is described in the NetXplorer
Operations Guide Chapter 3 (NetEnforcer or Service Gateway Configuration Parameters)
Administrators can define filtering of the report as follows:
 For specific service plans only
 For specific protocols only
The following protocols are supported: Skype, MSN RTP, Yahoo Voice Data, Yahoo
SIP, Yahoo RTP, Yahoo voice, AOL VoIP, GoogleTalk, Google Talk RTP, Ventrilo,
SIP, SIP-RTP, H.323

2.3.5 Embedded Service Protector Sensor

Allot ServiceProtector Sensor is now available as a license activated feature within AOS.
This offers significant benefits in terms of deployment convenience since additional
network devices do not need to be deployed.
The sensor capabilities utilize resources on the NetEnforcer and therefore may impact the
performance slightly when activated: Activating the SP sensor on the will not impact the
forwarding rate (PPS) by more than 5% for average sized packets (300Byte). This value
may rise to up to 20% for smaller sized packets.
2.3.6 Teredo Tunneling

In this AOS version, Allot added support for Protocol decoding of Teredo tunneling.
Teredo tunneling is designed for IPv6 traffic over IPv4 networks. This tunneling is
commonly used by P2P applications.
2.3.7 Raw HTTP Handling

Sessions running on port 80 which do not start with a SYN packet are regarded as
“RAW” sessions. When processing HTTP sessions, there are some cases where a session
is idle for longer than the AOS session idle time out. To avoid the such sessions being
classified as “RAW”, a new mechanism was introduced for sessions running on port 80
which do not start with a SYN packet. In these cases, Allot’s DPI engine will inspect
whether the packet in question is an HTTP request packet and if so will handle it.

3 Resolved Issues
3.1 Resolved in 12.3
ALLOT ID DESCRIPTION NOTES

24492 (129195) Active redundancy ports were malfunctioning Fixed
24294 (128729) AC-500 network ports do not support “Force

100Mbps” configuration
16571 NetEnforcer CLI included an option to define Fixed.
number of core controllers. This is actually a This option is now
command relevant to Service Gateways only. disabled on
NetEnforcers
21904 In the AC-504, traffic was enabled on a Fixed
network port (loopback) although it was not
connected to the network
23893 (127896) The CLI command set_device_bw_limits did Fixed
not work as expected
18939 (101585) In some rare cases, the wrong allocation of VC Fixed
instances caused a problem with opening new
instances for new subscribers and such
connections were opened in the fallback pipe.
23221 Any Protocol pack (PP) above PP 3.20 cannot Fixed.
not be installed due to reaching PP size limit of PP3.21 and above
6MB on AOS can be installed on
AOS12.3
18399 When a protocol pack package (tar file) was Fixed. Tar file is
corrupted, it would still be installed. now verified, and an
error is presented if
corrupted
18797 In some cases, snaphsot caused a reboot due to Fixed
long file retrieving processes
19763 (107336) Packet re-ordering was noticed in some rare Fixed
cases.
19865, 15598 When moving into bypass some traffic Fixed. When moving
continued to run inside the system in a loop, into bypass the loop
(35793)
which caused wrong traffic reports. traffic is dropped


20105 The following reduction profiles were not in Fixed. These profiles
use but were still accessible via CLI: were removed.
 reduction.conf.normal.40G
 reduction.conf.subscriber.40G
20274 Updating a volume threshold to a new service Fixed

plan did not take effect.
20669 When the swkeeper process was down (due to Fixed. Running
an operational error) the snapshot took a long snapshot is no longer
time to implement (~10 minutes) affected by
swkeeper
21038 In some cases when issuing a “go config” Fixed
command, the total number of CCs appeared
as active instead of just the active ones.
21446 NX view of management ports did not include Fixed. This
speed and duplex mode information now
appears
21665 Identification of the YouTube service would Fixed. UDS
override User Defined Signatures overrides all other
signatures
21892 If an in-line platform was deployed with Fixed
copper network ports and the “action on
failure” setting of these ports was configured
to “bypass”, the system would not restore
active operation after reboot
22051 In the most active domains report, in some Fixed
cases, a wrong domain name was presented
with significant traffic
22060 A problem could occur when configuring Fixed
asymmetric traffic synchronized for more than
2 in-line platforms
22099 When working with asymmetric traffic, the Fixed
Peer Learning System (PLS) was less effective
than when working in a regular configuration.
As a result, the Peer-to-peer identification rate
was lower.
22408 Telnet was enabled by default and could not be Fixed.
disabled Telnet can now be
enabled and disabled
by administrator


22503 The active connections SNMP counter was Fixed
inaccurate.
(123955)
22570 The HBAD process crashed after installation. Relevant for SG
Sigma with
AOS12.2 only.
Patch solution
already provided.
Fix now included in
AOS GA version
23163 (125096) The time interval until the CLI prompt Response time was
appeared for a telnet session after entering the lowered.
password increased over previous versions.
22479 In HTTP file transfer, if the policy changed to Fixed.
“redirect to captive portal” in the middle of the Existing HTTP
session, there would be no effect for existing connections will be
connections. dropped. New
connections will be
redirected to captive
portal
17090 Incorrect classification of traffic to the fallback Fixed.
policy element took place when a large
(125125)
number of static elements was defined, or for a
host group containing many host lists.
17242 When adding a steering license during system Fixed.

operation, the steering functionality did not
take effect.
21548 MAC learning was set to “dynamic” by default Fixed. The default
value is now “static”
21191 The Core Controller would crash in some cases Fixed.
with specific rare HTTP patterns
(120251)
19994 A Bus Hardware error caused the system to Fixed from patch
halt 12.2.100
Reboot is performed
instead, message is
written to rsyslog
20620 Protocol IS-IS is classified as Unrecognized Fixed from patch
and Frames and blocked by the in-line 12.2.100
platform


22175 When upgrading from 11.2.x to 12.2.x, in This issue affected
some cases the interface catalog entries on the AC-1400 and
were not preserved properly. AC-3000 Series
only.
21747 In some cases when subscriber traffic was The steering traffic
asymmetric across different links on the same is now returned
(Case ID:
device, the steering traffic was returned to the according to the link
121266)
wrong link. traffic was received
19017 Admin status of ports were not reflected in the
MIB.
19010 On some device types, error messages were
displayed after snapshot command executed.
18583 When device switches from bypass to active,
management port disconnected for 1 sec.
14566 Speed/mode were not updated after changing
transceiver type.
13234 Action on faillure(bypass/fail_all)' on mngt
port had no effect.
21173 Set_device_BW_limit returned the wrong
code.
20785 Steering UDP traffic to transparent proxy
failed in some cases.
(Case ID:
117482)
21260 The collection of HTTP statistics stopped in
rare cases.
(Case ID:
120469)
19379 The alarm time represented in the GUI was
offset from system time
(Case ID: 94711)
16840 The “alSevereSoftwareProblem” MIB field
(OID: ….2603.5.5.3.0) reported an inaccurate
(Case ID: 50497)
status.


13821 Unexpected behavior was observed when the When the In-line
system time of an in-line platform was platform is
changed after it had been added to a connected to the NX
NetXplorer. no manual editing of
system time is
enabled. The in-line
platform is instead
synchronized with
the NX clock
18189 The CLI command "go add pipe\line" did not Fixed
work when the In-line platform was not
connected to the NX.
16864 Redundancy could be defined for platforms The configuration

that do not support it. options are now
adjusted according
to platform
capabilities
15001 The /tmp dir directory became overloaded after The folder is now
excessive use. cleared in each boot
process
19448 The log file nedbg.vasMngr.log would be Fixed
flooded with an error message "Frame with
invalid length60 received". The message was
not indicative of any real error.
(Case ID: GoogleTalk chats failed to be identified as Issue existed only in
120747) GoogleTalk. Such faults would occur after 15 AOS12.1. Fixed. In
minutes had passed with no update on the chat. AOS12.2,
GoogleTalk chats
will be classified as
GoogleTalk even
when the chat is idle
for more than 15
minutes
(Case ID: The CPU utilization value in the MIB was not Fixed
121558) calculated correctly.
21608 CPU usage was calculated incorrectly. Fixed
20368 The FB-200 blade in slot 9 was erroneously Fixed
(Case ID: reported as not active.
116297)

Allot ID Description Resolution
19068 Security: The wrong permission was allocated to a Fixed

shadow file
19069 Security: Several configuration files held passwords Fixed

in clear text
19070 Security: The Telnet service was not disabled by Fixed. Disabled by
default default
17746 In ServiceProtector mitigation, DDoS mitigation Fixed. To be

used to be wrongly applied on both traffic applied on
directions. incoming only
18846 When creating a snapshot an error message was Fixed. Erroneous

displayed even if the operation succeeded message removed
(“dsAdmin command not found”).
19836 MAX & MIN QoS policies were not enforced on a Fixed
policy element with classification based on an IP
range
20478 / Fixed
21582 Rare crashed in SNMP process

4 Known Issues

24844 The following errors may appear after These log errors are
upgrading from AOS12.2: inaccurate and
Previous install was aborted should be ignored
abruptly!
Running with possibly unstable
s/w!
24504 If management port of a NetEnforcer is
configured to "auto negotiation" and then
reconfigured to work with force 10Mbps Full
duplex, a restart will occur.
23843 The following CLI commands present the Workaround:
wrong output: Accurate services
 go list service_entry and applications lists
 go list appl_entry are available in the
NetXplorer catalog
24796 When the NE is configured for bypass disable,
and the system is not active the bypass LED
will be ON
30561 An asymmetry device ID can be configured
from #1 and not from #0.
22136 A traffic steering redundancy scheme (re-hash
load balancing) can be maintained for a
maximum of 63 servers only.
22212 In rare cases when an in-line platform using
fiber connections goes into bypass mode some
traffic can continue to flow in an endless loop
on the in-line platform. This will cause traffic
volume to be reported even through the in-line
platform is in bypass mode. In addition a small
amount of traffic will be released to the
network when the in-line platform becomes
active.
22158 In some cases Websafe does not operate as
expected when configured in a service chain


21553 It is not possible to replace the NetXplorer Workaround: If a
operating with an in-line platform while the NetXplorer server
platform is operating working with an in-
line platform must
be switched, the
platform should be
moved to bypass
mode while the
switch takes place.
21710 After a User Defined Signature (UDS) service Workaround:
is deleted from the service catalogue, the When deleting a
signature is still being matched. UDS service, all
relevant UDS entries
should also be
deleted.
21028 Websafe does not support traffic that is
tunneled in GRE.
21141 In some cases, minor synchronization loss can
occur between the SMP, NetXplorer and the
in-line platform. This has no effect on system
functionality.
21156 No SNMP alarm is sent after an NTP sync
operation is performed.
22084 Service Protector HBAD will block traffic
only for established connections that are not
bypassed in the system
22092 When a VoIP connection is dropped because
of a Denial of Service (DoS) policy, the
connection will still be measured in the VoIP
minutes Of Use report.
20332 During synchronization between the SMP and
inline platform (after connection loss) when
more than 50% of subscribers are new, some
start messages could get lost
20770 A Teredo tunnel is not identified correctly
when used with certain optional extension
headers.
20835 When issuing a command to show statistics of
steered services (acstst –l server), the number
of connections for a proxy chain is inaccurate


19531 Sometimes after a device reboot, it might not Workaround:
be possible to open the configuration tab in the Restart the
NX GUI. AllSnmpAgent
process on the in-
line platform.
19182 AOS SNMP MIB does not present the
operational speed of the management
interfaces
When upgrading from previous AOS versions Allot Recommends:
the statistics collection profile is not Following
maintained. This can cause graph inaccuracies. installation make
sure the collection
profile is identical to
the profile defined
prior to installation.
Update the profile
manually if it does
not match the
previously defined
profile. In case
assistance with this
procedure is
required please refer
to the following KB
item
https://c.eu1.visual.f
orce.com/apex/KB?
KBID=13697339


In some cases when performing an upgrade Allot Recommends:
and the “action on failure” setting defined prior Prior to installation,
to upgrading was not the default setting, after set the “action on
the upgrade the system may remain in bypass failure” settings to
state due to the inconsistency. “fail pair” (the
default
configuration). After
installation change
the “action on
failure” settings to
the required settings.
In case assistance
with this procedure
is required please
contact customer
support at
support@allot.com
24105 Dynamic host list is limited to 900 entries in
this version
In some rare cases following an upgrade, the Allot Recommends:
failure to automatically boot a blade may result If the in-line
in the in-line platform remaining in bypass platform remains in
state. bypass state after
reboot, access every
blade separately via
the SMC and run cli
deactivate/activate
for any blade that
did not boot. In case
assistance with this
procedure is
required please
contact customer
support at
support@allot.com.


RTP codecs are only identified if a policy Allot Recommends:
element is associated with a Codec. It is If reporting per
enough to associate a single policy element Codec is needed,
with one Codec in order for all the codecs to define a dummy
be identified and reported. policy element with
no QoS that is
associated with a
Codec. If your
policy already
includes Codecs
there is no need for
this definition.
When setting a QoS maximum at the Pipe Example:
level to a value of X, the minimum at the VC Correct: Pipe Max
level needs to be set to X-1 in order to achieve = 2048kbps, VC
the correct behavior and avoid admission by Min = 2047kbps
priority situations.
Incorrect: Pipe Max
= 2048kbps, VC
Min = 2048kbps
SG-Sigma will not reject an invalid key and Allot Recommends:
will overwrite the current key definitions. Following an
upgrade, make sure
(via the NX GUI)
that all key
definitions are
correct. In case key
definitions are
incorrect, re-enter
the key.
Most Active URL report needs to be activated
from NetXplorer. Please refer to the
NetXplorer Operation Guide for instructions
on how to activate the feature. Please note that
report information starts appearing about
20min after activation of the feature.
Provisioning of large host catalogs (over 4000
entries) may take a few minutes.
The number of packets (packets in / packets
out) is not reported or presented in NetXplorer


When setting a DOS (Denial of Service)
catalog entry option to ”Reject”, the actual
behavior will be identical to “Drop” on TCP
traffic.
DOS catalog entries in the policy are enforced
in the Pipe/VC level only, not on the Line
level.
Cisco ISL encapsulation is currently not
supported – the in-line platform only sees the
tunnel and not the encapsulated traffic inside
the tunnel.
In scenarios in which the in-line platform’s
Quality of Service engine is configured for
high buffering on large portions of the traffic,
the in-line platform might suffer from
significant performance degradation.
When changing the in-line platform’s software
key, a "rebooting the box” message may
appear. This should be ignored since no reboot
will occur unless the software version is
changed.
Packets with destination MAC of zero (0) are
dropped by the in-line platform.
When some of the VCs under a specific Pipe Allot Recommends:
are defined with priority settings and some Make sure all
without, it is possible that the VCs that do not elements under a
have priority settings will not be allowed to specific Pipe either
forward data. have priority
definitions or all of
the elements do not
have priority
definitions at all.
23621 When using a 1GE-300 blade with copper Allot Recommends:
ports on RJ-45 interfaces, some packet drop When traffic is
may occur if traffic includes random sized expected to to
jumbo frames. include random
sized jumbo frames,
refrain from using
the 2 RJ45 ports on
each 1GE-300 blade


22366 In cases of extreme load, the number of Workaround:
registered subscribers in the “slots & boards” fuadmin command
tab in the NX in incorrect in CLI provides the
actual updated
number
22717 When downgrading a Service Gateway from Workaround:
12.3 to 11.1.410, the number of min/max CC is Reconfigure after
not maintained. downgrade
22741 When IPv6 configuration is enabled: teredo
traffic is identified as Ipv6 and not assigned
correctly to the subscriber
22948 The Connections Establishment Rate (CER)
Statistics report is inaccurate in the case that
DoS actions performed. i.e. the connections
blocked by DoS are also presented in the
report
23402 Disk space TCA is not working.
23547 The in-line platform sends a tethering
enabling/disabling trap when
enabling/disabling PDPI
23780 The Time zone is not synchronized with the Workaround:
host after inserting a new Core Controller into Manually re-define
a Service Gateway the timezone
22548 In some rare cases, the display of boards in the
GUI and MIB is wrong
22898 The SG-Sigma E 1GE-300 blade does not
support 10M and 100M configurations in the
copper transceivers
23176 The number of connections displayed in the
“slots&boards” tab in the NX may be incorrect
22361 The Port LED does not go off when port is
down due to a Remote fault
22905 If no previous snapshot exist in the system, the
snapshot command prints errors in response
24100 XFF based identification does not work in this
version
23978 After activating DHCP gleaner in the in-line
platform, a reboot is required


23922 After distributing websafe files, the log shows
"Web Safe has failed! " even though the files
were distributed correctly

5 Software Upgrade
NOTES The Software Upgrade Procedure may fail if the database of your in-line platform
is corrupted. In such cases, please consult Allot Customer Support at
support@allot.com.
A new key is required when upgrading to AOS12.3. In order to receive a new key
you must have your Boxkey number ready when contacting Allot Customer
Support. For a script and full instructions for accessing the Boxkey of your
chassis see https://c.eu0.visual.force.com/apex/KB?KBID=13697184
If downloading the version installation files from the Allot FTP site using Internet
Explorer, the browser may change the file name from *.tgz to *.tar. The
installation script will fail for .tar files. Allot recommends not to use Internet
Explorer to download these files. If this is the only method available, you should
rename the file after download from .tar to .tgz
1. Download the software version from the Allot ftp site by completing the following steps:
 Open Telnet and log in to the In-line platform with User Name: sysadmin
Password: sysadmin (default).
 Type mkdir AOS123.
 Type cd AOS123.
 Type ftp ftp.allot.com (the IP address is 209.62.76.11)
 Log into the ftp site as an anonymous user.
 Type cd <directory> /*See below FTP location information*/
 Type hash.
 Type bin.
 Type prompt.
 Type mget *
All required files will be downloaded automatically.
When the download finishes, type bye. This will close the ftp site but leave Telnet open.
2. Type chmod u+x aos-instl.sh
3. Type ./aos-instl.sh
4. The upgrade procedure could take as long as 10 minutes. You may be prompted to enter
a new key.
5. Type ac_reboot when you see a message that states that the upgrade completed
successfully.
5.1 Accessing the Software

The binary file locations on the Allot FTP Site are listed below:
AC-3000:
ftp://ftp.allot.com/Previous_Versions/DPI_device/AC-3000/AOS.AC3K.12.3.1_B32/
AC-1400:
ftp://ftp.allot.com/Previous_Versions/DPI_device/AC-1400/AOS.AC1K.12.3.1_B32/

AC-500:
ftp://ftp.allot.com/DPI_device/AC-500/GA/AOS.AC500.12.3.1_B32

AOS12 3 1 - Release Notes - v1r2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

AOS12 3 1 - Release Notes - v1r2

Uploaded by

Copyright:

Available Formats

Software

Release Notes AOS v12.3.1

© 2012 Allot Communications. All rights reserved. 2

3.3 Resolved in 12.1 ................................................................................................. 25

© 2012 Allot Communications. All rights reserved. 3

1 Platform and Software Management

NX 12.3.0 AOS 12.3.1 SMP 12.3.0

For more information about Allot license keys, see

1.2 Protocols and Applications

© 2012 Allot Communications. All rights reserved. 4

© 2012 Allot Communications. All rights reserved. 5

1.3 Performance and Sizing

Parameter AC-500 AC-1400 AC-3000

2.1.1 Tethering Detection

Figure 1: Tethering Example

© 2012 Allot Communications. All rights reserved. 6

Data usage analysis of tethering devices is required by marketing departments in order to

Figure 2: Tethering Support in NX Enforcement Policy Editor

iOS Full Full Full Full Full Full Full

Table 2: Supported Operating Systems

© 2012 Allot Communications. All rights reserved. 7

2.1.2 Inline DHCP Gleaning

Cable Modem Configuration DHCP

Figure 3: In-Line DHCP Gleaning in a Cable Environment

© 2012 Allot Communications. All rights reserved. 8

2.1.3 Increased number of Policy Elements

2.1.4 Secure Data Enrichment in HTTP redirect

2.1.5 HTTP Redirect to HTTPS

2.1.6 IPv6 support

Figure 4: Co-existance of IPv4 and IPv6 Networks

IPv6/IPv4 Dual Stack Support

© 2012 Allot Communications. All rights reserved. 9

© 2012 Allot Communications. All rights reserved. 10

© 2012 Allot Communications. All rights reserved. 11

2.1.7 IPv6 Support in Steering to Value Added Services

Figure 5: IPv6 Steering

© 2012 Allot Communications. All rights reserved. 12

2.1.8 DPI Improvements

© 2012 Allot Communications. All rights reserved. 13

Figure 6: PDPI Detection Flow

2.1.10 Troubleshooting Improvements

© 2012 Allot Communications. All rights reserved. 14

2.1.12 O&M improvements

2.1.13 Support for Additional Features Added in SMP/NX12.3

2.2 New Features in AOS12.2

2.2.1 Selective Bypass by VLAN Group

© 2012 Allot Communications. All rights reserved. 15

2.2.2 DPI capabilities – further inspection capability of SIP traffic

2.2.3 Support for Additional Features Added in SMP/NX12.2

© 2012 Allot Communications. All rights reserved. 16

2.3 New Features in AOS12.1

2.3.1 Real Time Usage Monitoring

© 2012 Allot Communications. All rights reserved. 17

2.3.2 Monitoring rules

Capacity of monitoring and policy rules are described in section 1.3

2.3.3 Steering Enhancements

2.3.4 VoIP minutes of use reporting

© 2012 Allot Communications. All rights reserved. 18

2.3.5 Embedded Service Protector Sensor

2.3.6 Teredo Tunneling

2.3.7 Raw HTTP Handling

© 2012 Allot Communications. All rights reserved. 19

ALLOT ID DESCRIPTION NOTES