This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[atlas] NAT conntrack invalid ICMP(v4) type 11 code 0 packets dropped by edge router
- Previous message (by thread): [atlas] NAT conntrack invalid ICMP(v4) type 11 code 0 packets dropped by edge router
- Next message (by thread): [atlas] Short and immediate report from the RIPE Atlas hackathon
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Philip Homburg
philip.homburg at ripe.net
Mon Mar 30 17:23:18 CEST 2015
On 2015/03/29 9:33 , Gary Gapinski wrote: > I recently observed a (ICMP type 11 code 0) packet for which the > reported rejection was for ctr-nue13.atlas.ripe.net, for which target > there are several active measurements on the probe. An extract of recent > logs for the related address yielded > > Mar 27 13:43:18 edge kernel: [WAN_LOCAL-2-D]IN=eth0 OUT= MAC=24:a4:3c:05:20:a3:00:01:5c:45:9a:41:08:00 SRC=4.68.111.17 DST=76.188.130.183 LEN=96 TOS=0x00 PREC=0x00 TTL=58 ID=3881 PROTO=ICMP TYPE=11 CODE=0 [SRC=76.188.130.183 DST=78.46.48.134 LEN=68 TOS=0x00 PREC=0x00 TTL=1 ID=57079 PROTO=UDP SPT=20494 DPT=33441 LEN=48 ] > > Is this simply an unfortunate consequence of probe measurement artifacts > arriving outside of the 30-second conntrack window, or is my local > configuration adversely affecting such measurements? It seems to affect hop 9 of the traceroute to ctr-nue13. It is hard to say if the packet was really 30 seconds late or not. Philip
- Previous message (by thread): [atlas] NAT conntrack invalid ICMP(v4) type 11 code 0 packets dropped by edge router
- Next message (by thread): [atlas] Short and immediate report from the RIPE Atlas hackathon
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]