It can be difficult to troubleshoot in a DMZ environment where you don’t have access to the firewalls if the routing for servers and hosts is done on them. Also, most of the time ICMP will be blocked and sometimes the firewalls are going to be the only ones holding the ARP cache tables for parts of the DMZ. When a lot of the tools to troubleshoot a network is taken away from you, we must use out of the box thinking to identify and resolve network problems. Today, I will be talking about how you can use IP SLA’s to verify reachability and RTT for devices by generating traffic that isn’t blocked by the firewall.
IP SLA or IP Service Level Agreement is a built in tool in Cisco routers and switches for testing and analyzing various network parameters like overall health of the network or to verify if QoS is working properly. IP SLA can generate traffic for network testing depending on what you want to test. It can run sampling against defined IP SLA traffic and results can be seen using the CLI. IP SLA can also store information on the syslog servers or it can be also accessed via SNMP.
Simple UDP Reachability IP SLA for a UDP port:
This IP SLA will check for reachability and RTT for the destination on a particular UDP Port (In this case UDP Port 1337 for 192.168.1.1 with source of 192.168.4.1). This test will start now and run every 10 seconds for 30 seconds.
Then we can check with the show ip sla statistic command:
To identify the TCP/UDP port to use in your IP SLA, you can use a locally TCL written Port Scanner script. You can find instructions on how to do this in my other post: https://routingnull0.com/2013/11/12/hour-125-tcl-scripting-powerful-and-dangerous/
This was just a quick example to show how IP SLA’s can be used to troubleshoot in restricted situations. I will be making more blogs on IP SLA in the future. Hope this was informative.