Catalyst 4500 Series Switch Software Configuration Guide, IOS XE 3.9.xE and IOS 15.2(5)Ex

Overview

The process starts with an organization’s requirements relating to management and control of network traffic. You begin by assessing—the software applications that run on the various hosts (phones, PCs etc.) in your network, the domains (websites) and applications accessed by these devices, and the business-relevance of these domains and applications in your organization.

The assessment helps you arrive at a list of domains and applications that are “trusted” by your organization - designating all remaining domains and applications as untrusted.

With DNS-AS enabled on your network and the list of trusted domains at hand, the networking devices or DNS-AS clients in your network identify which applications the network traffic belongs to or which domains are being requested. As long as the traffic is part of the trusted list, the switch requests the DNS server for metadata and IP address information. This request is sent in the form of a DNS-query. The response, once received, is cached locally until the Time-to-Live (TTL) for that resource record expires. The response is bound to the traffic and allows the DNS-AS client to now identify, classify, and forward traffic accordingly.

Key Concepts

AVC with DNS-AS Process Flow

This involves the DNS snooping process and the DNS-AS client process—both of which are loosely coupled, but independent processes. AVC with DNS-AS Process Flow is a representation of both processes.

Part -I: DNS Snooping Process

Step 1 The host initiates an “A” record request.

A user from your organization is in a meeting room in an office building. The associated DNS-AS client here is a switch (the wired network traffic from this meeting room is routed through this switch). The user looks up a website www.example.com, which initiates the request for an “A” record.

Step 2 The authoritative DNS-server responds with an “A” record response.

Part-II: DNS-AS Client Process

Step 1 The DNS-AS client sends a DNS query (TXT request) to the authoritative DNS server.

The DNS-AS client, which is constantly snooping for requests (based on the trusted domain list), finds the host’s forward look-up request.

Note The DNS-AS client receives a copy of the host’s “A” record request, and does not alter the host’s original request in any manner.

Based on the snooped result, the DNS-AS client sends a TXT request to the authoritative DNS server.

Step 2 The authoritative DNS-server responds with a TXT record response.

Step 3 A successful TXT response is followed by an “A” record request.

Step 4 The authoritative DNS-server responds with an “A” record response.

Step 5 The DNS-AS client parses and saves the response in its binding table.

The DNS-AS client saves the TXT record and “A” record in its binding table. The response will remain saved in the binding table for the duration specified by the TTL of the “A” record. The system automatically checks and prevents duplicate entries for a fully qualified domain name in the binding table.

The DNS-AS client applies a QoS policy based on the metadata from the DNS server, and exports application information to a collector, based on how the flow record is configured.

The DNS-AS client forwards information about identified applications to FNF, enabling you to export this information.

Figure 45-1 AVC with DNS-AS Process Flow

	An “A” record request from the host to the DNS server		An “A” record response from the DNS server to the host
	A copy of the host’s “A” record request that the DNS-AS client saves	—	—
	TXT record and “A” record request from the DNS-AS client to the DNS server		TXT record and “A” record response from the DNS server to the DNS-AS client

High Availability and ISSU for AVC with DNS-AS

The AVC with DNS-AS feature supports High Availability and ISSU.

For High Availability, the binding table database of the active DNS-AS client is synchronized with the standby DNS-AS client. As long as AVC with DNS-AS is enabled, no additional user configuration is required.

The binding table entries are synchronized when:

• The standby comes up (bulk synchronization).
• New entries are added to the binding table database.
• One or more entries are cleared from the database.

Note AVC with DNS-AS is also supported in the VSS mode, and Quad-Supervisor VSS Mode.

Default Configuration

AVC with DNS-AS is disabled.

Prerequisites for Configuring AVC with DNS-AS

• The DNS-AS client can snoop forward look-up requests originating from hosts.
• To ensure DNS packet logging or snooping, you must attach the policy map to the interface, by using the service-policy input command.
• You have maintained metadata in the authoritative DNS server and reachability exists - before you enable AVC with DNS-AS.

Restrictions and Guidelines for Configuring AVC with DNS-AS

• Only a forward look-up is supported.
• Two DNS servers are supported, in case of a failover. One is considered the primary DNS server and other, the secondary DNS server.
• IPv6 is not supported—AAAA requests, and IPv6 DNS servers are not supported.
• AVC with DNS-AS is supported only on physical interfaces, in the ingress direction.
• AVC with DNS-AS is not supported on wireless traffic.
• Virtual Routing and Forwarding (VRF) is not supported.
• We recommend a maximum of 300 AVC with DNS-AS applications (domain names) in the binding table, because of its effect on the ternary content addressable memory (TCAM). To know how the addition of applications affects the TCAM see the Troubleshooting AVC with DNS-AS section of this chapter

Generating Metadata Streams

Application metadata is configured and saved on the local, authoritative DNS server. You configure application classification information, for each trusted domain, in a prescribed format (a metadata stream). This is the information that the server propagates to switches when queried for application metadata. When the switch sends a TXT query regarding an application, the DNS server sends the relevant metadata in the TXT response.

To generate metadata streams, perform the following task:

Configuring a DNS Server as the Authoritative Server

All DNS-AS clients in the network should be configured to send all DNS queries to one authoritative DNS server. On a Cisco Catalyst switch, perform the following task:

Enabling AVC with DNS-AS

DNS-AS is disabled by default. To enable the feature on a Cisco Catalyst switch, perform the following task:

Making an Entry in the Trusted Domain List

When AVC with DNS-AS is first enabled on the switch, the trusted domain list is empty. You must maintain the list of trusted domains on the switch. The switch snoops only for network traffic that is maintained in this list. To make entries in this list, perform the following task

Configuring QoS for AVC with DNS-AS

In order to isolate and classify trusted traffic as defined in the metadata stream, you must complete this sequence of tasks—create class maps (one for each traffic class), define traffic-class match criteria and business-relevance match criteria, create a policy map, attach the policy map to the interface. This sub-section provides the following information:

• Class Map Configuration in the Easy QoS Model
• Policy Map Definitions in the Easy QoS Model
• App-Class and QoS Traffic Mapping
• Sample QoS Configuration for AVC with DNS-AS: Classifying Network Control Traffic

For more QoS information, see the Classification section of the Configuring QoS chapter in this guide.

Class Map Configuration in the Easy QoS Model

In order to determine how many traffic classes should be provisioned, you can use the 12-class Easy QoS Model. This model provides uniform, standards-based recommendations to help ensure that QoS designs and deployments are unified and consistent across an organization.

The following shows the class map configuration for traffic class and business relevance as per the 12-class Easy QoS Model:

Policy Map Definitions in the Easy QoS Model

The following sample output displays the policy map definitions, with traffic attribute marking for all the traffic classes in the 12-class Easy QoS Model:

App-Class and QoS Traffic Mapping

The following table shows how the app-class field in the metadata stream maps to the 12-class Easy QoS Model of traffic classification:

Note The DNS-AS client applies default forwarding behavior in these cases:

• If the match attributes that you specify for the traffic class and business relevance do not match what you have defined in the metadata stream.
• If the binding table entry is no longer active. This refers to the age of the entry. Use the show avc dns-as client binding-table command to display the age of an entry

Sample QoS Configuration for AVC with DNS-AS: Classifying Network Control Traffic

The following example shows how to classify network-control traffic based on the 12-class Easy QoS model. It shows how the DNS-AS client allows “example.org” to be classifed under class-map NETWORK-CONTROL.

For this example, the corresponding metadata that should be maintained is:

Create class maps and match attributes

Create the policy map, attach the class map to it and specify priority

Attach the policy map to an interface

Configuring FNF for AVC with DNS-AS

With FNF, you can gain visibility into the applications running on your network, and use FNF option templates to export application ID, description, and attribute information.

You must configure these FNF settings on the DNS-AS client:

• Configure a flow record to collect nonkey field application-name, and the key fields ipv4 source address and ipv4 destination address
• Configure a flow exporter and the two option templates, to fetch application information.

Option template application-table, exports only applications resolved by the DNS-AS client, that is, the application ID and name from the binding table. The corresponding application descriptions come from Network Based Application Recognition (NBAR) definition for standard applications. A constructured help string is used for custom applications.

Option application-attributes fetches attribute information by mapping it to the application name. Where standard application names are used, the option template uses standard NBAR attribute definitions; where custom application names are used, user-defined application names and only certain attribute fields are guaranteed to carry values.

• Configure a flow monitor and apply it to an interface to enable network traffic monitoring.

FNF Interaction with DNS-AS—With every flow that is created in the flow table, the DNS-AS client resolves the application name for the flow (if the entry exists in the binding table), by using the destination IP address (and if not available), the source IP address.

At periodic, configured intervals (600 seconds, by default), FNF exports option template data, that is mapped to the corresponding application name, to an external collector.

For more informattion about FNF, see the Configuring Flexible NetFlow chapter in this guide.

These sections provide more information:

• Option Templates
• Sample FNF Configuration for AVC with DNS-AS

Option Templates

The application-table and application-attributes options templates are supported. These templates determine the information that will be exported to an external collector.

option application-table

Exports the application name, application tag, and description to the external collector.

On a device where AVC with DNS-AS is enabled, only applications resolved by the DNS-AS client are exported. But in addition, the application-table template exports two applications called unclassified and unknown, irrespective of whether the feature is enabled or not.

• Application Name—For custom and standard applications, this information is derived from the TXT response ( app-name :) that is saved in the binding table.
• Application Tag—This is same as application ID in the context of the AVC with DNS-AS feature and consists of the engine ID and selector ID.

– Engine ID or Classification Engine ID—Defines the context for the selector ID. Only these values are supported:

L3—IANA layer 3 protocol number (IANA_L3_STANDARD, ID: 1)

L4—IANA layer 4 well-known port number (IANA_L4_STANDARD, ID: 3)

L7—Cisco global application ID (CISCO_L7_GLOBAL, ID: 13)

CU—Custom protocol, (NBAR_CUSTOM, ID: 6). For custom applications, the DNS-AS client automatically uses this engine ID.

– Selector ID—Uniquely identifies the application or classification.

For standard applications, the application tag information is derived from these sources, in the given order of precedence:

1. TXT response ( app-id :)

2. The NBAR definition for standard applications (if the TXT response does not carry a value)

For custom applications, the following applies to application tag information:

1. It is derived only from the TXT response ( app-id :)

2. For the engine ID, the DNS-AS client automatically uses CU—Custom protocol, (NBAR_CUSTOM, ID: 6).

3. For the selector ID, the DNS-AS client allots a custom selector ID. A maximum of 120 custom applications are supported - out of which 110 are available to the DNS-AS client. Starting with selector ID value 243, IDs are assigned in descending order. When there are no remaining IDs to assign, the entry is not saved in the binding table.

• Description—This information is derived from the NBAR definition for standard applications. For custom applications, the DNS-AS client uses: User Defined Protocol <app-name>.

option application-attributes

Enables the collector to map the application names (from the option application-table) to their attributes. Attributes are statically assigned to each protocol or application, and are not dependent on traffic.

For standard applicatons—

• Application Tag—Guidelines that apply this field as part of the option application-table template apply here as well.
• Category—Groups applications based on the first level of categorization for each protocol as the match criteria. Similar applications are grouped together under one category. For example, the email category contains all email applications such as, Internet Mail Access Protocol (IMAP), Simple Mail Transfer Protocol (SMTP), Lotus Notes, and so on.
• Sub-category—Groups applications based on the second level of categorization for each protocol as the match criteria. For example, clearcase, dbase, rda, mysql and other database applications are grouped under the database group.
• Application Group—Groups the same networking applications together. For instance, Example-Messenger, Example-VoIP-messenger, and Example-VoIP-over-SIP are grouped together under the example-messenger-group
• Peer-to-peer (p2p)—Groups protocols based on whether or not they use p2p technology.
• Tunnel—Groups protocols based on whether or not a protocol tunnels the traffic of other protocols. Protocols for which the NBAR does not provide any value are categorized under the unassigned tunnel group. For example, Layer 2 Tunneling Protocols (L2TP).
• Encryption—Groups applications based on the encrypted and nonencrypted status of the applications. Protocols for which the NBAR does not provide any value are categorized under the unassigned encrypted group.
• Traffic class—Groups applications and protocols based on the traffic class they belong to. For example, all applications that have traffic class TD.

Traffic class information is derived from these sources, in the given order of precedence:

1. TXT response ( app-class :)

2. The NBAR definition for standard applications (if the TXT response does not carry a value)

• Business relevance—Groups applications based on whether or not they have been marked as business-relevant. For example, all applications that have business relevance as YES.

Business relevance information is derived from these sources, in the given order of precedence:

1. TXT response ( business :)

2. The NBAR definition for standard applications (if the TXT response does not carry a value)

For custom applications—

Only these attributes of the application-attributes option template are guaranteed to carry a value:

• Application Tag—See the Application Tag info in section option application-table above. The same applies here as well.
• Traffic class—This information is derived from the TXT response ( app-class:)
• Business Relevance—This information is derived from the TXT response ( business:)

Sample FNF Configuration for AVC with DNS-AS

The following example shows how you can configure FNF for AVC with DNS-AS:

1. Create a flow record. As in the example, you must configure:

– The source and destination IP addresses as key fields, in order to resolve application names.

– The use of the application name as a nonkey field in flow record.

Additionally (not mandatory), you can also configure the number of bytes or packets in a flow as a nonkey field, to display the number of applications sent to the collector.

2. Create a flow exporter. Also configure the application-table and application-attributes option templates in the exporter. Without option templates, the collector cannot retrieve meaningful application information. At a minimum we recommend that you configure the application-table option. For attribute information, also configure the application-attribute option.

You can also change the frequency of template export in seconds (the allowed range is 1 to 86400 seconds; the default is 600 seconds)

3. Create a flow monitor and apply it to an interface to perform network traffic monitoring.

The interface you apply the flow monitor to, can also be the same interface you have applied the QoS policy to. This example applies the QoS policy created as part of the sample QoS configuration Sample QoS Configuration for AVC with DNS-AS: Classifying Network Control Traffic.

4. Other related show commands:

Example: show avc dns-as client status

Back to AVC with DNS-AS Monitoring Commands.

Example: show avc dns-as client trusted-domains

Back to AVC with DNS-AS Monitoring Commands.

Example: show avc dns-as client binding-table detail

Back to AVC with DNS-AS Monitoring Commands.

Example: show avc dns-as client statistics

Note Two DNS servers are configured in this example.

Back to AVC with DNS-AS Monitoring Commands.

Example: show avc dns-as client name-server brief

Switch# show avc dns-as client name-server brief

Server-IP | Vrf-name

------------------------------------------------------

192.0.2.1 | <default>

192.0.2.2 | <default>

Back to AVC with DNS-AS Monitoring Commands.

Example: show ip name-server

Back to AVC with DNS-AS Monitoring Commands.