Name resolution based on source IP

Hi Garth,

 

I believe so.

 

Take a look at this wiki for NAME resolution commands

 

 

http://devcentral.f5.com/wiki/default.aspx/iRules.NAME

 

 

I hope this helps

 

 

Bhattman

You could take the name lookup functionality from the first Codeshare example below and modify it to do a lookup every X seconds as in the second example:

 

 

http://devcentral.f5.com/wiki/default.aspx/iRules/DestinationSnatUsingDNS.html

 

http://devcentral.f5.com/wiki/default.aspx/iRules/LogEveryXSeconds.html

 

 

You might also want to consider upgrading to 10.1 to use the new RESOLV::lookup command:

 

 

 

http://devcentral.f5.com/wiki/default.aspx/iRules/resolv__lookup

 

 

Like the NAME::lookup command, RESOLV::lookup performs a DNS query, returning the A record for the indicated hostname, or the PTR record for the indicated IP address. The functional difference between the two is that RESOLV::lookup suspends and returns the result inline, whereas NAME::lookup continues and eventually causes NAME_RESOLVED to fire and then you need to call NAME::response to retrieve it.

 

 

 

 

Aaron

Can one use this code share in the following mannor?

 

In regards to using the LTM as a reverse proxy could the iRule be used to determine the destination that gets applied to the pool in a VIP?

 

An example, an internal server does file transfer to an ip that is a VIP on the external LTM. The LTM then is triggered by the iRule mentioned above, does a lookup to resolve the actual destination ip address and sends the traffic outbound.

 

 

Is it fair to say, a static name like update.sun.com would be applied to the iRule mentioned in the code share, when the response is received the destination is then set.

 

 

If this is the case would you have to configure all possible replies as members of a pool? Or would the response from the dns lookup result in being set as the destination?

 

 

 

 

 

You can use the node command to assign an arbitrary IP and port for a load balancing destination. The IP:port does not need to be a pool member.

 

 

I'll see about writing an example with RESOLV::lookup sometime soon with caching of the response(s) in a subtable. Else, you can use the Codeshare examples posted above as a start.

 

 

Aaron

So what Aaron's trying to say is, "No, you don't have to configure all of the possible IPs as a member of a pool". ;)

 

 

Colin