Forum Discussion

Eric_Frankenfie's avatar
Eric_Frankenfie
Icon for Nimbostratus rankNimbostratus
Aug 10, 2010

Virtual Route Table for VS

Is there a way to create a separate route table for a VS? I have devices that are local to the LTM that need to FTP to a new VS. My existing configuration requires using 10.206.173.1 as the default gateway, however the new VS requires using 10.206.0.1 as the gateway. I cannot modify the routing table because the same devices at the remote location use my existing VS via the default gateway 10.206.173.1. I am using the following iRule to perform the SNAT on the new VS which is working. when CLIENT_ACCEPTED { snat 10.206.0.251 } My issue now is that I have an asymmetrical routing situation. The SNAT (10.206.0.251) is routing out the DG (10.206.173.1) and then the return traffic is coming back on the 10.206.0.0/22 interface. Sources: 10.206.0.135, 10.206.1.50, 10.206.173.129 VS: 10.206.1.245 Pool Members: 10.249.1.59, 10.249.1.100 I attached a diagram that may help...

3 Replies

  • Is there a way to create a separate route table for a VS?

    I have devices that are local to the LTM that need to FTP to a new VS. My existing configuration requires using 10.206.173.1 as the default gateway, however the new VS requires using 10.206.0.1 as the gateway. I cannot modify the routing table because the same devices at the remote location use my existing VS via the default gateway 10.206.173.1.

    I am using the following iRule to perform the SNAT on the new VS which is working.

    when CLIENT_ACCEPTED {

    snat 10.206.0.251

    }

    My issue now is that I have an asymmetrical routing situation. The SNAT (10.206.0.251) is routing out the DG (10.206.173.1) and then the return traffic is coming back on the 10.206.0.0/22 interface.

    Sources: 10.206.0.135, 10.206.1.50, 10.206.173.129 VS: 10.206.1.245 Pool Members: 10.249.1.59, 10.249.1.100

    I attached a diagram that may help...

    Here's the ascii art inline:

                                      10.249.1.0/24
                                          |
                                          |
                                         WAN
                                          |
                                          |
                                     __________
                                    |          |
                                    |          |
                                    |    FW    |
                                    |          |
                                 ___|          |___
                                |   |__________|   |
                                |                  |
                                |                  |
                                |                  |
                                |    __________    |
                                |   |          |   |
                                |   |          |   |
                  10.206.0.0/22 |___|  F5 LTM  |___| 10.206.173.0/24
                                    |          |
                                    |          |
                                    |__________|
    
  • So a client on the 10.206.0.0/22 or 10.206.173.0/24 subnet establishes a connection to an LTM VS on the 10.206.0.0/22 subnet. The pool members are not on a local LTM subnet. They're on a subnet which is routed through the firewall. Connections to the FTP server pool are SNATed using a 10.206.0.0/22 source IP. However, the outbound connection to the non-local FTP servers goes out the 10.206.173.0/24 subnet's VLAN and come back in over the 10.206.0.0/22 subnet's VLAN from the firewall.

     

     

    Is that an accurate summary of the issue? What are the actual symptoms of the issue? Do the FTP connections work, but you get alerts on the firewall? Or is there a layer 3 issue with the IP addresses?

     

     

    Could you change the SNAT IP to one on the 10.206.173.0/24 subnet?

     

     

    You cannot configure routing specific to a load balancing virtual server. So there hopefully will be another solution to the issue.

     

     

    Aaron
  • The summary is correct. The 10.206.173.0/24 subnet is going away and no additional addresses on that subnet will be assigned. Looks like I will need to setup 32-bit routes for the pool members.