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 [email protected] > > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
