Step 1 |
parameter-map type regex
blacklist-name
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
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
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
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
Device(config-profile)# exit
|
|
Step 6 |
utd multi-tenancy
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
Device(config)# utd engine standard multi-tenancy
|
Enters UTD standard engine configuration mode for multi-tenancy.
Note
|
Later. after you exit the UTD standard engine configuration mode in step 50, the policy configurations are applied.
|
|
Step 8 |
web-filter sourcedb
sourcedb-number
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}
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.)
Table 1. System Message Severity Levels
Level
|
Description
|
0 – emergencies
|
System unusable
|
1 – alerts
|
Immediate action needed
|
2 – critical
|
Critical condition
|
3 – errors
|
Error condition
|
4 – warnings
|
Warning condition
|
5 – notifications
|
Normal but significant condition
|
6 – informational
|
Informational messages only
|
7 – debugging
|
Appears during debugging only
|
|
Step 10 |
web-filter block local-server profile profile-id
Device(config-utd-multi-tenancy)# web-filter block local-server profile 1
The content text is displayed by the local server.
|
|
Step 11 |
block-page-interface loopback
id
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
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
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
Device(config-utd-multi-tenancy)# web-filter block page profile 1
Device(config-utd-mt-webf-block-urc)# text "this page is blocked"
|
|
Step 15 |
web-filter url profile
web-filter-profile-id
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.
Note
|
When configuring commands for multi-tenancy, compared to single-tenancy, you do not use an initial utd keyword.
|
|
Step 16 |
blacklist
Device(config-utd-mt-webfltr-url)# blacklist
|
Enters web filtering blacklist configuration mode.
|
Step 17 |
parameter-map regex
blacklist-name
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
Device(config-utd-mt-webf-url-bl)# exit
Device(config-utd-mt-webfltr-url)#
|
Exits web filtering blacklist configuration mode.
|
Step 19 |
whitelist
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
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
Device(config-utd-mt-webf-url-wl)# exit
Device(config-utd-mt-webfltr-url)#
|
Exits web filtering whitelist configuration mode.
|
Step 22 |
exit
Device(config-utd-mt-webfltr-url)# exit
Device(config-utd-multi-tenancy)#
|
Exits web filtering URL profile mode.
|
Step 23 |
utd global
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}
]
In this example, alerts are logged to a designated host log file.Device(config-utd-mt-utd-global)# logging host systemlog1
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
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]]
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
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
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
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
Device(config-utd-mt-utd-global-threat)# exit
|
Exits threat inspection configuration mode.
|
Step 31 |
exit
Device(config-utd-mt-global)# exit
|
Exits global update configuration mode.
|
Step 32 |
threat-inspection whitelist profile
policy-name
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
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
Device(config-utd-mt-whitelist)# exit
|
Exits whitelist configuration mode.
|
Step 35 |
threat-inspection profile
profile-name
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 }
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}
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:
-
alert—provides alert level logs (severity=2)
-
crit—critical level logs (severity=3)
-
debug—all logs (severity=8)
-
emerg—emergency level logs (severity=1)
-
err—error level logs (severity=4) Default.
-
info—info level logs (severity=7)
-
notice—notice level logs (severity=6)
-
warning—warning level logs (severity=5)
|
Step 39 |
whitelist profile
profile-name
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
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
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
]
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
Device(config-utd-mt-policy)# all-interfaces
|
(Optional) Associates all interfaces under the VRF with the policy.
|
Step 45 |
threat-inspection profile
profile-name
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
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
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
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
Device(config)# exit
Device#
|
|
Step 52 |
show logging
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
Device(config)# interface GigabitEthernet4.101
|
Specify a sub-interface to be used for the tenant (VRF).
|
Step 54 |
encapsulation dot1Q
vlan-id
Device(config-if)# encapsulation dot1Q 101
|
Applies a VLAN ID to the sub-interface.
|
Step 55 |
ip vrf forwarding
vrf-name
Device(config-if)# ip vrf forwarding vrf101
|
Associates a VRF instance with the sub-interface.
|
Step 56 |
ip address
ip-address subnet-mask
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
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
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.
|