Application Telemetry Overview

Application Telemetry is a tool used in Extreme Analytics to extract network analytics information (e.g. running application details, flow pathway, latency, bandwidth etc). It uses sFlow and ERSPAN (Encapsulated Remote Span) to extract and transport specific raw packets and sampled flows from the SLXOS switches to Extreme Analytics processing engines for further analysis.

Supported Devices

The following devices support Application Telemetry.

Performance and Scale

All entries present in telemetry.pol file will be configured in the space reserved for App-Telemetry rules in the hardware. A maximum of 768 rules for SLX 9150/9250 and 1024 rules for SLX 9540 are supported in the telemetry.pol file.

Some of these rule types may need to expand before hardware installation. For example: App-telemetry rules given to check port-range is not written as one single rule, instead it is expanded in HW to support the full range. With these kind of rules, the maximum support is reduced.

Non-Goals and Limitations

  • FlexACLs are used internally to support this feature and are not user configurable.
  • When telemetry.pol file content is changed, user needs to remove and reapply using the rules using the provided configuration command.
  • On reload of the switch, telemetry.pol file will be read, and telemetry ACLs will be installed, if the configuration is saved.
  • Rules given in telemetry.pol file are called flex-rules.
  • FlexACLs are used internally to support this feature and are not user configurable.Only 4 offsets per flex-rule are supported.
  • Telemetry rules and ACL statistics are not persistent on system reload.
  • The offsets can different for the TCP and UDP rules, otherwise all UDP rules should use same offset, and all TCP rules should use the same offset.
  • The counters for every app-telemetry rule only indicate if packet matching the corresponding rules matched. It does not show the number of packet actually tunneled and sent out of the switch.
  • The rules are considered in decreasing order of precedence when writing the ACL rules from file. Meaning 2 rules written in HW, which can match the same packet, only the counter of the rule written first will increment.
  • In NightHawk, UDF‘s are BCM hardware resource which is used to compare pre-programed information against the incoming packet in an offset. A chunk can match 16-bit information and each UDF can be mapped to 2 chunks. For App-Telmetry rules with offsets, we will match the L5 information (UnknownL5), with offset starting from the L4 header.

For UnknownL5, the following packet types can be matched:

  1. UDP: all protocol packets except VxLAN | BFD | 1588 | GPE | GENEVE | INT will match UDF. Apart from VxLAN | BFD | 1588 | GPE | GENEVE | INT, 4 more custom formats by setting the register of the form PARSER_n_USER_DEFINED_m_UDP_DEST_PORT.
  2. TCP: all protocol packets except INT header followed by TCP header will match UDF.

When unsupported packet types are received, they don‘t match the rules (with offsets) in HW and will not get mirrored to Analytics engine.

TCAM Profile

The TCAM lib show command displays the number of entries supported for the default TCAM profile as displayed below.

SLX# show hardware profile current  
 
switch type: SLX9150-48Y 
 
            current TCAM profile: DEFAULT 
                          l2-acl: 4096 
                        l3v4-acl: 4096 
                        l3v6-acl: 2048 
                  l3v4-acl-vxlan: 0 
                        l2l3v4Of: 0 
                       egrl2-acl: 1024 
                       egrl3-acl: 1024 
                         l3v6-of: 0 
                        Flex-acl: 0 
                     App-tel-acl: 0 
 …
9036676-01 Rev AA