- Test - lists.nanog.org

RE: Server Redundancy
by Ejay Hire 06 Aug '03

06 Aug '03

It really depends on the application. I've seen a couple of boxes (IIRC, the one that the client bought was from cisco) that do "sticky" load balancing that associates the source address with the NAT translation and does round-robin nat to several internal servers... Come to think of it, most services depend on some sort of round-robin NAT. Can you tell us a little more about your application? -e -----Original Message----- From: Jason Greenberg [mailto:jg@execulink.com] Sent: Wednesday, August 06, 2003 12:36 PM To: nanog(a)merit.edu Subject: Server Redundancy Can I have some suggestions on how to load balance servers that are on seperate IP blocks? Is there any way to perform translation at this level? Exclude DNS based balancing please... -- Jason Greenberg, CCIE #11021 Network Administrator Execulink, Inc. <jg(a)execulink.com>

1 0

SBL soon only from sbl.spamhaus.org
by Steve Linford 06 Aug '03

06 Aug '03

If you currently use the SBL by querying the master zone sbl.spamhaus.org then you can ignore this message. If you are using the SBL via 3rd party composite DNSBLs and not directly from sbl.spamhaus.org, then please read this as the following change affects your DNSBL setup. For a long time the SBL has been available either directly from Spamhaus (as sbl.spamhaus.org) or via 3rd party composite zones such as relays.osirusoft.com (as spamhaus.relays.osirusoft.com) and blackholes.easynet.nl which import SBL data from Spamhaus. This distribution is now changing. In order to better manage SBL logistics, DNSBL zone and query traffic, from Monday 11 August 2003 the SBL should only be available from sbl.spamhaus.org. The fact the SBL was available from multiple DNSBLs was causing some confusion, plus other small factors (such as the different zones having different build times - which for example meant that we'd tell someone an IP had been removed, but they'd contact us a few hours later to say it was still blocked), plus the likely emergence of further composite lists which may add confusion, meant that it was time to make a change now rather than in a year or two. So, if you are not using sbl.spamhaus.org but would like to continue using the SBL, please add sbl.spamhaus.org to your mail server's DNSBL list. -- Steve Linford The Spamhaus Project http://www.spamhaus.org

1 0

RE: a list of hosts in a RPC BOTNET, mostly 209.x.x.x,
by Michel Py 06 Aug '03

06 Aug '03

> The controlling node for this problem seems to be: > spaley spale(a)le.seul.ircop.a.cul.nu For the entertainment on non French-speaking nanogers, the literal translation is: Spaley space(a)the.only.ircop.with.a.naked.ass Excuse my French. Michel.

1 0

Re: WANTED: ISPs with DDoS defense solutions
by Michael.Dillon＠radianz.com 06 Aug '03

06 Aug '03

>> How would the spoofing program, or its user, be able to tell if >> it was successful? Unless I'm very confused, the definition of >> spoofing is that the return packets aren't going to come back to you. >the whole thing would have to take place during a tcp control session >which used d-h to scramble itself, sort of the same way ssh does. Diffie-Hellmann is a bit overkill. It's simpler to have the client open a TCP connection to the server, retrieve a token which is just some reasonable number of random bits like 64, then send the token back in a set of UDP packets using spoofed addresses, then pause for a second or two and ask the server (through the TCP connection) whether it saw the spoofed packets. Three UDP packets should be enough to eliminate most packet loss scenarios and the spoofed address could be chosen by munging the first octet to a number from 44 to 54. That's enough for the server to collect stats and to provide a status report to the client. If the client is behind a NAT, and the spoofed source address doesn't get through, then that's OK because it means that no application in that same location behind the NAT can use spoofed addresses. --Michael Dillon

2 1

Is Anyone Seeing Packet Loss To Savvis?
by Peter Rohrman 06 Aug '03

06 Aug '03

I'm getting ICMP timeouts to 2 destinations that on are on Savvis. Is anyone else seeing it? I don't have packet loss to anything else. Below is my ping to www.savvis.net and a customer that I have masked to protect the innocent :). MUSKET:8:36:56am/export/home/pete:ping -s www.savvis.net PING www.savvis.net: 56 data bytes 64 bytes from 216.91.182.42: icmp_seq=0. time=67. ms 64 bytes from 216.91.182.42: icmp_seq=1. time=68. ms 64 bytes from 216.91.182.42: icmp_seq=2. time=68. ms 64 bytes from 216.91.182.42: icmp_seq=3. time=66. ms 64 bytes from 216.91.182.42: icmp_seq=4. time=66. ms 64 bytes from 216.91.182.42: icmp_seq=5. time=66. ms 64 bytes from 216.91.182.42: icmp_seq=6. time=64. ms 64 bytes from 216.91.182.42: icmp_seq=7. time=66. ms 64 bytes from 216.91.182.42: icmp_seq=8. time=66. ms 64 bytes from 216.91.182.42: icmp_seq=9. time=66. ms 64 bytes from 216.91.182.42: icmp_seq=10. time=68. ms 64 bytes from 216.91.182.42: icmp_seq=11. time=66. ms 64 bytes from 216.91.182.42: icmp_seq=12. time=66. ms 64 bytes from 216.91.182.42: icmp_seq=13. time=66. ms 64 bytes from 216.91.182.42: icmp_seq=14. time=73. ms ICMP Time exceeded in transit from dsl092-097-001.nyc2.dsl.speakeasy.net (66.92.97.1) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33434 ICMP Time exceeded in transit from dsl092-097-001.nyc2.dsl.speakeasy.net (66.92.97.1) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33435 ICMP Time exceeded in transit from dsl092-097-001.nyc2.dsl.speakeasy.net (66.92.97.1) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33436 ICMP Time exceeded in transit from border28.g3-2.speakeasy-26.nyc.pnap.net (209.191.132.48) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33437 ICMP Time exceeded in transit from border28.g3-2.speakeasy-26.nyc.pnap.net (209.191.132.48) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33438 ICMP Time exceeded in transit from border28.g3-2.speakeasy-26.nyc.pnap.net (209.191.132.48) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33439 ICMP Time exceeded in transit from core1.ge3-0-bbnet2.nyc.pnap.net (209.191.128.129) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33440 64 bytes from 216.91.182.42: icmp_seq=15. time=2063. ms ICMP Time exceeded in transit from core1.ge3-0-bbnet2.nyc.pnap.net (209.191.128.129) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33441 ICMP Time exceeded in transit from core1.ge3-0-bbnet2.nyc.pnap.net (209.191.128.129) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33442 ICMP Time exceeded in transit from sl-bb12-nyc-8-0.sprintlink.net (160.81.48.17) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33443 ICMP Time exceeded in transit from sl-bb12-nyc-8-0.sprintlink.net (160.81.48.17) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33444 ICMP Time exceeded in transit from sl-bb12-nyc-8-0.sprintlink.net (160.81.48.17) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33445 ICMP Time exceeded in transit from sl-bb26-nyc-15-1.sprintlink.net (144.232.7.125) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33446 64 bytes from 216.91.182.42: icmp_seq=16. time=3461. ms ICMP Time exceeded in transit from sl-bb26-nyc-15-1.sprintlink.net (144.232.7.125) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33447 ICMP Time exceeded in transit from sl-bb26-nyc-15-1.sprintlink.net (144.232.7.125) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33448 ICMP Time exceeded in transit from sl-bb22-nyc-6-0.sprintlink.net (144.232.7.42) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33449 ICMP Time exceeded in transit from sl-bb22-nyc-6-0.sprintlink.net (144.232.7.42) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33450 ICMP Time exceeded in transit from sl-bb22-nyc-6-0.sprintlink.net (144.232.7.42) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33451 ICMP Time exceeded in transit from sl-bb21-chi-9-0.sprintlink.net (144.232.9.149) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33452 64 bytes from 216.91.182.42: icmp_seq=17. time=4865. ms ICMP Time exceeded in transit from sl-bb21-chi-9-0.sprintlink.net (144.232.9.149) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33453 ICMP Time exceeded in transit from sl-bb21-chi-9-0.sprintlink.net (144.232.9.149) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33454 ICMP Time exceeded in transit from sl-gw31-chi-10-0.sprintlink.net (144.232.26.30) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33455 ICMP Time exceeded in transit from sl-gw31-chi-10-0.sprintlink.net (144.232.26.30) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33456 ICMP Time exceeded in transit from sl-gw31-chi-10-0.sprintlink.net (144.232.26.30) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33457 ICMP Time exceeded in transit from sl-savvis-16-0.sprintlink.net (144.228.154.178) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33458 64 bytes from 216.91.182.42: icmp_seq=18. time=6285. ms ICMP Time exceeded in transit from sl-savvis-16-0.sprintlink.net (144.228.154.178) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33459 ICMP Time exceeded in transit from sl-savvis-16-0.sprintlink.net (144.228.154.178) for udp from MUSKET (192.168.1.2) to 216.91.182.42 port 33460 64 bytes from 216.91.182.42: icmp_seq=19. time=6081. ms 64 bytes from 216.91.182.42: icmp_seq=20. time=5081. ms 64 bytes from 216.91.182.42: icmp_seq=21. time=4081. ms 64 bytes from 216.91.182.42: icmp_seq=22. time=3082. ms 64 bytes from 216.91.182.42: icmp_seq=23. time=2082. ms 64 bytes from 216.91.182.42: icmp_seq=24. time=1082. ms 64 bytes from 216.91.182.42: icmp_seq=25. time=82. ms 64 bytes from 216.91.182.42: icmp_seq=26. time=64. ms 64 bytes from 216.91.182.42: icmp_seq=27. time=68. ms 64 bytes from 216.91.182.42: icmp_seq=28. time=68. ms 64 bytes from 216.91.182.42: icmp_seq=29. time=66. ms 64 bytes from 216.91.182.42: icmp_seq=30. time=68. ms 64 bytes from 216.91.182.42: icmp_seq=31. time=66. ms 64 bytes from 216.91.182.42: icmp_seq=32. time=64. ms 64 bytes from 216.91.182.42: icmp_seq=33. time=64. ms 64 bytes from 216.91.182.42: icmp_seq=34. time=66. ms 64 bytes from 216.91.182.42: icmp_seq=35. time=64. ms 64 bytes from 216.91.182.42: icmp_seq=36. time=68. ms 64 bytes from 216.91.182.42: icmp_seq=37. time=68. ms 64 bytes from 216.91.182.42: icmp_seq=38. time=66. ms 64 bytes from 216.91.182.42: icmp_seq=39. time=70. ms 64 bytes from 216.91.182.42: icmp_seq=40. time=66. ms 64 bytes from 216.91.182.42: icmp_seq=41. time=64. ms 64 bytes from 216.91.182.42: icmp_seq=42. time=64. ms 64 bytes from 216.91.182.42: icmp_seq=43. time=66. ms ^C ----www.savvis.net PING Statistics---- 44 packets transmitted, 44 packets received, 0% packet loss round-trip (ms) min/avg/max = 64/919/6285 MUSKET:8:59:34am/export/home/pete: MUSKET:8:46:35am/export/home/pete:ping -s CustXOn.savvis PING CustXOn.savvis: 56 data bytes 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=0. time=49. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=1. time=100. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=2. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=3. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=4. time=102. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=5. time=122. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=6. time=56. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=7. time=50. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=8. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=9. time=45. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=10. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=11. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=12. time=50. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=13. time=50. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=14. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=15. time=51. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=16. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=17. time=78. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=18. time=52. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=19. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=20. time=76. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=21. time=45. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=22. time=56. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=23. time=44. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=24. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=25. time=50. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=26. time=66. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=27. time=70. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=28. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=29. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=30. time=52. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=31. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=32. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=33. time=52. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=34. time=58. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=35. time=62. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=36. time=72. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=37. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=38. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=39. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=40. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=41. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=42. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=43. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=44. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=45. time=58. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=46. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=47. time=44. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=48. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=49. time=76. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=50. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=51. time=58. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=52. time=54. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=53. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=54. time=58. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=55. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=56. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=57. time=60. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=58. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=59. time=98. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=60. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=61. time=56. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=62. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=63. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=64. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=65. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=66. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=67. time=64. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=68. time=51. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=69. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=70. time=76. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=71. time=50. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=72. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=73. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=74. time=51. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=75. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=76. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=77. time=50. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=78. time=47. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=79. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=80. time=51. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=81. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=82. time=47. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=83. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=84. time=47. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=85. time=44. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=86. time=73. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=87. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=88. time=99. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=89. time=58. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=90. time=57. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=91. time=46. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=93. time=50. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=101. time=48. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=102. time=47. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=103. time=44. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=104. time=45. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=105. time=57. ms ICMP Time exceeded in transit from dsl092-097-001.nyc2.dsl.speakeasy.net (66.92.97.1) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33434 ICMP Time exceeded in transit from dsl092-097-001.nyc2.dsl.speakeasy.net (66.92.97.1) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33435 ICMP Time exceeded in transit from dsl092-097-001.nyc2.dsl.speakeasy.net (66.92.97.1) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33436 ICMP Time exceeded in transit from border28.g3-2.speakeasy-26.nyc.pnap.net (209.191.132.4 8) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33437 ICMP Time exceeded in transit from border28.g3-2.speakeasy-26.nyc.pnap.net (209.191.132.4 8) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33438 ICMP Time exceeded in transit from border28.g3-2.speakeasy-26.nyc.pnap.net (209.191.132.4 8) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33439 ICMP Time exceeded in transit from core4.fe0-0-fenet1.nyc.pnap.net (209.191.128.72) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33440 ICMP Time exceeded in transit from core4.fe0-0-fenet1.nyc.pnap.net (209.191.128.72) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33441 ICMP Time exceeded in transit from core4.fe0-0-fenet1.nyc.pnap.net (209.191.128.72) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33442 ICMP Time exceeded in transit from p3-2.nycmny1-cr11.bbnplanet.net (4.25.14.17) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33443 ICMP Time exceeded in transit from p3-2.nycmny1-cr11.bbnplanet.net (4.25.14.17) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33444 ICMP Time exceeded in transit from p3-2.nycmny1-cr11.bbnplanet.net (4.25.14.17) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33445 ICMP Time exceeded in transit from p3-0.nycmny1-nbr1.bbnplanet.net (4.24.10.78) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33446 ICMP Time exceeded in transit from p3-0.nycmny1-nbr1.bbnplanet.net (4.24.10.78) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33447 ICMP Time exceeded in transit from p3-0.nycmny1-nbr1.bbnplanet.net (4.24.10.78) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33448 ICMP Time exceeded in transit from so-5-1-0-100.bbr1.nyc1.Level3.net (64.159.4.61) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33449 ICMP Time exceeded in transit from so-5-1-0-100.bbr1.nyc1.Level3.net (64.159.4.61) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33450 ICMP Time exceeded in transit from so-5-1-0-100.bbr1.nyc1.Level3.net (64.159.4.61) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33451 ICMP Time exceeded in transit from gigabitethernet2-1.core1.NewYork1.Level3.net (64.159.1 7.69) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33452 ICMP Time exceeded in transit from gigabitethernet2-1.core1.NewYork1.Level3.net (64.159.1 7.69) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33453 ICMP Time exceeded in transit from gigabitethernet2-1.core1.NewYork1.Level3.net (64.159.1 7.69) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33454 ICMP Time exceeded in transit from savvis-level3-oc3.NewYork1.Level3.net (209.244.160.174 ) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33455 ICMP Time exceeded in transit from savvis-level3-oc3.NewYork1.Level3.net (209.244.160.174 ) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33456 ICMP Time exceeded in transit from savvis-level3-oc3.NewYork1.Level3.net (209.244.160.174 ) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33457 ICMP Time exceeded in transit from savvis-pnet3.cntx13.usnycm4-bsn.savvis.net (66.100.79. 86) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33458 ICMP Time exceeded in transit from savvis-pnet3.cntx13.usnycm4-bsn.savvis.net (66.100.79. 86) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33459 ICMP Time exceeded in transit from savvis-pnet3.cntx13.usnycm4-bsn.savvis.net (66.100.79. 86) for udp from MUSKET (192.168.1.2) to CustXOn.savvis (64.242.xxx.yyy) port 33460 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=121. time=43. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=122. time=49. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=123. time=47. ms 64 bytes from CustXOn.savvis (64.242.xxx.yyy): icmp_seq=124. time=45. ms ^C ----CustXOn.savvis PING Statistics---- 130 packets transmitted, 102 packets received, 21% packet loss round-trip (ms) min/avg/max = 43/53/122 MUSKET:8:48:51am/export/home/pete: MUSKET:9:24:25am/export/home/pete:

1 0

Chicago CFP Redux
by Susan Harris 06 Aug '03

06 Aug '03

Thanks to everyone who's already sent in a proposal for NANOG 29. (PS they're due Sept. 8). * * * * * * * * * * * * * * * * * CALL FOR PRESENTATIONS NANOG 29 GENERAL SESSION TUTORIALS CASE STUDIES RESEARCH FORUM October 19-21, 2003 * * * * * * * * * * * * * * * * * The North American Network Operators' Group (NANOG) will hold its 29th meeting October 19-21, 2003, at the Chicago Marriott Downtown Hotel. This will be NANOG's second joint meeting with ARIN, the American Registry for Internet Numbers (www.arin.net) NANOG will meet from Sunday to Tuesday, and ARIN from Wednesday to Friday, October 22-24. Registration opens September 2. NANOG conferences provide a forum for the coordination and dissemination of technical information related to backbone/enterprise networking technologies and operational practices. Meetings are held three times each year, and include two days of short presentations, plus afternoon/evening tutorial sessions. The meetings are informal, with an emphasis on relevance to current backbone engineering practices. NANOG conferences draw over 350 participants, mainly consisting of engineering staff from national service providers, and members of the research and education community. For more information about NANOG meetings, schedules, and logistics, see: http://www.nanog.org ------------------------------------------------------------------------------ CALL FOR PRESENTATIONS NANOG invites presentations on backbone/enterprise engineering, coordination, and research topics. Presentations should highlight issues relating to technology already deployed or soon to be deployed in core Internet backbones and exchange points. Vendors are encouraged to work with operators to present deployment experiences with the vendor's products. Researchers are invited to present short (10-minute) summaries of their work for operator feedback. Topics include routing, network performance, statistical measurement and analysis, and protocol development and implementation. Studies presented may be works in progress. Researchers from academia, government, and industry are encouraged to present. The community is invited to present talks on: -- Survey of open-source/commercial network management systems -- Operator experience/how-to's on building packet-switched networks (e.g., IP or MPLS) that can carry: - TDM - Layer 2 (e.g., Frame Relay and ATM) - IP services - Emerging services such as the Virtual Private LAN Service (VPLS). -- Operator case studies on: - Integration with optical control planes (GMPLS, ASON, etc.), voice (enterprise, Class 4 and Class 5), and video - Provisioning and automation - Enterprise network security, management, and route control - Network troubleshooting and problems solved -- Experience with active DoS retaliation methods, e.g., reverse port scanning. -- Implementation and use of measurement technologies in vendor devices Other potential topics include: -- Backbone traffic engineering -- Impact of BGP dynamics on backbone traffic patterns -- Route processor architecture -- Large-scale wireless deployment -- Building large-scale measurement infrastructure -- Inter-domain multicast deployment NANOG also welcomes suggestions/recommendations for tutorials, panels, and other presentation topics. ------------------------------------------------------------------------------ HOW TO PRESENT Submit a detailed abstract or outline describing the presentation in email to nanog-support(a)nanog.org. The deadline for proposals is September 8, 2003. While the majority of speaking slots will be filled by September 8, a limited number of slots will be available after that date for topics that are exceptionally timely and important. Submissions will be reviewed by the NANOG Program Committee, and presenters will be notified of acceptance by September 22. Final drafts of presentation slides are due by October 8, and final versions October 15. ---------------------------------------------------------------------------

1 0

Re: WANTED: ISPs with DDoS defense solutions
by Paul Vixie 06 Aug '03

06 Aug '03

> How would the spoofing program, or its user, be able to tell if > it was successful? Unless I'm very confused, the definition of > spoofing is that the return packets aren't going to come back to you. the whole thing would have to take place during a tcp control session which used d-h to scramble itself, sort of the same way ssh does. the random address/addresses would be chosen by the server. the only info the initiator would gain is a count of how many spoofed packets made it in; this could be left out if we feared that bad people would profit from being able to use this tester. (we don't, though, since they have their own ways of knowing whether spoofing is working from a given source, and we don't think they'd want us to know what sources they were testing.) > I can imagine a packet format where the real source address was in the > data, but with no authentication this would itself be subject to abuse. > ... > Doing this from behind a NAT would be difficult. one hopes that a nat box would also complicate the lives of spoofers.

1 0

Re: WANTED: ISPs with DDoS defense solutions
by Paul Vixie 06 Aug '03

06 Aug '03

> I don't believe I ever said that the edges shouldn't filter... did I? nope. but you said that backbones couldn't/wouldn't/shouldn't, and i showed that "transitivity" => "laundering", which means backbones MUST filter, to within the best capabilities of current technology.

2 1

Re: testing bandwidth of big internet pipes
by Stewart, William C (Bill), RTSLS 06 Aug '03

06 Aug '03

I tend to think of T1 and E1 connections as small (STM1s are starting to be big :-). It's easy enough to test them if there's something fast enough to test to. The two kinds of tests your customers are likely to care about are - Is your connection to them really the speed it should be? - Do you have enough upstream bandwidth for your traffic load? There are lots of ways to get and measure a 2Mbps load - - Most Cisco routers have "ttcp" client/server code, http://www.cisco.com/warp/public/471/ttcp.html http://www.netcordia.com/tnm/tnm31/ttcp.htm and you can either talk to another Cisco or use a Windows or Linux PC. - FTP on a Sun 3/60 a decade ago, or a Linux box with FTP or HTTP today, and any medium-fast Windows machine with an FTP or HTTP client that shows you download speed is usually a good demonstration. (You need to ignore initial ramp-up time because of TCP slow-start.) If you've got a spare PC you can hang off one of your routers, run an FTP and HTTP server on it and keep a few "10MB.txt" type files on it. - Qcheck is a nice friendly free client for Windows and other platforms which does speed and latency tests using tcp, udp, and ping, and can also be driven by their non-free testing systems. http://www.ixiacom.com/enterprise/Qcheck.php (Qcheck does use more PC CPU than simpler tools - my 66MHz Pentium doorstop boxes could only do ~300-400 kbps, but anything over about 500 MHz should do just fine.) - A really *bad* method that's popular with some of my customers (:-) is to use really big pings on a Cisco router. There are lots of different reasons this tends to fail. The second question is harder to answer, because you need a site that's not in your network that can give a fast enough response that the customer will feel happy, and I've found that it's often hard to download files from public web sites at faster than 1-2 megabits per second, because either the web site is <= T1, or it's large and shared by many users. Linux distribution sites when there's nothing interesting being released are usually good, but unfortunately mirror sites often mirror lots of things, so you may have trouble finding a quiet one. I don't remember if BitTorrent has a fancy user interface that shows current download speed, but it's usually good at filling up any symmetrical Internet pipe if there's something popular to download.

2 1

Re: Edge 1 Networks/Williams Communications Group (fwd)
by william＠elan.net 06 Aug '03

06 Aug '03

I do believe you're right about edge1 being new front Nick Geyer (who just recently said he's done with ip hijackings and will be doing everything legit and proper now - wonder if this can really be believed...). About Nick Geyer and his associates, see http://www.completewhois.com/hijacked/gang_vmx.htm (and at http://www.completewhois.com/hijacked/ you can see list of all ip blocks they stole - that is a LOT of ip space!) Then again it is interesting if this was you being helpfull or was it inside information (the person providing this info is himself associated with hijackers listed at http://www.completewhois.com/hijacked/gang_wdh.htm) ---------- Forwarded message ---------- Date: Mon, 4 Aug 2003 18:14:22 -0400 From: "Booth, Michael (ENG)" <MBooth(a)corp.as26857.com> To: Jeff Kell <jeff-kell(a)utc.edu> Cc: nanog <nanog(a)nanog.org>, Michael.Winslow(a)wcg.com, blake.williams(a)wcg.com Subject: Re: Edge 1 Networks/Williams Communications Group > After several run-ins with Edge 1 Networks [69.44.28.0/22] having their > machines "hijack" victim machines on our networks infected with Jeem, > and then making their spam runs, I've had it. I have reported both to > Edge 1 and their parent Williams Communications Group [AS7911] with no > result and I will be blocking Edge 1 [in theory, AS29986, but no doubt > private spewage from WCG.NET) I smell a rat. I have a funny feeling Edge1 is a front for pro-spammer Nick Geyer. Look at their whois: Edge1 Networks Hostmaster Edge1 25 Broadway - 5th Floor New York, NY 10004 US Phone: 212-248-1121 Fax..: 212-248-0929 But if you call Verizon, they'll tell you these lines terminate on the sixth floor of 25 Broadway, an address I remember all too well from the VMX Networks hijackings. If you want the abuse to stop, call Nick at work (212-685-2009) or on his cellular phone (503-851-1963) and tell him to knock it off. If Nick is busy or at a meeting, as is often the case ask to speak to his boss, Paul Hodara, and see if he can track him down. The Williams NOC could care less, if you want to get anywhere, try contacting Blake Williams (blake.williams(a)wcg.com) or Michael Winslow (Michael.Winslow(a)wcg.com) who are capable of taking action, including ultimately denying service to Edge1 for AUP violations.

1 0