cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4679
Views
0
Helpful
30
Replies

IP SLA problems

rasoftware
Level 1
Level 1

have this config

ip sla 1

icmp-echo 62.6.200.5

timeout 1000

threshold 2

frequency 3

ip sla schedule 1 life forever start-time now

track 100 rtr 1 reachability

ip route 0.0.0.0 0.0.0.0 "our-next-hop" track 100

ip route 0.0.0.0 0.0.0.0 Dialer0 254

ip nat inside source route-map ispA interface FastEthernet0 overload

ip nat inside source route-map ispB interface Dialer0 overload

access-list 40 remark IPs for NAT policy

access-list 40 permit 192.0.0.0 0.255.255.255

access-list 101 permit icmp any host 62.6.200.5 echo

route-map LOCAL_POLICY permit 10

match ip address 101

set interface FastEthernet0

!

route-map ispB permit 10

match ip address 40

match interface Dialer0

!

route-map ispA permit 10

match ip address 40

match interface FastEthernet0

!

The track doesn seem to work, when I have default route to metric 1 and no track it works.

I have this config working where I have two DSL ports but this has 1 DSL and 1 FE.

Will this work?

30 Replies 30

One more thing, dude...

When you did the 'debug ip policy' followed by the ping, were you telnet'ed into the router ? If so, could you repeat that but enter the 'term mon' command first ? That will ensure that the debug output is displayed on your terminal window.

Paresh

Debug as requested

217.32.63.202 - is the icmp "target" for reliable routing.

*Mar 8 22:56:21.879: IP: s=81.149.144.41 (local), d=217.32.63.202, len 64, poli

cy match

*Mar 8 22:56:21.879: IP: route map LOCAL_POLICY, item 10, permit

*Mar 8 22:56:21.879: IP: s=81.149.144.41 (local), d=217.32.63.202 (FastEthernet

0), len 64, policy routed

*Mar 8 22:56:21.879: IP: local to FastEthernet0 195.172.169.17no

*Mar 8 22:56:23.231: IP: s=81.149.144.41 (local), d=81.179.89.80, len 576, poli

cy rejected -- normal forwarding

I added the null0.

If i shutdown the fastethernet0 (primary) and bring it back up, the route doesn not come back?

Do I need to define the null0 interface?

I think its trying to ping the target which the sla monitor requires, but because the dialer router is remaining and the set next hop is not reachable becuase of the set, its dropping the icmp and the router is never coming back.

The next-hop address is our gateway to the isp, same subnet the fastethernet0 so I thinks that correct.

Dialer interface is separate ISP.

Seems strange cos it worked well when I had two dialers and just did "set interface dialer" and matched ip of icmp target.

I added the null0.

If i shutdown the fastethernet0 (primary) and bring it back up, the route doesn not come back?

Do I need to define the null0 interface?

I think its trying to ping the target which the sla monitor requires, but because the dialer router is remaining and the set next hop is not reachable becuase of the set, its dropping the icmp and the router is never coming back.

The next-hop address is our gateway to the isp, same subnet the fastethernet0 so I thinks that correct.

Dialer interface is separate ISP.

Seems strange cos it worked well when I had two dialers and just did "set interface dialer" and matched ip of icmp target.

Would you be able to re-attach your config ? I can't open the one you attached earlier... some issue with the NetPro server, I guess.

Paresh

Config as per now.

Includes correct addresses. The .17 is ISP gateway router.

Thanks...

Now, when you shutdown the Fastethernet interface and then bring it up, 'sh track' shows that it is getting a timeout, right ? When that happens, are you able to ping the tracked address using the CLI at all ?

Paresh

Yes when I shutdown the FE, track shows down -timeout.

Once in this state I can't ping the tracked address from the cli even when I bring the FE back up. I need to reload before it reports the FE backup and add the route back to the routing table.

Ok, now could you do the following (in order):

- shut down the fastethernet interface

- bring it back up after 60 seconds

- wait 10 seconds

- enable 'debug ip policy'

- ping the tracked address via the CLI

- post back your results

Paresh

Ok pretty long debug..

Note I am telnet into the "dialer" 81... address doing this. Is it strange that I can telnet to either 195 or 81 when track is working? When it declares the route down i can only telnet into the dialer 81..?

Alright... can you change your icmp-echo statement so that it reads like the following:

icmp-echo 217.32.63.202 source-interface FastEthernet0

Then, repeat your tests :-)

Paresh

You matey are a god! It seems to be behaving correctly now! I really do appreciate your help on this one!

I think i understand what thats doing. Can you explain why when using 2 x dialers it worked without needing that "source interface" and the set nexthop. I basically had this working as per my original config (1st post) which I copied from a setup with 2 dialers, rather than a dialer and FE port.

Dude,

Were the two dialers (in your previous case) connecting to the same ISP ?

Generally, ISPs will drop packets from customers with a source address that does not belong to the block assigned to the customer. That's why your current setup was failing.

Happy to see that you got it going.

Till next time, then :-)

Paresh

Yes same ISP thinking about it now.

Does that mean it wont work correctly?

When I pull cables out it does seem to failover and back- same as this one does now.

More CCNP studies I think for me - thanks for your help! Hope the post helps others as everyone seems to be trying to do this at the moment!

I also now have used other route-maps to redirect web and SMTP over the "backup" link which makes use of the available bandwidth when not in failover mode.

Useful if anyone else is trying this.

Review Cisco Networking for a $25 gift card