Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1039
  • Last Modified:

Cisco object tracking dropped packets

I'm tracking some objects (using icmp-echo's) for use in a failover scenario. One of the objects that I'm tracking (outside my control) occasionally drops the ping. This results in a flap of the path.

Is there any way to have the object not considered down until a defined number of pings are dropped?

Running IOS version 15.
ip sla 1
 icmp-echo 1.1.1.1 source-interface f0/0
 frequency 10
 timeout 5000
ip sla schedule 1 life forever start-time now

Open in new window

0
Don Johnston
Asked:
Don Johnston
1 Solution
 
ffleismaCommented:
try tracking the interface status instead if that is applicable for your scenario. here is a link that briefly overviews it.

http://blog.ioshints.info/2007/08/track-interface-ip-routing-detects.html
0
 
Don JohnstonInstructorAuthor Commented:
That's not a viable option in this situation.
0
 
Ernie BeekCommented:
Perhaps react ?

The following example shows how to configure operation parameters and proactive threshold monitoring using an auto IP SLAs operation template. In this example, the proactive threshold monitoring configuration for the ICMP echo operation specifies that when three consecutive timeout events occur, an SNMP trap notification should be sent.

Router(config)#ip sla auto template type ip icmp-echo react-to
Router(config-tplt-icmp-ech)#react timeout action-type traponly threshold-type conecutive
3
Router(config-tplt-icmp-ech)#end
Router# show ip sla auto template type ip icmp-echo
IP SLAs Auto Template: react-to
    Measure Type: icmp-echo
    Description:
    .
      .
      .
      Reaction Configuration:
        Reaction Index       : 1
          Reaction           : timeout
          Threshold Type     : Consecutive
          Threshold CountX   : 3
          Threshold CountY   : 5
          Action Type        : Trap Only


Source: http://www.cisco.com/en/US/docs/ios/ipsla/command/reference/sla_03.html
0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
Don JohnstonInstructorAuthor Commented:
I looked at that. But it appears that can only be used to send SNMP traps while I'm trying to use a different route.

i.e.: http://www.cisco.com/en/US/docs/ios/12_3/12_3x/12_3xe/feature/guide/dbackupx.html#wp1071672
0
 
lrmooreCommented:
Have you played around with the sla frequency and timeout values? Increase the frequency to be longer than the timeout value?
Have you considered using other than icmp echo? I've been succesful in using http get instead. Too often the carriers will block icmp for no apparent reason, then open it back up.
0
 
lrmooreCommented:
Or set the track delay timer so the route change is delayed. Set the delay to be 2x the frequency value in the sla?
0
 
Don JohnstonInstructorAuthor Commented:
>Increase the frequency to be longer than the timeout value?

Tried that. The problem is that as soon as the packet is lost, the route flaps. I've increased the freq and the timeout.

>Have you considered using other than icmp echo?

No, I haven't. The object that I'm tracking is the carriers router. I didn't think that I could get a response from anything beyond as ICMP echo.

>Or set the track delay timer so the route change is delayed. Set the delay to be 2x the frequency value in the sla?

That might be the solution. Can you give my an example of the code to do this? (the "problem" object is sla 1)
!
interface f0/0
 ip address 1.1.1.2 255.255.255.252
 ip nat outside
!
interface f0/1
 ip address 2.2.2.2 255.255.255.252
 ip nat outside
!
interface f0/3
 ip address 192.168.6.2 255.255.255.0
 ip nat inside
 ip policy route-map alpha
! 
track 123 ip sla 1 reachability
!
track 234 ip sla 2 reachability
!
ip nat inside source route-map beta1 interface f0/0 overload
ip nat inside source route-map beta2 interface f0/1 overload
!
ip sla 1
 icmp-echo 1.1.1.1 source-interface f0/0
 frequency 10
 timeout 5000
ip sla schedule 1 life forever start-time now
!
ip sla 2
 icmp-echo 2.2.2.1 source-interface f0/1
 timeout 1000
 frequency 3
ip sla schedule 2 life forever start-time now
!
route-map beta2 permit 10
 match ip address 1
 match interface f0/1
!
route-map beta1 permit 10
 match ip address 1
 match interface f0/0
!
route-map alpha permit 10
 match ip address admin
 set ip next-hop verify-availability 1.1.1.1 10 track 123
 set ip next-hop verify-availability 2.2.2.1 20 track 234
!
route-map alpha permit 20
 match ip address res-guest
 set ip next-hop verify-availability 2.2.2.1 10 track 234
 set ip next-hop verify-availability 1.1.1.1 20 track 123
!

Open in new window

0
 
lrmooreCommented:
track 1 ip sla 1 reach
 delay down 30  <seconds>

Your sla pops every 10 seconds, so a track delay of 30 seconds should catch at least two iterations of lost packets before it drops.
0
 
Don JohnstonInstructorAuthor Commented:
Bingo!

I got so caught up in the SLA configuration that I never thought to look at a tracking delay.

Thanks!
0

Featured Post

Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Tackle projects and never again get stuck behind a technical roadblock.
Join Now