DNS IP Changes (ASM, SMGR, SBC) 2

[trilogy8]

I have to change the DNS server IP addresses on my ASM, SMGR and SBC's. The team stood up new DC's and are retiring the old. I am familiar with the SMnetSetup command. It's been a while though, but once I update the DNS IP's on the ASM, will I be able to avoid the whole SMGR trust process portion?

For SMGR, I don't remember the sequence of what happens.

I really need some guidance on how to invoke the process on the SBC. Can anyone provide steps to change these on the SBC's ?

 

[wpetilli]

I have to actually perform almost the same thing. This thread sparks the same questions. What's the best way to handle this when there are multiple SM's and a SMGR that needs this update. Mine has to do with NTP more than DNS, but there will be changes made to both.

 

[kyle555]

NTPs easy. SMNetSetup - not sure if it'd need a reboot to apply - maybe.

SMGR should have a script in like /opt/avaya/vsp

CM will want a reboot

The boxes you have root on you can just change ntpd.conf and restart the ntp service

 

[wpetilli]

From this thread though, it looks like the reboot can wind up being the cause of issues with certs and such being wiped out. That would stink. Is it just a matter of re-installing the certs against the sm100,, etc..

 

[kyle555]

changing fqdns means changing certs.

Now, you don't necessarily have to. If your users point to sipserver1.yourcompany.com and that DNS resolves to the SM100, then SM's mgmt and SM100 FQDNs could be yoursm1 and yoursm1-sm100

So, as long as the SMGR hosts file is up to date, you could change DNS from sipserver1 to sipcluster1 and just manage that on the on the identity cert offered on the SM100 for SIP and PPM

But, if you're going to be changing the FQDN globally, then you need a new cert and might be doing initTM

But you won't be doing that for NTP

 

[wpetilli]

I'm just updating the IP addresses for NTP, but may have to tweak a few DNS. We use IP for DNS server IP's.

 

[trilogy8]

A few weeks back I changed the DNS IP's on my SBC's via the web interface of EMS. Yesterday, our teams shutdown the domain controllers we moved off of. My SBC had incidents on it saying it couldn't resolve the SM100 hostname and the remote endpoints were offline. From the CLI of the SBC, the nslookup command isn't found to validate what DNS server it's using. I've since restarted the SBC application and things started working again. Is there a way from the CLI to prove the ability to do the name resolution? I have other SBC's that have not shown the same symptom, but if there were to have some sort of timer, I have a lot of endpoints on these.

 

[kyle555]

I wouldn't think so. The network stack within the app isn't what Linux would default to. You can set DNS to search from either the A1/M1/B1 interfaces. I'd think a default nslookup in Linux would pick M1 all the time.

 

[trilogy8]

On one SBC, which is a 7.1 I was able to do a ping -a to the hostname after restarting and it replied. It didn't reference DNS server it used. When I tried the other SBC's (7.2) the ping -a didn't work, nor did a regular ping. Not sure if we are blocking that on those. Would ideally like to know if I need to restart these others. Would rather not have to.

 

[kyle555]

If I were you, I'd rather not be running SBC 7.1!