Hi Mark,
1. What is the difference between line-protocol and ip routing in tracking down interface in GLBP?
The line-protocol verifies solely whether the interface is in the up/up state. Any other state (admin down/down, down/down, up/down) is considered non-operational.
The ip routing protocol verifies whether the interface is actually able to route IP packets, that is, the IP routing is enabled and active on the interface, the interface is up/up and has an IP address assigned. This may be important in situations where the IP address is negotiated (DHCP, PPP IPCP etc.).
Please read more about this command and the exact differences here:
http://www.cisco.com/en/US/docs/ios/ipapp/command/reference/iap_t1.html#wp1163288
2. By default, I can see that the hello and hold time of GLBP is hello=3s and holdtime=10s.
Does adjusting it to a faster speed like hello 1s hold 4s or even in
miliseconds have any benefit? Or the default values is good enough and
also to prevent higher cpu processing?
A faster hello allows for new GLBP members to be detected more quickly, and a shorter holdtime allows for faster switchover. Whether shortening these intervals has any benefit depends strongly on your requirements. If you do not have real-time services like IP Telephony, IPTV or similar applications, there is probably no point in setting these timers to overly aggressive values. Then again, I believe that a hello of 1 second and hold time of 3 seconds will not significantly increase your router's CPU - there are much more complex tasks than emitting and receiving a single GLBP Hello. As always, your mileage may vary, and you are advised to test the behavior for yourself to see the results.
3. If I have two routers and I want to achieve a 2:1 ratio of host to register, then I will used load balancing:weighted and have R1=80 weights and R2=160 weights
. Does this achieved what I want to happend? How can I check that GLBP
is really having 33% of host going to R1 and 66% of host going to R2?
Your configuration is correct. However, it is difficult to verify this ratio of traffic distribution. These weights primarily decide how often will the Active Virtual Gateway (AVG) respond to ARP requests for the vIP with the vMAC of the R1 and R2 as AVFs, respectively. Setting the weights to 80 and 160 will cause the AVG to statistically resolve one ARP to the vMAC of R1, and two ARPs to the vMAC of R2. However, the amount of traffic flowing through that router does not depend on the GLBP anymore - it depends only on the end station communicating through that router. Only over an extended period of time, the statistics should smooth out and converge on a 1:2 ratio.
You can of course conduct a controlled experiment by repeatedly sending the ARP for the vIP (use the arping utility on Linux) and observing the ratio of vMAC1 and vMAC2 appearing in the replies. They should follow the 1:2 ratio closely.
Please feel welcome to ask further!
Best regards,
Peter
