Forum Discussion

Jon's avatar
Jon
Icon for Nimbostratus rankNimbostratus
Jun 23, 2016

F5 As a Router

I have a pair of BIG IPs in an active/standby configuration running LTM 10.2.4. We have several LDAP servers configured on an internal VLAN as pool members and are doing basic load balancing to these servers through the F5s. In addition to the basic load balancing for these systems, We also have a number of external systems that need to reach the LDAP servers directly without being load balanced. For this, we've configured Virtual IPs on the LDAP servers on the internal VLAN which are used for this "direct" access. We have static routes for these networks setup in our LAN that point to a floating IP on an external VLAN on the F5 as the next hop. The F5 then forwards/routes this traffic directly to the VIPs on the LDAP pool members preserving the original client source address. The return traffic gets sent from the VIP on the LDAP servers to their default gateway (which is on the F5) and the F5 routes it back out the external VLAN to the client.

 

This setup has worked fine for years. We recently upgraded our LAN infrastructure to Cisco ACI and have moved all of our servers, as well as the F5s to the ACI fabric. When we migrated the subnet gateways for the external F5 VLANs off of our old Catalyst routers to ACI, we started seeing issues with this LDAP routing. All of a sudden some systems were not able to reach the VIPs on the LDAP servers, even though we had configured the same static routes for these networks in ACI. It seemed as if the F5 was not forwarding this traffic for whatever reason. To resolve the issue, we had to source a ping from the VIPs to an external system in the environment and then all of a sudden the F5 would start routing again and the server VIPs became reachable.

 

I don't understand much about how the F5 does this type of routing/forwarding. I have read SOL articles on Forwarding IP Virtual Servers as well as Forwarding Layer 2 Virtual Servers, but keep in mind we are not using either of these techniques. We're just pointing traffic to external floating IPs on the F5 and relying on the F5 to route the traffic to the back-end pool member. Perhaps using a forwarding virtual server is the better approach? If not, it would be good to understand a little bit more about how this routing works and why moving to Cisco ACI could caused things to break.

 

Any feedback on how this type of F5 routing/forwarding works and/or pointing me to some good resources would be extremely helpful! Thanks!

 

Jon

 

application delivery
BIG-IP
LTM

2 Replies

Sort By
  • IanB's avatar
    IanB
    Icon for Employee rankEmployee
    Jun 28, 2016

    It sounds like you either have a duplicate IP problem, or a firewall that only allows return traffic once it has seen traffic in the other direction.

     

    As far as routing goes, it's fundamentally not a router. What happens when you send a packet to the LTM is that it tries to match it to a listener. This could be a SNAT, or a virtual server. A virtual server can be set up to listen to either a host (/32) or network address, and to listen on all vlans, or specific vlans, so even if the destination matches, it won't necessarily match the virtual if that virtual isn't listening on the incoming vlan.

     

    If ip-forward is enabled on the virtual (in the GUI, this is virtual server type ip forwarding), or in fact, even if you have a standard virtual with no pool members, and a directly connected destination.... the LTM will proxy the packet out the other side. Optionally, the LTM can change the source address so that the destination sees the source as local, and sends the reply back to the LTM.

     

    All traffic through the LTM is proxied at layer 3/4. It doesn't route anything as a router would do, though you create a close simulation by creating a virtual server that is configured not to change the source address or port.

     

  • Payal_S's avatar
    Payal_S
    Ret. Employee
    Aug 17, 2020

    The F5 and Cisco APIC integration based on the device package and iWorkflow is End Of Life.

    The latest integration is based on the Cisco AppCenter named ‘F5 ACI ServiceCenter’.

     

    Click here to view the Cisco ACI and F5 BIG-IP design guide which discusses the following topics:

    • SNAT or no SNAT
    • BIG-IP redundancy
    • Multi-tenancy
    • Tighter integration using F5 ACI ServiceCenter

     

    Visit https://devcentral.f5.com/s/articles/F5-and-Cisco-ACI-Essentials-Design-guide-for-a-single-POD-APIC-cluster to learn how to access a lab for hands on experience using the F5 ACI ServiceCenter

     

    https://f5.com/cisco for updated information on the integration.