[c-nsp] Wonky tracking?

Mon Aug 13 13:28:14 EDT 2007

Can you get the debug track and debug ip sla mon/event
outputs?

Remember, this is best effort support and we try our best
to get to them as soon as we can.

Rodney

On Wed, Aug 08, 2007 at 02:05:52PM -0400, Tuc at T-B-O-H.NET wrote:
> Rodney/Anybody...
> 
> 	Help?
> 
> 	This is really getting annoying. The whole
> purpose of IP SLA/TRACK is being lost here. If I'm
> doing something wrong, PLEASE tell me. I've put the track
> as high up as possible, but I still see :
> 
> C3640-1#sho ip route
> Codes: 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
> 
> Gateway of last resort is 192.168.75.1 to network 0.0.0.0
> 
> C    192.168.75.0/24 is directly connected, Ethernet0/0
> C    192.168.0.0/24 is directly connected, Ethernet1/0
>      204.107.90.0/32 is subnetted, 1 subnets
> S       204.107.90.9 [1/0] via 192.168.0.1
> C    192.168.3.0/24 is directly connected, BVI1
> S*   0.0.0.0/0 [250/0] via 192.168.75.1
> C3640-1#sho ip route track
>  ip route 0.0.0.0 0.0.0.0 192.168.75.1 10 name SEABREEZE track 100 state is [down]
>  ip route 0.0.0.0 0.0.0.0 192.168.0.1 11 name HUGHES track 200 state is [up]
> 
> 	So when this happens, my site is trying to talk out
> a bad interface, since SOMEHOW its falling over the track 200 at weight 11 and
> going to weight 250 which is a default back to 192.168.75.1
> 
> 	I don't have a contract, for the price I could buy 4 or 5 of these
> a year, but this track issue is really a problem. I appreciate what people
> have said/done, but its still not working and I'm still having major gaps
> in connectivity.
> 
> 		Thanks, Tuc
> > 
> > Tuc,
> > 
> > What does 'sh ip sla mon stat' show for that probe?
> > 
> > What does debug track show?
> > debug ip sla monitor etcc...
> > 
> > Also, it's confusing. But it's bet to set the track
> > up/down to at least a 2x multiple of the sla probe frequency.
> > 
> > Meaning if you get a notification the probe is down
> > and you delay it going down for 10 more seconds but that
> > is right on the time the next probe should go out it's
> > potentially possible I think that you could get in a race
> > condition and it always show down.
> > 
> > Or it could be a bug. I've seen reports where the probe would
> > hang until it was reconfigured. But I'd like to see if the
> > probe is really reporting up/or down and the track object
> > is just stuck down.
> > 
> > Rodney
> > 
> > 
> > On Tue, Jul 31, 2007 at 11:20:21AM -0400, Tuc at T-B-O-H.NET wrote:
> > > Hi,
> > > 
> > > 	3640 running c3640-jk9s-mz.124-13a.bin .
> > > 
> > > 	I have a set of ip sla/tracks, as such :
> > > 
> > > ip sla monitor 200
> > >  type echo protocol ipIcmpEcho 204.107.90.128 source-ipaddr 192.168.0.3
> > >  timeout 4000
> > >  frequency 10
> > > ip sla monitor schedule 200 life forever start-time now
> > > ip sla monitor 201
> > >  type echo protocol ipIcmpEcho 64.200.58.69 source-ipaddr 192.168.0.3
> > >  timeout 4000
> > >  frequency 10
> > > ip sla monitor schedule 201 life forever start-time now
> > > 
> > > track 200 rtr 200 reachability
> > >  delay down 10 up 20
> > > !         
> > > track 201 rtr 201 reachability
> > >  delay down 10 up 20
> > > 
> > > 
> > > ip local policy route-map LocalPolicy
> > > 
> > > ip access-list extended Ping-HUGHES-VJOFN
> > >  permit icmp host 192.168.0.3 host 204.107.90.128
> > > ip access-list extended Ping-HUGHES-WCGRTR
> > >  permit icmp host 192.168.0.3 host 64.200.58.69
> > > ip access-list extended Ping-SEABREEZE-VJOFN
> > >  permit icmp host 192.168.75.49 host 204.107.90.128
> > > ip access-list extended Ping-SEABREEZE-WCGRTR
> > >  permit icmp host 192.168.75.49 host 64.200.58.69
> > > 
> > > route-map LocalPolicy permit 10
> > >  match ip address Ping-SEABREEZE-VJOFN
> > >  set ip next-hop 192.168.75.1
> > > !         
> > > route-map LocalPolicy permit 11
> > >  match ip address Ping-SEABREEZE-WCGRTR
> > >  set ip next-hop 192.168.75.1
> > > !         
> > > route-map LocalPolicy permit 20
> > >  match ip address Ping-HUGHES-VJOFN
> > >  set ip next-hop 192.168.0.1
> > > !         
> > > route-map LocalPolicy permit 21
> > >  match ip address Ping-HUGHES-WCGRTR
> > >  set ip next-hop 192.168.0.1
> > > 
> > > 
> > > The problem I have is :
> > > 
> > > C3640-1# sho track
> > > Track 200
> > >   Response Time Reporter 200 reachability
> > >   Reachability is Up
> > >     28 changes, last change 10:47:07
> > >   Delay up 20 secs, down 10 secs
> > >   Latest operation return code: OK
> > >   Latest RTT (millisecs) 691
> > >   Tracked by:
> > >     STATIC-IP-ROUTING 0
> > > Track 201 
> > >   Response Time Reporter 201 reachability
> > >   Reachability is Down
> > >     2 changes, last change 12:53:33
> > >   Delay up 20 secs, down 10 secs
> > >   Latest operation return code: Timeout
> > > 
> > > Which I don't get, since :
> > > 
> > > C3640-1#ping 64.200.58.69 source 192.168.0.3       
> > > 
> > > Type escape sequence to abort.
> > > Sending 5, 100-byte ICMP Echos to 64.200.58.69, timeout is 2 seconds:
> > > Packet sent with a source address of 192.168.0.3 
> > > !!!!!
> > > Success rate is 100 percent (5/5), round-trip min/avg/max = 768/806/856 ms
> > > 
> > > 
> > > 	Any way to figure out whats happening (or not happening)?
> > > 
> > > 			Thanks, Tuc
> > > _______________________________________________
> > > cisco-nsp mailing list  cisco-nsp at puck.nether.net
> > > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > > archive at http://puck.nether.net/pipermail/cisco-nsp/
> > 