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