Home > IP SLA Questions

IP SLA Questions

January 28th, 2021 in ENCOR 350-401 Go to comments

Question 1

Explanation

There is no problem with the Fa0/0 as the source interface as we want to check the ping from the LAN interface -> Answer A is not correct.

Answer B is not correct as we must track the destination of the primary link, not backup link.

In this question, R1 pings R2 via its LAN Fa0/0 interface so maybe R1 (which is an ISP) will not know how to reply back as an ISP usually does not configure a route to a customer’s LAN -> C is correct.

There is no problem with the default route -> D is not correct.

For answer E, we need to understand about how timeout and threshold are defined:

Timeout (in milliseconds) sets the amount of time an IP SLAs operation waits for a response from its request packet. In other words, the timeout specifies how long the router should wait for a response to its ping before it is considered failed.Threshold (in milliseconds too) sets the upper threshold value for calculating network monitoring statistics created by an IP SLAs operation. Threshold is used to activate a response to IP SLA violation, e.g. send SNMP trap or start secondary SLA operation. In other words, the threshold value is only used to indicate over threshold events, which do not affect reachability but may be used to evaluate the proper settings for the timeout command.

For reachability tracking, if the return code is OK or OverThreshold, reachability is up; if not OK, reachability is down.

Therefore in this question, we are using “Reachability” tracking (via the command “track 10 ip sla 1 reachability”) so threshold value is not important and can be ignored -> Answer E is correct. In fact, answer E is not wrong but it is the best option left.

This tutorial can help you revise IP SLA tracking topic: http://www.firewall.cx/cisco-technical-knowledgebase/cisco-routers/813-cisco-router-ipsla-basic.html and http://www.ciscozine.com/using-ip-sla-to-change-routing/

Note: Maybe some of us will wonder why there are these two commands:

R1(config)#ip route 0.0.0.0 0.0.0.0 172.20.20.2 track 10
R1(config)#no ip route 0.0.0.0 0.0.0.0 172.20.20.2

In fact the two commands:

ip route 0.0.0.0 0.0.0.0 172.20.20.2 track 10
ip route 0.0.0.0 0.0.0.0 172.20.20.2

are different. These two static routes can co-exist in the routing table. Therefore if the tracking goes down, the first command will be removed but the second one still exists and the backup path is not preferred. So we have to remove the second one.

Question 2

Explanation

The “ip sla 10” will ping the IP 192.168.10.20 every 3 seconds to make sure the connection is still up. We can configure an EEM applet if there is any problem with this IP SLA via the command “event track 10 state down”.

Reference: https://www.theroutingtable.com/ip-sla-and-cisco-eem/

The syntax of tracking command is: track object-number ip sla operation-number [state | reachability]

Tracking Return Code Track State
State

OK

(all other return codes)

Up

Down

Reachability

OK or over threshold

(all other return codes)

Up

Down

Both “state” and “reachability” return the track state of “up” or “down” only (no “unreachable” state) so we have to configure either “up” or “down” in “event track 10 state …” command.

Note:
+ There is no “event sla …” command.
+ There are only three states of an “event track”, which are “any”, “down” and “up”

Router(config-applet)#event track 10 state ?
  any   Any state
  down  Down state
  up    Up state

Question 3

Explanation

IP SLAs allows Cisco customers to analyze IP service levels for IP applications and services, to increase productivity, to lower operational costs, and to reduce the frequency of network outages. IP SLAs uses active traffic monitoring–the generation of traffic in a continuous, reliable, and predictable manner–for measuring network performance.

Being Layer-2 transport independent, IP SLAs can be configured end-to-end over disparate networks to best reflect the metrics that an end-user is likely to experience.

Reference: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipsla/configuration/15-mt/sla-15-mt-book/sla_overview.html

Question 4

Explanation

Cisco IOS IP SLA Responder is a Cisco IOS Software component whose functionality is to respond to Cisco IOS IP SLA request packets. The IP SLA source sends control packets before the operation starts to establish a connection to the responder. Once the control packet is acknowledged, test packets are sent to the responder. The responder inserts a time-stamp when it receives a packet and factors out the destination processing time and adds time-stamps to the sent packets. This feature allows the calculation of unidirectional packet loss, latency, and jitter measurements with the kind of accuracy that is not possible with ping or other dedicated probe testing.

Reference: https://www.cisco.com/en/US/technologies/tk869/tk769/technologies_white_paper0900aecd806bfb52.html

The IP SLAs responder is a component embedded in the destination Cisco device that allows the system to anticipate and respond to IP SLAs request packets. The responder provides accurate measurements without the need for dedicated probes.

Reference: https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/12-2/46sg/configuration/guide/Wrapper-46SG/swipsla.html

UDP Jitter measures the delay, delay variation(jitter), corruption, misorderingand packet lossby generating periodic UDP traffic. This operation always requires IP SLA responder.

Reference: https://www.ciscolive.com/c/dam/r/ciscolive/us/docs/2017/pdf/BRKNMS-3043.pdf

Comments
  1. ArShuRaZ
    February 1st, 2021

    I Think Q.1 correct answer would be

    A. The source-interface is configured incorrectly
    C. A route back to the R1 LAN network is missing in R2

    Because ISPs usually don’t have customer’s LAN in thier routing table. (Except you use a service “MPLS”).

    For general case, source for IP SLA should be source of interface Fa1/0 (WAN) not Fa0/0 (LAN).

  2. Tirou
    February 23rd, 2021

    @Up – Agree.

    Threshold value is not wrong, and they are asking why it’s not working, so in fact to let it work we would need to specify F0/1 as source or tell ISP1 how to get to LAN. I think A&C

  3. Panos
    March 10th, 2021

    Q1: Answer C makes sense solely when the IP SLA is configured with a source interface that belongs to R1’s LAN ( basically, ISP1 has no visibility on R1’s lan as it is not a directly connected destination ).

    I believe as well that answer A & C are the correct one.

    However, this can also be a tricky answer from Cisco “The source-interface is configured incorrectly”: The source interface configuration as configuration is OK but it may lead to routing issues….

    Still not 100% sure if A is the correct answer

    Thank you

  4. Anonymous
    March 16th, 2021

    Anyone having valid encor dumps please share at
    sk9587263 g m a i l . C o m

  5. tmr
    April 9th, 2021

    Q 1 … i guess AC is correct , the threshold doesn’t make sense

  6. contoso
    April 15th, 2021

    Q1, IMO. Best answer is A and C.

    ISP router normally don’t add customer LAN information in their table. IP SLA tracking will fail due to this reason if customer is using LAN as source interface. Customer should use interface that is facing ISP WAN. So answer A is correct, source interface is incorrect, engineer should use fa1/0 as source interface. Answer E is correct, missing customer LAN’s route in R2 if engineer use fa0/0 (LAN) as source interface, R2 would not know how to echo reply.

    The threshold value will not cause IP SLA tracking failure. The threshold value configured by this command is used only to calculate network monitoring statistics created by a Cisco IOS IP SLAs operation.
    For all other IP SLAs operations, the following configuration guideline is recommended:

    (frequency seconds ) > (timeout milliseconds ) > (threshold milliseconds )

    source: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipsla/command/sla-cr-book/sla_s2.html#wp4194409343

    Cisco asks, what are the 2 reasons for IP SLA tracking failures?
    A. Because engineer configured wrong source-interface, and E. because ISP R2 don’t have the route back to R1 LAN.

    “Any of these 2 reasons will cause IP SLA tracking failure.”

  7. sGhost
    April 28th, 2021

    Q1 .. C and E are the best answer… because they are the only two that will give this question some sense…

    if you use the LAN interface (F0/0) as the tunnel source, then you need a route back to the LAN from the ISP router.

  1. No trackbacks yet.