[c-nsp] Wonky tracking?
Rodney Dunn
rodunn at cisco.com
Thu Aug 16 08:31:16 EDT 2007
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 cisco-nsp at puck.nether.net
> > > > > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > > > > archive at http://puck.nether.net/pipermail/cisco-nsp/
> > > >
> >
More information about the cisco-nsp
mailing list