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 ?

 

[kyle555]

Can't remember smgr - there must be a script like the changeIPVFQDN.sh


Sbc is easy - from the dashboard, 'edit' the sbc, you set the DNS IP and choose the interface that's used for DNS. I remember that much - you use A1 or M1 or B1 for DNS queries to the defined DNS IP

 

[trilogy8]

I do see where to do that from the dashboard. I also reviewed an Avaya doc that references this:

Changing DNS IP and FQDN
Procedure
1. Log on to the Avaya SBCE server as a super user.
2. Type SBCEConfigurator.py change-dns—ip—fqdn DNS IP FQDN

is this basically the same thing ?

 

[kyle555]

Yeah, I think that'll do more though - like change the IP of the SBC itself if you want it to.

If its just DNS, i'd use the gui

 

[trilogy8]

As far as the various applications go, it looks like the DNS servers are input with IP addresses. Are any of the applications able to be given a DNS name in those fields instead of IP? When you open up the help sections on those pages in (CM, SBC, AES.. )it doesn't specify what is acceptable to be input there.

 

[kyle555]

if you put hostnames as DNS servers, how would you resolve them?

That's like dividing by 0

 

[trilogy8]

I slapped myself for you.. sorry

 

[kyle555]

LOL

 

[trilogy8]

Before making these changes is it safe to take VMware snapshots of CM,SBC,ASM servers?

 

[kyle555]

I power them off before snapshots but yes

 

[trilogy8]

Is that for corruption safety ? For a change like a DNS IP I'd rather do as little as possible.

 

[trilogy8]

Lastly.. hopefully. On the core CM, I updated the DNS servers the standby server and hit 'change' at the bottom of the screen. There is also the 'restart CM' choice down there. Is that required to do? After hitting 'change' I got a success message. Does that still require a CM restart? I would have hoped it would have told me I had to do it.

 

[kyle555]

Yea.

See if you can cat /etc/resolv.conf or just nslookup something in the CLI to see what name server it tries

Most things in that screen usually require a CM restart, but I could see DNS not really needing it.

 

[trilogy8]

Moving along. I watched an Avaya video on the SMnetSetup process. At the end of that script it says the SM will reboot. I was not expecting that. It's been years since that was rebooted. When it reboots is it going to need that trust password with SMGR during its bootup? That's probably been expired for so long.

 

[kyle555]

you just go set the pw in SMGR for trust management.

SM will restart, not reboot. if trust management isn't established with valid certificates, you're not going to see anything in the SM dashboard in SMGR. If you don't see anything in the SM dashboard, you had expired certificates already.

 

[trilogy8]

That popped in my head right after I asked the last question. What’s the behavior with certificates? We install our root and subca certs in the smgr trust store. Then we install SM identity certs from our pki for the for the relevant services. Is any of that going to be wiped out?

I do know there is currently some weblm legacy cert that is expired that alarms but it doesn’t seem to be relevant.

 

[kyle555]

YES.

initTM literally "initializes the trust store"

if you use 3rd party certs on SM interfaces offering SIP to phones, you need to put those back

Also, the SMs you initTM on will lose the other CA certs they trusted before - so if you did this on SM1 and 2 but not SM3 and 4 and SM3 and 4 had SM100 certs from your PKI, SMs 1 and 2 wouldn't talk to them until they trusted your PKI CA

 

[trilogy8]

So glad I asked this.

All this destruction over a simple reboot. I have 5 of these and were going to cascade these the next few weeks. So I can proceed with the 2 but have to reapply the identity certs? Is that what you’re saying? We use the same identity cert for all the SM’s and the cert has all the hostnames in it.

 

[kyle555]

initTM = certs like when you installed but with a new SM cert from SMGR with today's date.

So, it your SM trusts other CA certs, you have to put those back after a initTM

If your SM offers a cert on SM100 or HTTPS that isn't exactly like when a generic initTM happens, you have to put that cert back after.


That's why there's a auto-renew in there for the certs it requests from SMGR on its own.

initTM means initialize trust management. You'd think that means "initialize trust management between SM and SMGR" and "leave the trust store of what SM already trusts alone", but alas, it is not. Pretend you installed the SM from scratch. Whatever you did to setup certs right for your environment then you need to do after initTM.


Although, SMNetSetup won't do a initTM if it isn't required. initTM -f on your own will do that.

So, keep an eye out, but I wouldn't think it'd change anything.

If you have customer root, editing /etc/resolv.conf would save you the headache

 

[trilogy8]

For these DNS changes, is the best course of action to have the trusted and identity certs on hand, update DNS on SMGR and then the SM's? I'll have snaps taken of all these as well. Just concerning with these as if they do a wipe I'm gonna be down for a while.