cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
826
Views
0
Helpful
4
Replies
Highlighted
Beginner

GLBP IP SLA icmp readability

HI,

in my topology I have configured 2 routers with the following:

 

#R1
!
ip sla 1
 icmp-echo 192.168.137.1 source-ip 10.0.0.2
 threshold 700
 timeout 1000 (msec)
 frequency 2
 exit
!
track 1 ip sla 1 reachability
 exit
!
ip sla schedule 1 start-time now life forever
!
interface FastEthernet0/0
 ip address 192.168.1.11 255.255.255.0
 duplex full
 glbp 1 ip 192.168.1.1
 glbp 1 priority 110
 glbp 1 preempt
 glbp 1 weighting 5
 glbp 1 load-balancing weighted
 glbp 1 authentication md5 key-string cisco123
 glbp 1 weighting track 1 decrement 5


========================

#R2
!
ip sla 1
 icmp-echo 192.168.137.1 source-ip 20.0.0.2
 threshold 700
 timeout 1000 (msec)
 frequency 2
 exit
!
track 1 ip sla 1 reachability
 exit
!
ip sla schedule 1 start-time now life forever
!
interface FastEthernet0/0
 ip address 192.168.1.12 255.255.255.0
 duplex full
 glbp 1 ip 192.168.1.1
 glbp 1 timers msec 300 1
 glbp 1 priority 100
 glbp 1 preempt
 glbp 1 weighting 5
 glbp 1 load-balancing weighted
 glbp 1 authentication md5 key-string cisco123
 glbp 1 weighting track 1 decrement 5

============

 

it work perfectly fine ... BUT when I bring the WAN connection down like 10.0.0.1 it takes almost 50 seconds for the connections to come back on a LAN host

The ip sla and rtr doesnt act as quickly as I intended.

the glbp switch at no time though

how can tweak the ip sla times to make it act faster?

thank you very much  

 

 

 

Everyone's tags (2)
1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
Enthusiast

Hi Hassan,I replied to your

Hi Hassan,

I replied to your email but I figured I'd send you my recommendations here as well to make sure you receive it:

I don't think the SLA is the problem, it sounds like your host machines are not getting the updated AVF mac address for the VIP quickly enough when R1 is in a failed state.

In a test environment, try setting the glbp redirect timer to see if that improves the issue:

glbp 1 timers redirect 1 603

In theory, this command will tell the AVG to stop redirecting hosts to the old mac address of the VIP(i.e. the failed router) in 1 second (minimum is 0), and will completely remove the failed router from the GLBP group in 603 seconds (minimum) from the time the failure is detected.

Again, I strongly suggest testing in a lab environment before implementing on prod.

View solution in original post

4 REPLIES 4
Highlighted
Hall of Fame Expert

Hi,What if you don't use IP

Hi,

What if you don't use IP Sla at all, just use GLBP and test again.

HTH

Highlighted
Beginner

Glbp by itself... switch at

Glbp by itself... switch at no time..

Highlighted
Enthusiast

Hi Hassan,I replied to your

Hi Hassan,

I replied to your email but I figured I'd send you my recommendations here as well to make sure you receive it:

I don't think the SLA is the problem, it sounds like your host machines are not getting the updated AVF mac address for the VIP quickly enough when R1 is in a failed state.

In a test environment, try setting the glbp redirect timer to see if that improves the issue:

glbp 1 timers redirect 1 603

In theory, this command will tell the AVG to stop redirecting hosts to the old mac address of the VIP(i.e. the failed router) in 1 second (minimum is 0), and will completely remove the failed router from the GLBP group in 603 seconds (minimum) from the time the failure is detected.

Again, I strongly suggest testing in a lab environment before implementing on prod.

View solution in original post

Highlighted
Beginner

Thank you Dean very much,the

Thank you Dean very much,

the link you sent me was a great help ... now I understand FHRP convergence time and how to reduce it.

https://rekrowten.wordpress.com/2012/08/06/convergence-of-hsrp-vrrp-and-glbp-with-object-tracking-part-4/

thank you again

Hassan

 

Content for Community-Ad