You are right. I double check the traces. 1, 4 byte is checksum. 2, The pcap traces are actually broadcasted to another end, so, there is no flow table. But if I ping first, the end host can authenticate the dst mac, therefore a route can be set up for later coming pcap traces. These are not big issues. Thanks for your reply.
On Wed, Jan 27, 2010 at 1:54 PM, Dan Talayco <[email protected]> wrote: > Hi Guanyao-- > > For (1), I expect that the CRC is counted in the stats on the > switch, but not by pcap. It is a 4 byte "checksum" (actually, > cyclical redundancy check) attached at the L2 layer. This is > a frequent problem with counting bytes on Ethernet switches. > > I'm not sure about (2). Flows expire and it can sometimes be > hard to know what's there when a packet hits the switch. It > could also be something particular about your hardware setup. > What hardware are you using? > > -Dan > > On 1/26/10 1:09 PM, Guanyao Huang wrote: >> >> Hi >> I am running on my own nox module on a topology of 5 switches. I find >> two phenomena: >> >> 1, The byte number of every packet read from statistics is always 4 >> bytes larger than the real size. >> If pcap shows the packet is of size N, ./dpctl dump-flows will show a >> size of N+4. So, if we query statistics, it is also N+4. I want to >> know why there is a difference of 4? >> >> 2, I found that sometimes packets can also get redirected without an >> entry in flow table, or, the switch has a bug to show the correct flow >> table. >> When I tcpreplay from one host to another one, packets get redirected >> (tcpdump shows so), but ./dpctl dump-flows shows no entry. Even if >> the flow is so short to get counted as 0 size (first packet get lost), >> an entry should still exist. >> However, if I ping between these two hosts and then tcpreplay, the >> entries will show correctly. >> Is there any possible reason why flows get redirected but an entry is >> not there? >> >> Many thanks. >> _______________________________________________ >> openflow-discuss mailing list >> [email protected] >> https://mailman.stanford.edu/mailman/listinfo/openflow-discuss > _______________________________________________ nox-dev mailing list [email protected] http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
