IP::source_addr?

remote_addr is context specific, it will be the server on serverside events, and client on clientside events. I believe server_addr is always the server, regardless of context.

so there isn't a command which interrogates the IP packet and pulls the source address or destination address reguardless of context?

 

[IP::server_addr] and [IP::client_addr] are context-insensitive.

 

 

[IP::server_addr] is equivalent to the command [serverside { IP::remote_addr }]

 

[IP::client_addr] is equivalent to the command [clientside { IP::remote_addr }]

 

 

Documented in the wiki here:

 

http://devcentral.f5.com/wiki/default.aspx/iRules/IP__server_addr.html (Click here)

 

http://devcentral.f5.com/wiki/default.aspx/iRules/IP__client_addr.html (Click here)

"Destination address" can mean 2 different things, though...

 

 

client -> virtual server -> real server

 

 

For normal virtual servers, the destination address from the client's perspective is the virtual server address. From within an iRule, that would be the local address on the clientside: [clientside { IP::local_addr }].

 

 

HTH

 

/deb

 

 

 

There isn't any ambiguity, the IP packet has a source and it has a destination, period. I just need to know which command will return those values, without regard to whether or not the traffic is ingressing or egressing the BIGIP, and without regard to whether the traffic is on the clientside or the serverside.

 

 

Does such a command exist?

 

Check your tone....this is a forum full of people volunteering their time to help each other out.

 

 

IP::client_addr will give you the source IP of the packet as it is on the wire before hitting the BigIP on the clientside.

 

 

IP::local_addr will give you the destination IP of the packet as it is on wire before hitting the BigIP on the clientise when called within a clientside event.

 

 

IP::local_addr and IP::remote_addr can mean different things in different contexts and in different configurations, particularly if you are translating addresses.

 

 

First of all, there is plenty of ambiguity. Just because you can't see it, doesn't mean it's not there, period.

 

 

In most load balancing scenarios, since the Virtual Server is using a public IP address and the internal servers are not, the packet gets re-written at the BIG-IP, and gets a new destination address.

 

 

Then take into account the fact that the BIG-IP is a bi-directional proxy, and you've got two possible directions of traffic to account for. Since all you stated was that you wanted the source and destination addresses of "the packet", this could mean a packet in any possible context.

 

 

Now which destination are you looking for? The public address of the incoming Virtual Server? The private address of the internal server? The public address of the client your server is responding to? The "destination" could easily be interpreted as at least these different things. How would one command be able to return the value you're looking for regardless of context? Kind of ambiguous, don't you think?

 

 

Second, if you don't like the answers you're getting from the people here who are, as citizen_elah pointed out, taking their own free time to try and help answer your questions, then I'd suggest checking into the provided documentation.

 

 

 

You can read about each of these commands in the iRules Wiki:

 

 

IP::client_addr - Click here

 

 

IP::local_addr - Click here

 

 

IP::remote_addr - Click here

 

 

If you need clarification beyond what is provided there I would recommend you reference the data you received during your testing of these commands in the scenarios you're interested in, and then ask a more specific question if you're still unclear.

 

 

Colin

Not to beat a dead horse, but...hopefully this will clarify things a bit more:

 

 

The IP::local_addr and IP::remote_addr commands are context-specific, in that the value they return depends on whether they are called from a client-side or server-side event. In the client-side context (as in the CLIENT_ACCEPTED event, for example), remote_addr refers to the far end, or the client IP address). In the server-side context (as in the LB_SELECTED event, for example), remote_addr refers to the node IP address.

 

 

Some of the wiki entries on the IP commands were actually slightly incorrect. The example for IP::server_addr used the command in the clientside event, CLIENT_ACCEPTED. This is not valid as a serverside connection hasn't been established yet. I updated the errors I found on the IP commands.

 

 

[IP::server_addr] is the same as [serverside {IP::remote_addr} ]

 

[IP::client_addr] is the same as [clientside {IP::remote_addr} ].

 

 

I believe that "serverside {}" and "clientside {}" are specific to F5's implementation of TCL and are used to force the evaluation of the command into the specified context as opposed to the current event's context. So if you wanted to get the client IP address while in a serverside event, you could use clientside {IP::remote_addr}. Of course, IP::client_addr is probably a simpler method to get this value.

 

 

Here are a sampling of the major events for an HTTP connection (compiled from these two posts):

 

 

Colin added a good entry on the order of events and their context:

 

Click here

 

 

And here is another post with additional info on the context of events:

 

Click here

 

 

Request events:

 

---------------------------------------------

 

CLIENT_ACCEPTED- clientside - triggered when LTM receives and accepts a connection from a client

 

HTTP_REQUEST- clientside - triggered when an HTTP profiles

 

HTTP_REQUEST_DATA- clientside - triggered if HTTP::collect was called in HTTP_REQUEST

 

LB_SELECTED- clientside - triggered when a node has been selected per the load balancing algorithm

 

SERVER_CONNECTED- serverside - triggered when a connection is established with the node

 

HTTP_REQUEST_SEND- serverside - triggered when LTM sends the HTTP request to the node

 

CLIENT_CLOSED- clientside - triggered when the client connection is closed

 

 

Response events:

 

---------------------------------------------

 

HTTP_RESPONSE- serverside - triggered when LTM receives the HTTP response from the node

 

HTTP_RESPONSE_DATA- serverside - triggered if HTTP::collect was called in HTTP_RESPONSE

 

SERVER_CLOSED- serverside - triggered when the server connection is closed

 

 

Here are a few examples of the IP command results in different events:

 

 

client: 1.1.1.1

 

VIP:2.2.2.2

 

SNAT:3.3.3.3

 

Node:4.4.4.4

 

 

Rule log_IPs_rule :[IP::client_addr]:1.1.1.1

 

Rule log_IPs_rule :[IP::remote_addr]:1.1.1.1

 

Rule log_IPs_rule :[IP::local_addr]:2.2.2.2

 

Rule log_IPs_rule :[IP::server_addr]:invalid in this context (no serverside connection has been established)

 

 

Rule log_IPs_rule :[IP::client_addr]:1.1.1.1

 

Rule log_IPs_rule :[IP::remote_addr]:1.1.1.1

 

Rule log_IPs_rule :[IP::local_addr]:2.2.2.2

 

Rule log_IPs_rule :[IP::server_addr]:invalid in this context (no serverside connection has been established)

 

 

Rule log_IPs_rule :[IP::client_addr]:1.1.1.1

 

Rule log_IPs_rule :[IP::remote_addr]:1.1.1.1

 

Rule log_IPs_rule :[IP::local_addr]:2.2.2.2

 

Rule log_IPs_rule :[IP::server_addr]:invalid in this context (no serverside connection has been established)

 

 

Rule log_IPs_rule :[IP::client_addr]:1.1.1.1

 

Rule log_IPs_rule :[IP::remote_addr]:4.4.4.4

 

Rule log_IPs_rule :[IP::local_addr]:3.3.3.3

 

Rule log_IPs_rule :[IP::server_addr]:4.4.4.4

 

 

Rule log_IPs_rule :[IP::client_addr]:1.1.1.1

 

Rule log_IPs_rule :[IP::remote_addr]:4.4.4.4

 

Rule log_IPs_rule :[IP::local_addr]:3.3.3.3

 

Rule log_IPs_rule :[IP::server_addr]:4.4.4.4

 

 

Rule log_IPs_rule :[IP::client_addr]:1.1.1.1

 

Rule log_IPs_rule :[IP::remote_addr]:4.4.4.4

 

Rule log_IPs_rule :[IP::local_addr]:3.3.3.3

 

Rule log_IPs_rule :[IP::server_addr]:4.4.4.4

 

 

Rule log_IPs_rule :[IP::client_addr]:invalid in this context (no clientside connection has been established)

 

Rule log_IPs_rule :[IP::remote_addr]:4.4.4.4

 

Rule log_IPs_rule :[IP::local_addr]:3.3.3.3

 

Rule log_IPs_rule :[IP::server_addr]:4.4.4.4

 

 

Rule log_IPs_rule :[IP::client_addr]:1.1.1.1

 

Rule log_IPs_rule :[IP::remote_addr]:1.1.1.1

 

Rule log_IPs_rule :[IP::local_addr]:2.2.2.2

 

Rule log_IPs_rule :[IP::server_addr]:invalid in this context (no serverside connection has been established)

 

 

So all in all, if you wanted to make a load balancing decision based on the clien't IP address and the destination IP address (VIP) the client requested, you would want to focus on the clientside context and use IP::client_addr (or IP::remote_addr in clientside events) and IP::local_addr to refer to the VIP they requested.

 

 

--Aaron