Can you set up remote access for me so I can look? I might see something quicker that way than going back and forth in email.
I'll send you my ip address offline so you can poke a hole. Rodney On Mon, Aug 13, 2007 at 10:59:14PM -0400, Tuc at T-B-O-H.NET wrote: > Hi, > > I'm getting the debug track sent to syslog constantly, > its alot of output per day (About 550 or so lines so far today). > The problem is with the ip sla mon event one. I tried to turn > that on by default and it was putting out just too much output > to keep on without filling up the syslog server disk. I've tried > to back-channel to the router to turn it on when I notice the > problem, but I can't get there in time most of the time. I > can email privately. > > The image is c3640-jk9s-mz.124-13a.bin . I can't > go to 16, even though the site says its able to fit on > the unit. Its just too big. > > Is there some "intermittent" debug I can do? > Should I just monitor the heck out of things for 1 hour > every day and hope it occurs then? What is needed and how > often is it needed? > > Thanks, Tuc > > > > > 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/
