The features added in this protocol pack are as follows:
RTP dynamic payload type sub-classification
Microsoft Lync Audio/Video separation
Non-encrypted Cisco-Jabber support
Network Based Application Recognition (NBAR) Protocol Pack 6.2.0 is supported on Cisco ASR 1000 Series Aggregation Services Routers.
New Protocols in NBAR2 Protocol Pack 6.2.0
The following protocols are added to NBAR2 Protocol Pack 6.2.0:
Cisco Jabber Audio
Cisco Jabber is a unified communications client application that provides presence, instant messaging (IM), voice, and video calling capabilities on many platforms. This protocol classifies the audio calls part of Cisco Jabber.
Cisco Jabber Control
Cisco Jabber is a unified communications client application that provides presence, instant messaging (IM), voice, and video calling capabilities on many platforms. This protocol classifies the control and signaling part of Cisco Jabber.
Cisco Jabber IM
Cisco Jabber is a unified communications client application that provides presence, instant messaging (IM), voice, and video calling capabilities on many platforms. This protocol classifies the text messaging part of Cisco Jabber.
Cisco Jabber Video
Cisco Jabber is a unified communications client application that provides presence, instant messaging (IM), voice, and video calling capabilities on many platforms. This protocol classifies the video calls part of Cisco Jabber.
Microsoft Lync Audio
Microsoft Lync Audio is the audio calls support in MS Lync. This protocol classifies the voice part of video calls. The classification is based on STUN and RTP.
Microsoft Lync Video
Microsoft Lync video is the video calls support in MS Lync. This protocol classifies the visual part of the video call. The voice in the video call is classified as MS-Lync-Audio. The classification is based on STUN and RTP.
New Features in NBAR2 Protocol Pack 6.2.0
SSL Unique-name Sub-classification
In this protocol pack, a new sub-classification parameter called 'unique-name' is introduced for SSL. The unique-name parameter can be used to match SSL sessions of servers that are not known globally, or are not yet supported by NBAR. The unique-name will match the server name indication (SNI) field in the client request if the SNI field exists, or it will match the common name (CN) field in the first certificate of the server's response.
The feature also supports cases of SSL sessions that use session-id than the SSL sessions that use handshake.
The following example shows how an SSL based service with the server name as 'finance.cisco.com' is matched using unique-name:
The SSL sub-classification parameters have priority over the built in signatures. Therefore, when a 'unique-name' defined by a user matches a known application such as Facebook, it will not match the built in protocol but will match SSL with the configured sub-classification.
Similar to the other sub-classification features, the classification result (for example, as seen in protocol-discovery), does not change and will remain as SSL. However, the flows matching the class maps (as shown in the leading example) will receive the services such as QoS and Performance monitor configured for them. To view the detailed matching statistics, refer to the policy map counters.
In this protocol pack, the existing sub-classification parameters for 'RTP audio' and 'RTP video' are enhanced to detect RTP flows that use dynamic payload types (PT). Dynamic PTs are PTs in the dynamic range from 96 to 127 as defined in RTP RFC, and are selected online through the signaling protocols such as SIP and RTSP, for each session. In this protocol pack, only RTP sessions initiated using SIP will match by dynamic payload type.
There is no change in usability of the feature.
The following example shows how to detect RTP audio flows that include both static and dynamic PT:
class-map match-any generic-rtp-audio
match protocol rtp audio
The RTP audio/video sub-classification parameters are generic in nature and will match only on generic RTP traffic. More specific classification such as ms-lync-audio, cisco-jabber-audio, facetime, and cisco-phone will not match as RTP, and therefore will not match the audio/video sub-classification.
The following protocols are updated in NBAR2 Protocol Pack 6.2.0:
Updated signatures to support dynamic payload types.
Updated signatures to support sub classification of unique-name
Deprecated Protocols in NBAR2 Protocol Pack 6.2.0
The following protocols are deprecated in NBAR2 Protocol Pack 6.2.0:
ghostsurf—service no longer available
guruguru—service no longer available
hotmail—replaced with outlook-web-service
livemeeting—replaced with ms-lync
megavideo—service no longer available
ms-lync-media—replaced with ms-lync-audio and ms-lync-video
Caveats in NBAR2 Protocol Pack 6.2.0
If you have an account on Cisco.com, you can also use the Bug Toolkit to find select caveats of any severity. To reach the Bug Toolkit, log in to Cisco.com and go to http://www.cisco.com/pcgi-bin/Support/Bugtool/launch_bugtool.pl. (If the defect that you have requested cannot be displayed, this may be due to one or more of the following reasons: the defect number does not exist, the defect does not have a customer-visible description yet, or the defect has been marked Cisco Confidential.)
Resolved Caveats in NBAR2 Protocol Pack 6.2.0
The following table lists the resolved caveats in NBAR2 Protocol Pack 6.2.0:
Some Xunlei-KanKan traffic may be misclassified as Xunlei.
Video traffic generated by some ESPN websites might be misclassified as unknown.
Web traffic generated by some ESPN websites might be misclassified as unknown.
Known Caveats in NBAR2 Protocol Pack 6.2.0
The following table lists the known caveats in NBAR2 Protocol Pack 6.2.0:
Traffic generated by pcAnywhere for mac and pcAnywhere mobile app might be misclassified as unknown
gtalk-video might be misclassified as rtp
gbridge pc client might not be blocked
Traffic generated by AIM Pro might be misclassified as unknown and webex-meeting
Under heavy SSL traffic, the following error message my appear: ": %STILE_CLIENT-4-MAX_LINK_TOUCH_WARN: F0: cpp_cp: NBAR number of flow-slinks threshold is reached, can't allocate more memory for flow-slinks"
PCoIP session-priority configuration limitation
Segmented packets are not classified when using NBAR sub classification
Some qqlive traffic may be misclassified as qq-accounts when qqlive is configured under a class-map
When using Microsoft Lync in Office-365, the traffic might be misclassified as rtp or SSL
SSL sub classification will not be matched if a built-in protocol was matched in the SSL client-hello message
SIP related protocols classification and RTP sub-classification may fail when compact headers are used
SIP related protocols classification and RTP sub-classification may fail when field extraction is activated and the 'contact' or 'from' fields do not contain '@'.
Encrypted Cisco Jabber is not supported
Cisco-jabber-video and cisco-phone might be misclassified when configured under a class-map
Microsoft Lync might be misclassified in certain scenarios
Restrictions and Limitations in NBAR2 Protocol Pack 6.2.0
The following table lists the limitations and restrictions in NBAR2 Protocol Pack 6.2.0:
http traffic generated by the bitcomet bittorrent client might be classified as http
For capwap-data to be classified correctly, capwap-control must also be enabled
During configuring QoS class-map with ftp-data, the ftp protocol must be selected. As an alternative, the ftp application group can be selected.
Encrypted video streaming generated by hulu might be classified as its underlying protocol rtmpe
Traffic generated by the logmein android app might be misclassified as ssl
Login and chat traffic generated by the ms-lync client might be misclassified as ssl
Traffic generated by the mobile or mac app is not supported. ms-lync 2013 traffic if any, might be misclassified.
Login to QQ applications which is not via web may not be classified as qq-accounts
Voice traffic generated by secondlife might be misclassified as ssl