1 2 Previous Next 16 Replies Latest reply: Jan 14, 2018 8:53 PM by Steven Davidson RSS

    A curious issue with Object Tracking

    Amil Akhundoff

      Hi guys,

       

      I have a curious issue. I've built the following topology:

       

      ip sla.PNG

       

      I've the following significant configuration on R1 and R2:

       

      R1.PNG

       

       

      R2.PNG

       

       

      As you might imagine, the next to 192.168.0.0/24 on R1 is via 20.0.0.2. Let's shut down the interface Ethernet 2/1 on R2 and see what happens on R1:

       

      R1(2).PNG

       

      R2(3).PNG

       

      R1(3).PNG

       

       

      As you see, everything works OK.

       

      But when I change the "ip route 172.16.0.0 255.255.255.0 30.0.0.1" to "ip route 0.0.0.0 0.0.0.0 30.0.0.1" on R2, and I repeat the same operation, the Object Tracking starts flapping:

       

      R1(4).PNG

       

      This issue is very interesting. How can the "ip route ..." statement on one router affect on Object Tracking on the other route??! I just can't imagine the reason why.. the flow of process leading to it. Could you recreate this scenario and help me figure it out ?!

       

      Thanks!

        • 1. Re: A curious issue with Object Tracking
          Ing_Percy

          Hi!

           

          I Implemented your topology and see one detail in your configuration that is different to defined by the picture

           

          My configuration

          R2#sh run | sec ip route|Ethernet2/0|Ethernet2/1|Ethernet2/2

          interface Ethernet2/0

          ip address 192.168.0.1 255.255.255.0

          duplex full

          interface FastEthernet2/1

          ip address 20.0.0.2. 255.255.255.0

          duplex full

          interface FastEthernet2/2

          ip address 30.0.0.2. 255.255.255.0

          duplex full

          ip route 0.0.0.0 0.0.0.0 30.0.0.1

           

          Now, when you put "shutdown" in E2/1 in R2, you can see that the IP address in E2/1 in R1 continues in "up/up" state

          R1#sh ip int b

          Interface              IP-Address      OK? Method Status                Protocol

          Ethernet2/1          20.0.0.1        YES manual up                    up

           

          As the network 20.0.0.0/24 is active in R1, It will try to reach the IP 192.168.0.1 by the command:

          "icmp-echo 192.168.0.1 source-interface Ethernet2/1"

          It produces the flapping.

           

          Also, in CLN there is a similar case:

          IP SLA constant state change

           

          Cisco recommends to implement the "icmp-echo" using the next-hop address of the segment in case of ISPs, then, it will apply to the topology:

          R1#show run | i icmp-echo

          icmp-echo 20.0.0.2 source-interface Ethernet2/1

           

          Source: ISP Failover with Default Routes using IP SLA Tracking - Cisco

           

          When the interface E2/1 on R2 is "shutdown"

          R1#traceroute 192.168.0.1 source 172.16.0.254

          Type escape sequence to abort.

          Tracing the route to 192.168.0.1

          VRF info: (vrf in name/id, vrf out name/id)

            1 30.0.0.2 0 msec 44 msec 20 msec

           

          When the interface E2/1 on R2 is "no shutdown"

          R1#traceroute 192.168.0.1 source 172.16.0.254

          Type escape sequence to abort.

          Tracing the route to 192.168.0.1

          VRF info: (vrf in name/id, vrf out name/id)

            1 20.0.0.2 16 msec 24 msec 12 msec


          In my case, now the topology works without flapping. Maybe can be a bug in GNS3. When I practiced about this topic, I see some errors when change many times the IP SLA/track in GNS3 (Specially when I change the states of the interface to verify the changes in PBR). I recommend you implement these features (IP SLA/Track/PBR) in real devices.

           

          Best regards!

          • 2. Re: A curious issue with Object Tracking
            Modestas

            Amil Akhundoff (aka showint) wrote:

             

            Hi guys,

             

            I have a curious issue. I've built the following topology:

            This issue is very interesting. How can the "ip route ..." statement on one router affect on Object Tracking on the other route??! I just can't imagine the reason why.. the flow of process leading to it. Could you recreate this scenario and help me figure it out ?!

             

            Thanks!

            Hi

            I think solution works as designed, but design is not optimal.

            SLA is tracking remote network from source IP 20.0.0.1. As soon as "ip route 0.0.0.0 0.0.0.0 30.0.0.1" is configured on R2 and e2/1 is disabled, SLA operation succeeds and route via  20.0.0.2 kicks in again.

            You may want to track nexthop address 20.0.0.2 instead of 192.168.0.1.

            Regards

            Modestas

            • 3. Re: A curious issue with Object Tracking
              Modestas

              Tried to build this scenario in GNS3 and run icmp debug on R2.

              Hope this helps. See icmp echo source IP addr in the printout below:

              R2#sh proto

              Global values:

                Internet Protocol routing is enabled

              GigabitEthernet0/0 is up, line protocol is up

                Internet address is 20.0.0.2/24

              GigabitEthernet0/1 is up, line protocol is up

                Internet address is 30.0.0.2/24

              GigabitEthernet0/2 is up, line protocol is up

                Internet address is 192.168.0.1/24

              GigabitEthernet0/3 is administratively down, line protocol is down

              R2#deb ip icmp

              R2#

              *Jan 12 18:19:03.816: ICMP: echo reply rcvd, src 20.0.0.1, dst 20.0.0.2, topology BASE, dscp 0 topoid 0

              *Jan 12 18:19:03.824: ICMP: echo reply rcvd, src 20.0.0.1, dst 20.0.0.2, topology BASE, dscp 0 topoid 0

              *Jan 12 18:19:03.830: ICMP: echo reply rcvd, src 20.0.0.1, dst 20.0.0.2, topology BASE, dscp 0 topoid 0

              *Jan 12 18:19:03.840: ICMP: echo reply rcvd, src 20.0.0.1, dst 20.0.0.2, topology BASE, dscp 0 topoid 0

              R2#

              *Jan 12 18:19:06.623: ICMP: echo reply sent, src 192.168.0.1, dst 20.0.0.1, topology BASE, dscp 0 topoid 0

              R2#

              R2#

              *Jan 12 18:19:11.624: ICMP: echo reply sent, src 192.168.0.1, dst 20.0.0.1, topology BASE, dscp 0 topoid 0

              R2#

              *Jan 12 18:19:16.632: ICMP: echo reply sent, src 192.168.0.1, dst 20.0.0.1, topology BASE, dscp 0 topoid 0

              R2#conf t

              *Jan 12 18:19:21.641: ICMP: echo reply sent, src 192.168.0.1, dst 20.0.0.1, topology BASE, dscp 0 topoid 0

              R2#conf t

              Enter configuration commands, one per line.  End with CNTL/Z.

              *Jan 12 18:19:26.641: ICMP: echo reply sent, src 192.168.0.1, dst 20.0.0.1, topology BASE, dscp 0 topoid 0

              *Jan 12 18:19:31.637: ICMP: echo reply sent, src 192.168.0.1, dst 20.0.0.1, topology BASE, dscp 0 topoid 0

              R2(config)#ip route 0.0.0.0 0.0.0.0 30.0.0.1

              R2(config)#

              *Jan 12 18:19:36.643: ICMP: echo reply sent, src 192.168.0.1, dst 20.0.0.1, topology BASE, dscp 0 topoid 0

              R2(config)#^Z

              R2#

              R2#

              *Jan 12 18:19:38.977: %SYS-5-CONFIG_I: Configured from console by console

              R2#sh ip rou

              R2#sh ip route

              <snip>

              Gateway of last resort is 30.0.0.1 to network 0.0.0.0

               

              S*    0.0.0.0/0 [1/0] via 30.0.0.1

                    20.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

              C        20.0.0.0/24 is directly connected, GigabitEthernet0/0

              L        20.0.0.2/32 is directly connected, GigabitEthernet0/0

                    30.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

              C        30.0.0.0/24 is directly connected, GigabitEthernet0/1

              L        30.0.0.2/32 is directly connected, GigabitEthernet0/1

                    192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks

              C        192.168.0.0/24 is directly connected, GigabitEthernet0/2

              L        192.168.0.1/32 is directly connected, GigabitEthernet0/2

              R2#

              *Jan 12 18:19:41.643: ICMP: echo reply sent, src 192.168.0.1, dst 20.0.0.1, topology BASE, dscp 0 topoid 0

              R2#conf t

              Enter configuration commands, one per line.  End with CNTL/Z.

              R2(config)#int g0/0

              R2(config-if)#

              *Jan 12 18:19:46.644: ICMP: echo reply sent, src 192.168.0.1, dst 20.0.0.1, topology BASE, dscp 0 topoid 0s

              R2(config-if)#sh

              R2(config-if)#

              *Jan 12 18:19:50.434: %LINK-5-CHANGED: Interface GigabitEthernet0/0, changed state to administratively down

              *Jan 12 18:19:51.434: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to down

              R2(config-if)#

              *Jan 12 18:19:51.645: ICMP: echo reply sent, src 192.168.0.1, dst 20.0.0.1, topology BASE, dscp 0 topoid 0

              R2(config-if)#

              *Jan 12 18:19:56.656: ICMP: echo reply sent, src 192.168.0.1, dst 20.0.0.1, topology BASE, dscp 0 topoid 0

              R2(config-if)#

              *Jan 12 18:20:01.662: ICMP: echo reply sent, src 192.168.0.1, dst 20.0.0.1, topology BASE, dscp 0 topoid 0

              R2(config-if)#do sh ip rou

              R2(config-if)#do sh ip rou

              <snip>

              Gateway of last resort is 30.0.0.1 to network 0.0.0.0

               

              S*    0.0.0.0/0 [1/0] via 30.0.0.1

                    30.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

              C        30.0.0.0/24 is directly connected, GigabitEthernet0/1

              L        30.0.0.2/32 is directly connected, GigabitEthernet0/1

                    192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks

              C        192.168.0.0/24 is directly connected, GigabitEthernet0/2

              L        192.168.0.1/32 is directly connected, GigabitEthernet0/2

              R2(config-if)#

              *Jan 12 18:20:06.658: ICMP: echo reply sent, src 192.168.0.1, dst 20.0.0.1, topology BASE, dscp 0 topoid 0

              R2(config-if)#

              *Jan 12 18:20:11.658: ICMP: echo reply sent, src 192.168.0.1, dst 20.0.0.1, topology BASE, dscp 0 topoid 0

              R2(config-if)#

              *Jan 12 18:20:16.663: ICMP: echo reply sent, src 192.168.0.1, dst 20.0.0.1, topology BASE, dscp 0 topoid 0

              R2(config-if)#

              *Jan 12 18:20:21.663: ICMP: echo reply sent, src 192.168.0.1, dst 20.0.0.1, topology BASE, dscp 0 topoid 0

              R2(config-if)#int g0/0

              R2(config-if)#no sh

              *Jan 12 18:20:26.660: ICMP: echo reply sent, src 192.168.0.1, dst 20.0.0.1, topology BASE, dscp 0 topoid 0

              R2(config-if)#no sh

              R2(config-if)#do sh ip rou

              <snip>

              Gateway of last resort is 30.0.0.1 to network 0.0.0.0

               

              S*    0.0.0.0/0 [1/0] via 30.0.0.1

                    30.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

              C        30.0.0.0/24 is directly connected, GigabitEthernet0/1

              L        30.0.0.2/32 is directly connected, GigabitEthernet0/1

                    192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks

              C        192.168.0.0/24 is directly connected, GigabitEthernet0/2

              L        192.168.0.1/32 is directly connected, GigabitEthernet0/2

              R2(config-if)#

              *Jan 12 18:20:30.588: %LINK-3-UPDOWN: Interface GigabitEthernet0/0, changed state to up

              *Jan 12 18:20:31.588: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to up

              R2(config-if)#

              *Jan 12 18:20:31.646: ICMP: echo reply sent, src 192.168.0.1, dst 20.0.0.1, topology BASE, dscp 0 topoid 0

              R2(config-if)#do sh ip rou

              <snip>

              Gateway of last resort is 30.0.0.1 to network 0.0.0.0

               

              S*    0.0.0.0/0 [1/0] via 30.0.0.1

                    20.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

              C        20.0.0.0/24 is directly connected, GigabitEthernet0/0

              L        20.0.0.2/32 is directly connected, GigabitEthernet0/0

                    30.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

              C        30.0.0.0/24 is directly connected, GigabitEthernet0/1

              L        30.0.0.2/32 is directly connected, GigabitEthernet0/1

                    192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks

              C        192.168.0.0/24 is directly connected, GigabitEthernet0/2

              L        192.168.0.1/32 is directly connected, GigabitEthernet0/2

              R2(config-if)#

              *Jan 12 18:20:41.646: ICMP: echo reply sent, src 192.168.0.1, dst 20.0.0.1, topology BASE, dscp 0 topoid 0

              R2(config-if)#do undeb

              *Jan 12 18:20:46.647: ICMP: echo reply sent, src 192.168.0.1, dst 20.0.0.1, topology BASE, dscp 0 topoid 0

              R2(config-if)#do undeb all

              All possible debugging has been turned off

              R2(config-if)#

              • 4. Re: A curious issue with Object Tracking
                Modestas

                Ing_Percy wrote:

                 

                In my case, the topology works without flapping. Maybe can be a bug in GNS3. When I practiced about this topic, I see some errors when change many times the IP SLA/track in GNS3

                 

                Just curious.. Do you have switches between R1 and R2 in your topology?

                • 5. Re: A curious issue with Object Tracking
                  Ing_Percy

                  Hi!

                  Modestas escribió:

                  Just curious.. Do you have switches between R1 and R2 in your topology?

                  In the topology of this case, yes. But, in another implementations, the track/IP SLA doesn't change sometimes in GNS3 (The reason are by the efects to change of interfaces's state)

                   

                  Best regards!

                  • 6. Re: A curious issue with Object Tracking
                    Steven Davidson

                    Usually when you have track flapping it's because your IP SLA is reaching its target by an unattended route.  If you create a host route to your IP SLA target and specify an exit interface then it shouldn't perform recursion.

                     

                    For example:

                     

                    ip route 192.168.0.1 255.255.255.255 eth2/1 20.0.0.2

                     

                    Failure of the transit path between R1 and R2 on the primary link will cause the IP SLA to fail and the alternate default will take effect.

                    • 7. Re: A curious issue with Object Tracking
                      Amil Akhundoff

                      Percy,

                       

                      Yes, I made a mistake on a diagram. Thank you for pointing me to it.

                       

                      The below figure is the corrected one:

                       

                      Screen.PNG

                      • 8. Re: A curious issue with Object Tracking
                        Amil Akhundoff

                        Hi Steven,

                         

                        Usually when you have track flapping it's because your IP SLA is reaching its target by an unattended route.  If you create a host route to your IP SLA target and specify an exit interface then it shouldn't perform recursion.

                         

                        For example:

                         

                        ip route 192.168.0.1 255.255.255.255 eth2/1 20.0.0.2

                         

                        Failure of the transit path between R1 and R2 on the primary link will cause the IP SLA to fail and the alternate default will take effect.

                         

                        Can you describe it in more detail, please? Your reply seems to be of importance, but it is unclear to me.

                        • 9. Re: A curious issue with Object Tracking
                          Amil Akhundoff

                          Hi Percy,

                           

                          This excerpt is taken from the link you posted above:

                          IP SLA constant state change

                           

                          Sandeep,

                           

                          You are right, but as you can see from Trent's example, it can lead to other complications. Usually what I've seen being done in production to test ISP's connectivity to the rest of the world is that: an unused host on the internet was chosen. For example, 23.235.37.144. A static route to that host IP was configured via one link only. That ensured that any probes were sent only via one link. And it also shows that even though connectivity to the SP itself is up and healthy, the SP's transit links might be down.

                           

                          Hi

                          I think solution works as designed, but design is not optimal.

                          SLA is tracking remote network from source IP 20.0.0.1. As soon as "ip route 0.0.0.0 0.0.0.0 30.0.0.1" is configured on R2 and e2/1 is disabled, SLA operation succeeds and route via  20.0.0.2 kicks in again.

                          You may want to track nexthop address 20.0.0.2 instead of 192.168.0.1.

                          Regards

                          Modestas

                           

                          So what's the best practice to track, the next hop or an unused host on the Internet?

                           

                          Ing_Percy

                          Cisco recommends to implement the "icmp-echo" using the next-hop address of the segment in case of ISPs, then, it will apply to the topology:

                           

                          Where can I read about the Cisco's recommendation ?

                           

                          Thanks!

                          • 10. Re: A curious issue with Object Tracking
                            Modestas

                            Amil Akhundoff (aka showint) wrote:

                             

                            Hi

                            I think solution works as designed, but design is not optimal.

                            SLA is tracking remote network from source IP 20.0.0.1. As soon as "ip route 0.0.0.0 0.0.0.0 30.0.0.1" is configured on R2 and e2/1 is disabled, SLA operation succeeds and route via  20.0.0.2 kicks in again.

                            You may want to track nexthop address 20.0.0.2 instead of 192.168.0.1.

                            Regards

                            Modestas

                             

                            So what's the best practice to track, the next hop or an unused host on the Internet?

                            Hi

                            I was always tracking next hop address to detect transmission path / EVC failures. But that's great from ISP perspective when dynamic routing was not an option.

                            Your mileage may vary. Try to approach NW designer

                            I liked your idea to insert L2 switches between R1 and R2 to simulate impact of real world transmission failures.

                            • 11. Re: A curious issue with Object Tracking
                              Modestas

                              Amil Akhundoff (aka showint) wrote:

                               

                              Hi Steven,

                               

                              Usually when you have track flapping it's because your IP SLA is reaching its target by an unattended route.  If you create a host route to your IP SLA target and specify an exit interface then it shouldn't perform recursion.

                               

                              For example:

                               

                              ip route 192.168.0.1 255.255.255.255 eth2/1 20.0.0.2

                               

                              Failure of the transit path between R1 and R2 on the primary link will cause the IP SLA to fail and the alternate default will take effect.

                               

                              Can you describe it in more detail, please? Your reply seems to be of importance, but it is unclear to me.

                              This suggestion is good when primary goal is to stabilize SLA probe operation. But it will have side effect: users will experience communication problem with host 192.168.0.1 when primary path between R1 and R2 fails.

                              • 12. Re: A curious issue with Object Tracking
                                Ing_Percy

                                Hi!

                                 

                                Amil Akhundoff (aka showint) escribió:

                                 

                                Where can I read about the Cisco's recommendation ?

                                 

                                Thanks!

                                In the page of Cisco is its topology:

                                ISP Failover with Default Routes using IP SLA Tracking - Cisco

                                 

                                Best regards!

                                • 13. Re: A curious issue with Object Tracking
                                  Ing_Percy

                                  Hi!

                                   

                                  In your design original:

                                   

                                  When you put the interface Ethernet2/1 of R2 in "shutdown" and also will see that the interface Ethernet2/1 of R1 is un "up/up" state, occurs the following:

                                   

                                  1.The ping packets are sent over the broken link (next-hop 20.0.0.2) and because it is broken, there is no reply.

                                  2. The tracking object goes down.

                                  3. As the tracking object is down, another default route is used (next-hop 30.0.0.2).

                                  4. The ping packets are sent over the not broken link and the reply is received.

                                  5. The tracking object is UP again and the default route via broken link is reinstated (next-hop 20.0.0.2).

                                  6. The process is started all over again (Go to 1 again).

                                  It produces "flapping"


                                  Best regards!

                                  • 14. Re: A curious issue with Object Tracking
                                    Steven Davidson

                                    Amil Akhundoff (aka showint) wrote:

                                     

                                    Hi Steven,

                                     

                                    Usually when you have track flapping it's because your IP SLA is reaching its target by an unattended route.  If you create a host route to your IP SLA target and specify an exit interface then it shouldn't perform recursion.

                                     

                                    For example:

                                     

                                    ip route 192.168.0.1 255.255.255.255 eth2/1 20.0.0.2

                                     

                                    Failure of the transit path between R1 and R2 on the primary link will cause the IP SLA to fail and the alternate default will take effect.

                                     

                                    Can you describe it in more detail, please? Your reply seems to be of importance, but it is unclear to me.

                                    See if this makes sense

                                    1 2 Previous Next