In the end, we came with a very simple solution (no iptables/ip needed): >From DEVEL_SRV we ran: # ifconfig eth1 PROD_SRV_IP netmask PROD_SRV_NETMASK promisc -arp hw ether PROD_SRV_HWADDR up That is it ! All traffic targeted to PROD_SRV_IP is now being accepted by our mirrored eth1. Since this is an interface aimed to tests only, no matter what's being accepted. Thanks Jan and Grant for your suggestions and explanations. That worths a lot! regards, Mateus Caruccio On Thu, Oct 21, 2010 at 1:02 PM, Grant Taylor <gtaylor@xxxxxxxxxxxxxxxxx> wrote: > On 10/20/10 16:58, Mateus Caruccio wrote: >> >> Thanks to this damn GUI world, probably this ascii-art is ruined. > > Nope. Using text mode email and a fixed width font (my default) it came > through just fine. ;-) > >> All traffic is UDP port 2077 only. I can not change any config on >> PROD_SRV. > > Ok... UDP will take care of the protocol handshake issue that you have with > TCP. That means that your dev server can truly receive the request and not > have borked connections. > >> Our DEVEL_SRV should receive exactly the same packet PROD_SRV receives, >> but with destination address modified so it can reach our userspace >> application. > > On the surface I agree. Just under the surface I wonder if you really need > to alter the destination IP or not. (More in a bit.) > >> I've tried to "DNAT" it, but without success: > > Rather than DNAT, why not try simple routing. (More in a bit.) > >> From DEVEL_SRV point of view, it receives a legitime request. > > I assume that you are looking at the traffic (via TCPDump or something like > it) and deciding that it's legitimate b/c you haven't gotten traffic to make > it in to the service yet. > >> I've setup a DROP rule so responses do not interfer on client's requests. > > I'd wonder if you really want to DROP the traffic or redirect the replies so > that you could test (analyze) that as well. (More in a bit.) > >> If I'm not clear, please fell free to ask anything. > > Na, I think I understand what you are trying to do. - Set up something so > that you can test dev code under (possibly a portion of) live traffic load. > > For giggles I'd try having the dev server and prod server be in different > subnets. That will allow you to bind the prod server's IP to a different > nic (dummy or something like it) and enable routing. That way when the > traffic comes in to the eth0 interface on the dev box, it would be routed to > the proper nic where your software is bound to the real IP. There by doing > away with any hacks needed to get the traffic in to your service. > > As a bonus, you should have a better emulation of the service between the > prod and dev servers, there by making it a better test and allowing service > config migration between the two boxen. > > Just something that I'd try. > > As far as the DROP rule, I'd rather set the default gateway on the dev box > so that it would go out a different nic (physical or virtual) such that your > service could send reply packets that could then be analyzed elsewhere. > >> Thanks for helping, > > n/p > > Good luck. > > Please provide follow up and let us know what worked for you. > > > > Grant. . . . > -- > To unsubscribe from this list: send the line "unsubscribe netfilter" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- # ################ VOTE NULO ################ # Mateus de Oliveira Caruccio <mateus at caruccio dot com> # Old programmers never die. They just branch to another namespace -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
