LSP 2

[btrain08]

Does anyone happen to have some sort of listings of how LSP's behave when the link is intact and when it is fractured?

ex. on an outbound pstn call from the remote site and the link is broke.. does that call stay preserved??

Is there a phone interuption when the system registers back to the main site?

If the CLAN board on the main site that the remote site links to goes down.. does the remote site just find another available CLAN to talk to or does the system get fractured?

Anything would help.

 

[Mitch672]

you are confused.

You mean to ask about the "gateway", not the LSP. as the gateway is what provides service to the remote site. The LSP just takes over in the event of a WAN failure...

Yes, you can have up to 4 gatekeepers listed in the media gateway, it can look for alternative service, then fail over to the local LSP.



Mitch

AVAYA Certified Expert

 

[inerguard]

It would help if you list the equipment you have, so let's say you have an 8300 LSP in a G350 Gateway. If the wan link goes down and stays down for 3 seconds (or three heart beats) then the pstn call will stay up. Between 3 and 60 seconds and the call will be lost. The Gateway will try and register with another processor, i.e. the 8300 and will remain with this processor until the rule that states when it is to re-register back is met. (ch syst mg 1 ). Look at this rule to see the conditions that are set on when the gateway will look to see if the main server is available again.

There will be an interuption when the gateway tries to register back to the main server again.


[Started on Version 3 software 15 years a go]

 

[btrain08]

There's a mix of s8300/G700's and G350's at the remote site and the hub is s8730's/G650's. They are currently all standalone, but we are converting them and have to document the user experience in all scenarios. I was under the impression a PSTN call (which is local to the remote site) would stay up regardless of the link breaking.

 

[inerguard]

Here's the answer to your questions, sorry but the nice diagrams didn't post.

IPSI Sockets and Heartbeats

The CM Server communicates with a Port Network via a TCP socket connection to the IPSI as shown in Figure 1. This connection is critical to all communications that go through the port network (G650). All control signals for all endpoints and adjuncts that connect through the Port Network are multiplexed and sent via this TCP socket connection.







Figure 1: Server – Port Network Connection





The server exchanges heartbeats with the IPSIs every second. IPSI sanity failure occurs when a heartbeat is missed and if no other data has been received from the IPSI during the last second. During a Control Network outage, the server and the IPSIs buffer all downstream and upstream messages in queues. If the socket communication is restored before the IPSI Socket Sanity Timeout is reached, the socket communication resumes and all queued messages are sent. This recovery is represented by



Region A in Figure 2.



If the IPSI sanity failures last longer than the IPSI Socket Sanity Timeout setting but shorter than 60 seconds, then recovery actions are initiated, including closing and reopening the socket connection (all downstream and upstream messages buffered in queues are lost), resetting the PKTINT (Packet Interface on the IPSI cards) and performing a warm restart of the affected port network. This recovery is represented by Region B in Figure 2.



If the IPSI sanity failures last longer than 60 seconds, the affected port network goes through a cold restart. This recovery is represented by Region C in Figure 2.







If an alternate control path to the affected port network is available and viable, interchange to the alternate control path is made after 3 seconds of IPSI sanity failures. Alternate control path is either:



• Secondary IPSI in the same port network, or



• Fiber connection via ATM switch or Centre Stage Switch If both primary and secondary IPSI connections have concurrent network outages (most likely due to non-diverse-path routing), the secondary IPSI connection is not viable and thus not available for interchange.



Recovery Behaviour in Region A



If the Control Network outage is shorter than the IPSI Socket Sanity Timeout (Region A in Figure 2), the upstream and downstream data that were blocked and buffered due to the network outage will resume flowing after the TCP recovery. All connections that go through the port network are preserved. All messages are buffered and sent with a delay due to the network outage and recovery. See Table 1 for more details on recovery behaviour in Region A. Refer to Figure 3 when reading Table 1. Note that there are two port networks in this example. The network outage happens in the WAN. The port network at the remote site is affected by the network outage, but the port network at the main site is not affected by the network outage.



Recovery Behaviour in Region B



If the Control Network outage is longer than the IPSI Socket Sanity Timeout period, but is shorter than 60 seconds (Region B in Figure 2), then, the port network goes through a warm restart and the Packet Interface (PKTINT) is reset. This results in lost upstream and downstream messages and results in LAPD links being reset and C-LAN socket connections being closed and reopened. Most stable calls will stay connected. Calls in transition may be lost. See Table 2 for more details on recovery behaviour in Region B.



Recovery Behaviour in Region C

If the Control Network outage is longer than 60 seconds, the recovery of the affected port network requires a cold restart of the port network1. This drops all calls going through the affected port network. Only the shuffled IP-to-IP calls that are not using any port network resources will stay connected until the user drops the call. See Table 3 for more details on recovery behaviour in Region C.




[Started on Version 3 software 15 years a go]

 

[Mitch672]

btrain08, any local calls will stay up, until the gateway re-registers, once that happens, a "new" controller will see the call in progress and leave it alone. However, they would not be able to "conference", or "transfer" or do anything with that call.. they would have to hangup, get new dial tone, then they would have those features back.


Mitch

AVAYA Certified Expert

 

[btrain08]

Thanks. Would you happen to know what impact the remote site would see in the event that the CLAN board that its registered to at the main site failed?

 

[gblucas]

As long as you have more than one CLan in the pool, and in the search list, it will find another card to register to and there should no interruption in service.

gblucas

 

[surferdude949]

inerguard, anyway I can get a copy of the nice diagrams? THank you.

 

[btrain08]

I'm dreading having to sniff through the Avaya docs so can anyone as briefly as possible list out the commands/screens where LSP programming is done on the main site in the event I have to troubleshoot etc...

I know about 'locations', sys para mg-recover for the most part. I know how to status media gateways. I'm wondering where else programming is added.. ie..IGAR, DSP etc..

Also, to convert a current standalone remote site (s8300/G700) over to a surviveable site off the main site I know the s8300 blade has to be swapped and licenses converted. For a site with about 5 - 10 users is a seamless conversion about 2 hrs give or take??

 

[dmagel]

inerguard, do you know what TCP port the IPSI's communicate with the S8X00 server? Thanks reid