The slighly better solution:
Like many of us, I strugled to keep few Quintum gateways properly registered with a gatekeeper. Those gateways are on ADSL lines overseas, with the tipycal changes on I.P. every few hours and the troubles related to it>
A400 or A800. They did have troubles getting a new registration from another gateway that was still registered with the old I.P. addres.
That did lead to double registrations or just to ignore the new registration when the number of registrations went over the gatekeeper limit.
Solution: Do not register the remote/changing gateways to the gatekeeper. Instead, point the remote gateways to the border element of the one that is on a static I.P. address.
Advantages: 1)There is no limit on the ammount of gateways that you send information to a border element.
2)Seems to work a lot better, specially whent the remote gateways are on PPOE.(Do not ask why, I do not know, I just noticed it).
I have three gateways working that way right now, and I am impresed. Not a single one of them failed to report to the border element after a change of I.P. address in over a week!!!!!
I never saw any of my quintums on remote sites go this long without a need for a reset or power down.
in order to see the I.P. of the remotes, go to the prompt and type :
gk table.
Go to the remote gateways and put the I.P. of the “master” or gateway on static I.P. address under “border element 0”
Do not enter anything on the gatekeeper field of the remotes.
Warning: By these settings, the remotes will “learn” the static I.P. routes of the master, and try to contact them directly. If you have static routes defined on the gateway that you are using as a border element, the remotes will “learn” the routes.
On the remotes, use gk route plus the number to see what the remotes knows.
Good hunting!!!!!