Disabling one measurement on my probe...
Hi all, Due to much stupidity my probe lives behind 2 NATs (don't ask). Anyway, one of the NATs / firewalls is suddenly throwing hissyfits and logging a bunch of messages like: [00005] 2013-08-27 17:33:29 [Root]system-critical-00435: ICMP fragment! From 78.46.37.134 to 192.168.15.207, proto 1 (zone Untrust, int ethernet3). Occurred 2 times. I can see the Measurement IDs that are causing this (1019675, 1019728), but I have two questions: 1: is there a way to disable specific measurements from a specific probe and 2: did anything change recently with the "Ping" measurement, like the packet size for example? I *did* spend some time reading the list archives and documentation, but was not able to find an answer. W P.S: And yes, I will sometime remove the NATs, but cannot until there is another ISP available -- I live in a 3rd world country where any broadened is a luxury, and multiple providers is more than one can reasonably expect… -- "When it comes to glittering objects, wizards have all the taste and self-control of a deranged magpie." -- Terry Pratchett
Hi Warren, On 8/27/13 11:49 PM, Warren Kumari wrote:
Hi all,
Due to much stupidity my probe lives behind 2 NATs (don't ask). Anyway, one of the NATs / firewalls is suddenly throwing hissyfits and logging a bunch of messages like: [00005] 2013-08-27 17:33:29 [Root]system-critical-00435: ICMP fragment! From 78.46.37.134 to 192.168.15.207, proto 1 (zone Untrust, int ethernet3). Occurred 2 times.
I can see the Measurement IDs that are causing this (1019675, 1019728), but I have two questions: 1: is there a way to disable specific measurements from a specific probe and No there is not an easy way yet, although we are working on it and users will be able to add/remove probes. Anyhow, from what I see these two UDMs are already stopped so you shouldn't have any more cases with these two. 2: did anything change recently with the "Ping" measurement, like the packet size for example? Among other options[1] user can change the packet size and from what I see it's 48bytes for the first one 1485 for the second.
I *did* spend some time reading the list archives and documentation, but was not able to find an answer.
W P.S: And yes, I will sometime remove the NATs, but cannot until there is another ISP available -- I live in a 3rd world country where any broadened is a luxury, and multiple providers is more than one can reasonably expect…
-- "When it comes to glittering objects, wizards have all the taste and self-control of a deranged magpie." -- Terry Pratchett
Regards, Andreas [*] You can see the different options users can set for the ping UDMs if you scroll a bit down on this page https://atlas.ripe.net/doc/udm#creating-a-new-measurement
Hi Warren,
Due to much stupidity my probe lives behind 2 NATs (don't ask). Anyway, one of the NATs / firewalls is suddenly throwing hissyfits and logging a bunch of messages like: [00005] 2013-08-27 17:33:29 [Root]system-critical-00435: ICMP fragment! From 78.46.37.134 to 192.168.15.207, proto 1 (zone Untrust, int ethernet3). Occurred 2 times.
I can see the Measurement IDs that are causing this (1019675, 1019728), but I have two questions: 1: is there a way to disable specific measurements from a specific probe and No there is not an easy way yet, although we are working on it and users will be able to add/remove probes. Anyhow, from what I see these two UDMs are already stopped so you shouldn't have any more cases with these two. 2: did anything change recently with the "Ping" measurement, like the packet size for example? Among other options[1] user can change the packet size and from what I see it's 48bytes for the first one 1485 for the second.
I'm the culprit here. I did start a couple of UDM measurements with large packet-sizes to try and provide some data from what RIPE Atlas sees when sending fragmented packets (this is a discussion on the NANOG-list currently), and apparently your probe is one of the cases it caught (though the log message doesn't specify if it blocked the fragments or not). Emile Aben RIPE NCC
I *did* spend some time reading the list archives and documentation, but was not able to find an answer.
W P.S: And yes, I will sometime remove the NATs, but cannot until there is another ISP available -- I live in a 3rd world country where any broadened is a luxury, and multiple providers is more than one can reasonably expect…
-- "When it comes to glittering objects, wizards have all the taste and self-control of a deranged magpie." -- Terry Pratchett
Regards, Andreas
[*] You can see the different options users can set for the ping UDMs if you scroll a bit down on this page https://atlas.ripe.net/doc/udm#creating-a-new-measurement
On Aug 28, 2013, at 3:00 AM, Emile Aben <emile.aben@ripe.net> wrote:
Hi Warren,
Due to much stupidity my probe lives behind 2 NATs (don't ask). Anyway, one of the NATs / firewalls is suddenly throwing hissyfits and logging a bunch of messages like: [00005] 2013-08-27 17:33:29 [Root]system-critical-00435: ICMP fragment! From 78.46.37.134 to 192.168.15.207, proto 1 (zone Untrust, int ethernet3). Occurred 2 times.
I can see the Measurement IDs that are causing this (1019675, 1019728), but I have two questions: 1: is there a way to disable specific measurements from a specific probe and No there is not an easy way yet, although we are working on it and users will be able to add/remove probes. Anyhow, from what I see these two UDMs are already stopped so you shouldn't have any more cases with these two. 2: did anything change recently with the "Ping" measurement, like the packet size for example? Among other options[1] user can change the packet size and from what I see it's 48bytes for the first one 1485 for the second.
I'm the culprit here.
No worries.
I did start a couple of UDM measurements with large packet-sizes to try and provide some data from what RIPE Atlas sees when sending fragmented packets (this is a discussion on the NANOG-list currently), and apparently your probe is one of the cases it caught (though the log message doesn't specify if it blocked the fragments or not).
I guess I make a good test case then :-) I get a log email for each of the failures, I can easily tell procmail to just send those mails to /dev/null (I'm not at that house, so I cannot tell the firewall to not log) This is interesting / useful research, please don't let my bizarre home network deter you from running tests, etc. I was just interested… W
Emile Aben RIPE NCC
I *did* spend some time reading the list archives and documentation, but was not able to find an answer.
W P.S: And yes, I will sometime remove the NATs, but cannot until there is another ISP available -- I live in a 3rd world country where any broadened is a luxury, and multiple providers is more than one can reasonably expect…
-- "When it comes to glittering objects, wizards have all the taste and self-control of a deranged magpie." -- Terry Pratchett
Regards, Andreas
[*] You can see the different options users can set for the ping UDMs if you scroll a bit down on this page https://atlas.ripe.net/doc/udm#creating-a-new-measurement
-- "Working the ICANN process is like being nibbled to death by ducks, it takes forever, it doesn't make sense, and in the end we're still dead in the water." -- Tom Galvin, VeriSign's vice president for government relations.
On Tue, Aug 27, 2013 at 05:49:00PM -0400, Warren Kumari <warren@kumari.net> wrote a message of 34 lines which said:
Due to much stupidity my probe lives behind 2 NATs (don't ask).
Actually, I think it is a very good idea to have probes in many various setups, so we can test many cases, not just the "properly managed and IETF-sanctioned newtwork". Do note that future (currently in state AUTH48) RFC 7021 "Assessing the Impact of Carrier-Grade NAT on Network Applications" describes exactly such tests on CGN/dual-NAT/NAT444/whateveryoucallit.
participants (4)
-
Andreas Strikos -
Emile Aben -
Stephane Bortzmeyer -
Warren Kumari