Forum Discussion
L4L7_53191
May 04, 2011Nimbostratus
This is a long thread and I've not read it all. But if I understood the original use case correctly, you can do this.
Moreover, it can be a super powerful design pattern depending upon your goals. I wouldn't go so far as to say that it should be a best practice, but it's an absolutely killer solution for certain environments, and some large shops have things setup this way.
So here's the short story: A VIP address doesn't really have to be 'owned' by the BigIP; that is, it doesn't have to be mapped to the same network(s) as the self IPs. Moreover, the VIP address space need not exist anywhere but on the BigIP itself. For example (and this is JUST an example) think about it like this:
A Self IP lives on 192.168.1.x/24, and this is a real network with other devices. They arp, send packets, etc. like a network device should. But let's say you want to carve out some new address space for your virtual servers:
---> Virtual server space "A" lives on some other network totally, say 10.1.1.x/24 <== This is 'fake', i.e. it doesn't really exist anywhere on your network.
---> Another virtual server space, "B" lives on 10.2.2.x/24 <== ditto.
So here's the trick: 10.1.1.x and 10.2.2.x only live on the BigIP, and arp is disabled. To get it to work, just forward traffic to this address space by pointing your routes to the floating self IP on 192.168.1.x. The BigIP will handle the rest from there and your flows will work.
There's a bit more to it than this, but the short answer is that you can absolutely have made-up virtual server addresses on the BigIP and forward traffic to it at L3. One benefit of doing this is that you're now going to issue GARPs on only the 'real' networks - that is, the self-ip vlans. This can help fail over scenarios in some situations, among other things...
Good luck!
-Matt