I have 2 different companies as follows:
Company 1 - OXE system on 2 x Appliance servers in Melbourne with 4 sites - 3 remote shelves. R9.1 i1.605.21-as
Problem on shelf 4 - GD3 takes about 50 minutes to come into service. Normally says failed binmg3linux binary but if nothing is done it comes up after about 50 minutes. The GD3s on other shelves are fine.
Company 2 - BiCs solution in Sydney with 3 remote shelves aswell R9.1 i1.605.25.b
Problem on shelf 4 - GD3 takes about 50 minutes to come into service similar to above company. GD3 has been replaced but same issue happening. The GD3s on other shelves are fine.
NOTE: Both companies are a few blocks away on the same street even though totally different businesses on the same street in brisbane QLD.
When connecting back to PCS it takes the same amount of time for GD to come into service hence beats the purpose of PCS rescue during business hours.
They are both working fine just worried if there is a break in the WAN link then system takes 50 minutes for GD to restart and come in service.
I have attached the incidents from "Company 2" incidents of this GD3 as below.
12/12/11 16:37:02 000001M|004/00/-/---|=4:0740=Beginning of an INT/IP downloadin
g @:00.80.9f.9c.c4.e4 (binmg3)
12/12/11 16:37:02 000001M|004/00/-/---|=5:0741=End of downloading of an INT/IP b
oard @:00.80.9f.9c.c4.e4 (binmg3)
12/12/11 16:37:30 000001M|004/00/-/---|=4:0740=Beginning of an INT/IP downloadin
g @:00.80.9f.9c.c4.e4 (binmg3)
12/12/11 16:37:30 000001M|004/00/-/---|=5:0741=End of downloading of an INT/IP b
oard @:00.80.9f.9c.c4.e4 (binmg3)
12/12/11 16:37:34 000001M|004/00/-/---|=4:0740=Beginning of an INT/IP downloadin
g @:00.80.9f.9c.c4.e4 (binmg3linux)
12/12/11 16:39:19 000001M|004/00/-/---|=5:0741=End of downloading of an INT/IP b
oard @:00.80.9f.9c.c4.e4 (binmg3linux)
12/12/11 16:39:19 000001M|004/00/-/---|=4:0740=Beginning of an INT/IP downloadin
g @:00.80.9f.9c.c4.e4 (binmg3rdimg)
After 6 minutes
12/12/11 16:45:03 000001M|004/00/-/---|=2:0742=The INT/IP board downloading has
failed @:00.80.9f.9c.c4.e4 (binmg3rdimg)
But if nothing is done, the GD3 comes up after approx 50min.
12/12/11 17:37:35 000001M|004/00/-/---|=5:0409=The inter-ACT link over IP from (
19 1) is up
12/12/11 17:37:36 000001M|004/00/-/---|=3:5873=telnet service opened
12/12/11 17:37:36 000001M|004/00/-/---|=3:5873=telnet service opened
12/12/11 17:37:36 000001M|004/00/-/---|=0:5857=GD/GA/INTIP/RGD: reason of reboot
0
12/12/11 17:37:36 000001M|004/00/-/---|=3:5873=telnet service opened
12/12/11 17:37:38 000001M|004/27/-/---|=4:0260=Beginning of downloading /DHS3ext
/vgadpcm/flash/std/vgadpcm.AS0
12/12/11 17:38:05 000001M|004/00/-/---|=5:2019=GD/GD3 coupler commissioning
12/12/11 17:39:55 000001M|004/27/-/---|=5:0261=End of downloading /DHS3ext/vgadp
cm/flash/std/vgadpcm.AS0
12/12/11 17:39:56 000001M|---/--/-/---|=4:2500=Dow: file /DHS3ext/vgadpcm/flash/
std/adpcmmoh opening error
12/12/11 17:40:26 000001M|004/27/-/---|=4:2491=GPA(4,27) virtual coupler commiss
ioning of the associated coupler GD/GD3(4,0)
12/12/11 17:41:15 000001M|004/01/-/---|=5:2019=Z coupler commissioning
12/12/11 17:42:06 000001M|004/02/0/000|=4:2113=T2 lapD not established still try
ing
12/12/11 17:42:27 000001M|004/02/-/---|=4:2103=T2 access end of 75 time-out unus
ual
12/12/11 17:42:36 000001M|004/02/-/---|=5:2019=PRA coupler commissioning
12/12/11 17:43:16 000001M|004/02/0/000|=4:2080=T2 access is synchronizing on Boa
rd (4,2)
12/12/11 17:43:16 000001M|004/02/0/000|=5:2102=T2 access back to normal
12/12/11 17:43:16 000001M|004/02/0/000|=4:2113=T2 lapD not established still try
ing
12/12/11 17:43:16 000001M|004/02/0/000|=5:0311=T2 Dlap Established
Any assistance or tweaking of any tftp parramaters would be handy.
Thanks
GD-3 takes long time to come into service
GD-3 takes long time to come into service
SWINSTU
ACSE OXE R12.1
ACSE 8770 R3.2(4760 R5.x)
ACSE OT R2.3 IP/SIP and UC&C
ACSE OXE R12.1
ACSE 8770 R3.2(4760 R5.x)
ACSE OT R2.3 IP/SIP and UC&C
Re: GD-3 takes long time to come into service
Do you have console logs from the GD and/or tcpdump/Wireshark traces?
Is the MTU size smaller than usual?
Is the MTU size smaller than usual?
-
matt
Re: GD-3 takes long time to come into service
the MTU is set to 1024, is that considered too short for the payload of a GD3, is there a timer that can be adjusted to allow more time for the download from the CS
┌─Consult/Modify: INTIP B and GD Parameters─────────────────────────────┐
│ │
│ Node Number (reserved) : 1 │
│ Instance (reserved) : 1 │
│ Parameter + MTU │
│ │
│ MTU : 1024 │
│ │
└───────────────────────────────────────────────────────────────────────┘
┌─Consult/Modify: INTIP B and GD Parameters─────────────────────────────┐
│ │
│ Node Number (reserved) : 1 │
│ Instance (reserved) : 1 │
│ Parameter + MTU │
│ │
│ MTU : 1024 │
│ │
└───────────────────────────────────────────────────────────────────────┘
Re: GD-3 takes long time to come into service
Cheers Matt for the MTU parameter info.
Hi Elliot,
I havent got console logs from the GD. Will try for tcpdump or wireshark after VPN access to these sites soon.
Hi Elliot,
I havent got console logs from the GD. Will try for tcpdump or wireshark after VPN access to these sites soon.
SWINSTU
ACSE OXE R12.1
ACSE 8770 R3.2(4760 R5.x)
ACSE OT R2.3 IP/SIP and UC&C
ACSE OXE R12.1
ACSE 8770 R3.2(4760 R5.x)
ACSE OT R2.3 IP/SIP and UC&C

