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 Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
CM SID
- Thread starter wpetilli
- Start date
Usually it's SID 1 nowadays. Pre-6 each PBX had a unique SID. You'd set it in the webpage server role page.
If you upgraded a pre-6 system to 6, your xml license file might retain the previous SID of the system you upgraded entitlements from, so you might need to set it in the CM webpage too.
If you upgraded a pre-6 system to 6, your xml license file might retain the previous SID of the system you upgraded entitlements from, so you might need to set it in the CM webpage too.
- Thread starter
- #3
So it sounds as if the SID is only relevant between the CM and LSP's it's associated, unless it's specified in the LF.
I backed up the translations and restored the .xln file onto a spare CM (off network), via console. I modified the 'cha sys ips' field to disable IPSI control. The idea was to be able to restore these translations on my new VE duplex. I did a save trans and didn't realize the backup methods didn't provide an option other than scp/ftp/sftp. I thought I'd be able to backup locally.. guess not. In any event I did the 'save trans' and went to /etc/opt/defty and saw xln1 and xln2, but they were listed under the root ID to which I don't have the creds. Tried every combo I can think of. Is there any other way to peel this file off this box so I can restore to the new system?
I backed up the translations and restored the .xln file onto a spare CM (off network), via console. I modified the 'cha sys ips' field to disable IPSI control. The idea was to be able to restore these translations on my new VE duplex. I did a save trans and didn't realize the backup methods didn't provide an option other than scp/ftp/sftp. I thought I'd be able to backup locally.. guess not. In any event I did the 'save trans' and went to /etc/opt/defty and saw xln1 and xln2, but they were listed under the root ID to which I don't have the creds. Tried every combo I can think of. Is there any other way to peel this file off this box so I can restore to the new system?
As it relates to ESS's and LSPs, yes, they all have their own MID, but the same SID. Pre-6, each LSP would get it's own license file and it would be like s1234m2.lic to say SID 1234, MID 2 and you'd need to match those in your server role pages. You still need to match them today as far as SID/MID is concerned, but they don't need a license anymore. That's why you'll usually see in your main license VALUE MAX SURVIVABLE STATIONS be something like 63 (max ESS) + 250 (max lsps) = 313*the total number of stations you have.
You can backup locally. just use scp with CM's own IP and folder /var/home/ftp/pub
* and remember, OS backup is IP stuff, Security is account stuff, XLN is call processing database stuff. Don't spin up a new vm on the same subnet as production and restore the OS backup. Bad IP conflicty things will happen.
You can backup locally. just use scp with CM's own IP and folder /var/home/ftp/pub
* and remember, OS backup is IP stuff, Security is account stuff, XLN is call processing database stuff. Don't spin up a new vm on the same subnet as production and restore the OS backup. Bad IP conflicty things will happen.
- Thread starter
- #5
- Thread starter
- #7
That worked.. sweet
to test an ESS failover the 'get forced' command is all that's needed? I ran it, saw the IPSI go in service to the ESS, but the phones are fluxed and won't register over. well a handful did, but they're not reachable. I let it sit for over 10 minutes and still they're in a wacky state. I failed back to the main for now. I have the backup server in the network region so that's not the issue.
to test an ESS failover the 'get forced' command is all that's needed? I ran it, saw the IPSI go in service to the ESS, but the phones are fluxed and won't register over. well a handful did, but they're not reachable. I let it sit for over 10 minutes and still they're in a wacky state. I failed back to the main for now. I have the backup server in the network region so that's not the issue.
That'll force all IPSIs to the ESS
There's a command to force failure of network regions too
But if you got G450s to procr, that'll never totally fail it. I'd say disable ip-interface procr to knock the H323/H248 stuff out and get force ips all on the ESS, that ought'a fail'er good.
There's a command to force failure of network regions too
But if you got G450s to procr, that'll never totally fail it. I'd say disable ip-interface procr to knock the H323/H248 stuff out and get force ips all on the ESS, that ought'a fail'er good.
- Thread starter
- #9
hmmm.. maybe they were in a flux because the PE address was still reachable. One of the phones that were flaked said 'resources unavailable' when a call was tried.
I have the ESS survivable processor set to intervening region 250. NR 250 has direct WAN to all other NR's. I didn't see your message about disabling the mains, PROCR for h.323 regs until late.
I have the ESS survivable processor set to intervening region 250. NR 250 has direct WAN to all other NR's. I didn't see your message about disabling the mains, PROCR for h.323 regs until late.
- Status