Forum Discussion
CirrusAdding new rSeries Tenant to existing Device Group
We are refreshing our iSeries with rSeries hardware. I have deployed the new Tenant for LTM and associated the proper VLANs and I see them in the new LTM but they are all in the Common Partition. On the existing LTM's the VLANS are in their respective partitions. I have case open with support and they provided guidance on adding the new device to the group to get the configuration synced.
Can I get any suggestions from anyone that has already gone through this exercise? I have a change request in for tonight to add this device to the group and I am concerned with the process.
Thanks,
Joe
4 Replies
mwolfAltocumulus
What I would likely do:
- Restore the rSeries to the factory configuration.
- Manually add the VLAN to the correct partitions.
- Then import all the other configuration.
Refreshing BIG-IP hardware is challenging. Every BIG-IP install is unique.
I never have been able to directly import the configuration from an older BIG-IP hardware platform on to a new BIG-IP hardware platform. There are always issues with the configuration conversion.
Why do you need the VLAN configuration objects to be in child partitions / folders?
My experience is that it's easier to support having all the VLAN in Common. It's my general recommendation is to put all the VLAN in Common.
A child partition of the parent Common partition should be able to use a VLAN object from Common.
I view partitions / folders as a multi tenancy feature. When the BIG-IP device is being used in a single customer environment. Partitions can add unneeded complexity to the configuration. Some of the BIG-IP modules do not fully support partitions.
A good use for partitions is limiting remote user access to the BIG-IP. Pulting the VLAN in Common should not affect user access to the other configuration objects in a partition.
Are you using a route domain for each partition to isolate traffic? In my mind this would be a justifiable reason to place the VLAN in the partition.
Matt
jomedusaYes, we are using route domains in each partition.
I think I found my answer and it was published yesterday:
Moving an inherited VLAN to an alternate partition in a BIG-IP tenant
Please let me know your thoughts.
Joe
ashu2280We are also refreshing our iSeries with rSeries hardware. We are going to add the new devices to the current HA group to get the configuration synced on this weekend. Although we have only common partition. Please share your experience with config sync if already done or going to do it sooner. We already ran into an issue in our earlier attempt described in the article. Make sure you don't have a HA-sync certificate expired already.
https://my.f5.com/manage/s/article/K41500200
- mwolf
F5 nomenclature:
F5 hardware device is not added to an HA group. An HA group is comprised of configuration objects. The state of the objects in a HA group can cause an redundancy active device become the standby device.
You add F5 devices to the Device Service Cluster (DCS). You have to establishing trust with the other devices in DCS. The trust is set up by adding the new device to the device trust.
Once the new device is in the DCS you can add it to a device group. You then can attempt a configuration sync. The sync may fail. The shared configuration may be dependent on device specific configuration that does not exist on the new hardware.
K000150141: Setting up ConfigSync and failover addresses and adding a device to a device trust
How I refresh F5 hardware:
I do not add a new F5 hardware platform to an existing DCS. I create a new DCS that only contains the new hardware. Then migrate the configuration. This what I have done since TMOS was created.
Is F5 now supporting DCS with mixed hardware platforms? My personal best practice has been to only allow the one hardware platform in a DCS. I am biased after having to fix many non-functional DCS.
-Matt
