Is it possible to configure the IPSI card in a remote EPN on the corporate LAN and the local IPSIs in a control LAN configuration. I only have one ethernet connection in the remote site and I have Medpros and CLANs that need to be on the corporate lan. Any ideas anyone
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
remote EPN IPSI not on control lan
- Thread starter mrjedi
- Start date
MRJEDI
If I'm understanding your post correctly, you want to configure the IPSI without using the services port right? It is actually possible to do some configuration changes via the Control Interface (port 1). To do this, you need go to the bash prompt and type: ipsisession -p NNN.NNN.NNN.NNN. The 'N's are the IP address of the IPSI. Then you just establish a telnet session to the IPSI using the same IP address issued in the ipsisession command. (be careful...you might lock youself out if you try to change the IP subnet/gateway...you can certainly change QOS values, and if you are careful, you can completely change the subnet/gateway by connecting from a host that is on the same subnet.) You can also issue the command using the hostname assigned by Communication Manager: ipsisession -c IPSI-A01A. Remember, be very careful if you are changing the address or gateway. Since those two items require two separate telnet sessions to complete, it is possible to get locked out. If possible, telnet to the IPSI from a host that is on it's same subnet, so that you can then go in, set the IP address, and then set the gateway last. If it is a newer version of IPSI, it may require SSH, so you might have to use a program such as Putty to get in. The session is automatically terminated after 5 minutes, or after you kill the telnet session, so you will need to enter the ipsisession command before each telnet session.
I hope this answered your question.
Mike
If I'm understanding your post correctly, you want to configure the IPSI without using the services port right? It is actually possible to do some configuration changes via the Control Interface (port 1). To do this, you need go to the bash prompt and type: ipsisession -p NNN.NNN.NNN.NNN. The 'N's are the IP address of the IPSI. Then you just establish a telnet session to the IPSI using the same IP address issued in the ipsisession command. (be careful...you might lock youself out if you try to change the IP subnet/gateway...you can certainly change QOS values, and if you are careful, you can completely change the subnet/gateway by connecting from a host that is on the same subnet.) You can also issue the command using the hostname assigned by Communication Manager: ipsisession -c IPSI-A01A. Remember, be very careful if you are changing the address or gateway. Since those two items require two separate telnet sessions to complete, it is possible to get locked out. If possible, telnet to the IPSI from a host that is on it's same subnet, so that you can then go in, set the IP address, and then set the gateway last. If it is a newer version of IPSI, it may require SSH, so you might have to use a program such as Putty to get in. The session is automatically terminated after 5 minutes, or after you kill the telnet session, so you will need to enter the ipsisession command before each telnet session.
I hope this answered your question.
Mike
- Thread starter
- #4
This is an IP Connect. RFWatts, I have s x 8710 in site A with two contorl networks and IPSIs are configure on Control A and B. My remote site only has one ethernet connection and a C360 switch, two ipsis and one medpro and one clan. The ethernet connection is actually connected via fibre to the HQ. I plug the remote end into port 1 of my C360 and the other end, port one of the C360 of Control B network. Both these ports are configured on the same VLAN as the CN B. However, in this scenario, the MEDPRO in the EPN will not talk to the MEDPRO locally which means calls between the two port networks will nto work. However, if I change all the IP address to the corporate LAN, the IPSIs dont get registered which is strange because the IPSI should connect via the Corporate LAN connection on the servers. But it doesn't.
siriussatelliteradio
Programmer
Here is a question for you....Can you upgrade the firmware on an IPSI with direct connect using the services port? We have IPSI's in our system that are acting as tone boards so we cannot upgrade the firmware on those boards through the web interface because they are not on the network.
The Radio Revolution has begun....
The Radio Revolution has begun....
- Thread starter
- #7
cnc on" is a command you can run on a production server without affecting call processing. Basically, once enabled, Communication Manager will start listening for system-control traffic (IPSI control traffic, not to be confused with CLAN call-control traffic). It doesn't affect CLAN or MEDPRO traffic. You must be running CM 3.0 or greater to use the customer lan interface to listen for IPSI traffic. Avaya calls this CNOCL-Control Network On Customer LAN.
In your scenario, you can set the VLAN at the remote site to the customer lan side (not CNA or CNB), and put your IPSI, CLAN, and MEDPRO on the same subnet. This would be an IP-connect connect configuration using CNC.
In your scenario, you can set the VLAN at the remote site to the customer lan side (not CNA or CNB), and put your IPSI, CLAN, and MEDPRO on the same subnet. This would be an IP-connect connect configuration using CNC.
We use all three control networks in our environment.
We have a local S8710 (Centerstage) with 5 PN local to it using Control network A and B.
We also have to IP connect EPNs in two different states using CNOCL for connectivity back to the main.
To add one more layer to it (as if it wasn't bleeding edge enough) we deployed S8500 ESS servers to each of the remote EPNS and placed them into a cluster for redundancy (in case of failure on the main site.
Not all the bugs are out....certainly not the case with CNOCL...We ran into a few issues. Not the least of which is the inability of the Int04 (Which is used for CNOCL) has no options for it's VID# it defaults to 0 so enabling QOS for control network C required us to jump through some hoops.
We have had this configuration in for a cople of months and it is just starting to settle down.
We have a local S8710 (Centerstage) with 5 PN local to it using Control network A and B.
We also have to IP connect EPNs in two different states using CNOCL for connectivity back to the main.
To add one more layer to it (as if it wasn't bleeding edge enough) we deployed S8500 ESS servers to each of the remote EPNS and placed them into a cluster for redundancy (in case of failure on the main site.
Not all the bugs are out....certainly not the case with CNOCL...We ran into a few issues. Not the least of which is the inability of the Int04 (Which is used for CNOCL) has no options for it's VID# it defaults to 0 so enabling QOS for control network C required us to jump through some hoops.
We have had this configuration in for a cople of months and it is just starting to settle down.
"joecom (Instructor) 17 Jan 06 17:53
You have to decide Multi Connect or IP Connect"
Multi connect the answer is no.
IP Connect you can use vlans, but i geuss the question is what is the PBX topology "
See my above post as to my current configuration. What your saying is true prior to 3.0, now with the advent of CNOCL you can do mixed environments.
Dunstan
How do you plan for your ESS servers to control your 5 PNs that are on CNA and CNA? I have a similar setup. I am considering re-addressing my CNA and CNA networks, and routing them between my 3 primary sites (all 8700s) along with CNC for my secondary sites.
Tnx,
Mike
How do you plan for your ESS servers to control your 5 PNs that are on CNA and CNA? I have a similar setup. I am considering re-addressing my CNA and CNA networks, and routing them between my 3 primary sites (all 8700s) along with CNC for my secondary sites.
Tnx,
Mike
Mike
In this stage of our deployment (2 out of 5 sites converted) our intention for the ESS servers is for the remote locations to have fallback amongst themselves (provided a wan failure between the S8710 and whichever site and to allow for stand alone processing at each site in the event of a massive network failure. Our corp HQ where the S8710's are located is essentially bulletproof from a DR perspective with contigencies in place for key employees et al (which was another long story). If we were to have a failure of the type required to bring down our Corp facilities it is likely we have no building to talk about
The two ESS locations are part of a regional cluster of 5 different facilities spanning a couple hundred mile area in the Mid-Atlantic (which we are converting one at a time-2 down three to go) which share a 10 mb fiber ring (With each other to our corp office the links are PTP T-1's.) These sights were all stand alone and we had been waiting for ESS to go GA before we converted them. Our purpose was to allow us to pool the sites RTU and administration. Centralize VM and services etc but whithout sacrificing any reliability...in fact while increasing reliability for those sites through the multiple points of failure the nature of those sights and the business we do there does not allow for down time.
Hope I didn't digress to much.
In this stage of our deployment (2 out of 5 sites converted) our intention for the ESS servers is for the remote locations to have fallback amongst themselves (provided a wan failure between the S8710 and whichever site and to allow for stand alone processing at each site in the event of a massive network failure. Our corp HQ where the S8710's are located is essentially bulletproof from a DR perspective with contigencies in place for key employees et al (which was another long story). If we were to have a failure of the type required to bring down our Corp facilities it is likely we have no building to talk about
The two ESS locations are part of a regional cluster of 5 different facilities spanning a couple hundred mile area in the Mid-Atlantic (which we are converting one at a time-2 down three to go) which share a 10 mb fiber ring (With each other to our corp office the links are PTP T-1's.) These sights were all stand alone and we had been waiting for ESS to go GA before we converted them. Our purpose was to allow us to pool the sites RTU and administration. Centralize VM and services etc but whithout sacrificing any reliability...in fact while increasing reliability for those sites through the multiple points of failure the nature of those sights and the business we do there does not allow for down time.
Hope I didn't digress to much.
I guess I should answer your question lol...which as I re-read that I realized I hadn't done it directly. In the event that we wish to bring the Main/HQ site PN's into the mix so that they are controlled via ESS I would opt for the option you stated and run C between the various IPSI's (meaning re-configuring your CN/IPSI's. That is what our plan is/was if when we discussed it during the design phase.
- Thread starter
- #14
- Thread starter
- #15
- Status
Similar threads