Further searching turned up a post on the Quagga-users list which suggested TTL might be the culprit.
I bounce the interface using ifconfig to recreate the interface route in the routing table, then throw tcpdump extra options to monitor MTU, as well as running route -nv monitor in the background:- The cisco doesn't respond: 23:17:16.197493 0:4:76:5e:ec:7d 0:2:b3:8d:23:e4 0800 122: saboteur > bms-gre-eth0: gre 172.16.1.2 > 172.16.1.1: icmp: echo request (ttl 64, id 30027, len 84) (ttl 30, id 30729, len 108, bad cksum 0!) There is no RTM_MISS message recorded by route monitor. If I try in the opposite direction:- 23:18:05.184120 0:50:54:80:6:98 0:4:76:5e:ec:7d 0800 138: bms-gre-eth0 > saboteur: gre 172.16.1.1 > 172.16.1.2: icmp: echo request (ttl 255, id 39, len 100) (ttl 255, id 37, len 124) 23:18:05.184241 0:4:76:5e:ec:7d 0:2:b3:8d:23:e4 0800 138: saboteur > bms-gre-eth0: gre 172.16.1.2 > 172.16.1.1: icmp: echo reply (ttl 64, id 18208, len 100) (ttl 30, id 49163, len 124, bad cksum 0!) The Cisco's ICMP echo request is being correctly de-encapsulated by FreeBSD, It hits icmp_reflect() in the kernel, hence the correctly generated echo reply message. I can't find any evidence of an RTM_MISS, though - and the above capture is on a physical interface. I could try inserting a dumb non-switching hub and inspecting packet capture from another machine on the same segment as the Cisco to be sure the packet really is hitting the Cisco, but given that the link-layer addresses are correct after if_gre processing, this doesn't seem to be the problem. One thing leaps out at me here though - 122 vs 138. Ciscos send 100-byte pings by default. Casual inspection of the headers suggests that they are the same length. The payloads appear to begin at the same offset in the frame. Still scratching my head. BMS _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
