Hi Has anyone had involvment with a customer transitioning from a WS5100 V2 architecture to RFS6000 or WiNG WS5100, using auto config via the command file option with V2 and DHCP scope options to pull a config file from a TFTP server. Have a customer that has had to do this due to EOS of WS5100, and we have 2 issues. Firstly with the method of auto config being restricted to vendor option 43 with embedded options and requiring the exact firmware file name to be the syntax for kicking off the auto config process (for example V4.2.0.0-024R). The issue this causes is if a RFS is deployed that does not have that specific version of firmware the auto config does not start, so not a real out of box auto config anymore! Secondly the customer needs to encrypt the config file that will be distributed on FTP servers across the stores (using “service password secret 2 XXXXX” command) due to internal security protocols. However when this encrypted file is then used on another RFS the TKIP passphrases that have been encryted on the config file do not match and the MU's will not connect, it seems the Hashing of the encrption keys is directly related to the hardware it is created on. Anyone got answers as to how we can do this differently and get the same results we currently get with the V2 WS5100 install? or if I'm missing something let me know what it is. Cheers Dave
RFS6000 auto config// Expert user has replied. |
9 Replies
I've not had a chance to test yet so thanks for validating this Chris, what I can say though is my SNMP engine ID was always different between my two switches as I had been using cluster GUI previously.
Thanks again for the feedback
I didn't check but I will. Both switches started with pure defaults. The hashed passphrase values were showing up different (using show run) on each switch so I have to assume they were unique. That also does indicate that it is using the engine ID somehow in the process but this obviously doesn't stop it from working once the command is applies in the correct order.
looks like they were the same. Do you think this means if the engine ID is unique this process will no longer work?
snmp-server engineid netsnmp 53796d626f6c2020
I've not had a chance to test yet so thanks for validating this Chris, what I can say though is my SNMP engine ID was always different between my two switches as I had been using cluster GUI previously.
Thanks again for the feedback
Hey Chris, Got a further answer on this one which basically states: The running config does not export the encryted passphrases so the only way to actually do this is to copy and past the appropriate line with the passphrase secret on into a default cfg file and import into the RFS, then apparently when i import the customer cfg that is encryted with same secret, it should work. I need to test this yet but that the answer I got from the BU...hopefully this V5 firmware has addresssed fully the lack of auto config for the RFS controllers. Cheers Dave
Ok, i did some testing today to get some further clarity on this subject. What I found is that there is a difference between WiNG v3.x to v4.x. I used a pair of RFS6000's loaded with v4.2.1. I created a config file with some WPA2 passphrases and saved it. Then used the service password-encryption secret 2 chris command to encrypt the passphrases. I then took a copy of this startup-config file. As we know, the "secret" is not contained in this file. So on to the second RFS6000, I applied the service password-encryption secret 2 chris command, saved it, then loaded my startup-config file, rebooted and it DID NOT work (MU's not able to associate and get denied with invalid key). I then did the test the other way around by loading the startup-config first, reboot the switch, then applying the service password-encryption secret 2 chris command and IT DID WORK this way. Good news. Then I re-did the same tests with the same RFS6000's but loaded with v3.3.2. I found it worked the opposite way. I did have to apply the service password-encryption secret 2 chris command first, then load the startup-config, reboot and then MU's able to associate. So in a nutshell, v3.x and v4.s work the opposite way. For v4.x - load config file and then apply service password-encryption secret 2 chris command For v3.x - apply service password-encryption secret 2 chris command and then load config file Now my only remaining question is, is it possible to mass deploy this command via RFMS to hundreds of locations? I think not as it isn't really part of the configuration, it is a service command. Anyway, hope this helps anyone interested in the subject. It also means that Support and Engineering were not correct a year ago when they told us this couldn't be done!!
Hello Chris, Were the SNMP EngineID's the same on both RFS's or unique?
Hi Dave, RE: the second part of your question relating to using the “service password secret 2 XXXXX” command and transferring config files between RFS's. Before a file generated from a RFS that has the password-encryption enabled can be transferred onto a new RFS, the new RFS needs to have the same "service password-encryption secret 2 xxxxx" command executed. Thus, one method you could use is the following sequence - unfortunately this will make your process a 2 step process that requires some manual intervention after the auto upgrade: 1. Use the "Auto Config" or some other method to upgrade the firmware of your RFS's (keeping the IP address info). 2. Execute the "service password secret 2 xxxxx" command on the upgraded RFS. 3. Copy over / install the new startup.config file that has encrypted passphrases. 4. Reboot the new box and you are up and running. This is the process we have been using for our customers.
Do we know for sure if the process below from Jack works? I was told about a year ago that the hashing of passphrases uses the engine id of the hardware and therefore you could not re-use a config file on another switch even if you configure it with the same service secret passphrase.