Moving from viprion 2250 to f5os r10600 The current viprion is running with multiple partitions. Each partition has different route domain. I'd like to know if it is possible to create only one tenant and still be using one f5 devided into partitions, just like what we're doing today? Or must we create a tenant for each partition?
Also we have OSPF and EBGP configuration in imish. How should we move these configuration to the F5OS rseries device? Is it in the f5os level or per tenant? Is there a document for this?
You can still use exactly the same config if you wish ie partitions/RDs on a single tenant. Present all of the VLANs to the tenant and allocate them to the RDs as before.
It is your choice how to migrate these - you can do it all together, as a 'big bang' which is fast and easy but risky, or move them one RD at a time, or even one application at a time. It all depends on your own risk appetite. In PS we do these migrations all the time, I always make sure i have ways to check whether things are working, the current status, etc. And get buy-in from the rest of the business about how to migrate ie tell them about the risk, get them to decide and/or agree. Expect minor issues such as monitors, firewall rules etc
You can still use exactly the same config if you wish ie partitions/RDs on a single tenant. Present all of the VLANs to the tenant and allocate them to the RDs as before.
It is your choice how to migrate these - you can do it all together, as a 'big bang' which is fast and easy but risky, or move them one RD at a time, or even one application at a time. It all depends on your own risk appetite. In PS we do these migrations all the time, I always make sure i have ways to check whether things are working, the current status, etc. And get buy-in from the rest of the business about how to migrate ie tell them about the risk, get them to decide and/or agree. Expect minor issues such as monitors, firewall rules etc
correct - keep the BIG-IP config as-is - you can migrate with UCS. If you are migrating with big-bang then you do the config migration a few days before, then for the traffic migration you disconnect the old devices and connect the new ones. Check that everything comes up at the network level ie routing etc and then check individual services.
Let me clarify this further - on rSeries the layer 1/2 config ie interfaces, trunks and VLANs are done on the platform, everything else is done on the tenant. So you will have to manually setup interfaces, trunks and VLANs on the platform, allocate them to the tenant and modify the tenant UCS before you load it, but otherwise everything remains the same.
You can use the Journeys application to help with the migration of config
Although, me myself, I prefer the old fashion way, to do it maually, and not using external tools, especially when it comes to this complicated design. (the design it self are going to changed and thats a different story), but I will give the tool a try.
Is it OK if I ask you to give this discussion a quick look?
I'm afraid i haven't come across that scenario - the question is whether Fortigate can do remote LACP trunks across peer devices. I doubt it, quite honestly - that is more of a switch function.
However, you may find that you can add the standby fortigate to the existing LACP trunk and all of the standby links go down ie you only have links up to the active Fortigate. In which case, the BIG-IP will only send traffic across the active links to the active Fortigate which is fine. If the active firewall goes down, its links go down and the previously-active links come up.
You'd have to test this out though - I suspect it will not be the case. More likely is that LACP is up to both active and standby but traffic which is sent to standby is blackholed. In which case you need an intermediate switch which can do remote LACP trunks ie the same trunk across two switches.
