Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Answers

Going from Untagged to Tagged VLANs

Problem:

Our Network team has recently added a new VLAN to our current Network Topology and use those addresses for our Virtual Servers on our LTMs. Our typical configuration is to use trunk two interfaces, enable them for LACP and assign them to a VLAN. Then configure the ports on the switch with LACP and as access ports for a given VLAN. We also have Self-IPs for each F5 VLAN (floating and non-floating). In our UAT environment, we have used all our interfaces and now need to make a decision to incorporate the new VLAN.

My thought is that we could take an existing F5 VLAN and convert it from untagged to tagged. This would essentially allow us to tag on the F5 as opposed to tagging on the Cisco side. My concern is taking an existing VLAN and reconfiguring it as a tagged VLAN without causing any issues. We are in an Active/Standby configuration so we could make the change on the Standby unit and then failover to make the changes on the "Active" after then fail back. Each Self-IP is assigned a VLAN which at this point is untagged. Can we simply just create a new VLAN as a tagged VLAN and just update the Self-IPs to use that new tagged VLAN?

I know on there will need to be a port configuration change on the switch to become a trunk port but I'm more concerned with adding the new tagged VLAN and updating the Self-IPs without having to remove that configuration and start over.

Any thoughts?

0
Rate this Question

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

You can't just create a new vlan and change the self-IPs to use the new VLAN. You need to change both the non-floating and floating self-IPs at the same time, so the same IP address range is not applied to two different VLANs at the same time.

You can make the change on the VLAN settings to modify the VLAN from untagged to tagged and change the VLAN interfaces to the trunk without too many problems.

0
Comments on this Answer
Comment made 4 months ago by Shann_P 352

I'm not using the same Self-IPs for two different VLANs. Sorry for the confusion as I probably stated that wrong. The current Self-IPs (for an existing VLAN) are assigned to our external VLAN on the F5. I need to start tagging as opposed to having that VLAN untagged. Is it as simple as creating my new tagged VLAN and updating the existing Self-IPs to use that F5 VLAN thus removing them from my untagged VLAN? Or do I need to remove and add them back?

The switch ports are configured as access ports but will be switched to trunk ports to allow the F5 to handle tagging.

0
Comment made 4 months ago by S Blakely

Is it as simple as creating my new tagged VLAN and updating the existing Self-IPs to use that F5 VLAN thus removing them from my untagged VLAN? Or do I need to remove and add them back?

If you create a new VLAN, you will need to delete the floating self-IP on the VLAN (so there is only one self-IP on the VLAN), and then change the remaining self-IP to use the new VLAN, and recreate the floating self-IP.

Modifying the existing VLAN to be tagged on a new trunk is a less disruptive option (in my opinion).

0
Comment made 4 months ago by Shann_P 352

I can't create a new trunk. All interfaces are currently being used. This might make it easier, for me anyway:

I have 6 interfaces on my i2600 (excluding mgmt). Here are my interfaces:

1, 2 -> trunked/LACP -> Layer 2 VLAN for Heartbeat (static Self-IP on each box) 3, 4 -> trunked/LACP -> external VLAN (DMZ traffic) (static on each box and shared floating Self-IP) 5, 6 -> trunked/LACP -> internal VLAN (Server traffic) (static on each box and shared floating Self-IP)

As you can see, I cannot create a new trunk without removing an existing one. My thought was that we could preform the Standby Box and force offline. Then have the port on the switch changed form an access port (VLAN 10) to a trunk port. Then create a new F5 VLAN and tag for Network VLAN 10. Then update the Self-IPs that are configured for external VLAN and update them to use the new VLAN. Are you saying that it's better to making configuration changes on the existing external VLAN to make it tagged?

Sorry for all the questions but just trying to talk through it here before making any changes. Thanks for your help S Blakely!

0
Comment made 4 months ago by S Blakely

Are you saying that it's better to making configuration changes on the existing external VLAN to make it tagged?

Yes. Then you do not need to delete any self-IPs, and all you have to do is change the external VLAN to be tagged on the trunk and not untagged.

0
Comment made 4 months ago by Shann_P 352

Thanks so much! I have an environment to test in so I'll start there.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

The work you need to do with BigIPs is 15 minutes max. I'm more concerned about possible impact due absence of dot1q interface configuration in servers or VM hypervisor.

  1. Do what S Blakely recommended on Standby unit. Update Standby unit's status to ForcedOffline as a safety measure. This works as insurance against possible unwanted Auto-Sync updates from Standby to Active unit among other things. Unlike self-only IP configuration, FloatingIP configuration is synced in HA clusters. If you or your managers are paranoid, also disable HA configuration auto-sync feature. Assuming ForcedOffline works as intended, IP address conflict with Floating IP being present in two different VLANs is unlikely to cause any harm. The unit you're working on should not consider itself owner of any Floating IPs while in Standby state and ForcedOffline state. That's the case in my experience but I give no guarantees.

  2. Changes implemented, try to ping some of the back-end servers. Using Bash shell of the Standby unit, specify the tagged VLAN as source interface. I.e ping -I VLAN200 172.16.200.15. If you want to be extra safe, try to ping all of your backend servers that BigIP uses as nodes in any of its pools.

  3. When you're happy with results, release ForcedOffline state and fail over to that unit. Then repeat configuration changes on the unit which was previously active.

If you run into any problems, lmk. I usually respond in 24 hours if question is clear and relevant.

0
Comments on this Answer
Comment made 4 months ago by Shann_P 352

Yeah...the plan is to force the standby offline similar to how we do upgrades, perform the work, then failover...test...test...test..if all goes right, then we can do the same on the other box. Since these are UAT boxes, we're not impacting production so no real fear just nice to hear opinions from the community.

Thanks!

0
Comment made 4 months ago by Hannes Rapp 3850

Good luck :)

0
Comment made 4 months ago by Shann_P 352

Haha...thanks Hannes. I'll wait until after the Holidays obviously. :)

0