[c-nsp] Wonky tracking?
Tuc at T-B-O-H.NET
ml at t-b-o-h.net
Mon Aug 13 22:59:14 EDT 2007
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