reason for different tcpdump results at node and node-bridge interface

23 views
Skip to first unread message

shin...@gmail.com

unread,
Jan 1, 2015, 2:21:42 PM1/1/15
to ns-3-...@googlegroups.com
Hello all,

My aim is to build to a switch with a simple scheduler.
I started with a simple bridge example (to have an idea on how some of the functions can be reused).
If this is not the right approach to buid a switch, I am open to your inputs.

I tried to build a simple network that has 3 nodes connected to a bridge (please find attached the source code). One of them is a client and two are servers.
I push one UDP packet from one of the client to the server. I print some crap, please avoid it.

I use both ascii trace and pcap to dump the activities.

I noticed that the pcap dump at the nodes is similar to what I expected.
But I notice something different at the bridge interface (as I expected it to be similar to what I see in the node).
Could some one explain me why there is this difference. May be I am missing something.

tcpdump at the client node.

boffin:ns-3-dev$ tcpdump -nn -tt -r v2-0-0.pcap
reading from file v2-0-0.pcap, link-type EN10MB (Ethernet)
2.007000 ARP, Request who-has 10.1.1.2 (ff:ff:ff:ff:ff:ff) tell 10.1.1.1, length 50
2.015410 ARP, Reply 10.1.1.2 is-at 00:00:00:00:00:03, length 50
2.015410 IP 10.1.1.1.49153 > 10.1.1.2.9: UDP, length 100
2.024083 ARP, Request who-has 10.1.1.1 (ff:ff:ff:ff:ff:ff) tell 10.1.1.2, length 50
2.024083 ARP, Reply 10.1.1.1 is-at 00:00:00:00:00:01, length 50
2.032757 IP 10.1.1.2.9 > 10.1.1.1.49153: UDP, length 100

tcpdump at the client bridge interface.

boffin:ns-3-dev$ tcpdump -nn -tt -r v2-3-0.pcap
reading from file v2-3-0.pcap, link-type EN10MB (Ethernet)
2.009102 ARP, Request who-has 10.1.1.2 (ff:ff:ff:ff:ff:ff) tell 10.1.1.1, length 50
2.013308 ARP, Reply 10.1.1.2 is-at 00:00:00:00:00:03, length 50
2.021981 ARP, Request who-has 10.1.1.1 (ff:ff:ff:ff:ff:ff) tell 10.1.1.2, length 50
2.030523 IP 10.1.1.2.9 > 10.1.1.1.49153: UDP, length 100


thanks,
shin

 
 
 
v2_tcp.cc
Reply all
Reply to author
Forward
0 new messages