On 02/15/2011 11:51 AM, Joseph Sinclair wrote: > I would assume that he's talking about broad testing within a local network, rather than testing against localhost directly. > I often do this because I can insert firewalls, routers, etc... as/where desired to emulate probable scenarios. It's particularly helpful to emulate 4in6 or 6in4 connections when using external providers that do not provide sufficient IPv6 support. > > It's just easier to create a hostfile entry on the test client(s) than to create or modify public DNS (sometimes that's not even possible). This is particularly true when the service you're testing is already live and you need to black-box test a component of an interconnected SOA system. Yes, I understand that. My point is to question if this is wise at all. I have seen far too many times where a computer sends traffic out to its public address, and still does not respond the same way it does in production. The reason is one NIC. You are routing from yourself to yourself, and it will get turned around at the NIC. I have worked R&D for the past 4 1/2 years, and trust me, this happens far more than most people think. You would be better off bouncing off another computer, that redirects the traffic truly from another machine. Example 1: Use NX Free edition to get a desktop on another computer, and then run your browser on that. Example 2: Use a *Nix machine for which you have root access to create a forwarded port (ssh -R 80:mypublicip:80 root@server). This makes the IP address on the foreign machine tunnel back to yourself, and cuts out optimizations at both the NIC and the switch and gives you a true experience as to what your clients will see. Example 3: Have a second NIC. Force traffic out through NIC-1 to the public IP on NIC-2. The switch and NIC have no idea that the machine sending and responding are one in the same. Therefore, once again, you can eliminate any ability of the devices to optimize. As I said in my original comment. The goal is to avoid the "It works on my machine" situation. I hope my comments made more sense this time. Kevin --------------------------------------------------- PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us To subscribe, unsubscribe, or to change your mail settings: http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss