awesome, it works. thanks!
Hi Rene,
Is there a way to delay fail-back for more than 30 minutes or some timer to Primary ISP to avoid flapping connections? Or anyway to make it NO FAIL BACK like config?
Hi Will,
The ātrackā command has a delay option but it has a maximum of 180 seconds. I think if you want to delay it for 30 minutes that your best bet is a simple script created with EEM.
Rene
Hi rene,
From your experience when you use bfd protocol over ip-sla and the opposite?
Hi Sahar,
BFD is useful for local networks where you use protocols like OSPF or EIGRP. IP SLA is more useful for WAN connections, you can use it to check if your Internet connection is operational.
Rene
1 Like
Hi rene,
sla configure does not accept "timeout 100 ". It shows error "timeout is less than treshold 5000.
Thanks
You should configure the threshold first before setting the timeout.
Hello,
1)Getting following error when defining timeout:
%Error: timeout value is less than threshold 5000
So the threshold and timeout should be same as follows:
R1(config-ip-sla-echo)#threshold 300
R1(config-ip-sla-echo)#timeout 300
2)Configure Tracking Object.
track 1 rtr 1 ------ Donāt accept
R1(config)#track 1 ip sla 1 reachability ---- works
Hello,
I need some advice here. In my lab I have 2 Ibgp routers going to the make believe web, I have 1 being prefered over the the other. My core isnāt participating in bgp, so Im trying to dynamically fail over when my primary goes down. the issue im running into is that when I bring up the primary router the default route isnāt pointing to the primary but staying on the secondary.In other words not failing over back to the primary. Is this a good method for this situation?
Hereās the config:
ip sla monitor 2
type echo protocol ipIcmpEcho 8.8.8.8 source-ipaddr 208.1.1.2
frequency 10
ip sla monitor schedule 2 life forever start-time now
core1#sh run | sec track
track 1 rtr 2
ip route 0.0.0.0 0.0.0.0 208.1.1.1 track 2
Thanks
Fabian,
It generally looks like you have the right idea, but if I am understanding your situation, you are also going to need a what is called a floating static route using a higher administrative distance. So general terms, this is how it works:
For your primary ISP, create a static default route which references a track object. It looks like you have done this.
For your secondary ISP, create a static default route, but define the administrative distance as being something higher than default (1). It would look like this:
ip route 0.0.0.0 0.0.0.0 <secondary gateway ip> 2
The number ā2ā above is defining the administrative distance. What will happen is that when your track object fails, the primary default route will be withdrawn, but unless you have a floating static route, nothing will replace it. By doing that second ip route statement, that route will only pop in after your primary route drops out because of the tracked object failure.
Hi Andrew,
Thanks for your reply. I added my floating route like below:
core1#sh run | i ip route
ip route 0.0.0.0 0.0.0.0 208.1.1.1 track 2
ip route 0.0.0.0 0.0.0.0 208.1.1.3 250
now Iām seeing some peculiar things, when i shut down the primary routerās interface, my default route from isp is pointing to back up router. But when i bring up the primary, the back router points to the primary but my core is still pointing to my secondary router. Im going to try tracking another ip and see what happens.
Iāll let you know what I see.
Isnt this the same as hsrp? Im not understanding the difference and the actual application of these two seem the same.
Rafa,
They are a bit different in both scope and purpose.
HSRP devices monitor each other to determine who should be the gateway, whereas IP SLA allows you to monitor just about anything. With HSRP, it is an all or nothing affair, meaning that upon a failure detection, the HSRP partner would completely take over the virtual IP and MAC address that other devices are using as a gateway. IP SLA can be more granular in its actions. For example, you could control whether a single route is published based on some failure condition being watched by an SLA monitor.
Hi Rene,
I am little bit confused about timers of IP SLA .
threshold 100
timeout 1000
frequency 3
Could you please make it clear about all above timers in your simple way .Thanks
br//
zaman
Hello Mohammad
The three parameters that you mention above are used like so:
* The threshold is the amount of time in milliseconds above which an ip sla is activated. In other words, if the response is less than the threshold, the network is functioning normally. If it is above the threshold, statistics are gathered and some action that is configured takes place.
* The timeout is the number of milliseconds the system waits for a response. If this time is exceeded, the attempt is considered lost.
* The frequency is how often the SLA operation takes place.
For example, if you create an IP sla where a specific IP address is pinged, and you set the threshold to be 500, the timeout to be 2000 and the frequency to be 10, then the following will occur:
* A ping will be sent out every 10 seconds.
* If the response is below the threshold, it is considered normal network behaviour
* If the response is above the threshold but below the timeout, statistics are updated and the configured action takes place
* If the response is above the timeout, the attempt is considered lost, statistics are gathered and the system no longer waits for a response.
I hope this has been helpful!
Laz
Hi Rene/Moderators,
When 8.8.8.8 is not reachable from dialer0, default route via cellular takes over.
The traffic is not failing back from cellular to dialer, would it be because timeout and threshold have not been defined?
track 234 ip sla 1 reachability
ip sla 1
icmp-echo 8.8.8.8 source-interface Dialer0
frequency 5
ip sla schedule 1 life forever start-time now
ip route 0.0.0.0 0.0.0.0 Dialer0 track 234
ip route 0.0.0.0 0.0.0.0 Cellular0 254Hi @mrleeiian
Your IP SLA configuration looks fine, even if you havenāt configured a timeout/threshold, there are default values:
R1#show ip sla configuration
IP SLAs Infrastructure Engine-III
Entry number: 1
Owner:
Tag:
Operation timeout (milliseconds): 5000
Type of operation to perform: icmp-echo
Target address/Source interface: 4.4.4.4/GigabitEthernet0/1
Type Of Service parameter: 0x0
Request size (ARR data portion): 28
Data pattern: 0xABCDABCD
Verify data: No
Vrf Name:
Schedule:
Operation frequency (seconds): 5 (not considered if randomly scheduled)
Next Scheduled Start Time: Start Time already passed
Group Scheduled : FALSE
Randomly Scheduled : FALSE
Life (seconds): Forever
Entry Ageout (seconds): never
Recurring (Starting Everyday): FALSE
Status of entry (SNMP RowStatus): Active
Threshold (milliseconds): 5000
Distribution Statistics:
Number of statistic hours kept: 2
Number of statistic distribution buckets kept: 1
Statistic distribution interval (milliseconds): 20
Enhanced History:
History Statistics:
Number of history Lives kept: 0
Number of history Buckets kept: 15
History Filter Type: None
Rene
Hi Rene
I have read this ! 
You recommend to ping something on internet and i have try 8.8.8.8 and apply IP SLA on my primary static route, so when some thing wrong with my first static route to ISP1 it canāt reach 8.8.8.8. Then it will show %TRACKING-5-STATE: 1 rtr 1 state Up->Down, then it will pick up the secondary static route install in routing table then mean it can reach 8.8.8.8. It make my IP sla keep up and down up and down.
Can you help me on this, Thank you!
Hi Rene
I have read this !
You recommend to ping something on internet and i have try 8.8.8.8 and apply IP SLA on my primary static route, so when some thing wrong with my first static route to ISP1 it canāt reach 8.8.8.8. Then it will show %TRACKING-5-STATE: 1 rtr 1 state Up->Down, then it will pick up the secondary static route install in routing table then mean it can reach 8.8.8.8. It make my IP sla keep up and down up and down.
Can you help me on this.
Thank you so much
Sovandara !