cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3340
Views
1
Helpful
4
Replies

Application Hosting using Managment Interface (Thousand Eyes)

Richard G.
Level 1
Level 1

This is our first time deploying app hosting (Thousand Eyes).

I deployed the enterprise agent successfully on an ISR 4431 (through vManage) but am having issues with a 9300

and management interface.

C9300-24T 17.03.04 

 

Does the Docker interface and Thousand Eyes require their own IP address?

 

Below is my configuration...as I understand I do not need to configure Ap1/0/1 since I am using the managment interface

 

interface GigabitEthernet0/0
vrf forwarding Mgmt-vrf
ip address 10.2.15.10 255.255.255.0
negotiation auto
end

 


app-hosting appid thousand_eyes
app-vnic management guest-interface 0
guest-ipaddress 10.2.15.200 netmask 255.255.255.0
app-default-gateway 10.2.15.10 guest-interface 0
app-resource docker
run-opts 1 "-e TEAGENT_ACCOUNT_TOKEN=*******************"
run-opts 2 "--hostname "Cisco-9300-SW"
prepend-pkg-opts

name-server0 8.8.8.8

 

Cisco-9300-SW# sh app-hosting list
App id State
---------------------------------------------------------
thousand_eyes RUNNING

 

Cisco-9300-SWe#ping vrf Mgmt-vrf cisco.com
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 72.163.4.185, timeout is 2 seconds:
!!!!!!!!!!

 

 

I am not sure what else I am missing but am currently getting this error

 

IOX_INST_NOTICE: Switch 1 R0/0: ioxman: IOX SERVICE te LOG: Error calling createAgent: Curl error - Couldn't resolve host name resolve host name Error calling createAgent: Cur

 

 

 

 

1 Accepted Solution

Accepted Solutions

Tyler Langston
Cisco Employee
Cisco Employee
Adding a response from our engineers on this:
 
Hi everyone - happy to add some clarification on this issue!  The error message indicates a problem resolving a hostname, the most likely reason is the agent (container) can’t reach the DNS server, hence the hostname resolution doesn’t happen.
 
I noticed the app-default-gateway in Richard G’s post is configured as the GigabitEthernet0/0 IP address. Instead, this should be the real gateway of the subnet. To validate reachability to the gateway and DNS server working properly you can get into the agent’s shell by running the commands:
#app-hosting connect appid <agent app id> session bash
verify the DNS server config
# cat /etc/resolv.conf
verify the routing table
# route -n
then validate the connectivity with the commands
# te-ping -M icmp <dns-server-ip-address>
# te-ping -M icmp <default-gateway-ip-address>
the customer can also verify the DNS queries work by running the commands
# dig sc1.thousandeyes.com @8.8.8.8
# curl -v sc1.thousandeyes.com
After validating the connectivity to the DNS server and the gateway, if you find problems, you can modify the app-default-gateway and retest.
 
If you are still running into issues after you’ve attempted the above please feel free to contact Support for additional assistance!

View solution in original post

4 Replies 4

Hi

 It seems to me that the createAgent is try do exit using the global vrf. When you do the test, you add "ping vrf Mgmt-vrf" but looks like the agent is not doing the same.

Try to not use vrf on the interface just to make sure.

patrickroberts
Level 1
Level 1

Hi did this get fixed ?

C9300-24U 17.06.03

i have the same issue below is my config

interface GigabitEthernet1/0/13
description Uplink MGMT
switchport access vlan 21
!
interface Vlan21
ip address 10.100.21.1 255.255.255.0
!
interface AppGigabitEthernet1/0/1
switchport trunk allowed vlan 21
switchport mode trunk

 

enable
app-hosting install appid xxxx package flash:thousandeyes-enterprise-agent-4.2.2.cisco.tar
configure terminal
app-hosting appid xxxx
app-vnic AppGigabitEthernet trunk
vlan 21 guest-interface 0
exit
name-server0 8.8.8.8
name-server1 8.8.4.4
app-resource docker
prepend-pkg-opts
run-opts 1 "-e TEAGENT_ACCOUNT_TOKEN=xxxxxxxx"
run-opts 2 "--hostname xxxx"
exit
exit
exit
write memory
app-hosting activate appid xxxx
app-hosting start appid xxxx

adam.james
Level 1
Level 1

Hi Richard. 

I too had the same problem.  We are doing a large roll out of TE in our environment.  I have found the fix for this, and it was partly down to my own error.  For TE to run correctly you first need to apply HTTP config.  If you use DNAc to install TE you will be a window pop up referenving to the HTTP configs.  As soon as I applied the HTTP config I could see in the TE dashboard that the devices were now joined.  Just as an FYI - I have had more problems with TE when trying to use DNAc as and the installation process.  Using the CLI is much easier and quicker.  Hope this helps. Thanks Adam

prompt# sh run | sec http
ip http server
ip http authentication local
ip http secure-server
ip http max-connections 16
ip http client source-interface vlan 911
!
** Additional configuration for switches with Cisco IOS XE release earlier than 17.3.3:
ip http secure-active-session-modules dnac
ip http session-module-list dnac NG_WEBUI
ip http active-session-modules none
!
** Additional configuration for switches with Cisco IOS XE 17.3.3 or later:
ip http secure-active-session-modules webui
ip http session-module-list webui NG_WEBUI
ip http session-module-list pki OPENRESTY_PKI
ip http active-session-modules pki
!

 

Tyler Langston
Cisco Employee
Cisco Employee
Adding a response from our engineers on this:
 
Hi everyone - happy to add some clarification on this issue!  The error message indicates a problem resolving a hostname, the most likely reason is the agent (container) can’t reach the DNS server, hence the hostname resolution doesn’t happen.
 
I noticed the app-default-gateway in Richard G’s post is configured as the GigabitEthernet0/0 IP address. Instead, this should be the real gateway of the subnet. To validate reachability to the gateway and DNS server working properly you can get into the agent’s shell by running the commands:
#app-hosting connect appid <agent app id> session bash
verify the DNS server config
# cat /etc/resolv.conf
verify the routing table
# route -n
then validate the connectivity with the commands
# te-ping -M icmp <dns-server-ip-address>
# te-ping -M icmp <default-gateway-ip-address>
the customer can also verify the DNS queries work by running the commands
# dig sc1.thousandeyes.com @8.8.8.8
# curl -v sc1.thousandeyes.com
After validating the connectivity to the DNS server and the gateway, if you find problems, you can modify the app-default-gateway and retest.
 
If you are still running into issues after you’ve attempted the above please feel free to contact Support for additional assistance!
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: