node name re-written: Upgrade from v10 - V11

You could consider scripting this in Bash.

Start with a list of the nodes and dump to a file:

cat bigip.conf |grep "ltm node" |awk -F" " '{ print $3 }'

Create a copy of your bigip.conf file - you'll be working with the copy (bigip.conf.replace)

cp bigip.conf bigip.conf.replace

Now create a Perl script and add the following line for as many nodes as you have:

perl -pi -e 's/OLD-NAME/NEW_NAME/g' bigip.conf.replace

Where OLD-NAME is the (escaped) current value. So for example, if an existing node name is "/Common/10.70.0.3", your Perl script line will look something like this:

perl -pi -e 's/\/Common\/10.70.0.3/local-dot-3/g' bigip.conf.replace

** The -i means to edit in place.

If you dumped the original list into a text file:

1. replace any instance of "/" with "\/"

2. add "perl -pi -e 's/" to the beginning of each line

3. add "/g' bigip.conf.replace" to the end of each line

4. manually fill in the second part of each replace string to meet your naming requirements.

Open the bigip.conf.replace file to make sure everything looks good. If it does, swap it with bigip.conf (don't delete the original in case you run into problems - make another copy), and reload:

tmsh load sys config

If you can generate a list of IPs to descriptions you can just use sed in vi.

 

save your config:

tmsh save sys config

 

edit your config:

bash vim /config/bigip.conf

 

modify nodes (this will do nodes and pool members)

:%s/Common/127.0.0.1/Common/localhostg

 

:%s/Common/127.0.0.2/Common/localhost2g

 

save your work & quit

:wq

 

load your updated config

tmsh load sys config

 

I came across this issue as well. Fortunately it was a small deployment we had at the time. I could see it was going to be a much big nuisance for our larger deployment when we do upgrade at a later time.

 

I also recall that there seems to be more restrictions as to what chars can be used in a name ('%' no longer allowed?) under v11.

 

What is the rationale behind this behaviour in an upgrade? A name is just a label, and a user's choice of what to put in there, within reason, should be respected.

 

One year on since this question was raised, has this behaviour been changed in a later release, say, v. 11.5.0?

 

This software is supposed to bridge/converge network and applications, and network admins' usual preference of just using IP addresses in configurations can be a nightmare for administration of applications. I see a lot of examples of naming a virtual server "vs_blah_blah", and in my deployment I tend to use a more intuitive naming scheme, such as, my.service.my.com_443 (":" is not allowed), which makes it easier to find a service amongst a multitude of others.

 

Just a thought (and a couple of more questions).