The first verification step is to check whether the router's app-hosting environment (IOx) is up and running. IOx combines Cisco IOS with Linux OS to provide a flexible platform to host applications. We check the status of the IOx environment using the sh iox-service command.
cEdge-3# show iox-service
IOx Infrastructure Summary:
---------------------------
IOx service (CAF) : Running
IOx service (HA) : Not Supported
IOx service (IOxman) : Running
IOx service (Sec storage) : Not Supported
Libvirtd 5.5.0 : RunningIf the IOx environment is running, we need to check whether the LxC container that hosts the UTD virtual image is running, as shown below.
cEdge-3# show app-hosting list
App id State
---------------------------------------------------------
utd RUNNINGYou can see that one LxC container with id “utd” is currently running. To see the details of the LxC container, we use the show app-hosting detail command.
cEdge-3# show app-hosting detail appid utd
App id : utd
Owner : ioxm
State : RUNNING
Application
Type : LXC
Name : UTD-Snort-Feature
Version : 1.0.1_SV3.3.5.0_XE26.1
Description : Unified Threat Defense
Network interfaces
---------------------------------------
Network stats:
ieobc: RX packets:86871, TX packets:86877
eth0: RX packets:7808, TX packets:11013
DNS server:
nameserver 208.67.222.222
nameserver 208.67.220.220
Interface: eth1
ip address: 192.0.2.2/30
Interface: eth0
ip address: 192.1.0.2/16
Address/Mask Next Hop Intf.
-------------------------------------------------------------------------
0.0.0.0/0 192.0.2.1 eth1
0.0.0.0/0 192.1.0.1 eth0 From the output, we can see that the UTD container has two interfaces – eth0 and eth1. The first interface is used to source logs to log collectors and pull signature updates from Cisco’s repository. The second interface is used to forward packets that arrive on the data plane for UTD inspection. The diagram below shows a simplified illustration of the app-hosting environment.
Notice that when you configure UTD using NGFW policy, vManage automatically configures the 192.0.2.0/30 IP address range on the VPG interface for data traffic in VPN0. The use of this subnet (192.0.2.0/24) is defined in RFC3330. You must not use 192.0.2.0/24 anywhere else within the SD-WAN domain.
The interfaces of the UTD container should be visible on the show ip int brief command, as you can see in the following CLI output.
cEdge-3# show ip int brief
Interface IP-Address OK? Method Status Protocol
GigabitEthernet1 39.3.3.1 YES other up up
GigabitEthernet2 10.10.3.1 YES other up up
...
NVI0 unassigned YES unset up up
Tunnel1 39.3.3.1 YES TFTP up up
Tunnel2 10.10.3.1 YES TFTP up up
Tunnel2000000001 192.168.2.1 YES unset up up
Tunnel2000000002 192.168.2.1 YES unset up up
Tunnel2000000003 192.0.2.1 YES unset up up
VirtualPortGroup0 192.1.0.1 YES other up up
VirtualPortGroup1 192.0.2.1 YES other up up
VirtualPortGroup2 192.168.2.1 YES other up up Notice that VPG0 is the UTD/Snort management interface, VPG1 is the data-plane interface and VPG2 is the Service-insertion interface (used for AppQoE). Also notice that the router configured overlay tunnels on top of the VPG interfaces.
The last verification step is to check if you can ping the app-hosting container from VPN0.
cEdge-3# ping 192.0.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.0.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
Digital Book Access
For now, the digital version of this book is available only to active subscribers and readers who own a paperback copy.
The ability to buy the digital copy directly is coming soon.
- Subscribers can access the full digital version as part of their membership.
- Paperback owners can access the digital version using the instructions provided in the book.