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. I must rewrite the
packets with valid but unused IP and MAC addresses. Do I have that correct
as well? If so, Is it common that I would need to add these fake MAC
addresses to the ARP table of the DUT manually?
And what's the best way to monitor the traffic? 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.
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
