Hi Sean, On Oct 29, 2010, at 2:10 PM, [email protected] wrote:
> Here are the outputs of print_10gbe_core_details and tcpdump. It looks to > me that the ARP table is configured properly. Do you still see something > funny in the received packet? > > ARP Table: > IP: 10. 0. 0. 20: MAC: 02 02 0A 00 00 14 > IP: 10. 0. 0. 30: MAC: FF FF FF FF FF FF The ROACH's ARP table has an entry for itself (10.0.0.20), but it does not have a valid MAC address for the PC (10.0.0.30), which leads to... > [r...@arcons controlScripts]# /usr/sbin/tcpdump -xx -i eth1 -c 1 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes > 13:53:27.263857 IP 10.0.0.20.60000 > 10.0.0.30.60000: UDP, length 4104 > 0x0000: ffff ffff ffff 0202 0a00 0014 0800 4500 > 0x0010: 1024 0000 4000 ff11 5797 0a00 0014 0a00 > 0x0020: 001e ea60 ea60 1010 0000 0000 0000 0000 > 0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 > 0x0050: 0000 0000 0000 0000 0000 0000 0000 0000 This packet still has broadcast Ethernet address and unicast IP address. It seems like for some reason that ROACH is not sending the PC an ARP request OR the firewall is blocking the ARP request OR the firewall is blocking the ARP response OR the ARP response is not being properly addressed/routed to the right egress interface. If you ping the the ROACH from the PC (e.g. run "ping 10.0.0.20" on the PC), does it get replies? What does "arp -a" show afterwards? Hope this helps, Dave
