Renaming VLANs on a Viprion chassis and vCMP Guests

Can I get a sanity check on what I'd like to do here?

 

• I think this is do-able but potentially disruptive to your production guests, so I'd do everything in a maintenance window.

Force the guests offline on the secondary chassis. Shut down the guests. Rename the VLANs on the Vipreon by editing bigip.conf and bigip_base.conf

 

• Not sure you would need to force them offline, but certainly force to standby any that are active. Would probably also be a good idea to do a forceload on MCPDB before shutting them down. You would probably need to set them to provisioned at least, maybe configured for shutting down.
• To be clear, the .conf files you are modifying would be on the Host and not the guests. Since the guests inherit the vlan name and tag from the host, I don't believe you need to modify .conf files on the guests.
• I also always do a "cp -p /config/bigip_base.conf /config/bigip_base.conf.bup" in case I screw up syntax or something else and corrupt the .conf file.

load sys config verify load sys config (or just reboot the chassis to be thorough)

 

• For this I really do not think a reboot is necessary, and honestly you would only be shutting down the guests to keep things clean and controlled. The "load sys config" on the host for something like this would certainly result in disrupting traffic processing on the guests for a short period.
• What may make a reboot necessary is if you note issues on the hosts like the VLAN name/tag does not appear to have changed. It may be a good idea to have MCPD rebuild its' database with a forceload. Since you are modifying the textual configuration directly, I think the forceload would be a wise move (I suggested this earlier for the guests prior to shutdown). https://support.f5.com/csp/article/K13030

Bring up one guest offline, repeat the same procedure on the guest. Failover during a maintenance window and test. Repeat for other guests.

 

• I would do everything during a MW, not just the failover, but that's my organizations requirements. If you issued a forceload prior to shutting the guests down, when they boot back up they will rebuild their MCP DB.

If everything works there, repeat the same procedure on the primary chassis. Resync the configs once all changes are made and tested.

 

• If you use auto-sync I would also disable that prior to the shutdown of the guests on your secondary chassis. I am a control freak when doing stuff like this and would not want the F5 doing something I didn't tell it to do.

At this point the guests that are migrated over should be able to access the newly renamed VLANs as well.

 

• You got it. Also, and if possible, make sure your VLAN names are reasonably short. I tried doing a quick search to find the cutoff size (possibly 32 chars), but the VLAN name looks fine on the host but gets truncated on the guest and is annoying.

   

• An example from our VIPRION:

   

1. Host VLAN is WEBX-DMZ-ABCPROXYFRONT-VIPS-ABCD tag is 1000.
2. Guest VLAN reads WEBX-DMZ-ABCPROXYFRONT--T1000.0

Am I missing anything here?

 

• Probably turn off VLAN failsafe if in use on any VLANs subject to this change.
• Pull a fresh UCS off of everything before doing anything...Host and Guest(s).
• If possible, open a F5 support case and run this by support.

Editing config files can lead to instability!!!

 

First question is : how many times in your guest configuration these vlan are referenced?

 

Did you configure virtual servers with vlan assignment?

 

If not, the easiest solution is:

 

• create new vlans in host with fake ID but new names
• assign these vlans to guests
• move self ips to new vlan
• in host, change old vlan ID to other fake ID
• set the right vlan ID to new vlan