On Thu, Sep 20, 2012 at 4:53 PM, Richard Blalock <yawningdo...@gmail.com> wrote: > Yes, that's very helpful thank you. > > So in this setup, I cannot use the actual IP and MAC addresses of the > computer running tcpreplay because the actual TCP/IP stack will interfere > with the "dummy" stack that tcpreplay has set up.
Yeah, if you are replaying the traffic on the same device that captured it you'll want to change the IP addresses. Depending on the protocols involved, you might get away with not rewriting the MAC's. Another option is to use IPTables on the computer running tcpreplay to drop the traffic on the inbound side that tcpreplay sends. > I must rewrite the packets > with valid but unused IP and MAC addresses. Do I have that correct as well? Valid enough for your DUT to accept them as valid. > If so, Is it common that I would need to add these fake MAC addresses to the > ARP table of the DUT manually? Depends on the DUT. Transparent devices generally aren't a problem. Routers can be more challenging because you'll need to rewrite the destination MAC address to be that of the router's interfaces so that it will see the traffic. > > And what's the best way to monitor the traffic? I generally would open up two terminals and run tcpdump on each interface separately to see what's happening. > The DUT is a Juniper SRX > 1400. I'm not asking you to be a Junos expert, but I don't think Junos has a > Wireshark-ish method of looking at traffic. My Juniper rep has yet to reply > to my support request. Been a long time since I've dealt with Juniper (used to work there, but before the SRX platform existed). They should have at least a tcpdump like command, and quite possibly a way to save/export a pcap file that you could load up in wireshark. Good luck! > > Thanks a lot. > > Rick > > On Thu, Sep 20, 2012 at 10:56 AM, Aaron Turner <synfina...@gmail.com> wrote: >> >> That is correct. Tcpreplay reports that the packets were successfully >> *sent* out on the wire. It never "listens" to see that they are >> successfully delivered to the other NIC. >> >> You mentioned the word "socket" so a bit more detail is perhaps useful: >> >> Normal networking programming uses TCP or UDP sockets (SOCK_STREAM or >> SOCK_DGRAM in C speak). Your web server/browser for example. This is >> convenient because the kernel handles all the TCP/IP stuff for you >> automatically. You don't have to worry about IP fragmentation, TCP >> stream re-assembly, re-transmissions, etc. However, that means you >> have very limited control regarding exactly what the packets look >> like. Some things like TCP sequence numbers for example you have no >> control over at all. >> >> Tcpreplay uses raw sockets (PF_PACKET under Linux for example) to send >> traffic. The downside is you have to do everything yourself- the >> kernel takes a blob of raw bytes and injects them onto the wire. The >> upside of course is you have compete control over what the packets >> look like. This is good when you want to re-create the exact same >> traffic on the network as before. The downside is that once you start >> manipulating the traffic on the wire (say a network firewall dropping >> traffic) things can get all weird because things can get out of sync. >> >> For example: >> >> Take your typical TCP 3 way handshake: >> >> Client ---- Syn ---> Server >> >> Client <--- Syn/Ack Server >> >> Client ---- Ack ----> Server >> >> Tcpreplay can do that all day without problem. However once you >> insert a firewall between the client and server which is dropping >> traffic on say TCP/80 then that initial Syn packet from the client >> will be dropped and won't reach the server. Under normal >> circumstances, the server would never send the Syn/Ack then because it >> didn't receive the Syn. However, Tcpreplay doesn't know about that >> firewall dropping the Syn and sends the Syn/Ack anyways. >> >> Hopefully that helps. >> >> Regards, >> Aaron >> >> On Mon, Sep 17, 2012 at 3:34 PM, Richard Blalock <yawningdo...@gmail.com> >> wrote: >> > The FAQ contains the following question and subsequent answer which I >> > have >> > found confusing. >> >> >> >> Can I send packets on the same computer running tcpreplay? >> >> >> >> Generally speaking no. When tcpreplay sends packets, it injects them >> >> between the TCP/IP stack of the system and the device driver of the >> >> network >> >> card. The result is the TCP/IP stack system running tcpreplay never >> >> sees the >> >> packets. >> >> >> >> One suggestion that has been made is using something like VMWare, >> >> Parallels or Xen. Running tcpreplay in the virtual machine (guest) >> >> would >> >> allow packets to be seen by the host operating system. >> > >> > >> > So let's say I'm testing a firewall and I have one NIC connected to the >> > outside of the firewall and one NIC connected to the inside. If the >> > firewall >> > blocks all the traffic that was previously allowed (as when the .pcap >> > file >> > was created) then I will need to examine the firewall traffic logs to >> > verify >> > this. Tcpreplay will indicate all packets successful because all it does >> > is >> > put them on the wire, and has no knowledge as to whether the socket was >> > actually working. Do I have that right? Feel free to be verbose, I'm >> > trying >> > to learn all I can. >> > >> > The reason I ask is because I have done this very thing and have been >> > confused when tcpreplay says all packets on both NICs are successful, >> > when >> > in fact there is no way they actually made it through the firewall. >> >> >> -- >> Aaron Turner >> http://synfin.net/ Twitter: @synfinatic >> http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & >> Windows >> Those who would give up essential Liberty, to purchase a little temporary >> Safety, deserve neither Liberty nor Safety. >> -- Benjamin Franklin >> "carpe diem quam minimum credula postero" >> >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://ad.doubleclick.net/clk;258768047;13503038;j? >> http://info.appdynamics.com/FreeJavaPerformanceDownload.html >> _______________________________________________ >> Tcpreplay-users mailing list >> Tcpreplay-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/tcpreplay-users >> Support Information: http://tcpreplay.synfin.net/trac/wiki/Support > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://ad.doubleclick.net/clk;258768047;13503038;j? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > _______________________________________________ > Tcpreplay-users mailing list > Tcpreplay-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/tcpreplay-users > Support Information: http://tcpreplay.synfin.net/trac/wiki/Support -- Aaron Turner http://synfin.net/ Twitter: @synfinatic http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin "carpe diem quam minimum credula postero" ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ Tcpreplay-users mailing list Tcpreplay-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tcpreplay-users Support Information: http://tcpreplay.synfin.net/trac/wiki/Support
