IP SLA Questions
Question 1
Explanation
We cannot use the LAN (inside) interface to communicate to the ISP as the ISP surely does not know how to return the reply -> Answer A is 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.
Note:
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.
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.
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
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).
@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
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
Anyone having valid encor dumps please share at
sk9587263 g m a i l . C o m
Q 1 … i guess AC is correct , the threshold doesn’t make sense
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.”
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.
Q1:
The Question doesnt say that we have to Ping from the LAN, so my guess would be that choosing Fa1/0 as the source would still be a valid answer, because then the ISP would know the Route back to the source as its in the same subnet as ISP1?
for Q2 it depends if two options to select are meant to be AND or OR. If they mean OR, then route back OR wrong source interface are correct options. If they mean AND, then route back AND something else, maybe threshold, but with AND the given options don’t make much sense….
Every IP SLAs operation maintains an operation return-code value. This return code is interpreted by the tracking process. The return code may return OK, OverThreshold, and several other return codes. Generally, Two aspects of an IP SLAs operation can be tracked: state and reachability.
Tracking Return Code Track State
State OK = Up
(all other return codes) = Down
Reachability OK or over threshold = Up
(all other return codes). = Down
In this question, the “reachability” has been used, so the “track state” will be down only in case of an ICMP timeout.
Note: If you use the “state”, the “track state” will be down also if the threshold (500) is reached.
In a nutshell, the threshold value is not wrong, and the correct answers are: “The source-interface is configured incorrectly” and “A route back to the R1 LAN network is missing in R2”
@digitaltut
A lot of people here are sharing that on Q1 the right answer should be A and C. Please take a look, they have a valid reasons.
Thank you for your time!
where are the questions
@digitialtut
would appreciate some input on this, q1 seems to have the wrong answers, i don’t agree with what you’ve put either
@digitaltut @admin
Please update the correct answer for Q1.
Q3. I thought IP SLA can provide a MOS score ? Ive literally seen this happen.
Q1!!!!!
WHAT IS THE CORRECT ANSWER!!!
@digitaltut @admin
@digitaltut @admin
@digitaltut @admin
@digitaltut @admin
@digitaltut @admin
@all: Thank you for your information about Q1! It is a debated question but we changed the answer from E to A.
Regarding “Refer to exhibit. What are two reasons for IP SLA tracking failure? (Choose two)”
A. The source-interface is configured incorrectly
B. The destination must be 172.30.30.2 for icmp-echo
C. A route back to the R1 LAN network is missing in R2
D. The default route has wrong next hop IP address
E. The threshold value is wrong
We cannot use the LAN (inside) interface to communicate to the ISP as the ISP surely does not know how to return the reply -> Answer A is correct.
How can you know what type of IP (private or public) is used for the LAN interface?
We could be using a public subnet provided by the ISP and the ISP could know of the public subnet either with a static route to 172.20.20.2 or by eBGP peering with 172.20.20.2
So “A” could be the right answer because B, D, E are wrong but the provided explanation for “A” is not correct.
More on the IP SLA question
A. The source-interface is configured incorrectly
B. The destination must be 172.30.30.2 for icmp-echo
C. A route back to the R1 LAN network is missing in R2
D. The default route has wrong next hop IP address
E. The threshold value is wrong
icmp-echo 172.20.20.2 source-interface FastEthernet0/0
If “A” is correct then the above command would use the FastEthernet1/0 (P2P with ISP).
If we use the Fa1/0 interface, then “C” is irrelevant because the LAN network is not a part of the SLA operation.
My guess is that there is typo in this question. I have seen it elsewhere as a picture and the
source interface is Fa0/1.
In my mind, the goal is to ping the ISP IP from the LAN. So the source must be the LAN interface. The LAN is either assigned a public IP or is using NAT. In either case, the ISP must have a route to the LAN address.
Ip sla can measure MOS -> https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipsla/configuration/15-mt/sla-15-mt-book/sla_udp_jitter_voip.html
Then how about answers ? 3 answers are valid ?