How you define the standar "external" vlan ???

A virtual server may be configured with any ip address that will route to the unit. And will accept inbound connections from any vlan by default (or you can be selective). The virtual ip doesnt even have to be on a real vlan...

 

 

H

 

 

(ha ha.. I almost typed physical vlan. But managed to stop myself)

Oh... External and internal vlans not required... Iirc it used to be in 4.x days... Istr having a few problems if they werent. But v9 and onwards has freed us from all that possibly because of the move to a full proxy model.

 

 

H

Thanks for the clarification.

 

 

So if i have lets say 3 vlans defined:

 

 

each one with different ip addressing.

 

 

and i define a virtual server like this:

 

 

virtual myvirtual {

 

destination 192.168.200.1:any

 

ip protocol tcp

 

pool mypool

 

}

 

 

it will listen on all the vlans for incoming traffic to the 192.168.200.1 even if i don't have an interface on this network on any of the vlans (the self ip of each vlan it's not in the 192.168.200.x network) ? I understand that in order for this 192.168.200.1 ip to work i have to have a route to any of the self ip's of the F5 on any of the vlans.. right ?

 

 

 

Lets say that i have the following vlans with self ip's on each vlan:

 

 

vlan 1 - self ip: 172.18.1.100

 

vlan 2 - self ip: 200.10.10.1

 

vlan 3 - self ip: 10.1.1.100

 

 

and from a client i have the following route:

 

 

route 192.168.200.0/24 10.1.1.100

 

 

this will send the requests for the 192.168.200.1 ip to the 10.1.1.100 self ip o the bigip, and since it will listen on all the vlans for the 192.168.200.1 requests it will be served.

 

 

Same thing if i have a route from another part of the network stating:

 

 

route 192.168.200.0/24 172.18.1.100

 

 

it will be serviced as long as i have a route to the bigip.

 

 

am i right ?

 

 

 

 

 

 

 

 

 

It's not so much listening on the attached vans as willing to accept any traffic ROUTED through the clan interface TO the VS IP address.

 

 

A small distinction, but pretty important when considering your routing infrastructure.

 

 

 

H

Posted By Hamish on 12/16/2011 04:40 AM

 

It's not so much listening on the attached vans as willing to accept any traffic ROUTED through the clan interface TO the VS IP address.

 

 

A small distinction, but pretty important when considering your routing infrastructure.

 

 

 

H

 

Right, so it won't listen on each vlan per se..., but if traffic arrives to that VS IP address, don't matter from what interface it comes from, it will be served.. this works even if the traffic comes on the management interface to the VS IP ?

 

 

Ah no... Switchport interfaces only. The management intface is completely oob from the tmm kernel.

 

 

H

Yeah I've seen some pretty funky setups where there are 32 bit routes all over the network destined for VIPs on an LTM where the VIP doesn't match any directly connected subnet.. Noet pretty, but it still works ;)

 

 

shudder

 

 

I have nightmares about that kind of thing... I like to try & insist on having the LTM inline. And like to keep all the VS's on a dedicated VLAN.

 

 

If I can't get the LTM inline another favourite trick is to drop an interface from the LTM into the pool member VLAN and use policy routing on the pool member to ensure the return traffic goes back via the LTM (No SNAT needed, on Linux it's an iptables rule to mark the traffic from the pool member port and have a route for that mark).

 

 

H

Ah yes it proves for some very "fun" troubleshooting ;)

 

 

In line is nice in a controlled midsized environments.. but I've really come to appreciate SNAT in a larger environment.. Especially when you have to deal with multiple tiers of load balancers.. Being able to load balance anything you can route to is quite the option..