Forum Discussion

flitz_29934's avatar
flitz_29934
Icon for Nimbostratus rankNimbostratus
Apr 19, 2011

LTM : virtual server in different subnet than a vlan --> possible

Hi everybody,

 

 

I'm not able to test it in short term so I'm wondering if the following design can work ?

 

 

I would like to know if the Virutal Server (VS) can be set in a subnet not known by the F5, I mean in a subnet not associated to a vlan. To be more clear, see the example below.

 

 

- create a vlan "link" + self-IP : 10.1.1.1/30 associated to the vlan "link". This "link" is used to connect the LTM to a router in the network. So a route to the LTM is possible through this vlan.

 

- create a VS : 192.168.1.1/32. As you can see this VS is not in the vlan previously defined. So it is a single IP only known internal to the LTM.

 

 

Could the design work ? Is it possible or must the VS in a defined vlan ?

 

 

If I configure a static route on the router saying that 192.168.1.1 can be reached by 10.1.1.1, could it work ? Does the LTM automatically consider the VS ?

 

 

Thank you in advance

 

 

best regards

 

config
design
  • David_24361's avatar
    David_24361
    Icon for Nimbostratus rankNimbostratus
    May 04, 2011
    @matt: thanks a lot matt for your reply.

     

     

    what can i summarize from your reply is, i should disable arp to get it to work? and just rely in on routes on the routers pointing to the bigip's floating ip?

     

    and can you explain more about the GARP thing? what is that? sorry i have less knowledge in this bigip thing :)

     

     

     

    thanks a lot matt for your suggestion :)

     

     

    -- dave --
  • L4L7_53191's avatar
    L4L7_53191
    Icon for Nimbostratus rankNimbostratus
    May 04, 2011
    I would disable arp on the VIPs in question, yes. The GARP mechanism is basically this: when BigIP fails over, it'll issue a gratuitous arp on the network. It'll do this for all of the addresses that it owns, with the idea that all of the devices in each vlan will update their tables and forward to the new active device. In large environments this can be a lot of arp traffic. The method described above can help avoid this type of arping, as the BigIP will only arp out for the floating self-ips in the event of a failover.

     

     

    -Matt
  • David_24361's avatar
    David_24361
    Icon for Nimbostratus rankNimbostratus
    May 04, 2011
    okay matt i will try disabling the arp. thanks for your explanation, i will let u know the result :)

     

    meanwhile, i'm still searching on the log files. there are lots o "Inet port exhaustion on 10.3.11.74 to 10.4.0.10:3128 (proto 6)" there
  • L4L7_53191's avatar
    L4L7_53191
    Icon for Nimbostratus rankNimbostratus
    May 04, 2011
    Only forward to the single floating IP address. Whichever unit is active will hold this address (think of it like an HSRP address almost).

     

    -Matt
  • David_24361's avatar
    David_24361
    Icon for Nimbostratus rankNimbostratus
    May 05, 2011
    hmm matt, this also has been a question in my mind. should i forward to floating ip 1 or 2? or just the same?

     

    because the person who config this before me said that the active unit is unit 2, even when the config is active-active
  • L4L7_53191's avatar
    L4L7_53191
    Icon for Nimbostratus rankNimbostratus
    May 05, 2011
    Had to throw in a curve ball, didn't you! That's actually a good question, and I'll ask around internally with a person or two that may have done this. In the meantime, I'd start here: http://support.f5.com/kb/en-us/solutions/public/9000/400/sol9487.html?sr=13185918three

     

     

    Also, I'd step through this on a single system (like a virtual edition) so you can characterize the behaviors step-by-step as you build into your active/active setup.

     

     

    -Matt
  • David_24361's avatar
    David_24361
    Icon for Nimbostratus rankNimbostratus
    May 05, 2011
    haha sorry matt, have been curious about that for a long time :D

     

    am reading the materials in your link, thanks a lot!

     

     

     

    dave