In order to create redundancy on the network I am planning to use GLBP but I do have a question.
I have a remote location (A) which contains my CallManager and Unity Servers. Location A is connected to location B (another office) using two frame-relay circuits ending in two different routers. GLBP will be configured on those two routers so in case one link fails the other will take over.
In location B (which is where GLBP will be implemented) are located the IP Phones that communicate with CCM in location A.
My question is: Has somebody ever implemented GLBP in a similar environment? I am trying to find out if the IP phones will experience any issues such as trouble communicating with the CCM, etc.
The IP Phones will loose the Registration with the CCM ONLY if the Keep Alives are NOT recieved in time from the respective CCM Servers.
Now, if you are implementing the GLBP for this matter, please ensure that the overall delay is less than that of the Keep Alives.
However, let me share and implementation of one of our clients, where-in we had 2 Routers and 2 Links to the remote site where all the IP Phones were there, and all the IP Phones were registered to the CCMs across the Links.
However we have had only implemented the OSPF, and using the OSPF we seldom experienced the Re-Registration of the IP Phones, ofcourse we did experience a silence period of about 5 - 10 seconds whenever the link failed on which a call was active.
I hope this should help.
Please get back to us, in case you require further information on the aspect.
1. GLBP is for 2 purposes a) Redundancy b) Load Balancing / Load Sharing
If you are deploying GLBP, I guess you would willingly or unwillingly induce delay for any failover situation.
1. Its nothing but the time when the AVG / AVF failure would compell the potential AVF / AVG to take the role.
>Did you experience any issues with the
phones while having the two links working?
Well, never faced any issued regarding having 2 links to the CCM from the IP Phones.
>Was the voice quality OK?
Yes, it wass quite good, the only problem we ever faced was, in case of a link failure on an active communication, the call would go Silent for about 5 - 8 seconds, and then it would resume the Call, which is quite affordable compared to a complete call drop.
Could you explain a bit more about the Re-registration issue? Were you able to solve it?
We have had faced enough re-registration issues due to Link Flaps, the flap would be of about 10 seconds (most of the times) and the moment a link used to flap, the call used to get dropped (if there is any active call on that link) or else the phone would re-register.
Secondly, once we migrated to OSPF, only a very few times the IP Phone would re-register in case of a link flap.
Final conclusion would be something like this:-
1. If you are concerned just about Call Drops / IP Phone Re-registrations during a Link Flap or Link Failure, just deploy OSPF / EIGRP and rest be assurred about everything else.
2. We had deployed 2 Core / Dist Switches on the Remote Site, and 2 Core/Dist Switches on the CCM Site.
Similarly 2 Routers with 1 Link on each on both sides, and then deployed the OSPF for Routing all in one Area.
Your case is may be bit more complex, but for our case, it really worked well.
I really appreciate your time answering my questions.
I feel better now since you did not experience any issues while the links were working. I do expect the phones to loose the call when there is a link failure something I think is acceptable. As of this moment, when I loose a link the call drops and the phone becomes unusable until the service is restored.
Having GLBP the phone will be able to Re-register with the CCM automatically and continue working for the user which is our main priority.
Yes, my case is a bit different since I have two router in location B and only one in location A so I am using GRE tunnel to connect them. I use EIGRP but I also want to load balance the traffic.
We have GLBP in our enviorment and we did have one issue that you should be aware of. Within the GLBP config guide it recommends changing the ARP and CAM timeout values. DO NOT change these values, this will cause huge issues with phones reregistering every few hours.
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...