Thanks Brian, Is it normal for phones to only use CTL's? it seems like they pull both
On Thu, Mar 26, 2015 at 12:44 PM, Brian Meade <bmead...@vt.edu> wrote: > Phone config files are signed by the CallManager.pem from the node serving > up the files. > > Phones with SBD using ITLs will be able to authenticate the new > certificates right away using TVS. I would just make sure the phones get > the new ITL before moving onto the next node. > > For phones only using CTLs, they are not going to trust config files until > the CTL client is re-ran, TFTP service restarted, and new CTL downloaded. > The phones are probably fine to use the cached configs for a little bit > until you finish the whole cluster and run the CTL client once assuming > you're doing it all in one window. > > On Thu, Mar 26, 2015 at 11:34 AM, Ed Leatherman <ealeather...@gmail.com> > wrote: > >> Sorry for resurrecting this old thread, now that I have some spare cycles >> to devote to this I wanted to follow up about it.. >> >> - The node names are not changing, just adding DNS servers and domain >> name to each node >> >> - Call Manager servers are defined by IP address, and IP's are also not >> changing. >> >> - with respect to database replication, it seems configuring DNS and >> setting a domain name should take care of itself just with rebooting each >> node one at a time >> >> - production cluster is mixed-mode security. Currently no domain name is >> setup, and in the certificates this is reflected in the CN. On my test >> cluster, which already has dns and a domain name configured, I see that the >> CN has the domain as part of it - so when I add a domain name to my >> production cluster all the certs will need to be regenerated, requiring a >> CTL update >> >> My initial thoughts on this were just to update the dns info and reboot >> one at a time on each node (pub first), letting dbrep settle down between >> reboots, and then run the CTL client to update that, then restart CM and >> TFTP services on each node. >> >> So, do I just need to do one CTL update after I have made the change and >> rebooted all my nodes, or will I have to update the CTL after each reboot? >> I'm picturing in my head getting halfway into the process and having phones >> unable to pull config files until I update the CTL at the end, but does TVS >> take care of this interim case? >> >> Thanks!! >> Ed >> >> >> >> >> >> On Mon, Aug 11, 2014 at 9:43 AM, Ryan Ratliff (rratliff) < >> rratl...@cisco.com> wrote: >> >>> Kind of makes me want to enable mixed-mode on the 2nd cluster. >>> >>> >>> If you've got the eTokens handy then it will certainly make you life a >>> lot easier when it comes to SBD and endpoints. >>> >>> -Ryan >>> >>> On Aug 11, 2014, at 8:41 AM, Ed Leatherman <ealeather...@gmail.com> >>> wrote: >>> >>> Thanks Matt, >>> >>> So it sounds like purely from database replication perspective >>> enabling DNS by itself isn't an issue. >>> >>> If I do need to change the domain or hostnames on the cluster then it >>> becomes a certificate operation of some variety depending on the security >>> state of the particular cluster - in addition to minding replication. Kind >>> of makes me want to enable mixed-mode on the 2nd cluster. >>> >>> Thanks! >>> >>> Ed >>> >>> >>> On Mon, Aug 11, 2014 at 8:19 AM, Matthew Loraditch < >>> mloradi...@heliontechnologies.com> wrote: >>> >>>> >>>> https://supportforums.cisco.com/document/68701/communications-manager-security-default-and-itl-operation-and-troubleshooting#Changing_Host_Names_or_Domain_Names >>>> >>>> >>>> >>>> Take a look there, pretty much covers every scenario, I just did a >>>> multi-node with ITL only for the same reasons as you and it worked like a >>>> charm. >>>> >>>> >>>> >>>> Rebuild definitely not necessary. >>>> >>>> >>>> >>>> >>>> >>>> <image001.jpg> >>>> >>>> Matthew G. Loraditch – CCNP-Voice, CCNA-R&S, CCDA >>>> >>>> 1965 Greenspring Drive >>>> Timonium, MD 21093 >>>> >>>> direct voice. 443.541.1518 >>>> fax. 410.252.9284 >>>> >>>> Twitter <http://twitter.com/heliontech> | Facebook >>>> <http://www.facebook.com/#!/pages/Helion/252157915296> | Website >>>> <http://www.heliontechnologies.com/> | Email Support >>>> <supp...@heliontechnologies.com?subject=Technical%20Support%20Request> >>>> >>>> Support Phone. 410.252.8830 >>>> >>>> <image002.png> >>>> >>>> >>>> >>>> *From:* cisco-voip [mailto:cisco-voip-boun...@puck.nether.net] *On >>>> Behalf Of *Ed Leatherman >>>> *Sent:* Monday, August 11, 2014 8:00 AM >>>> *To:* Cisco VOIP >>>> *Subject:* [cisco-voip] Question about enabling DNS on CUCM cluster(s) >>>> >>>> >>>> >>>> Good morning! >>>> >>>> >>>> >>>> Was hoping someone with a little more experience on the jabber/collab >>>> edge side could point me in the right direction here. >>>> >>>> >>>> >>>> I have 2 CUCM clusters that I am researching configuring jabber and/or >>>> collab edge for. Up till now I've never had a need for DNS resolution on >>>> the either. One of them has been operational since version 3 dot something >>>> and back then it seemed the recommendation to stay away from DNS in general >>>> on CUCM unless there was a good reason otherwise. >>>> >>>> >>>> >>>> I see there are just a few commands to enable it and setup servers etc >>>> - are there any gotchas with database replication or security that I need >>>> to be aware of? I don't plan on changing the hostname of the servers >>>> themselves or their IP addresses. >>>> >>>> >>>> >>>> The old cluster has CTLs/USB tokens. The "slightly" newer cluster is >>>> just running in security-by-default mode. Both clusters are @ version 9.1. >>>> >>>> >>>> >>>> My research thus far seems to say turning DNS up on earlier versions of >>>> CUCM required rebuilds but seems to not be the case now, but I haven't >>>> turned up anything in the official docs. I have a TAC case open to ask >>>> about it but I'm still at the explain DNS and what my business case is >>>> stage ;) >>>> >>>> >>>> >>>> Appreciate any tips! >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Ed >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Ed Leatherman >>>> >>> >>> >>> >>> -- >>> Ed Leatherman >>> _______________________________________________ >>> cisco-voip mailing list >>> cisco-voip@puck.nether.net >>> https://puck.nether.net/mailman/listinfo/cisco-voip >>> >>> >> >> >> -- >> Ed Leatherman >> >> _______________________________________________ >> cisco-voip mailing list >> cisco-voip@puck.nether.net >> https://puck.nether.net/mailman/listinfo/cisco-voip >> >> > -- Ed Leatherman
_______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip