Re: IP SLA flapping using ICMP delay within GNS3 LAB

RLhodges1 · ‎01-02-2019

GNS3 Topology.PNG I am trying to figure out why the SLA is flapping between 10.1.2.2 and 10.1.3.2 every 15 seconds. The delay is below 60 Milliseconds and it still flaps to 2nd static route 10.1.3.2. Also, even if I shut down the interface on R2 , 10.1.2.2 still shows up in the routing table during the consistent flapping. I do have EIGRP configured as well. But I would think that the static entries would take precedence over the dynamic route since it has a lower AD. Here is the SLA configuration I have

! ip sla 1

icmp-echo 10.1.6.2 source-ip 10.1.1.1

threshold 60

frequency 5

track 1 ip sla 1

delay down 5 up 5

ip sla schedule 1 life forever start-time now

ip route 10.1.6.0 255.255.255.0 10.1.2.2 track 1

ip route 10.1.6.0 255.255.255.0 10.1.3.2 2

However I am getting this response even if the connection to router 2 to is down.

Router(config)# *Jan 2 17:00:03.150: %TRACK-6-STATE: 1 ip sla 1 state Down -> Up

Router(config)# *Jan 2 17:00:18.158: %TRACK-6-STATE: 1 ip sla 1 state Up -> Down

Router(config)# *Jan 2 17:00:33.166: %TRACK-6-STATE: 1 ip sla 1 state Down -> Up

Router(config)# *Jan 2 17:00:48.176: %TRACK-6-STATE: 1 ip sla 1 state Up -> Down

Router(config)# *Jan 2 17:01:03.180: %TRACK-6-STATE: 1 ip sla 1 state Down -> Up

Georg Pauwen · ‎01-03-2019

Hello,

looking at your SLA, if the source IP is 10.1.1.1, then 10.1.6.2 is always reachable. What if you make the source IP 10.1.2.1 ?

Georg Pauwen · ‎01-03-2019

Hello,

also, can you post the full configuration of your R1 router ?

RLhodges1 · ‎01-03-2019

The router configuration is attached to the original post. but here it is. And since it is using ICMP-echo, it should be from a constant reference. I have seen configs using loopback interfaces for this purpose, but still cannot figure out why this is happening. It may be a GNS3 bug. Or is it because I have EIGRP enabled as well? But again, this should not matter, as a static route takes precedence over a dynamically learned route. I have also increased the delay to 500 milliseconds and the frequency to every 10 seconds and it is still happening.

Router(config)#do show run
Building configuration...

Current configuration : 3467 bytes
!
! Last configuration change at 17:34:46 UTC Wed Jan 2 2019
!
version 15.6
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname Router
!
boot-start-marker
boot-end-marker
!
!no aaa new-model
ethernet lmi ce
!
!
mmi polling-interval 60
no mmi auto-configure
no mmi pvc
mmi snmp-timeout 180
!
!
no ip icmp rate-limit unreachable
!
no ip domain lookup
ip cef
no ipv6 cef
!
multilink bundle-name authenticated
!
redundancy
!
no cdp log mismatch duplex
!
track 1 ip sla 1
delay down 10 up 10
!
ip tcp synwait-time 5
!
!
interface GigabitEthernet0/0
ip address 10.1.1.1 255.255.255.0
duplex auto
speed auto
media-type rj45
!
interface GigabitEthernet0/1
ip address 10.1.2.1 255.255.255.0
duplex auto
speed auto
media-type rj45
!
interface GigabitEthernet0/2
ip address 10.1.3.1 255.255.255.0
duplex auto
speed auto
media-type rj45
!
interface GigabitEthernet0/3
no ip address
shutdown
duplex auto
speed auto
media-type rj45
!
!
router eigrp 1
network 10.0.0.0
!
ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
ip route 10.1.6.0 255.255.255.0 10.1.2.2 track 1
ip route 10.1.6.0 255.255.255.0 10.1.3.2 2
!
ip sla 1
icmp-echo 10.1.6.2 source-ip 10.1.1.1
threshold 500
frequency 10
ip sla schedule 1 life forever start-time now
!

control-plane
!
banner exec ^C
**************************************************************************
* IOSv is strictly limited to use for evaluation, demonstration and IOS *
* education. IOSv is provided as-is and is not supported by Cisco's *
* Technical Advisory Center. Any use or disclosure, in whole or in part, *
* of the IOSv Software or Documentation to any third party for any *
* purposes is expressly prohibited except as otherwise authorized by *
* Cisco in writing. *
**************************************************************************^C
banner incoming ^C
**************************************************************************
* IOSv is strictly limited to use for evaluation, demonstration and IOS *
* education. IOSv is provided as-is and is not supported by Cisco's *
* Technical Advisory Center. Any use or disclosure, in whole or in part, *
* of the IOSv Software or Documentation to any third party for any *
* purposes is expressly prohibited except as otherwise authorized by *
* Cisco in writing. *
**************************************************************************^C
banner login ^C
**************************************************************************
* IOSv is strictly limited to use for evaluation, demonstration and IOS *
* education. IOSv is provided as-is and is not supported by Cisco's *
* Technical Advisory Center. Any use or disclosure, in whole or in part, *
* of the IOSv Software or Documentation to any third party for any *
* purposes is expressly prohibited except as otherwise authorized by *
* Cisco in writing. *
**************************************************************************^C
!
line con 0
exec-timeout 0 0
privilege level 15
logging synchronous
line aux 0
exec-timeout 0 0
privilege level 15
logging synchronous
line vty 0 4
login
transport input none
!
no scheduler allocate
!
end

Georg Pauwen · ‎01-03-2019

Hello,

I recreated the entire lab, and I get some weird results. Does the tracked static route ever appear in your routing table ?

Somehow I don't even get to manage 'ip route 10.1.6.0 255.255.255.0 10.1.2.2 tack 1' to appear in the routing table...

Either way, I'll look further. Can you ping:

ping 10.1.6.2 source 10.1.1.1

because I cannot...

RLhodges1 · ‎01-03-2019

I am using EIGRP as my underlying routing protocol and removed auto-summary on all router configs. I can ping 10.1.6.2 source 10.1.1.1. And notice that the max reply is under 50 ms. Also both routes toggle with this behavior. Check the routing table before and after the message. (second example)

Router(config-router)#do ping 10.1.6.2 source 10.1.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.6.2, timeout is 2 seconds:
Packet sent with a source address of 10.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/34/47 ms
Router(config-router)#

(second Example)

Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 10 subnets, 2 masks
C 10.1.1.0/24 is directly connected, GigabitEthernet0/0
L 10.1.1.1/32 is directly connected, GigabitEthernet0/0
C 10.1.2.0/24 is directly connected, GigabitEthernet0/1
L 10.1.2.1/32 is directly connected, GigabitEthernet0/1
C 10.1.3.0/24 is directly connected, GigabitEthernet0/2
L 10.1.3.1/32 is directly connected, GigabitEthernet0/2
D 10.1.4.0/24 [90/2682112] via 10.1.3.2, 02:07:11, GigabitEthernet0/2
D 10.1.5.0/24 [90/2170112] via 10.1.3.2, 02:07:11, GigabitEthernet0/2
S 10.1.6.0/24 [2/0] via 10.1.3.2 <<<<<<<<<<<<<<<<<<<<
C 10.1.7.1/32 is directly connected, Loopback1
Router#
*Jan 4 04:31:55.215: %TRACK-6-STATE: 1 ip sla 1 state Down -> Up
Router#show ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 10 subnets, 2 masks
C 10.1.1.0/24 is directly connected, GigabitEthernet0/0
L 10.1.1.1/32 is directly connected, GigabitEthernet0/0
C 10.1.2.0/24 is directly connected, GigabitEthernet0/1
L 10.1.2.1/32 is directly connected, GigabitEthernet0/1
C 10.1.3.0/24 is directly connected, GigabitEthernet0/2
L 10.1.3.1/32 is directly connected, GigabitEthernet0/2
D 10.1.4.0/24 [90/2682112] via 10.1.3.2, 02:07:42, GigabitEthernet0/2
D 10.1.5.0/24 [90/2170112] via 10.1.3.2, 02:07:42, GigabitEthernet0/2
S 10.1.6.0/24 [1/0] via 10.1.2.2<<<<<<<<<<<<<<<<<<<<<<
--More--
*Jan 4 04:32:20.226: %TRACK-6-STATE: 1 ip sla 1 state Up -> Down
--More--

Georg Pauwen · ‎01-04-2019

Hello,

S 10.1.6.0/24 [2/0] via 10.1.3.2 <<<<<<<<<<<<<<<<<<<<

This is exactly what I get, with both links up. While you would expect the tracked route (with next hop 10.1.2.2) to be in the routing table, but that never happens. In my lab, it seems that somehow the 'track' command added to the static route prevents it from ever getting to the routing table. Not sure if this is GNS3 specific, at the very least, it is not expected behavior.

I am doing some further testing...

Georg Pauwen · ‎01-04-2019

Hello,

I think I figured it out. The problem is that in GNS3, an interface is always up/up unless is it admined down. Even if you shut down the interface on R2, the interface on R1 is still up/up. Only when you shut the interface on R1 that connects to R2, the route flapping and the Track flapping stops.

On 'real' routers, if the adjacent side goes down, the interface status on R1 would be up/down, or down/down, but never up/up.

So basically, it is a flaw in GNS3. Administratively shut down interface GigabitEthernet0/1 on R1, an the flapping stops.

RLhodges1 · ‎01-05-2019

Hello Georg,

I got this working too. The two routers on the ends were supposed to be set up as clients with no routing enabled. I recreated it with no eigrp routing processes on 10.1.1.2 and 10.1.6.2. Also with the no ip routing command. I ran a debug after this and as long as the delay was below 80 ms the route stayed with the next hop being 10.1.2.2 on it's way to 10.1.6.2. I think it might have been a GNS3 issue. But after recreating it with those changes, then it started to work. I guess I could recreate the process on those two end routers and see if it starts bouncing again. Thanks.

here is the output of the routing table and the "Debug ip sla trace 1" for R1

10.0.0.0/8 is variably subnetted, 9 subnets, 2 masks
C 10.1.1.0/24 is directly connected, GigabitEthernet0/0
L 10.1.1.1/32 is directly connected, GigabitEthernet0/0
C 10.1.2.0/24 is directly connected, GigabitEthernet0/1
L 10.1.2.1/32 is directly connected, GigabitEthernet0/1
C 10.1.3.0/24 is directly connected, GigabitEthernet0/2
L 10.1.3.1/32 is directly connected, GigabitEthernet0/2
D 10.1.4.0/24 [90/2170112] via 10.1.2.2, 00:01:18, GigabitEthernet0/1
D 10.1.5.0/24 [90/2170112] via 10.1.3.2, 00:01:18, GigabitEthernet0/2
S 10.1.6.0/24 [1/0] via 10.1.2.2
Router#
*Jan 5 20:08:31.407: IPSLA-INFRA_TRACE:OPER:1 slaSchedulerEventWakeup

*Jan 5 20:08:31.408: IPSLA-INFRA_TRACE:OPER:1 Starting an operation

*Jan 5 20:08:31.409: IPSLA-OPER_TRACE:OPER:1 source IP:10.1.1.1

*Jan 5 20:08:31.409: IPSLA-OPER_TRACE:OPER:1 Starting icmpecho operation - destAddr=10.1.6.2, sAddr=10.1.1.1

*Jan 5 20:08:31.409: IPSLA-OPER_TRACE:OPER:1 Sending ID: 13

*Jan 5 20:08:31.502: IPSLA-OPER_TRACE:OPER:1 ID:13, RTT=20

*Jan 5 20:08:31.515: IPSLA-INFRA_TRACE:OPER:1 slaSchedulerUpdate Enter

*Jan 5 20:08:31.517: IPSLA-INFRA_TRACE:OPER:1 Updating result

*Jan 5 20:08:31.518: IPSLA-INFRA_TRACE:OPER:1 Updating link

Router#
*Jan 5 20:08:31.518: IPSLA-INFRA_TRACE:OPER:1 Updating link

*Jan 5 20:08:31.519: IPSLA-INFRA_TRACE:OPER:1 Updating link

*Jan 5 20:08:31.522: IPSLA-INFRA_TRACE:OPER:1 Updating link

*Jan 5 20:08:31.523: IPSLA-INFRA_TRACE:OPER:1 Updating link

*Jan 5 20:08:31.531: IPSLA-INFRA_TRACE:OPER:1 slaSchedulerUpdate:set Wakeup op=13, cm= 0