I haven't seen all of the messages posted in nznog on this subject so forgive me if I go over some ground that has been covered already. I'd like to make it quite clear to all NZ operators reading this that neither Telstra Saturn or any of its operating companies have any rules in place on their routers which are blocking traffic from the ORBS tester, relaytest.orbs.vuurwerk.nl We have not had any such rules and I am more than happy to make arrangements for an independant party to inspect the relevant router configurations and the audit trail of those configurations which is kept under RCS. Alan Brown has published a traceroute which he says demonstrates that Telstra Australia is blocking traffic. I have inspected the configuration of the pad19 router and no such filter exists on that host. Let me remind you of his posting: [RelayTst(a)amersfoort alan]$ /usr/sbin/traceroute 203.97.144.41 traceroute to 203.97.144.41 (203.97.144.41), 30 hops max, 40 byte packets 1 router (194.178.232.1) 0.871 ms 0.928 ms 1.077 ms 2 border (194.178.232.125) 0.834 ms 0.726 ms 0.688 ms 3 Vuurwerk.cust.ip.versatel.net (212.189.159.237) 1.132 ms 1.047 ms 1.152 m ... 16 199.37.127.190 (199.37.127.190) 284.622 ms 277.222 ms 288.499 ms 17 205.174.74.34 (205.174.74.34) 414.984 ms 406.353 ms 396.054 ms 18 FastEthernet0-0-0.pad19.Sydney.telstra.net (203.50.13.68) 399.113 ms 381.658 ms 405.766 ms 19 * * * 20 * * * 21 * * * 22 * * * He says this demonstrates that Telstra is blocking his tester. It does no such thing. The explanation is straightforward but not obvious. Traffic to 203.97.144.41 under the above traceroute was taking a path to New Zealand via Sydney at the time of the traceroute. The return path from Sydney is: pad19.Sydney>traceroute 194.178.232.55 Type escape sequence to abort. Tracing the route to relaytest.orbs.vuurwerk.nl (194.178.232.55) 1 FastEthernet1-0-0.pad16.Sydney.telstra.net (203.50.13.67) 0 msec 0 msec 0 msec 2 205.174.74.33 220 msec 220 msec 224 msec 3 199.37.127.193 [AS 5727] 220 msec 220 msec 224 msec 4 POS2-0-0.GW5.SFO4.ALTER.NET (157.130.197.77) [AS 701] 224 msec 220 msec 224 msec 5 145.ATM3-0.XR2.SFO4.ALTER.NET (146.188.149.38) [AS 701] 224 msec 220 msec 224 msec 6 190.at-1-0-0.TR2.SAC1.ALTER.NET (152.63.51.10) [AS 701] 224 msec 228 msec 228 msec 7 127.at-6-1-0.TR2.NYC9.ALTER.NET (152.63.6.81) [AS 701] 304 msec 308 msec 308 msec 8 186.ATM6-0.XR2.NYC1.ALTER.NET (152.63.21.73) [AS 701] 304 msec 308 msec 304 msec .... The next hop that a packet takes on route to 203.97.144.41 is to Telstra Australia's router in Auckland. This is Telstra Saturn's interconnect point with Telstra Australia. The nzsx-core1 router has two paths out of New Zealand, one to pad19 and the other to above.net at the PAIX. The preferred path for return packets to relaytest.orbs.vuurwerk.nl on that router in Auckland is via the direct route to Palo Alto. So we have an assymetric path from the site in the Netherlands to 203.97.144.41 on that trans Pacific part of the packet flow. Why is this important? Because above.net appear to have something on one of their routers which drops packets to/from relaytest.orbs.vuurwerk.nl Compare this trace: $ traceroute relaytest.orbs.vuurwerk.nl traceroute: Warning: ckecksums disabled traceroute to relaytest.orbs.vuurwerk.nl (194.178.232.55), 30 hops max, 40 byte packets 1 router.wlg.office.netlink.net.nz (203.97.244.1) 1.458 ms 1.202 ms 3.674 ms 2 b1.wlg.netlink.net.nz (203.97.132.129) 2.402 ms 2.696 ms 1.383 ms 3 Fe0-0.nzlq1.Wellington.telstra.net.nz (203.98.56.177) 1.584 ms 1.324 ms 1.474 ms 4 FastEthernet0-0-0.nzsx-core1.Auckland.telstra.net.nz (203.98.21.26) 31.880 ms 24.598 ms 21.631 ms 5 Serial0-1-0.paix1.PaloAlto.telstra.net (203.50.126.18) 155.577 ms 155.112 ms 290.211 ms 6 core1-gige.pao.above.net (209.249.0.244) 155.199 ms 155.356 ms 155.082 ms 7 sjc-pao-oc12.sjc.above.net (209.133.31.149) 159.880 ms !H 155.972 ms !H 156.138 ms !H with: $ traceroute 194.178.232.1 traceroute: Warning: ckecksums disabled traceroute to 194.178.232.1 (194.178.232.1), 30 hops max, 40 byte packets 1 router.wlg.office.netlink.net.nz (203.97.244.1) 1.687 ms 1.436 ms 1.317 ms 2 b1.wlg.netlink.net.nz (203.97.132.129) 1.806 ms 1.753 ms 1.545 ms 3 Fe0-0.nzlq1.Wellington.telstra.net.nz (203.98.56.177) 1.834 ms 1.755 ms 1.652 ms 4 FastEthernet0-0-0.nzsx-core1.Auckland.telstra.net.nz (203.98.21.26) 22.730 ms 21.084 ms 23.203 ms 5 Serial0-1-0.paix1.PaloAlto.telstra.net (203.50.126.18) 156.800 ms 159.412 ms 382.058 ms 6 core1-gige.pao.above.net (209.249.0.244) 195.495 ms 154.912 ms 155.196 ms 7 core3.sjc2-core1.pao-oc12.sjc2.above.net (216.200.254.185) 157.541 ms 156.235 ms 159.225 ms 8 core5.sjc2-core3.sjc2.above.net (208.185.156.66) 156.049 ms 155.687 ms 157.684 ms 9 nyc-sjc-oc12.nyc.above.net (208.185.156.162) 232.711 ms 233.514 ms 232.355 ms 10 core2-core1-oc12.nyc.above.net (209.133.31.202) 232.135 ms 231.995 ms 232.695 ms 11 POS3-0-0.GW4.NYC4.ALTER.NET (157.130.31.45) 237.016 ms 242.895 ms 241.483 ms 12 146.ATM2-0.XR2.NYC4.ALTER.NET (146.188.179.174) 237.683 ms 238.036 ms 237.969 ms .... So let me summarise this for you all. 1) We are not blocking nor have we been blocking traffic from this particular ORBS tester or any other ORBS tester. Until this incident occurred we had no knowledge that this address hosted such a tester. 2) My technical staff have reiterated this on a number of occasions on this list and directly to Alan Brown. He has consistently refused to accept their explanations and assurances. 3) We have a customer who had a misconfigured host. They have taken steps to rectify that. Our published Terms & Conditions make it clear that we do not tolerate spam and we acted promptly on notification of the problem. 4) We are guilty of having an assymetric routing path. I am not aware that this is an "ORBSable" offence. 5) Any discussion on 'filters' needs to be with above.net who provide connectivity for Telstra and a number of other NZ providers. Now can I please get back to my weekend? Regards, andy --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog