IP Phones not registering with LSP

[TykeUK]

We have just set up the 7th G700 with LSP on our network. For some reason i can't get the phones to register with the LSP when we drop the network. They sit there showing Discover and only seem to look for our 4 main clan's.
I have checked DHCP, IP Network-regions etc and everything is set as per the other offices?
Any ideas on anything else I can check?

 

[charmstrong]

It sounds like the DHCP Scope, it needs to be configured to register to the LSP unlike the other sites.

In the option 176 string wihin the DHCP Scope, mcipadd= needs to be set to the correct ip addresses of the main c-lan's and the last entry to that of the LSP.

Pretty sure that is where your problem lies.

You can allways download a utility called ipboottest from the Provision website which emulates an ip phone on your laptop and is very usefull for diagnosing these sorts of issus.

 

[TykeUK]

As far as I can see the 176 string is setup as per your post... here it is..
MCIPADD=172.16.8.1,172.16.8.2,172.16.56.4,MCPORT=1719,TFTPSRVR=172.16.58.37,L2QAUD=5,L2QSIG=3,DCSPAUD=46,DSCPSIG=26,VLANID=2,VLANTEST=0

172.16.8.1 &.2 are our primary c-lans, 56.4 is the LSP.

 

[charmstrong]

OK, that's good.

Then, I think what might be happing is that your breaking the WAN, the phones are not registering to the main C-Lan's and then attempting to register to the LSP but the request is being rejected as the LSP is not in survivable mode.

The best way to test this, set up an ip phone with a static ip address and then, in CM from the LSP, do a "list trace ras".

Are you sure that the gateways and the 8300 (it is an 8300 right?) are in survivable mode. If the trace above says that the registration request is being refused then the LSP is not in survivable mode yet. Have a look at the mgc list and mgp recovery timers in the Gateways and make sure these are configured correctly - it does take (a user definable amount of) time for the gateways to go into survivable mode.

 

[TykeUK]

What seems to be happening is the phones don't attempt to register with the 8300. When they are discovering they only attempt to connect to the clans.
I can get a phone to register when in LSP by giving it a full static list of addresses using the 8300 ip address as the call server. But using DHCP this doesn't work, even after waiting half an hour.
The MGP recovery times and list are definately set correctly.

I'll check the ras trace test out of hours tonight and see what happens.
Thanks

 

[TykeUK]

I've run the bootest software, the mainthings I noticed were...
Warning: Received DHCP-Offer from 172.16.58.36, but DHCP opti
ons appear misconfigured. Check that 'lease period' is infinite and the 'MCIPADD
' parameter exists
and
DHCP test result: your DHCP server and network appear to be c
orrectly configured.

 

[charmstrong]

Tyke,

Don't worry about that, it's something of nothing. Have you ran the trace as that will give you more info. that you need?

 

[charmstrong]

Just re-read your post - the fact that it's complaining about no mcipadd is a problem.

I've seen it before when it's been cutand pasted with an extra ' at the strat of the mcipadd. It seems like this s the likely source of the problem.

I suggest trying to double, double-check the option 176 string and maybe post it on here.

Also maybe worth postting the results of the ipboottest log itself (you can export to a text file and then cut and paste).

Cheers

 

[TykeUK]

The 176 string is already posted above, the results of the boottest are below. I have noticed that the IP Address that was leased during this test was a data IP address not a voice one???

C:\Program Files\Avaya\IP Boot Test>C:

C:\Program Files\Avaya\IP Boot Test>cd "C:\Program Files\Avaya\IP Boot Test"

C:\Program Files\Avaya\IP Boot Test>ipboottest.exe -i
Run DHCP Testing (y/n)? [y] y
Enter the number of phones to be simulated. [Default = 1] 1
Run TFTP Testing (y/n)? [y] n
Output filename? [Press enter for output to screen.]
Output additional run-time test information (y/n)? [n] y

Avaya IP Boot Test (Version 1.3.2) copyright 2002 Avaya Inc.
Please send feedback or report problems to ipboottest@avaya.com.
INFO [17:48:49.66] Testing DHCP by simulating 1 endpoints
INFO [17:48:49.67] Simulating endpoint number: 1
INFO [17:48:49.67] Sent DISCOVER Packet
INFO [17:48:49.69] No OFFER was received.
INFO [17:48:49.69] No OFFER was received.
INFO [17:48:53.85] Received OFFER Packet
INFO [17:48:53.89] DHCP server was found with IP address: 172.16.58.36 - (**Removed for security**)
INFO [17:48:53.89] Examining Offer from: 172.16.58.36
INFO [17:48:53.89] Check for option 51
INFO [17:48:53.89] Option 51: Offered a 3600 second lease
INFO [17:48:53.89] Warning: Received DHCP-Offer from 172.16.58.36, but DHCP opti
ons appear misconfigured. Check that 'lease period' is infinite and the 'MCIPADD
' parameter exists
INFO [17:48:53.91] Sent REQUEST Packet
INFO [17:48:53.91] Received ACK Packet
INFO [17:48:53.91] Checking availability of: 172.16.58.134
INFO [17:48:54.49] Valid Offer for endpoint 1 : allocated 172.16.58.134 successf
ully
INFO [17:48:54.49] Attempt number 0 to send RELEASE Packet for: 172.16.58.134
INFO [17:48:54.69] Attempt number 1 to send RELEASE Packet for: 172.16.58.134
INFO [17:48:54.89] Attempt number 2 to send RELEASE Packet for: 172.16.58.134
PASS [17:49:01.86] DHCP test result: your DHCP server and network appear to be c
orrectly configured.
INFO [17:49:01.86] TFTPSERVER set to:
INFO [17:49:01.86] TFTPPATH set to:

-------
TEST SUMMARY:
1 address(es) were requested and successfully obtained.

Press return to exit...

 

[charmstrong]

Hi Tyke,

Now it's sarting to make sense (I think) - you are using pc's off the back of the phones or having a dual voice/data lan.

The option 176 string above, is that for the data or voice vlan?

The data vlan dhcp option 176 should have a l2qvlan=[voice vlan] value in the option 176 string after the tftp server.

The voice vlan should be identical to the data but without the l2qvlan.

I would double check these values.

 

[TykeUK]

Hi there, we have separate scopes for voice and data and a network card for each. Our data scope doesn't have a 176 string at any of our locations.
Maybe our Network manager has set things up slightly different to normal but we have had 6 other sites working correctly for over 2yrs now.
Does the data vlan definitely need a 176 string in your opinion?
I can get phones registered normally using DHCP but not when the WAN link is down.

 

[charmstrong]

Hi, obviously it's difficult for me to say without being there on site to get a proper handle on it.

Do you have seperate voice and data vlan's (I guess you do)?

The standard, Avaya recommended way is to have the default vlan the data vlan, the phone then boots and and get's it's option 176 data from this data scope, finds the l2qvlan value and then reboots tagging in the voice vlan and then get's it's data from the voice option 176.

Maybe it's worth running through your setup because i'm trying to guess how you've got it configured and I'm maybe guessing wrong.

 

[TykeUK]

currently we don't have option 176 on the data lan, we manually change the phones into vlan 2. It's always worked for us and isn't a great deal of work changing the vlanID manually.
Can you send me an example of the 176 string for the data lan? Might be worth trying?
Thanks

 

[charmstrong]

Tyke,

If you give mem your e-mail address i'll send you a copy of the "IP Telephony Implementation Guide" & the "4600 Series IP Telephone LAN Administrator's Guide" but you'll probably be better off getting them direct from support.avaya.com.

 

[TykeUK]

charmstrong,
I tested the LSP on several occassions last night and tried removing settings/re-adding them etc. Eventually I got some phones to register with the LSP. However it took much longer than usual (around 12-15mins) for 7 phones to come up. I'm not sure what enabled this to happen but as long as it's working!
I know the timings are also set correctly and would have expected them to register sooner but I can continue to work on this.
Thanks for your help.

 

[charmstrong]

Tyke,

Then it's definetly down to your mgp timers/ mgc list

Don't forget the values are in minutes, this confuses people.

e.g.

mgc list

clan1
clan2
------------
lsp

mgp primary search 3
mgp total search 10
transistion point (obvious) in this example it's 2

So, in this example, the gateways would search c-lan1 for 3 mins, then c-lan2 for 3 mins = 6 mins.

After 6 mins the gateways would then try to register to the lsp until after 10 mins the (if not registered) the mgp does a hard reset and repeats.

It get's misunderstood a lot that it takes so long to go into lsp mode.

99.9% certain it's your list that's causing the delays.

You can have the lsp in the primary search list (set the transition point to after the lsp's) and have a primary search of 1.

In this case, it would search for the primary c-lan for a minute, then the second a minute before registering to the lsp just after that = just over 2 mins.

I know these values sound like a long time but it's to avoid bouncing links sending sites into lsp mode all the time.

Hope this helps.

 

[TykeUK]

Thanks,

We have our mgc list the same as you, search times..
mgp primary search 2
mgp total search 6
transistion point (obvious) in this example it's 2

Will have a play around with the timings but we have used these on all sites and have been happy with the results.