nice! chalk full of reading. 

thanks 


--- 
Lelio Fulgenzi, B.A. 
Senior Analyst, Network Infrastructure 
Computing and Communications Services (CCS) 
University of Guelph 

519‐824‐4120 Ext 56354 
[email protected] 
www.uoguelph.ca/ccs 
Room 037, Animal Science and Nutrition Building 
Guelph, Ontario, N1G 2W1 

----- Original Message -----

From: "Ryan Ratliff (rratliff)" <[email protected]> 
To: "Lelio Fulgenzi" <[email protected]> 
Cc: "cisco-voip voyp list" <[email protected]> 
Sent: Thursday, February 20, 2014 1:10:45 PM 
Subject: Re: [cisco-voip] unexpected behaviour with "Prepare Cluster for 
Rollback" and migrating phones between v9 and v7 cluster 


https://supportforums.cisco.com/docs/DOC-17679 


This should be the one. 

Sent from my iPhone 

On Feb 20, 2014, at 1:03 PM, "Lelio Fulgenzi" < [email protected] > wrote: 






Thanks Ryan! 

Can you clarify "CSC doc on SBD" ? I'd like to review it. Is it the chapter you 
are referring to? 


--- 
Lelio Fulgenzi, B.A. 
Senior Analyst, Network Infrastructure 
Computing and Communications Services (CCS) 
University of Guelph 

519‐824‐4120 Ext 56354 
[email protected] 
www.uoguelph.ca/ccs 
Room 037, Animal Science and Nutrition Building 
Guelph, Ontario, N1G 2W1 

----- Original Message -----

From: "Ryan Ratliff (rratliff)" < [email protected] > 
To: "Lelio Fulgenzi" < [email protected] > 
Cc: "cisco-voip voyp list" < [email protected] > 
Sent: Thursday, February 20, 2014 12:32:42 PM 
Subject: Re: [cisco-voip] unexpected behaviour with "Prepare Cluster for 
Rollback" and migrating phones between v9 and v7 cluster 

Inline... 


-Ryan 
<blockquote>



On Feb 20, 2014, at 10:49 AM, Lelio Fulgenzi < [email protected] > wrote: 




As a follow up to this, I'm still a little confused. 

I have confirmed 


    * that the phone that I removed after setting the "Prepare Cluster for 
Rollback" to True, had an empty trust list 
    * that the phone that I removed after setting the "Prepare Cluster for 
Rollback" to False, had an non-empty trust list 
        * TFTP: fqdn of TFTP server 
        * TVS: fqdn of PUB 
        * TVS: fqdn of SUB1 
    * this was with only changing the parameter and resetting phones, no 
restarts of TFTP or TVS services. 



Good, that is what I'd expect you to see. 

<blockquote>





I was also able to confirm that: 

    * both the phone with an empty trust list AND non-empty trust list were 
able to register to the old cluster 

</blockquote>

All phones, in absence of getting a valid configuration file, attempt to 
register to the configured TFTP server. The best way to tell if the phone is 
happy about it's config is to look at the Status Messages log. Failures to get 
a config file, update the trust list, or successful config file downloads will 
be logged here. 
<blockquote>






    * I was able to change the configuration (adding a secondary DN) to both 
phones and they both accepted them 

</blockquote>

This behavior will vary by phone model and protocol used (SCCP vs SIP). SCCP 
phones don't get any DN information in their config file. 
The biggest thing that will get you moving between 7.x and 8.x or later is a 
phone with a real trust list (CTL or non-empty ITL) will only request a signed 
config file. A 7.x server with no CTL installed will not generate a signed 
configuration file for a device. How the phone behaves at this point depends on 
what's different between the cached config file the phone has and the current 
cluster it's trying to register to. If the nodes have the same IP address and 
such then there's a good shot the device will still register, even though new 
config file updates won't take. 

<blockquote>









Is the trust list simply a _list_ of acceptable hosts? And because the (fqdn) 
hostnames and IP addresses are the same on both clusters the phones are still 
able to register and accept changes? 


If not simply a list, and it uses the host certificates, i.e. it uses host 
certificates to either build the list hash or push the certificates down to the 
phones, is what I am seeing the same certificate being generated on each host? 
I mean, I'm using all the same information, could that be possible? I don't 
know which certificates to compare, or I would have provided the results of 
that test. 
</blockquote>



The CSC doc on SBD has a great deal of this information in it already. The 
trust list is just that, a list of certificates that the phone can trust for 
SSL communication or signed configuration files. If you upgraded your 7.x 
servers to 9.x and are swapping phones between a lab and production network 
then there's a good chance most of the same certs are present (though they 
won't be used the same). For ITLs the two certs used most commonly are Tomcat 
(for HTTPS services) and CCM (for signing config files by TFTP). The last one 
is the TVS cert which is used by the phone to validate any cert it is presented 
with that isn't in the trust list already. 

<blockquote>







Thoughts? 


Lelio 










--- 

Lelio Fulgenzi, B.A. 
Senior Analyst, Network Infrastructure 
Computing and Communications Services (CCS) 
University of Guelph 

519‐824‐4120 Ext 56354 
[email protected] 
www.uoguelph.ca/ccs 
Room 037, Animal Science and Nutrition Building 
Guelph, Ontario, N1G 2W1 

----- Original Message -----

From: "Lelio Fulgenzi" < [email protected] > 
To: "cisco-voip voyp list" < [email protected] > 
Sent: Wednesday, February 19, 2014 4:37:35 PM 
Subject: unexpected behaviour with "Prepare Cluster for Rollback" and migrating 
phones between v9 and v7 cluster 



OK, now I am officially confused. ;) 

I was under the impression that once a phone has registered to a v9 cluster, it 
downloads an ITL trust list/file which prevents it from registering to a v7 
cluster. To help with this, the "Prepare Cluster for Rollback" enterprise 
parameter was introduced. 

Here's what I did: 


    * upgraded offline cluster (all servers had same hostname and IP address) 
    * set the "Prepare Cluster for Rollback" parameter to True and clicked Save 
(because there were no phones registered, I did not "Apply Changes") 
    * plugged phones into the offline network 
    * phones registered to the new offline v9 cluster 
    * checked phone security pages - they showed ITL files listed (that long 
string of numbers) 
    * thinking it was the "Apply Changes" that missed something, I clicked that 
    * phones restarted, but still showed an ITL file 
    * brought a phone back to the live network, phone registered to the v7 
cluster (still has an ITL file listed) 
    * on offline cluster, change the "Prepare Cluster for Rollback" to False, 
clicked Save, clicked Apply Changes (phones restarted, and showed an ITL file) 
    * I picked up one of the phones from the offline network (now in 
rollback=false mode) and brought it to the live network. It registered to the 
v7 cluster. 

So what I see are a few things confusing me: 

    * Why do phones still have ITL files if the cluster is in rollback mode. 
This is not a big deal, but I'd like to be able to tell from the phone when 
it's registered with the "Prepare Cluster for Rollback" set to TRUE. 
    * Why does a phone that registers to a v7 cluster still have it's ITL file 
set? 
    * Why (and this is the one that gets me) does a phone that was on v9 with 
"Prepare Cluster for Rollback" set to FALSE successfully register to the v7 
cluster? 

Is the ITL trust list a simple hash of the IP addresses and host names of the 
cluster members? If I don't change anything, things will continue to work? 


Is something wrong with my logic and steps? I was testing with a 7942 and a 
7962. 



Lelio 


--- 
Lelio Fulgenzi, B.A. 
Senior Analyst, Network Infrastructure 
Computing and Communications Services (CCS) 
University of Guelph 

519‐824‐4120 Ext 56354 
[email protected] 
www.uoguelph.ca/ccs 
Room 037, Animal Science and Nutrition Building 
Guelph, Ontario, N1G 2W1 


_______________________________________________ 
cisco-voip mailing list 
[email protected] 
https://puck.nether.net/mailman/listinfo/cisco-voip 


</blockquote>


</blockquote>

_______________________________________________
cisco-voip mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/cisco-voip

Reply via email to