Forum Discussion

Patrick_Farrel1's avatar
Patrick_Farrel1
Icon for Nimbostratus rankNimbostratus
Mar 27, 2019

Renaming VLANs on a Viprion chassis and vCMP Guests

I'm in the unenviable position of having to rename a dozen+ VLANs on a Vipreon chassis and vCMP guests. The reason stems from having to combine guests from 2 pairs of chassis where one pair is being decommissioned. Unfortunately the original admin who set up the chassis did not use the same VLAN naming convention for both sets of chassis, and the same VLAN tags exist in both places. This results in guests that are brought over from the old chassis not being able to access the network as the VLAN names do not match up. The destination is 2 chassis where the LTMs are in an active-standby pair with the members of the pair being split between the 2 chassis. (Same situation on the chassis I'm migrating from.)

 

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

 

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

 

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

 

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

 

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

 

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

 

Am I missing anything here?

 

BIG-IP
f5 viprion
Super-NetOps
vcmp guest
vlan
  • wesleyjack's avatar
    wesleyjack
    Icon for Nimbostratus rankNimbostratus
    Mar 27, 2019

    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.
  • Stanislas_Piro2's avatar
    Stanislas_Piro2
    Icon for Cumulonimbus rankCumulonimbus
    Apr 03, 2019

    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