It is a common design to have an internet Edge router connected to two different internet service providers to protect against the failure of an ISP bringing the office down. The topology may look something like this:
The two ISPs are used in an active/standby fashion using static routes. This is normally implemented by using two default routes where one of the routes is a floating static route. It will look something like this:
ip route 0.0.0.0 0.0.0.0 203.0.113.1 name PRIMARY ip route 0.0.0.0 0.0.0.0 203.0.113.9 200 name SECONDARY
With this configuration, if the interface to ISP1 goes down, the floating static route which has an administrative distance (AD) of 200 will be installed and traffic will flow via ISP2. The drawback to this configuration is that it only works if the physical interface goes down. What happens if ISP1’s CPE has the interface towards the customer up but the interface towards the ISP Core goes down? What happens if there is a failure in another part of the ISP’s network? What if all interfaces are up but they are having BGP issues in the network?
In scenarios like these, since the customer’s interface towards ISP1 is still up, traffic would flow to ISP1 but would not reach their final destination. The traffic will then blackholed. To prevent failures like these, the IP SLA feature can be implemented to track something of importance, such as a service provided by the ISP or one outside of the ISP network to have the static route only installed if the service is available. How do we select what to track, though?
Selecting what to track
What services are important to an ISP? They normally provide a resolver service. If the resolvers are down, that prevents people from browsing the internet so the resolver service is very important to the ISP. What else? The ISP has a web page where you order products and interact with them, for example verizon.com. Ff that site is down, they lose money so it will be an important service to them. Using Verizon as an example, let’s find out what IP addresses are interesting to track. We can do this using dig on a Linux host. First let’s see what verizon.com resolves to:
dig verizon.com ; <<>> DiG 9.16.1-Ubuntu <<>> verizon.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52122 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;verizon.com. IN A ;; ANSWER SECTION: verizon.com. 600 IN A 192.16.31.89 ;; Query time: 40 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: sön aug 21 08:54:45 CEST 2022 ;; MSG SIZE rcvd: 56
The IP address of interest is 192.16.31.89. When it comes to resolvers, this will most likely vary per region and service, but on the other hand we can check what name servers Verizon uses for verizon.com domain. These are guaranteed to be important as well.
daniel@devasc:~$ dig ns verizon.com ; <<>> DiG 9.16.1-Ubuntu <<>> ns verizon.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55703 ;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;verizon.com. IN NS ;; ANSWER SECTION: verizon.com. 3600 IN NS s1ns1.verizon.com. verizon.com. 3600 IN NS ns2.edgecastdns.net. verizon.com. 3600 IN NS s3ns3.verizon.com. verizon.com. 3600 IN NS s2ns2.verizon.com. verizon.com. 3600 IN NS ns1.edgecastdns.net. verizon.com. 3600 IN NS s4ns4.verizon.com. verizon.com. 3600 IN NS ns3.edgecastdns.net. verizon.com. 3600 IN NS ns4.edgecastdns.net. ;; Query time: 624 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: sön aug 21 09:00:26 CEST 2022 ;; MSG SIZE rcvd: 207
There are several servers here. Note that it seems Verizon is using a 3rd party DNS service to provide resiliency for their name servers. Pick a server and check the IP:
dig s1ns1.verizon.com ; <<>> DiG 9.16.1-Ubuntu <<>> s1ns1.verizon.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12917 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 65494 ;; QUESTION SECTION: ;s1ns1.verizon.com. IN A ;; ANSWER SECTION: s1ns1.verizon.com. 3573 IN A 192.16.16.5 ;; Query time: 0 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) ;; WHEN: sön aug 21 09:00:52 CEST 2022 ;; MSG SIZE rcvd: 62
The IP address 192.16.16.5 is what we are looking for here. We now have two IP addresses we can track. Conceptually, it looks like this:
This is a good first step. We have identified important services to the ISP. However, this is not the best way of tracking availability of your internet service. Why?
- The availability of these services does not guarantee availability towards the greater internet
- These services may not respond to ICMP Echo packets or be rate limited
While we did achieve measuring availability beyond the CPE of the ISP, we want to make sure that we can reach services that are not local to the ISP. This is usually where people start tracking something like 8.8.8.8, which is Google’s well known resolver service. This would look like this:
Compared to the previous scenario, the health of 8.8.8.8 should be more relevant as it’s not local to the ISP. However, as this is a resolver service, responding to ICMP Echo is not in the job description, meaning that ICMP may get rate limited. Let’s implement tracking of 8.8.8.8 and then describe some of the challenges/caveats.
Basic implementation and caveats
Let’s start with a standard implementation of IP SLA tracking and then I’ll describe some of the challenges/caveats. Here is the basic configuration:
interface GigabitEthernet1 ip address 203.0.113.2 255.255.255.248 ! interface GigabitEthernet2 ip address 203.0.113.10 255.255.255.248 ! ip route 0.0.0.0 0.0.0.0 203.0.113.1 name PRIMARY track 1 ip route 0.0.0.0 0.0.0.0 203.0.113.9 200 name SECONDARY ! ip sla 1 icmp-echo 8.8.8.8 source-ip 203.0.113.2 ip sla schedule 1 life forever start-time now ! track 1 ip sla 1 reachability
GigabitEthernet1 is towards ISP1 and GigabitEthernet2 is towards ISP2. The following commands can be used to verify the IP SLA setup:
Edge#show ip sla sum IPSLAs Latest Operation Summary Codes: * active, ^ inactive, ~ pending All Stats are in milliseconds. Stats with u are in microseconds ID Type Destination Stats Return Last Code Run ----------------------------------------------------------------------- *1 icmp-echo 8.8.8.8 RTT=8 OK 44 seconds ag o Edge#show ip sla statistics IPSLAs Latest Operation Statistics IPSLA operation id: 1 Latest RTT: 7 milliseconds Latest operation start time: 07:10:40 UTC Mon Aug 22 2022 Latest operation return code: OK Number of successes: 14 Number of failures: 0 Operation time to live: Forever Edge#show ip route track-table ip route 0.0.0.0 0.0.0.0 203.0.113.1 name PRIMARY track 1 state is [up] Edge#show ip route 0.0.0.0 Routing entry for 0.0.0.0/0, supernet Known via "static", distance 1, metric 0, candidate default path Routing Descriptor Blocks: * 203.0.113.1 Route metric is 0, traffic share count is 1
This is behaving as expected. The IP SLA is up. The tracker is up. The default route towards ISP1 is installed. Now, let’s simulate a failure of ISP1. I will implement this in the background using an ACL in my lab filtering the ICMP Echo packets. Let’s check the logs:
Aug 22 07:37:22.171: %TRACK-6-STATE: 1 ip sla 1 reachability Down -> Up Aug 22 07:37:32.171: %TRACK-6-STATE: 1 ip sla 1 reachability Up -> Down Aug 22 07:37:42.171: %TRACK-6-STATE: 1 ip sla 1 reachability Down -> Up Aug 22 07:37:52.171: %TRACK-6-STATE: 1 ip sla 1 reachability Up -> Down Aug 22 07:38:02.171: %TRACK-6-STATE: 1 ip sla 1 reachability Down -> Up
This doesn’t look too good. Why is the reachability flapping? Let’s check some of the routes:
Edge#show ip route 0.0.0.0 Routing entry for 0.0.0.0/0, supernet Known via "static", distance 200, metric 0, candidate default path Routing Descriptor Blocks: * 203.0.113.9 Route metric is 0, traffic share count is 1 Edge#show ip cef 8.8.8.8 0.0.0.0/0 nexthop 203.0.113.9 GigabitEthernet2 Edge#show ip cef exact-route 203.0.113.2 8.8.8.8 203.0.113.2 -> 8.8.8.8 =>IP adj out of GigabitEthernet2, addr 203.0.113.9
This looks like expected. The default route is now pointing towards 203.0.113.9. Notice what the next-hop is for 8.8.8.8, though… I’ll come back to this but first let’s check the routing a few seconds later:
Edge#show ip route 0.0.0.0 Routing entry for 0.0.0.0/0, supernet Known via "static", distance 1, metric 0, candidate default path Routing Descriptor Blocks: * 203.0.113.1 Route metric is 0, traffic share count is 1 Edge#show ip cef 8.8.8.8 0.0.0.0/0 nexthop 203.0.113.1 GigabitEthernet1 Edge#show ip cef exact-route 203.0.113.2 8.8.8.8 203.0.113.2 -> 8.8.8.8 =>IP adj out of GigabitEthernet1, addr 203.0.113.1
The routing is flapping between 203.0.113.1 and 203.0.113.9. Why is this happening? This is because initially the SLA packets flow through GigabitEthernet1. This path then fails so the SLA packets are sent towards GigabitEthernet2 as the default route towards Gi1 is removed. When the SLA packets are sent towards Gi2, they succeed. Since the SLA is successful, the tracked default route gets installed again. And the process repeats…
To prevent this from happening, we must ensure that SLA packets only get sent towards Gi1. How can we do this? What happens if we set the source interface in our SLA configuration?
ip sla 1 icmp-echo 8.8.8.8 source-interface GigabitEthernet1 frequency 10 ip sla schedule 1 life forever start-time now
Unfortunately, the results are still the same. We still have flapping. When configuring the SLA, it does say ingress interface, not egress:
Edge(config-ip-sla)#icmp-echo 8.8.8.8 ? source-interface Source Interface (ingress icmp packet interface) source-ip Source Address
We can verify that packets are using GigabitEthernet2 as the next-hop:
Edge#show ip cef exact-route 203.0.113.2 8.8.8.8 203.0.113.2 -> 8.8.8.8 =>IP adj out of GigabitEthernet2, addr 203.0.113.9
Unfortunately we can’t specify the egress interface of the SLA packets. So what can we do? The options we have are:
- Create a static route for the destination of the SLA packets
- Use policy-based routing to force SLA packets out GigabitEthernet1
Let’s try using the static route approach first. A static route for 8.8.8.8 is added:
Edge(config)#ip route 8.8.8.8 255.255.255.255 203.0.113.1 name SLA
Are packets to 8.8.8.8 should only be flowing via 203.0.113.1 now, right? Initially, this looks promising:
Edge#show ip cef exact-route 203.0.113.2 8.8.8.8 203.0.113.2 -> 8.8.8.8 =>IP adj out of GigabitEthernet1, addr 203.0.113.1 Edge#show ip cef exact-route 203.0.113.2 8.8.8.8 203.0.113.2 -> 8.8.8.8 =>IP adj out of GigabitEthernet1, addr 203.0.113.1 Edge#show ip cef exact-route 203.0.113.2 8.8.8.8 203.0.113.2 -> 8.8.8.8 =>IP adj out of GigabitEthernet1, addr 203.0.113.1 Edge#show ip cef exact-route 203.0.113.2 8.8.8.8 203.0.113.2 -> 8.8.8.8 =>IP adj out of GigabitEthernet1, addr 203.0.113.1
Packets are only being sent out GigabitEthernet1. Not so fast, though! The current way of simulating a failure is by filtering packets. What happens if Gi1 actually goes down? I will shut down the interface to simulate failure where interface towards ISP1 goes down. I added some debugs to show what goes on in the background:
Aug 22 08:18:05.209: RT: interface GigabitEthernet1 removed from routing table Aug 22 08:18:05.209: RT: del 203.0.113.0 via 0.0.0.0, connected metric [0/0] Aug 22 08:18:05.209: RT: delete subnet route to 203.0.113.0/29 Aug 22 08:18:05.209: CONN: delete conn route, idb: GigabitEthernet1, addr: 203.0.113.2, mask: 255.255.255.248 Aug 22 08:18:05.210: CONN(multicast): connected_route: FALSE Aug 22 08:18:05.210: RT: interface GigabitEthernet1 topo state DOWN, afi 0 Aug 22 08:18:05.210: IP-ST-EV(default): queued adjust on GigabitEthernet1 Aug 22 08:18:05.210: RT: del 203.0.113.2 via 0.0.0.0, connected metric [0/0] Aug 22 08:18:05.210: RT: delete subnet route to 203.0.113.2/32 Aug 22 08:18:05.221: RT: del 8.8.8.8 via 203.0.113.1, static metric [1/0] Aug 22 08:18:05.221: RT: delete subnet route to 8.8.8.8/32 Aug 22 08:18:06.108: %SYS-5-CONFIG_I: Configured from console by daniel on vty0 (10.254.255.2) Aug 22 08:18:07.202: %LINK-5-CHANGED: Interface GigabitEthernet1, changed state to administratively down Aug 22 08:18:07.208: CONN: connected_route: FALSE Aug 22 08:18:07.208: is_up: GigabitEthernet1 0 state: 6 sub state: 1 line: 0 Aug 22 08:18:08.203: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet1, changed state to down Aug 22 08:18:08.204: CONN: connected_route: FALSE Aug 22 08:18:08.204: is_up: GigabitEthernet1 0 state: 6 sub state: 1 line: 0
From the debug above, we can see that Gi1 goes down, it removes the connected subnet 203.0.113.0/29, but also the route to 8.8.8.8 is removed. This means that the SLA packets are now flowing via Gi2:
Edge#show ip cef exact-route 8.8.8.8 203.0.113.2 8.8.8.8 -> 203.0.113.2 =>IP adj out of GigabitEthernet2, addr 203.0.113.9
The default route via Gi1 can’t be installed as the interface is down, but if we were tracking SLA statistics, it would skew the data as these packets are now going through even though ISP1 is down.
There is a more elegant solution, though. It is possible to add a permanent static route using the permanent keyword:
Edge(config)#ip route 8.8.8.8 255.255.255.255 203.0.113.1 permanent name SLA
Notice the permanent keyword in the output below:
Edge#show ip route 8.8.8.8 Routing entry for 8.8.8.8/32 Known via "static", distance 1, metric 0 Routing Descriptor Blocks: * 203.0.113.1, permanent Route metric is 0, traffic share count is 1
When the interface is shut down, this route will remain:
Edge(config)#int gi1 Edge(config-if)#sh Edge(config-if)#^Z Edge#show ip route 8.8.8.8 Routing entry for 8.8.8.8/32 Known via "static", distance 1, metric 0 Routing Descriptor Blocks: * 203.0.113.1, permanent Route metric is 0, traffic share count is 1
This ensures that SLA packets can only ever use Gi1. This works well. Keep in mind one thing, though. What we just configured will apply for ALL packets towards 8.8.8.8. Not only the SLA packets. If people are using 8.8.8.8 as their resolver, and ISP1 is down or having issues, packets towards 8.8.8.8 will NOT be able to use ISP2. We have essentially made our secondary link unavailable for any packets towards 8.8.8.8. This is not that great. What if we could change the routing towards 8.8.8.8 for only the packets generated by the router itself? We can, but it means we’ll have to use our old friend/foe policy based routing. Let’s configure PBR:
ip access-list extended G1-ICMP-TO-GOOGLE-DNS permit icmp host 203.0.113.2 host 8.8.8.8 echo ! route-map LOCAL-POLICY permit 10 match ip address G1-ICMP-TO-GOOGLE-DNS set ip next-hop 203.0.113.1 ! ip local policy route-map LOCAL-POLICY
The policy is being used:
Edge#show ip local policy Local policy routing is enabled, using route map LOCAL-POLICY route-map LOCAL-POLICY, permit, sequence 10 Match clauses: ip address (access-lists): G1-ICMP-TO-GOOGLE-DNS Set clauses: ip next-hop 203.0.113.1 Policy routing matches: 2 packets, 128 bytes Edge#show ip access-lists Extended IP access list G1-ICMP-TO-GOOGLE-DNS 10 permit icmp host 203.0.113.2 host 8.8.8.8 echo (3 matches)
Packets to 8.8.8.8 can use the secondary path:
Edge#show ip cef 8.8.8.8 0.0.0.0/0 nexthop 203.0.113.9 GigabitEthernet2
This all looks great. We have pinned the SLA packets to Gi1 but user traffic to 8.8.8.8 can still use the secondary path. So far we have only used ICMP Echo, which is not the best way of determining if a path is healthy. Let’s look into some more advanced options.
IP SLA using DNS
Instead of sending ICMP Echo packets to DNS servers. What if we just sent DNS queries instead? Wouldn’t this be better? It would indeed as the job of a DNS server is to respond to DNS queries, not ICMP Echo packets. It’s possible to configure IP SLA to send DNS queries. Define the name to be queried and the name server in the IP SLA configuration:
ip sla 1 dns google.com name-server 8.8.8.8 frequency 10 ! ip sla schedule 1 life forever start-time now
Edge#show ip sla statistics IPSLAs Latest Operation Statistics IPSLA operation id: 1 Latest RTT: 8 milliseconds Latest operation start time: 13:08:24 SWE Mon Aug 22 2022 Latest operation return code: OK Number of successes: 4 Number of failures: 0 Operation time to live: Forever Edge#show ip sla Edge#show ip route trac Edge#show ip route track-table ip route 0.0.0.0 0.0.0.0 203.0.113.1 name PRIMARY track 1 state is [up]
The default route is now installed based on that 8.8.8.8 responds to our query for the google.com name. This is a lot better! Consider this, though:
- What happens if there is no response for google.com?
- What happens if 8.8.8.8 does not respond at all?
- What is the packet length of a DNS query?
Before answering the first two questions, why would we care about the packet size? What if DNS queries can go through but other user traffic can’t? Maybe the path does not allow for 1500 bytes packets due to some upstream issue… First, let’s check what the size of the SLA packet is by using some packet capturing magic:
Edge#debug platform condition ipv4 8.8.8.8/32 both Edge#debug platform packet-trace packet 256 Please remember to turn on 'debug platform condition start' for packet-trace to work Edge#debug platform condition start Edge#show platform packet-trace sum Pkt Input Output State Reason 0 INJ.2 Gi1 FWD 1 Gi1 internal0/0/rp:0 PUNT 11 (For-us data) Edge#show platform packet-trace packet 0 Packet: 0 CBUG ID: 0 IOSd Path Flow: Feature: UDP Pkt Direction: OUTsrc=203.0.113.2(53883), dst=8.8.8.8(53), length=36 Feature: UDP Pkt Direction: OUT FORWARDED UDP: Packet Handoff to IP Source : 203.0.113.2(53883) Destination : 8.8.8.8(53) Feature: IP Pkt Direction: OUTRoute out the generated packet.srcaddr: 203.0.113.2, dstaddr: 8.8.8.8 Summary Input : INJ.2 Output : GigabitEthernet1 State : FWD Timestamp Start : 97239727399057 ns (08/22/2022 11:10:03.807558 UTC) Stop : 97239727755013 ns (08/22/2022 11:10:03.807914 UTC) Path Trace Feature: IPV4(Input) Input : internal0/0/rp:0 Output : <unknown> Source : 203.0.113.2 Destination : 8.8.8.8 Protocol : 17 (UDP) SrcPort : 53883 DstPort : 53
This is quite a small packet, only 36 bytes. Let’s get back to this later. For our first problem, how can we track something more than google.com and also to send queries to more than one DNS server? That can be implemented using multiple IP SLA statements:
ip sla 1 dns google.com name-server 8.8.8.8 frequency 10 ip sla schedule 1 life forever start-time now ip sla 2 dns amazon.com name-server 208.67.220.220 frequency 10 ip sla schedule 2 life forever start-time now ip sla 3 dns microsoft.com name-server 1.1.1.1 frequency 10 ip sla schedule 3 life forever start-time now ! track 2 ip sla 2 reachability ! track 3 ip sla 3 reachability
Then, configure a track statement that uses Boolean logic for all of these SLA statements:
track 10 list boolean or object 1 object 2 object 3
Finally, update the default route to use the new tracker:
Edge(config)#no ip route 0.0.0.0 0.0.0.0 203.0.113.1 name PRIMARY track 1 Edge(config)#ip route 0.0.0.0 0.0.0.0 203.0.113.1 name PRIMARY track 10
Let’s verify:
Edge#show track 10 Track 10 List boolean or Boolean OR is Up 2 changes, last change 00:02:25 object 1 Up object 2 Up object 3 Up Tracked by: Static IP Routing 0 Edge#show ip route 0.0.0.0 Routing entry for 0.0.0.0/0, supernet Known via "static", distance 1, metric 0, candidate default path Routing Descriptor Blocks: * 203.0.113.1 Route metric is 0, traffic share count is 1 Edge#show ip route track-table ip route 0.0.0.0 0.0.0.0 203.0.113.1 name PRIMARY track 10 state is [up] Edge#show ip cef exact-route 203.0.113.2 8.8.8.8 203.0.113.2 -> 8.8.8.8 =>IP adj out of GigabitEthernet1, addr 203.0.113.1
This looks great! We now have three SLA statements and one of them failing is not enough to move traffic to the secondary path. If just one of them fails, it’s more likely that there is a temporary issue with a DNS server or DNS zone.
Remember I mentioned something about packet sizes? Let’s discuss this in the next section.
IP SLA using HTTP
Tracking connectivity using DNS is definitely more useful than a simple ICMP Echo. What if we could move even further up the stack? This can be achieved by using HTTP probes. Rather than just checking that we get responses to DNS queries, let’s try to actually connect to a web site. The syntax is similar to that of DNS:
ip sla 5 http secure get https://amazon.com name-server 8.8.8.8 source-interface GigabitEthernet1 ! ip sla schedule 5 life forever start-time now ! track 5 ip sla 5 reachability ! no ip route 0.0.0.0 0.0.0.0 203.0.113.1 name PRIMARY track 10 ip route 0.0.0.0 0.0.0.0 203.0.113.1 name PRIMARY track 5
Then let’s verify:
Edge#show ip sla statistics 5 IPSLAs Latest Operation Statistics IPSLA operation id: 5 Latest RTT: 1175 milliseconds Latest operation start time: 13:57:12 SWE Mon Aug 22 2022 Latest operation return code: OK Latest DNS RTT: 7 ms Latest HTTP Transaction RTT: 1168 ms Number of successes: 2 Number of failures: 0 Operation time to live: Forever Edge#show ip route track-table ip route 0.0.0.0 0.0.0.0 203.0.113.1 name PRIMARY track 5 state is [up]
The router is now sending HTTP GET for the name amazon.com by first resolving the name through a DNS query to 8.8.8.8. This tests more of the stack than a DNS query. What’s the size of our SLA packets now? Let’s use another packet capturing utility to check:
ip access-list extended CAP-HTTP 10 permit tcp host 203.0.113.2 any 20 permit tcp any host 203.0.113.2 ! Edge#monitor capture CAP interface GigabitEthernet1 both Edge#monitor capture CAP access-list CAP-HTTP Edge#monitor capture CAP start Started capture point : CAP Edge#monitor capture CAP export flash:/CAP.pcap Exported Successfully Edge#copy flash:/CAP.pcap ftp://redacted:[email protected]
Let’s have a look at the PCAP:
The packets are definitely larger than when just using DNS. We see packets approaching 600 bytes of size. Not quite 1500 bytes, though! For production use we should of course track more than one web server. What else can we do when it comes to IP SLA? Time to get fancy!
Getting fancy with IP SLA
There’s a lot we can do with IP SLA. Time to get fancy! Let’s implement this:
- Resolve google.com via 8.8.8.8
- Resolve amazon.com via 208.67.220.220
- HTTP GET to amazon.com
- Ping sdwan.measure.office.com (O365 beacon service) with 1500 bytes ICMP Echo
If everything succeeds, the circuit is functioning as we can send ICMP, resolve DNS, and browse to web sites. This is the configuration:
track 1 ip sla 1 reachability ! track 2 ip sla 2 reachability ! track 5 ip sla 5 reachability ! track 20 ip sla 20 reachability ! track 100 list boolean and object 1 object 2 object 5 object 20 ! ip sla 1 dns google.com name-server 8.8.8.8 frequency 10 ip sla schedule 1 life forever start-time now ip sla 2 dns amazon.com name-server 208.67.220.220 frequency 10 ip sla schedule 2 life forever start-time now ip sla 5 http secure get https://amazon.com name-server 8.8.8.8 source-interface GigabitEthernet1 ip sla schedule 5 life forever start-time now ip sla 20 icmp-echo sdwan.measure.office.com source-interface GigabitEthernet1 request-data-size 1450 frequency 10 ip sla schedule 20 life forever start-time now
Note that the request data size is set to 1450 which will generate 1500 byte ICMP Echo packets. I’m not sure how the math maths here but I verified it with a packet capture. The ICMP Echo SLA when using a DNS name will resolve to an IP when configuring and be put into the running configuration. Let’s see if this all works:
Edge#show track 100 Track 100 List boolean and Boolean AND is Up 2 changes, last change 00:00:03 object 1 Up object 2 Up object 5 Up object 20 Up Tracked by: Static IP Routing 0 Edge#show ip route track-table ip route 0.0.0.0 0.0.0.0 203.0.113.1 name PRIMARY track 100 state is [up] Edge#show ip cef exact-route 203.0.113.2 8.8.8.8 203.0.113.2 -> 8.8.8.8 =>IP adj out of GigabitEthernet1, addr 203.0.113.1
Pretty cool! Using only static routes and IP SLA we now have a pretty good mechanism for verifying connectivity. A lot better than the simple ICMP Echos we started with.
Conclusion
You can make it as simple or complex as you want to using IP SLA. It all comes down to your requirements. Keep the following in mind:
- Consider what you want to measure
- How do you ensure SLA packets are flowing towards the correct ISP?
- How many things do you want to measure to ensure the path is good?
I hope this post has been informative and that you have learned some new IP SLA tricks as well as some good debugging and packet capture commands.
