How often do you have to update your switch translations or routing? Among our clients this varies from “every week” to “once or twice a year” – and every time a change is made there’s a risk of impacting service.
With any network wide change you need to strike a balance between operating efficiently and avoiding risk. I’ve certainly worked with telcos who required a pre-approved MOP and a maintenance window to update the switch translations, but if you follow the best practices below you should be able to make changes during the day with minimal risk of impacting service.
Some of these are directly intended to reduce the risk of error, and others are best practices that create well-structured translations logic which avoid confusion and thereby reduce errors.
Label Everything
The best translations or routing logic is easy to understand, and in large part this comes from clear labels. In the Metaswitch CFS you can enter human readable names / comments for every Config Set, Attribute Set, Number Validation Table / Entry, Routing Table and Routing Action.
By using clear labels for all your entries you can make it easy for your future self (or a coworker, or your friendly consultant) to understand what you’ve built and why – which really helps avoid mistakes later.
Define Overflow Routes
Wherever possible, every trunk group should have a pre-defined overflow route, so that service will automatically overflow to that backup route in the event of a capacity limit or the failure of the primary trunk group.
This is not only good practice in terms of service availability, but it also helps to minimize panicked translations changes when a trunk group goes down.
Build LRN routing logic in advance
If an LNP dip returns an LRN this can easily throw off your standard routing logic, so make sure that you have (a) your switch configured to re-run Number Validation after an LNP query (if that’s where the route is defined) and (b) routing tables that cope with the possibility that you might be routing a non-local LRN and can identify the correct trunk group.
If you set this all up in advance then you can avoid the need to create a new version of translations to handle a one-off LRN routing update.
Export your translations to easily search them
On the Metaswitch CFS you can export each section of your routing config set to a text file, which you can then inspect in a text editor like Notepad++. I find this invaluable whenever I’m making a big change, because you can easily find all the entries that reference a particular trunk group or routing table.
This makes it much easier to spot all the places you need to make a change, and to figure out all the types of call that might be impacted.
Always test thoroughly before going live
Even for the smallest change, you’ll want to do some testing before activating your updated configuration for your entire network.
On the Metaswitch CFS we recommend that our clients maintain a full set of Route Verification Tests that can be easily re-run by pressing one button. It’s always worth spending the extra minute to check that all those tests still complete as expected, before turning the translations live. You can even add a test each time you make a change – to validate your specific situation works as expected.
For more significant changes, we would also recommend some live testing. On the Meta you can specific an Overriding config set for a certain subscriber or certain calls, then place live calls through your new configuration before activating for everyone else – and this is a great final validation step before completing your update.
If you follow these best practices, you can both reduce the need for regular changes, while also reducing the risk of errors when you need to make an update.
Thus allowing changes to be made quickly, efficiently and safely – and allowing everyone to sleep soundly at night.
