cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1778
Views
0
Helpful
4
Replies

GLBP IP SLA icmp readability

Hassan Chalabi
Level 1
Level 1

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  

 

 

 

1 Accepted Solution

Accepted Solutions

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

Reza Sharifi
Hall of Fame
Hall of Fame

Hi,

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

HTH

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

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.

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

 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: