Hello,

I have change the configs as per the PBR document attatched  but the failover is too late 1 min 15 sec, Before with Reliable Static Routing Backup it was only 8 sec,

Any additional command that can help much faster failover ??????????. Actually the command  delay {up seconds [down seconds] | [up seconds] down seconds} in PBR document i have not understood this command can it help for faster failover ?? IF SO ,,, then what i shld put ???

I m doing this as a LAB on dynamips secnario before applying to live network.

Awaiting ur replies experts,

Attached are the configs

Thanks

Thomas,

Once the physical ckt comes up and stays up for 10 seconds the tracking state will go active along with anything your tracking - routes in your case. The same if the interface goes done. Try setting the delays to 0.

track 100 rtr 10

delay down 15 up 10

Question.

Why not use a default route such as ip route 0.0.0.0 0.0.0.0 "next hop" 250 or use route-map to verify availability (if the other device has CDP enabled). It may be easier to troubleshoot depending on what your actually doing.

Route-map test permit 10

Match ip address 10

Set ip next-hop "ip"

set ip next-hop verify-availability

!

Route-map test permit 20

Hello Experts,

It's the same no effect after applying delays,I applied delay 0 as well as delay down 15 up 10 but no change I have applied a static route with track command and also the route-map with set ip nex-hop verify reacheability,just have a look on the attached configs of the last mail.

I did'nt understood ? ur below words.

Once the physical ckt comes up and stays up for 10 seconds the tracking  state will go active along with anything your tracking - routes in your  case. The same if the interface goes done. Try setting the delays to 0.

Can u explain me why u r advicing to use PBR instead Reliable Static Routing Backup Using Object Tracking ????,

I have attached the configs in my first mail for Reliable Static Routing Backup Using Object Tracking,just review and reply back.

Thanks for ur prompt reply.

R3(config-track)#do sh run
Building configuration...

Current configuration : 1256 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R3
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
!
!
ip cef
!
!
ip sla monitor 1
type echo protocol ipIcmpEcho 192.168.10.1
ip sla monitor schedule 1 life forever start-time now
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
track 123 rtr 1 reachability
delay down 15 up 10
!
!
!
interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
interface FastEthernet0/0
ip address 192.168.10.2 255.255.255.0
ip policy route-map local
duplex auto
speed auto
!
interface FastEthernet2/0
ip address 192.168.30.2 255.255.255.0
duplex auto
speed auto
!
router ospf 1
router-id 3.3.3.3
log-adjacency-changes
redistribute static metric 1 subnets
network 3.3.3.3 0.0.0.0 area 0
network 192.168.30.2 0.0.0.0 area 0
!
ip http server
ip forward-protocol nd
ip route 100.100.100.100 255.255.255.255 192.168.10.1 track 123
!
!
!
access-list 101 permit icmp any host 192.168.10.1 echo
!
route-map local permit 10
match ip address 101
set ip next-hop verify-availability 192.168.10.1 10 track 123
!
route-map local permit 20
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
line con 0
line aux 0
line vty 0 4
login
!
!
end

Hello Experts

I want to apply the configs in real senario in MPLS network, In a Carrier supporting carrier senario

R2 is the customer,(with redundant connection to PE's)

R3 & R5 are the distribution /PE's (the link between the DIST and CORE is MPLS enabled)

R4 is the Core (which is connecting to ISP).

ANSWER:

I will recieve trafic from the ISP for the 100.100.100.100 which is on R2,so i have put the static routes on R3 and R5,

I m running OSPF internal network not with the customer. Only static with the customer.

Question:

Once your ip sla monitor is able to ping and recieve reply's from 192.168.10.1, track 123 will wait for 10 seconds before it brings up the static route to 100.100.100.100, which is being tracked.

How come it is coming up in 7 - 8 sec in Reliable static routing with backup object tracking?????????????????????.

i m fine with Reliable static routing with backup object tracking but can u tell me why u r suggesting me PBR.

Thanks

Hello Dear's,

Can anybody help me for the above query, I'm also facing the same issue.

Thanks

Thomas sorry for the delayed reply.

The 7-8 seconds is pretty close but to get an accurate time you need to tear down the link that's being track in this case that would be the f0/0 interface on R3. Once the link is down issue the "show track" command with in 15 seconds and you should see the delay down notification go into effect. You'll noticed the seconds starting to drop. Do the same thing when you bring the link up. Essentially you can log the output to the moniter via term mon.

I thought maybe changing the delay timers would decrease the swithover but apparently it didn't. The threshold and frequency on the sla is low also.

I suggested th PBR because I didn't really know your scenario and what device you are responsible for. However I see what you are doing

and it looks nice,  except for the 7-8 second delay on failover.  It seems like it would be hard not to get any delay in this setup, even more so because your not performing dynamic routing between the customer and the PE's.

Hello Dear's,

SO THE CONCLUSION IS Reliable Static Routing Backup Using Object Tracking IS THE PERFECT SOLUTION FOR THE CURRENT SCENARIO.

THANKS

Hey,

Being that your not running a routing protocol between the PE and the Customer,  you have no way of proving the availability of 100.100.100.100 from R4 w/ out the use of static routes -which are being injected into OSPF.  I believe this is a good efective solution and there's no perfect network anywhere you go! 

However if there's a better way of doing it I would love to know.

That's True Dear,

No where in the world u will get fully failover within a seconds,

Thanks for ur replies,hope to see u soon in the next thread,Keep it up,be with ur helping nature it will lead to success,

Cheers,

Thanks for the rating Sandy and see ya next time, Packet Head!

Hello, 

which route do you still see ? Post the full running configuration of your router.

For the IP SLA to work, you need a static host route pointing to the interface (or the next hop address of the interface) that is being tracked:

ip route x.170.119.181 255.255.255.255 ip_address-of_next-hop or outgoing_interface