The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Multi-tenancy for Unified Threat Defense provides Snort IPS and Web Filtering for multiple users. You can define policies for one or more tenants in a single Cisco CSR 1000v instance. Each policy can have a threat inspection profile and a web filtering profile. The following sections describe how to configure multi-tenancy for Unified Threat Defense. Many of the commands used in these configuration steps are similar to those used in configuring single-tenancy—see: Snort IPS and Web Filtering.
Multi-tenancy for Snort IPS and Web Filtering allows you to define policies for one or more tenants, in one Cisco CSR 1000v instance. This feature was introduced in Cisco IOS XE Everest 16.6.1.
Each tenant is a VPN routing and forwarding instance with one or more VPN routing and forwarding tables (VRFs). A Unified Threat Defense (UTD) policy is associated with a threat inspection profile and web filtering profile. Multiple tenants can share a UTD policy.
The system logs include the name of the VRF which allows you to produce statistics per-tenant.
The CLI commands used in multi-tenancy mode are similar to those used in single-tenancy mode (see Snort IPS and Web Filtering). In multi-tenancy, you enter a sub-mode utd engine standard multi-tenancy and configure UTD policies, web filtering and threat-inspection profiles. After exiting the utd engine standard multi-tenancy sub-mode, the UTD policies are applied.
The benefits of web filtering and threat inspection (Snort IPS/IDS) are explained in the following sections:
Web filtering allows you to provide controlled access to the internet by configuring URL-based policies and filters. Web filtering helps to control access to websites by blocking malicious or unwanted websites and therefore making the network more secure. You can blacklist individual URLs or domain names and configure whitelisting policies for the same. You can also make provision to allow or block a URL based on reputation or category.
The Snort IPS feature enables Intrusion Prevention System (IPS) or Intrusion Detection System (IDS) for branch offices on Cisco 4000 Series Integrated Services Routers and Cisco Cloud Services Router 1000v Series. This feature uses the Snort engine to provide IPS and IDS functionalities.
Snort is an open source network IPS that performs real-time traffic analysis and generates alerts when threats are detected on IP networks. It can also perform protocol analysis, content searching or matching, and detect a variety of attacks and probes, such as buffer overflows, stealth port scans, and so on. The Snort engine runs as a virtual container service on Cisco 4000 Series Integrated Services Routers and Cisco Cloud Services Router 1000v Series.
The Snort IPS feature works in the network intrusion detection and prevention mode that provides IPS or IDS functionalities. In the network intrusion detection and prevention mode, Snort performs the following actions:
Monitors network traffic and analyzes against a defined rule set.
Performs attack classification.
Invokes actions against matched rules.
Based on your requirements, you can enable Snort either in IPS or IDS mode. In IDS mode, Snort inspects the traffic and reports alerts, but does not take any action to prevent attacks. In IPS mode, in addition to intrusion detection, actions are taken to prevent attacks.
The Snort IPS monitors the traffic and reports events to an external log server or the IOS syslog. Enabling logging to the IOS syslog may impact performance due to the potential volume of log messages. External third-party monitoring tools, which supports Snort logs, can be used for log collection and analysis.
The Snort IPS solution consists of the following entities:
Snort sensor—Monitors the traffic to detect anomalies based on the configured security policies (that includes signatures, statistics, protocol analysis, and so on) and sends alert messages to the Alert/Reporting server. The Snort sensor is deployed as a virtual container service on the router.
Signature store—Hosts the Cisco Signature packages that are updated periodically. These signature packages are downloaded to Snort sensors either periodically or on demand. Validated signature packages are posted to Cisco.com. Based on the configuration, signature packages can be downloaded from Cisco.com or a local server.
Note | If you are downloading signature packages from a local server to hold the signature packages, only HTTP is supported. |
Signature packages must be manually downloaded from Cisco.com to the local server by using Cisco.com credentials before the Snort sensor can retrieve them.
The Snort container performs a domain-name lookup (on the DNS server(s) configured on the router) to resolve the location for automatic signature updates from Cisco.com or on the local server, if the URL is not specified as the IP address.
Alert/Reporting server—Receives alert events from the Snort sensor. Alert events generated by the Snort sensor can either be sent to the IOS syslog or an external syslog server or to both IOS syslog and external syslog server. No external log servers are bundled with the Snort IPS solution.
Management—Manages the Snort IPS solution. Management is configured using the IOS CLI. Snort Sensor cannot be accessed directly, and all configuration can only be done using the IOS CLI.
The Snort sensor runs as a service on routers. Service containers use virtualization technology to provide a hosting environment on Cisco devices for applications.
You can enable Snort traffic inspection either on a per interface basis or globally on all supported interfaces. The traffic to be inspected is diverted to the Snort sensor and injected back. In Intrusion Detection System (IDS), identified threats are reported as log events and allowed. However, in Intrusion Prevention System (IPS), action is taken to prevent attacks along with log events.
The Snort sensor requires two VirtualPortGroup interfaces. The first VirtualPortGroup interface is used for management traffic and the second for data traffic between the forwarding plane and the Snort virtual container service. Guest IP addresses must be configured for these VirtualPortGroup interfaces. The IP subnet assigned to the management VirtualPortGroup interface should be able to communicate with the Signature server and Alert/Reporting server.
The IP subnet of the second VirtualPortGroup interface must not be routable on the customer network because the traffic on this interface is internal to the router. Exposing the internal subnet to the outside world is a security risk. We recommend the use of 192.0.2.0/30 IP address range for the second VirtualPortGroup subnet. The use of 192.0.2.0/24 subnet is defined in RFC 3330.
You can assign the Snort virtual container service IP address on the same management network as the router on which the virtual service is running. This configuration helps if the syslog or update server is on the management network and is not accessible by any other interfaces
Multi-tenancy for Unified Threat Defense is only supported on the Cisco CSR 1000v.
Domain-based filtering is not supported.
Up to 25 tenants are supported on each Cisco CSR 1000v instance.
A maximum of 25 policies are supported.
A maximum of 50,000 concurrent sessions are supported on a Cisco CSR 1000v.
Bringing up (or reloading/updating) the Snort IPS/IDS package may take up to 20 minutes, depending on the number of policies configured with threat inspection. Updating the signatures will reload Snort IPS and will also take up to 20 minutes.
The blacklist/whitelist rules support only a regular expression (regex) pattern. Currently, 64 patterns are supported for each blacklist/whitelist rule. However, each tenant can have multiple rules.
Local block server does not support serving HTTPS block page.When the URL filter tries to inject block page or redirect message, it does not support HTTPS traffic.
When there is a username and password in the URL, URL filter does not remove them from the URL before matching the whitelist/blacklist pattern. However, the category/reputation lookup does not have this limitation and removes the username and password from the URL before lookup.
HTTPS inspection is limited. Web filtering uses server certificate to obtain the URL/domain information. It is not possible to inspect the full URL path.
UTD does not inter-operate with WCCP, and NBAR under inter-VRF scenario.
The Snort IPS command threat inspection profile profile-name uses an alphanumeric profile-name, not an ID (number).
Before you configure the multi-tenancy for UTD feature on the Cisco CSR 1000v, ensure that the router is set up as follows:
The Cisco CSR 1000v running Cisco IOS XE Everest 16.6.1 or later.
The Cisco CSR 1000v must have a security K9 license to enable web filtering.
The Cisco CSR 1000v "multi-tenancy" profile requires the following virtual service System CPU, virtual service Memory, and Platform Requirements:
System CPU—25%
Platform Memory Requirements—Min. 12GB RAM (8GB disk/flash)
To deploy multi-tenancy for Unified Threat Defense on supported devices, perform the following tasks:
Provision the device upon which you wish to install web filtering and threat inspection for multi-tenancy. This feature is currently only supported on the Cisco CSR 1000v.
Obtain the license. UTD is available only for routers running security packages and you will require a security license to enable the service. Contact Cisco Support to obtain a security license.
1. Install and activate the virtual-service: Installing the UTD OVA File for Multi-Tenancy.
2. Configure the VirtualPortGroup interfaces and the virtual-service: How to Configure VirtualPortGroup Interfaces and Virtual Service for Multi-Tenancy.
3. Configure the VRFs: How to Configure VRFs for Multi-Tenancy.
4. Configure threat inspection and web filtering for multi-tenancy: How to Configure Multi-Tenancy Web Filtering and Threat Inspection
Step 1 | Install and activate the virtual-service: Installing the UTD OVA File for Multi-Tenancy. |
Step 2 | Configure the VirtualPortGroup interfaces and the virtual-service: How to Configure VirtualPortGroup Interfaces and Virtual Service for Multi-Tenancy. |
Step 3 | Configure the VRFs: How to Configure VRFs for Multi-Tenancy. |
Step 4 | Configure threat inspection and web filtering for multi-tenancy: How to Configure Multi-Tenancy Web Filtering and Threat Inspection |
The virtual-service OVA file is an Open Virtualization Archive file that contains a compressed, installable version of a virtual machine. You must download this OVA file to the router and then install the virtual-service. The virtual-service OVA file is not bundled with Cisco IOS XE release images that are installed on the router. OVA files may be available pre-installed in the router's flash memory.
For installing the OVA file, you must use a Cisco IOS XE image with a security license. During installation, the security license is checked.
Example of installing the virtual service:
Device> enable Device# virtual-service install name utd package bootflash:utdsnort.1.0.4_SV2983_XE_16_6.20170623_174453_RELEASE.ova Device# show virtual-service list Name Status Package Name ------------------------------------------------------------------------------ utd Activated utdsnort.1.0.4_SV2983_XE_16_6.20170
Example of upgrading the virtual service:
Device> enable Device# virtual-service upgrade name utd package bootflash:utdsnort.1.0.4_SV2983_XE_16_6.20170623_174453_RELEASE.ova Device# show virtual-service list Name Status Package Name ------------------------------------------------------------------------------ utd Activated utdsnort.1.0.4_SV2983_XE_16_6.20170
Example of uninstalling the virtual service:
Device> enable Device# virtual-service uninstall name utd Device# show virtual-service list Virtual Service List:
As shown in this procedure, for multi-tenancy you must configure two VirtualPortGroup interfaces and guest IP addresses for both interfaces.
Note | The VirtualPortGroup interface for data traffic must use a private or nonroutable IP address. We recommend the use of 192.0.2.0/30 IP address range for this interface. |
1.
enable
2.
configure
terminal
3.
interface VirtualPortGroup
interface-number
4.
ip address ip-address mask
5.
exit
6.
interface VirtualPortGroup
interface-number
7.
ip address ip-address mask
8.
exit
9.
virtual-service name
10.
profile multi-tenancy
11.
vnic gateway VirtualPortGroup interface-number
12.
guest ip address ip-address
13.
exit
14.
vnic gateway VirtualPortGroup
interface-number
15.
guest ip address ip-address
16.
exit
17.
activate
18.
end
19.
show virtual-service list
Note | For inter-VRF traffic, if the traffic flowing between two VRFs has ingress and egress interfaces configured for UTD, rules are applied to decide which VRF represents the session. The UTD policy for the selected VRF then applies to all packets in the inter-VRF traffic. |
1.
vrf definition
vrf-name
2.
rd route-distinguisher
3.
address-family ipv4
4.
exit address-family
5. Repeat steps 1 to 4 for each VRF.
To configure threat inspection (IPS/IDS) and web filtering for multi-tenancy (multiple tenants/VRFs), perform the following steps.
In this procedure, the definition of blacklist and whitelists are shown in the initial steps 1 to 5. The main configuration steps (in UTD standard engine configuration mode for multi-tenancy) are shown in step 6 onwards.
Note | For details about threat inspection and web filtering for single-tenancy, see Snort IPS and Web Filtering. |
Remove any existing single-tenancy UTD configuration, using the no utd engine standard command.
You must have previously configured a VRF for each tenant—see How to Configure VRFs for Multi-Tenancy.Command or Action | Purpose | |||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Step 1 | parameter-map type regex
blacklist-name
Example: Device(config)# parameter-map type regex urlf-blacklist1 |
Defines a blacklist parameter map, which is used later in step 17. | ||||||||||||||||||
Step 2 | pattern
URL-name Example: Device(config-profile)# pattern www\.cnn\.com Device(config-profile)# pattern www\.msnbc\.com |
Defines the URL to be blacklisted. Note that the periods within URL-name must be preceded by an escape "\" character. Repeat this step to configure multiple URLs to be blacklisted. | ||||||||||||||||||
Step 3 | parameter-map type regex
whitelist-name Example: Device(config-profile)# parameter-map type regex urlf-whitelist1 |
Defines a whitelist parameter map, which is used later in step 20. | ||||||||||||||||||
Step 4 | pattern
URL-name Example: Device(config-profile)# pattern www\.nfl\.com |
Defines the URL(s) to be whitelisted. Note that, as for the blacklist, periods within URL-name must be preceded by an escape "\" character. Repeat this step to configure multiple URLs to be whitelisted. | ||||||||||||||||||
Step 5 | exit
Example: Device(config-profile)# exit | |||||||||||||||||||
Step 6 |
utd multi-tenancy Example: Device(config)# utd multi-tenancy |
This command acts a switch, in preparation for the following utd engine standard multi-tenancy command. | ||||||||||||||||||
Step 7 |
utd engine standard multi-tenancy
Example: Device(config)# utd engine standard multi-tenancy |
Enters UTD standard engine configuration mode for multi-tenancy.
| ||||||||||||||||||
Step 8 | web-filter sourcedb
sourcedb-number Example: Device(config)# web-filter sourcedb 1 |
Configures a web filtering sourcedb profile—sourcedb-number, which is numeric. This is used later in step 29. | ||||||||||||||||||
Step 9 | logging level
{alerts
|
critical
|
debugging
|
emergencies
|
errors
|
informational
|
notifications
|
warnings} Example: Device(config)# logging level errors |
Sets the level of system messages that are reported upon for web filtering events. Messages of the specified level and lower are reported. (Each level has a numeric value as shown in the table below.)
| ||||||||||||||||||
Step 10 | web-filter block local-server profile profile-id Example: Device(config-utd-multi-tenancy)# web-filter block local-server profile 1 The content text is displayed by the local server. |
Configures the a local block server profile for web filtering. The range of values for profile-id is 1–255. See Configure URL-based Web Filtering with a Local Block Server.
| ||||||||||||||||||
Step 11 | block-page-interface loopback
id Example: Device(config-utd-mt-webf-blk-srvr)# block-page-interface loopback 110 |
Associates a loopback interface with this profile. The IP address of this loopback interface is then used as the IP address of the block local-server. | ||||||||||||||||||
Step 12 | content text
display-text Example: Device(config-utd-mt-webf-blk-srvr)# content text "Blocked by Web-Filter" |
Specifies the warning text that appears after a blocked page is accessed. | ||||||||||||||||||
Step 13 | http-ports
port-number Example: Device(config-utd-mt-webf-blk-srvr)# http-ports 80 |
The http-ports value is a string of ports separated by commas. The nginx HTTP server listens to these ports. | ||||||||||||||||||
Step 14 | web-filter block page profile
profile-name Example: Device(config-utd-multi-tenancy)# web-filter block page profile 1 Device(config-utd-mt-webf-block-urc)# text "this page is blocked" |
See Configure URL-based Web Filtering with an Inline Block Page, except that the command used here for multi-tenancy does not use the utd keyword which is used for single-tenancy.). | ||||||||||||||||||
Step 15 | web-filter url profile
web-filter-profile-id
Example: Device(config-utd-multi-tenancy)# web-filter url profile 1 Device(config-utd-mt-webfltr-url)# |
Specifies a URL profile for web filtering—web-filter-profile-id. Values: 1–255. After this command, you can configure alerts for blacklists, whitelists, and categories. For further information, see: Configure URL-based Web Filtering with an Inline Block Page.
| ||||||||||||||||||
Step 16 | blacklist Example: Device(config-utd-mt-webfltr-url)# blacklist |
Enters web filtering blacklist configuration mode. | ||||||||||||||||||
Step 17 | parameter-map regex
blacklist-name Example: Device(config-utd-mt-webf-url-bl)# parameter-map regex urlf-blacklist1 |
Specifies a parameter-map regular expression using the blacklist that was defined earlier in step 1. | ||||||||||||||||||
Step 18 | exit Example: Device(config-utd-mt-webf-url-bl)# exit Device(config-utd-mt-webfltr-url)# |
Exits web filtering blacklist configuration mode. | ||||||||||||||||||
Step 19 | whitelist Example: Device(config-utd-mt-webfltr-url)# whitelist Device(config-utd-mt-webf-url-wl)# |
Enters web filtering whitelist configuration mode. | ||||||||||||||||||
Step 20 | parameter-map regex whitelist-name Example: Device(config-utd-mt-webf-url-wl)# parameter-map regex urlf-whitelist1 |
Specifies a parameter-map regular expression using the whitelist that was defined earlier in step 3. | ||||||||||||||||||
Step 21 | exit Example: Device(config-utd-mt-webf-url-wl)# exit Device(config-utd-mt-webfltr-url)# |
Exits web filtering whitelist configuration mode. | ||||||||||||||||||
Step 22 | exit Example: Device(config-utd-mt-webfltr-url)# exit Device(config-utd-multi-tenancy)# |
Exits web filtering URL profile mode. | ||||||||||||||||||
Step 23 | utd global Example: Device(config-utd-multi-tenancy)# utd global |
The commands entered for utd global apply to all tenants or policies e.g the commands shown below: logging server syslog and threat inspection for this Cisco CSR 1000v instance. | ||||||||||||||||||
Step 24 | logging
host
[{ip-address|host-name}
] Example:In this example, alerts are logged to a designated host log file. Device(config-utd-mt-utd-global)# logging host systemlog1 Example:In this example, alerts are logged to IOS syslogs. Device(config-utd-mt-utd-global)# logging syslog |
The logging command specifies either a host name or IOS syslog, to which syslog messages are sent. | ||||||||||||||||||
Step 25 | threat inspection Example: Device(config-utd-mt-utd-global)# threat inspection |
Enters global threat inspection mode. | ||||||||||||||||||
Step 26 |
signature update server {cisco | url url } [username username [password password]]
Example: Device(config-utd-mt-utd-global-threat)# signature update server cisco username abcd password cisco123 |
Configures the signature update server parameters. You must specify the signature update parameters with the server details. If you use www.cisco.com for signature updates, you must provide the username and password. If you use a local server for signature updates, based on the server settings you can provide the username and password. The router must be able to resolve the domain name by being connected to the internet. | ||||||||||||||||||
Step 27 |
signature update occur-at {daily | monthly
day-of-month | weekly day-of-week} hour minute
Example: Device(config-utd-mt-utd-global-threat)# signature update occur-at daily 0 0 |
Configures the signature update interval parameters. This configuration will trigger the signature update to occur at midnight. | ||||||||||||||||||
Step 28 | web-filter Example: Device(config-utd-mt-utd-global-threat)# web-filter |
This command, used in combination with the following sourcedb command, specifies the URL source database for web filtering. | ||||||||||||||||||
Step 29 | sourcedb
sourcedb-number Example: Device(config-utd-mt-utd-global-threat)# sourcedb 1 |
Assigns a web filtering source database. Only one source database can be active. | ||||||||||||||||||
Step 30 | exit Example: Device(config-utd-mt-utd-global-threat)# exit |
Exits threat inspection configuration mode. | ||||||||||||||||||
Step 31 | exit Example: Device(config-utd-mt-global)# exit |
Exits global update configuration mode. | ||||||||||||||||||
Step 32 | threat-inspection whitelist profile
policy-name
Example: Device(config-utd-multi-tenancy)# threat-inspection whitelist profile wh101 |
Associates a whitelist profile with the policy currently being configured. A similar command is used in single-tenancy, but with a utd keyword. | ||||||||||||||||||
Step 33 | signature id id Example: Device(config-utd-mt-whitelist)# signature id 101 |
Specify the ID id that you have previously identified as a threat; for example, after observing the ID in an alert log file. Repeat this command for multiple signature IDs. | ||||||||||||||||||
Step 34 | exit Example:Device(config-utd-mt-whitelist)# exit |
Exits whitelist configuration mode. | ||||||||||||||||||
Step 35 | threat-inspection profile
profile-name Example: Device(config-utd-multi-tenancy)# threat-inspection profile 101 |
Configures a threat inspection profile, which can be reused by multiple tenants. You can configure multiple threat-inspection profiles. Within a profile you can configure multiple whitelists. profile-name is alphanumeric. | ||||||||||||||||||
Step 36 | threat {detection | protection }
Example: Device(config-utd-mt-threat)# threat protection |
Specifies Intrusion Detection System (IDS) or Intrusion Prevention System (IPS) as the operating mode for the Snort engine. The default is threat detection | ||||||||||||||||||
Step 37 |
policy {balanced | connectivity | security}
Example: Device(config-utd-mt-threat)# policy security |
Configures the security policy for the Snort engine. | ||||||||||||||||||
Step 38 | logging level{alert |
crit | debug | emerg |err | info |
notice | warning} |
Provides logs in one of these categories:
| ||||||||||||||||||
Step 39 |
whitelist profile
profile-name
Example: Device(config-utd-mt-threat)# whitelist profile wh101 |
You can also specify whitelist profiles in a profile only for whitelists in another place—the threat-inspection whitelist profile command above. (Optional) Enables whitelisting under the UTD engine. | ||||||||||||||||||
Step 40 | exit Example:Device(config-utd-mt-threat)# exit |
Exits threat inspection mode. | ||||||||||||||||||
Step 41 | Repeat steps 35 to 40 to add additional threat-inspection profiles. | |||||||||||||||||||
Step 42 | policy policy-name Example: Device(config-utd-multi-tenancy)# policy pol101 |
Defines the policy that will be associated with multiple tenants. A threat detection (IPS) and web filtering profile are added to the policy. | ||||||||||||||||||
Step 43 |
vrf
[
vrf-name |
global
]
Example:This example shows the configuration of two tenants (VRFs) and two policies. Device(config-utd-mt-policy)# vrf vrf101 |
Repeat the vrf vrf-name command for each of the VRFs (tenants) that will use the UTD policy. These VRFs previously defined, see: How to Configure VRFs for Multi-Tenancy. Alternatively use vrf global to associate with the global (default) VRF and enables VRF under the interface. | ||||||||||||||||||
Step 44 | all-interfaces Example:Device(config-utd-mt-policy)# all-interfaces |
(Optional) Associates all interfaces under the VRF with the policy. | ||||||||||||||||||
Step 45 | threat-inspection profile
profile-name Example: Device(config-utd-mt-policy)# threat-inspection profile 101 |
(Optional) Associates the policy with a previously defined threat inspection profile, see Step 35. | ||||||||||||||||||
Step 46 | web-filter url profile
web-filter-profile-id Example:Device(config-utd-mt-policy)# web-filter url profile 1 |
(Optional) Associates the policy with a previously defined web filtering profile, see step 15. | ||||||||||||||||||
Step 47 | fail close Example:Device(config-utd-mt-policy)# fail close |
(Optional) Drops IPS/IDS packets on engine failure. Default is fail open. | ||||||||||||||||||
Step 48 | exit |
Exits from policy configuration mode. | ||||||||||||||||||
Step 49 | Repeat steps 42 to 48 for each policy | |||||||||||||||||||
Step 50 | exit Example: Device(config-utd-multi-tenancy)# exit |
Exits the utd engine standard multi-tenancy mode. The policy configurations are applied, which may take a few minutes. During this time, further utd engine standard multi-tenancy configuration mode commands cannot be entered. | ||||||||||||||||||
Step 51 | exit Example: Device(config)# exit Device# | |||||||||||||||||||
Step 52 | show logging Example: Device(config)# show logging ..UTD MT configuration download has started ..UTD MT configuration download has completed |
(Optional) Shows log messages that confirm whether policy configurations have been applied. Look for messages such as the following: ..UTD MT configuration download has started ..UTD MT configuration download has completed The message that includes "download has completed" shows that the policy configurations have been applied. | ||||||||||||||||||
Step 53 | interface
sub-interface Example: Device(config)# interface GigabitEthernet4.101 |
Specify a sub-interface to be used for the tenant (VRF). | ||||||||||||||||||
Step 54 | encapsulation dot1Q
vlan-id Example: Device(config-if)# encapsulation dot1Q 101 |
Applies a VLAN ID to the sub-interface. | ||||||||||||||||||
Step 55 | ip vrf forwarding
vrf-name Example: Device(config-if)# ip vrf forwarding vrf101 | Associates a VRF instance with the sub-interface. | ||||||||||||||||||
Step 56 | ip address
ip-address subnet-mask Example: Device(config-if)# ip address 111.0.0.1 255.255.255.0 |
Specifies the sub-interface IP address of the VRF. | ||||||||||||||||||
Step 57 | ip route
ip-address
subnet-mask
sub-interface Example:In this example, the VRF's subnet GigabitEthernet4.101 is linked to the global routing table using the static IP address 111.0.0.0 255.255.255.0. Device(config-if)# ip route 111.0.0.0 255.255.255.0 GigabitEthernet4.101 |
(Optional) This ip route command and the ip route vrf command in the following step are optional—you can use these steps if you want to configure route leaking using a static route between the VRF and the global routing table. This configures a static route to the VRF subnet from the VRF interface, so that the VRF subnet is accessible from the global routing table. For further information on configuring route leaking, see Route Leaking in MPLS/VPN Networks. | ||||||||||||||||||
Step 58 | ip route vrf
vrf-name
ip-address
subnet-mask
global
Example: Device(config-if)# ip route vrf vrf101 0.0.0.0 0.0.0.0 5.2.1.1 global |
(Optional) This step and the previous step are optional——you can use these steps if you want to configure route leaking using a static route between the VRF and the global routing table. For further information on configuring route leaking, see Route Leaking in MPLS/VPN Networks. Specifies the static VRF default route to the global routing table. | ||||||||||||||||||
Step 59 | utd enable |
(Optional) Enables UTD on an interface. You can use this command if the all-interfaces command was not configured (in step 44). | ||||||||||||||||||
Step 60 | To configure a sub-interface for each tenant (VRF), repeat steps 53 to 59. | |||||||||||||||||||
Step 61 | exit
|
Exits interface configuration mode. |
The profiles for web filtering and threat inspection (IPS) have now been applied.
This example shows a typical running configuration after configuring Multi-Tenancy for UTD for two tenants.
Note | The following example mentions parameter maps urlf-blacklist1 and urlf-whitelist1. The configuration of these parameter maps is not shown in the example. For further information on blacklist and whitelist parameter-maps, see Configure URL-based Web Filtering with an Inline Block Page. |
utd multi-tenancy utd engine standard multi-tenancy web-filter block page profile 1 text “This page is blocked" web-filter block page profile 2 text “This page is blocked" web-filter url profile 1 alert all blacklist parameter-map regex urlf-blacklist1 whitelist parameter-map regex urlf-whitelist1 categories block social-network sports block page-profile 1 log level error web-filter url profile 2 alert all blacklist parameter-map regex urlf-blacklist2 categories block shopping news-and-media sports real-estate motor-vehicles block page-profile 2 log level error reputation block-threshold low-risk web-filter sourcedb 1 logging level error threat-inspection whitelist profile wh101 signature id 101 threat-inspection profile 101 threat protection policy security logging level debug whitelist profile wh101 threat-inspection profile 102 threat detection policy security logging level debug utd global logging host 172.27.58.211 logging host 172.27.58.212 logging host 172.27.56.97 threat-inspection signature update server cisco username abc password ]RDCe[B\^KFI_LgQgCFeBEKWP^SWZMZMb]KKAAB signature update occur-at daily 0 0 web-filter sourcedb 1 policy pol102 vrf vrf102 all-interfaces threat-inspection profile 102 web-filter url profile 2 policy pol101 vrf vrf101 all-interfaces threat-inspection profile 101 web-filter url profile 1 fail close
Use the following commands to verify your configuration.
1.
enable
2.
show
utd multi-tenancy
3.
show utd engine standard global
4.
show utd engine standard status
5.
show utd engine standard statistics
6.
show utd engine standard statistics daq [
dp
|
cp
]
7.
show utd engine standard statistics url-filtering
8.
show utd engine standard statistics url-filtering vrf name
vrf-name
9.
show utd engine standard statistics internal
10.
show utd engine standard logging event
11.
show logging |
include
CONFIG_DOWNLOAD
12.
show utd threat-inspection whitelist
[profile profile-name]
13.
show
utd threat-inspection
profile
profile-name
14.
show utd [policy
profile-name]
15.
show utd web-filter
url
[profile profile-name]
16.
show utd web-filter
block
local-server
[profile profile-name]
17.
show utd web-filter
sourcedb
[profile profile-name]
18.
show utd
engine
standard
statistics
daq
dp
[engine
engine-num]
[vrf [name
vrf-name
|global]]
19.
show
utd
engine
standard
config
threat-inspection
whitelist
[profile
profile-name
]
20.
show
utd
engine
standard
config
web-filter
url profile
profile-name
21.
show utd engine standard config
[vrf
name
vrf-name
]
22.
show utd engine standard config
threat-inspection
profile
profile-name
23.
show utd engine standard threat-inspection
signature
update
status
24.
show platform software qfp active feature utd config
[
vrf[ {id
vrf-id
|
name
vrf-name|global
} ]
25.
show platform software utd interfaces
26.
show platform hardware qfp active feature utd config
[vrf {id
vrf-id
|
name
vrf-name|global
} ]
27.
show platform hardware qfp active feature utd stats [clear
| divert
| drop
|
general
|
summary]
[vrf
{id
vrf-id
|
name
vrf-name
|
global
}]
[all]
[verbose]
28.
show platform hardware qfp active feature utd stats
summary
[vrf name vrf-name
|
all]
29.
show platform hardware qfp active feature utd stats
drop all
Device# show virtual-service list Virtual Service List: Name Status Package Name ------------------------------------------------------------------------------ snort Activated utdsnort.1_0_1_SV2982_XE_16_3.20160701_131509.ova
Device# show platform software utd global UTD Global state Engine : Standard Global Inspection : Disabled Operational Mode : Intrusion Prevention Fail Policy : Fail-open Container techonlogy : LXC Redirect interface : VirtualPortGroup1 UTD interfaces GigabitEthernet0/0/0
Device# show platform hardware qfp active feature utd config Global configuration NAT64: disabled SN threads: 12 CFT inst_id 0 feat id 0 fo id 0 chunk id 4 Context Id: 0, Name: Base Security Ctx Ctx Flags: (0x60000) Engine: Standard SN Redirect Mode : Fail-open, Divert Threat-inspection: Enabled, Mode: IDS Domain Filtering : Not Enabled URL Filtering : Not Enabled SN Health: Green
Device# show platform hardware qfp active feature utd config vrf name vrf102 Global configuration NAT64: disabled Drop pkts: disabled Multi-tenancy: enabled Data plane initialized: yes SN threads: 12 CFT inst_id 0 feat id 0 fo id 0 chunk id 4 SN Health: Green
Device# show virtual-service detail Virtual service UTDIPS detail State : Activated Owner : IOSd Package information Name : utdsnort.1_0_1_SV2982_XE_16_3.20160701_131509.ova Path : bootflash:/utdsnort.1_0_1_SV2982_XE_16_3.20160701_131509.ova Application Name : UTD-Snort-Feature Installed version : 1.0.1_SV2982_XE_16_3 Description : Unified Threat Defense Signing Key type : Cisco development key Method : SHA-1 Licensing Name : Not Available Version : Not Available Detailed guest status ---------------------------------------------------------------------- Process Status Uptime # of restarts ---------------------------------------------------------------------- climgr UP 0Y 0W 0D 0: 0:35 1 logger UP 0Y 0W 0D 0: 0: 4 0 snort_1 UP 0Y 0W 0D 0: 0: 4 0 Network stats: eth0: RX packets:43, TX packets:6 eth1: RX packets:8, TX packets:6 Coredump file(s): lost+found Activated profile name: None Resource reservation Disk : 736 MB Memory : 1024 MB CPU : 25% system CPU Attached devices Type Name Alias --------------------------------------------- NIC ieobc_1 ieobc NIC dp_1_0 net2 NIC dp_1_1 net3 NIC mgmt_1 mgmt Disk _rootfs Disk /opt/var Disk /opt/var/c Serial/shell serial0 Serial/aux serial1 Serial/Syslog serial2 Serial/Trace serial3 Watchdog watchdog-2 Network interfaces MAC address Attached to interface ------------------------------------------------------ 54:0E:00:0B:0C:02 ieobc_1 A4:4C:11:9E:13:8D VirtualPortGroup0 A4:4C:11:9E:13:8C VirtualPortGroup1 A4:4C:11:9E:13:8B mgmt_1 Guest interface --- Interface: eth2 ip address: 48.0.0.2/24 Interface: eth1 ip address: 47.0.0.2/24 --- Guest routes --- Address/Mask Next Hop Intf. ------------------------------------------------------------------------------- 0.0.0.0/0 48.0.0.1 eth2 0.0.0.0/0 47.0.0.1 eth1 --- Resource admission (without profile) : passed Disk space : 710MB Memory : 1024MB CPU : 25% system CPU VCPUs : Not specified
Device# show service-insertion type utd service-node-group Service Node Group name : utd_sng_1 Service Context : utd/1 Member Service Node count : 1 Service Node (SN) : 30.30.30.2 Auto discovered : No SN belongs to SNG : utd_sng_1 Current status of SN : Alive Time current status was reached : Tue Jul 26 11:57:48 2016 Cluster protocol VPATH version : 1 Cluster protocol incarnation number : 1 Cluster protocol last sent sequence number : 1469514497 Cluster protocol last received sequence number: 1464 Cluster protocol last received ack number : 1469514496
Device# show service-insertion type utd service-context Service Context : utd/1 Cluster protocol VPATH version : 1 Time service context was enabled : Tue Jul 26 11:57:47 2016 Current FSM state : Operational Time FSM entered current state : Tue Jul 26 11:57:58 2016 Last FSM state : Converging Time FSM entered last state : Tue Jul 26 11:57:47 2016 Cluster operational state : Operational Stable AppNav controller View: 30.30.30.1 Stable SN View: 30.30.30.2 Current AppNav Controller View: 30.30.30.1 Current SN View: 30.30.30.2
Device# show platform hardware qfp active feature utd stats Security Context: Id:0 Name: Base Security Ctx Summary Statistics: Active Connections 29 TCP Connections Created 712910 UDP Connections Created 80 Pkts entered policy feature pkt 3537977 byt 273232057 Pkts entered divert feature pkt 3229148 byt 249344841 Pkts slow path pkt 712990 byt 45391747 Pkts Diverted pkt 3224752 byt 249103697 Pkts Re-injected pkt 3224746 byt 249103373 ….
Device# show platform hardware qfp active feature utd stats vrf name vrf 101 Security Context: Id:1 Name: 1 : vrf101 Summary Statistics: Active Connections 2 TCP Connections Created 34032 UDP Connections Created 11448 ICMP Connections Created 80 Pkts dropped pkt 626 byt 323842 Pkts entered policy feature pkt 995312 byt 813163885 Pkts entered divert feature pkt 639349 byt 420083106 Pkts slow path pkt 45560 byt 7103132 Pkts Diverted pkt 638841 byt 419901335 Pkts Re-injected pkt 630642 byt 412139098 ….
Device# show utd eng standard threat-inspection signature update status Current signature package version: 29.0.c Current signature package name: default Previous signature package version: None --------------------------------------- Last update status: Failed --------------------------------------- Last successful update time: None Last successful update method: None Last successful update server: None Last successful update speed: None --------------------------------------- Last failed update time: Thu Jan 11 13:34:36 2018 PST Last failed update method: Manual Last failed update server: http://172.27.57.252/UTD-STD-SIGNATURE-2983-1-S.pkg Last failed update reason: [Errno 113] No route to host --------------------------------------- Last attempted update time: Thu Jan 11 13:34:36 2018 PST Last attempted update method: Manual Last attempted update server: http://172.27.57.252/UTD-STD-SIGNATURE-2983-1-S.pkg --------------------------------------- Total num of updates successful: 0 Num of attempts successful: 0 Num of attempts failed: 1 Total num of attempts: 1 --------------------------------------- Next update scheduled at: None --------------------------------------- Current status: Idle
Device# show run | i name-server ip name-server 10.104.49.223
Device# show utd engine standard config UTD Engine Standard Configutation: Operation Mode : Intrusion Prevention Policy : Security Signature Update: Server : cisco User Name : ccouser Password : YEX^SH\fhdOeEGaOBIQAIcOVLgaVGf Occurs-at : weekly ; Days:0 ; Hour: 23; Minute: 50 Logging: Server : IOS Syslog; 10.104.49.223 Level : debug Whitelist Signature IDs: 28878
Device# show utd engine standard logging events 2016/06/13-14:32:09.524475 IST [**] [Instance_ID: 1] [**] Drop [**] [1:30561:1] BLACKLIST DNS request for known malware domain domai.ddns2.biz - Win.Trojan.Beebone [**] [Classification: A Network Trojan was Detected] [Priority: 1] [VRF_ID: 2] {UDP} 11.1.1.10:58016 -> 21.1.1.10:53 2016/06/13-14:32:21.524988 IST [**] [Instance_ID: 1] [**] Drop [**] [1:30561:1] BLACKLIST DNS request for known malware domain domai.ddns2.biz - Win.Trojan.Beebone [**] [Classification: A Network Trojan was Detected] [Priority: 1] [VRF_ID: 2] {UDP} a000:0:0:0:0:0:0:10:59964 -> b000:0:0:0:0:0:0:10:53
ps -eaf | grep syslog root 2073 1 0 Apr12 ? 00:00:02 syslogd -r -m
Conditional debugging is supported by multi-tenancy for Unified Threat Defense. For further details about how to configure conditional debugging, see:
http://www.cisco.com/c/en/us/td/docs/routers/asr1000/troubleshooting/guide/Tblshooting-xe-3s-asr-1000-book.html#task_AC969BB06B414DCBBDEF7ADD29EF8131