New to the Sonus SBC 1000 and SBC 2000 is the ability to perform a Partial Import of another gateway’s configuration. As it says on-screen “Existing Logical Interfaces, Ethernet Ports, VLANs, MST Instances, ACLs, Static Routes, ASM Networking, Link Monitor, NAT, IPsec Tunnels, Node-Level Settings and Certificate configurations won’t be modified. All other configurations will be over written.”
This is a fantastic way to ‘clone’ an existing gateway or perhaps start every build from a standardised template-style config, but you might find it’s not always going to be 100% successful for you.
I recently encountered a customer who has an existing SBC 1000 and has bought a second for their DR DC, but alas our attempt to blow the first one’s config into the new one failed:
“Port 7.1 in use by ISDN Signaling Group 10001 not found”.
“Port 7.2 in use by ISDN Signaling Group 10002 not found”.
The issue is that the ‘donor’ or ‘source’ system has ISDN cards in it, which the new one does not. I think a lot of customers are going to encounter a situation like this as they migrate from ISDN to SIP Trunking, but thankfully it’s relatively easy to get around.
The Work-Around
There are two options, and the path you choose will probably be dictated by whether you have another SBC of the same model (a third) that also has ISDN cards in it.
We just need to get the ISDN signaling groups out of the config and then create a backup.
No spare (third) gateway?
Schedule some downtime. 10 or 15 minutes should do it, and most of that will be spent twiddling your thumbs.
- Login to the active gateway and back it up. Put the file somewhere safe. We’re going to restore it later
- Navigate to the Call Routing tables and delete all routing table entries that send calls to the ISDN trunks
- Navigate to the Signaling Groups and delete the ISDN Signaling Groups
- Now perform another backup of the gateway. It’s THIS one you’re going to restore into the new gateway
- Now restore (into this first gateway) the backup you took in Step 1 and make sure the gateway reboots into service. The conservative in me likes the idea of a full restore here, but I see no real reason why a Partial Import wouldn’t be fine. Test as appropriate before proceeding though!
- The backup you took in Step 4 should now be good for a Partial Import into the new gateway
- Ta-da:
You have a spare?
Easy – provided (as I said above) your spare/Lab/demo gateway has ISDN cards.
If the current config in this third gateway is important to you, back it up.
The rest of the process is much the same as above:
- Perform a partial import of the backup file from the customer’s initial gateway. (As an alternative you might choose a full restore, but take note of their networking settings beforehand, so you know what you need to change on your PC so you can talk to it after it comes up)
- Delete the routing table entries
- Delete the ISDN Sig Gps
- Perform a backup. Again, this is the one you’ll use in the new g/w
- Import the backup from Step 4 into the customer’s new gateway
- If you opted for the Partial Import in Step 1, double-check the new gateway just in case anything from your Lab has leaked into the customer’s config. I don’t know if there’s a risk of that, but no harm spending a few minutes to check it
- Restore your spare/Lab gateway’s config as appropriate
What Next?
Now’s probably a great time to download my ‘uxbuilder’ script so you can turn these backup files into more legible Word documents and PDFs:
https://greiginsydney.com/uxbuilder/
BTW, the above is accurate as at 4.1.0 b369. Sonus is aware of this and we’ll hopefully have this behaviour improved in a future release.
– G.
Postscript
Updated 7th March 2015: The Sonus TAC says this operation is design intent. A PI has been raised on the subject.
