September 2001 - Test - lists.nanog.org

Afghanistan
by Smith, Rick 19 Sep '01

19 Sep '01

Has anyone started to deny all traffic to/from Afghanistan ? Wouldn't that be worth it ? Or did I miss that post? R

13 15

RE: looping traceroutes
by Hire, Ejay 19 Sep '01

19 Sep '01

This behavior would occur if the traffic was routed to a loopback interface. -----Original Message----- From: Leo Bicknell [mailto:bicknell@ufp.org] Sent: Wednesday, September 19, 2001 8:09 AM To: nanog(a)merit.edu Subject: Re: looping traceroutes On Wed, Sep 19, 2001 at 12:40:51AM -0700, Ratul Mahajan wrote: > Do you think that it can be a real persistent routing loop (data packets > would actually shuttle between the two interfaces) as against some > wierdness because of traceroute? I'd tell you a story, but it would make all of nanog cringe. Put simply, I know of at least one medium size regional network who when they couldn't make "bgp work" decided to implement a series of scripts that logged into all routers and installed statics to make things work. Let me just tell you, after a few short weeks of adding and removing (and missing) such routes there were loops all over the place, many of which are probably still there. :-( There are a number of ways long lived loops can occur. I believe others have pointed out some other methods. -- Leo Bicknell - bicknell(a)ufp.org Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - tmbg-list-request(a)tmbg.org, www.tmbg.org

1 0

Worm probes
by sigma＠pair.com 19 Sep '01

19 Sep '01

Has anyone else been seeing a dramatic increase in /scripts/.. NT worm probes this morning? We're seeing about 8000/second, starting around 9:15 Eastern time, to and from a wide variety of addresses. Is CodeRed or one of its relatives scheduled to start sweeping again today? We've never seen this level of traffic related to the NT worms. Even though we don't run any NT at all, we still have to suffer :( Kevin

30 35

RE: Afghanistan
by Smith, Rick 19 Sep '01

19 Sep '01

I called. Arin does not. They explained that they DO store the country code with the data, but then they don't allow you to query whois by country code... At least not in their version. -----Original Message----- From: Tim Devries [mailto:tim.devries@inquent.com] Sent: Tuesday, September 18, 2001 5:54 PM To: nanog(a)merit.edu Subject: Re: Afghanistan What about all other nations and states? I think that type of information would be useful regardless of this particular situation. Anyone know if arin et al catagorizes and publishes this information? ----- Original Message ----- From: "Nathan J . Mehl" <memory-nanog(a)blank.org> To: <nanog(a)merit.edu> Sent: Tuesday, September 18, 2001 10:45 AM Subject: Re: Afghanistan > > In the immortal words of Tim Devries (tim.devries(a)inquent.com) > > > > Does anyone even have a list of IP blocks allocated on a national or > > regional level? > > "None" and "none." > > Afghanistan barely has working voice phone service, and the Taliban > issued an edict banning all computers and most especially internet > access several months ago. > > Note reply-to. > > -n > > ------------------------------------------------------------<memory@blank. org> > "Thus do `Snuff Movies' take their place with `Political-Correctness,' `Sex > Addiction,' and `Postmodernism' as Godzillas of bogus moral panic, always > threatening to crush the nation in their jaws, but never quite willing to take > the final step of biting down. (--www.suck.com) > <http://blank.org/memory/>-------------------------------------------------- -- >

2 1

RE: looping traceroutes
by Jeb R. Linton 19 Sep '01

19 Sep '01

Even more interesting, I think, is the fact that the first example (with the same repeating host address) increases RTT while the second (with the alternating address) does not. It seems counter-intuitive based on the alternating versus non-alternating host addresses, but it may be that the first is a route loop, while the second is actually the filter, as described by Patrick, but between two load-balancing interfaces. As for the route-loop (?) with the same repeating address... maybe the addresses are NATed? - Jeb -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Stephen J. Wilcox Sent: Wednesday, September 19, 2001 5:16 AM To: Ratul Mahajan Cc: nanog(a)merit.edu Subject: Re: looping traceroutes the most interesting thing is that the rtt increases.. and it does so by regular amounts, about 30ms in each hop i'd guess there is a routing loop going on there for sure, i'd also guess its between two routers that are 30ms apart! perhaps it could be being caused by some sort of nat on the router so there are actually two routers looping but one or both of the addresses get nat'd as the replies come to you Steve On Tue, 18 Sep 2001, Ratul Mahajan wrote: > > > > while playing around with traceroutes for a measurement study of bgp, i > often come across the traceroute outputs similar to those appended below. > i don't have a reasonable explanation of such behaviour (i don't think > these are routing loops; they are not transient in any case). i am hoping > someone on the list has a hang of traceroute implementations, and provide > insights into under what circumstances this might happen. > > thanks, > -- ratul > > -------------- > > $ traceroute 200.13.39.1 > traceroute to 200.13.39.1 (200.13.39.1), 30 hops max, 38 byte packets > 1 regina-GE1-2.cac.washington.edu (128.95.219.100) 1.098 ms 1.233 ms > 2 uwbr2-GE3-0.cac.washington.edu (140.142.153.24) 0.349 ms 0.377 ms > 3 cnsp1-wes-GE1-0.pnw-gigapop.net (198.107.150.1) 1.561 ms 1.005 ms > 4 so-1-2-2.a07.sttlwa01.us.ra.verio.net (204.203.3.1) 21.690 ms 6.076 > 5 ge-6-2-0.r03.sttlwa01.us.bb.verio.net (129.250.28.1) 8.481 ms 8.756 > 6 p4-7-2-0.r06.plalca01.us.bb.verio.net (129.250.3.138) 29.934 ms > 7 p16-3-0-0.r00.plalca01.us.bb.verio.net (129.250.2.162) 26.740 ms > 8 p4-0.francetelecom.plalca01.us.bb.verio.net (129.250.9.134) 23.058 ms > 9 P4-3.DALBB1.Dallas.opentransit.net (193.251.132.221) 84.523 ms > 10 P5-1.FWHBB2.Fort-worth.opentransit.net (193.251.132.213) 86.653 ms > 11 Sr9-0-0.FWHAR1.Fort-worth.opentransit.net (193.251.132.227) 88.507 ms > 12 193.251.133.117 (193.251.133.117) 115.472 ms * 116.554 ms > 13 193.251.133.117 (193.251.133.117) 145.386 ms 147.224 ms 148.333 ms > 14 193.251.133.117 (193.251.133.117) 178.751 ms 172.224 ms * > 15 193.251.133.117 (193.251.133.117) 208.640 ms 203.841 ms 199.946 ms > 16 193.251.133.117 (193.251.133.117) 231.618 ms 233.234 ms 229.844 ms > 17 193.251.133.117 (193.251.133.117) 259.227 ms 258.488 ms 262.034 ms > 18 193.251.133.117 (193.251.133.117) 288.661 ms 292.598 ms 288.129 ms > 19 193.251.133.117 (193.251.133.117) 321.982 ms 320.806 ms 318.364 ms > 20 193.251.133.117 (193.251.133.117) 350.245 ms 349.834 ms 540.883 ms > 21 193.251.133.117 (193.251.133.117) 539.971 ms 410.838 ms 419.743 ms > 22 193.251.133.117 (193.251.133.117) 468.291 ms 409.761 ms 406.256 ms > 23 193.251.133.117 (193.251.133.117) 432.990 ms 439.589 ms 434.184 ms > 24 * 193.251.133.117 (193.251.133.117) 466.399 ms 465.287 ms > 25 193.251.133.117 (193.251.133.117) 500.719 ms 498.601 ms 499.957 ms > 26 193.251.133.117 (193.251.133.117) 530.089 ms 527.642 ms 528.999 ms > 27 193.251.133.117 (193.251.133.117) 556.208 ms 555.552 ms 557.387 ms > 28 193.251.133.117 (193.251.133.117) 586.776 ms 584.171 ms 586.944 ms > 29 193.251.133.117 (193.251.133.117) 608.677 ms 610.789 ms 618.232 ms > 30 193.251.133.117 (193.251.133.117) 641.141 ms 643.149 ms 639.050 ms > > ---------- > > $ traceroute 198.146.21.26 > traceroute to 198.146.21.26 (198.146.21.26), 30 hops max, 38 byte packets > 1 regina-GE1-2.cac.washington.edu (128.95.219.100) 4.395 ms 0.986 ms > 2 uwbr2-GE2-0.cac.washington.edu (140.142.155.24) 0.326 ms 0.310 ms > 3 cnsp1-wes-GE1-0.pnw-gigapop.net (198.107.150.1) 1.305 ms 1.113 ms > 4 so-1-2-2.a07.sttlwa01.us.ra.verio.net (204.203.3.1) 4.219 ms 4.308 > 5 ge-6-2-0.r03.sttlwa01.us.bb.verio.net (129.250.28.1) 4.096 ms 6.462 > 6 p4-5-0-0.r06.plalca01.us.bb.verio.net (129.250.3.89) 25.469 ms > 7 p4-0-0.r05.plalca01.us.bb.verio.net (129.250.2.129) 23.593 ms 22.371 > 8 svl-brdr-01.inet.qwest.net (205.171.4.45) 24.093 ms 25.967 ms > 9 svl-core-03.inet.qwest.net (205.171.14.109) 27.487 ms 22.669 ms > 10 svl-core-01.inet.qwest.net (205.171.14.121) 22.500 ms 24.719 ms > 11 chi-core-03.inet.qwest.net (205.171.8.50) 62.208 ms 55.153 ms > 12 chi-core-01.inet.qwest.net (205.171.20.173) 57.742 ms 54.672 ms > 13 chi-edge-01.inet.qwest.net (205.171.20.34) 54.261 ms 58.971 ms > 14 208.46.63.202 (208.46.63.202) 88.583 ms 69.619 ms 67.605 ms > 15 208.63.128.3 (208.63.128.3) 70.551 ms 67.581 ms 69.375 ms > 16 208.63.128.1 (208.63.128.1) 65.115 ms 70.951 ms 66.083 ms > 17 208.63.128.3 (208.63.128.3) 67.628 ms 65.488 ms 68.418 ms > 18 208.63.128.1 (208.63.128.1) 72.197 ms 71.422 ms 69.517 ms > 19 208.63.128.3 (208.63.128.3) 68.539 ms 68.976 ms 67.911 ms > 20 208.63.128.1 (208.63.128.1) 72.373 ms 67.838 ms 66.468 ms > 21 208.63.128.3 (208.63.128.3) 67.040 ms 69.136 ms 67.631 ms > 22 208.63.128.1 (208.63.128.1) 66.317 ms 83.947 ms 70.693 ms > 23 208.63.128.3 (208.63.128.3) 66.865 ms 69.521 ms 69.760 ms > 24 208.63.128.1 (208.63.128.1) 69.604 ms 67.534 ms 70.447 ms > 25 208.63.128.3 (208.63.128.3) 68.285 ms 69.772 ms 67.721 ms > 26 208.63.128.1 (208.63.128.1) 71.915 ms 69.530 ms 72.403 ms > 27 208.63.128.3 (208.63.128.3) 111.475 ms 69.670 ms 69.267 ms > 28 208.63.128.1 (208.63.128.1) 68.883 ms 67.147 ms 72.106 ms > 29 208.63.128.3 (208.63.128.3) 69.842 ms 67.889 ms 66.944 ms > 30 208.63.128.1 (208.63.128.1) 70.986 ms 73.124 ms 68.452 ms > > > > -- Stephen J. Wilcox IP Services Manager, Opal Telecom http://www.opaltelecom.co.uk/ Tel: 0161 222 2000 Fax: 0161 222 2008

1 0

Re: looping traceroutes
by Marshall Eubanks 19 Sep '01

19 Sep '01

> >From AS 16517 one seems normal, one does not. In both cases eBGP seems normal. I cannot ping to the non-normal one, so a black hole is possible. Maybe they are running an iBGP with a loop. Regards Marshall Eubanks NORMAL multicasttech-2>trace 200.13.39.1 Type escape sequence to abort. Tracing the route to 200.13.39.1 1 207.ATM1-0.GW2.DCA8.ALTER.NET (157.130.46.53) 4 msec 4 msec 4 msec 2 0.so-3-0-0.XL2.DCA8.ALTER.NET (146.188.162.194) [AS 701] 8 msec 4 msec 24 msec 3 0.so-3-0-0.TR2.DCA8.ALTER.NET (152.63.144.29) [AS 701] 4 msec 4 msec 4 msec 4 115.at-6-0-0.TR2.HOU7.ALTER.NET (146.188.141.142) [AS 701] 64 msec 56 msec 60 msec 5 186.at-1-0-0.XR2.HOU7.ALTER.NET (152.63.97.233) [AS 701] 60 msec 52 msec 56 msec 6 182.ATM5-0.GW4.HOU7.ALTER.NET (152.63.100.133) [AS 701] 60 msec 56 msec 60 msec 7 avental-gw.customer.ALTER.NET (157.130.133.206) [AS 701] 72 msec 72 msec 72 msec 8 200.33.208.206 [AS 6503] 100 msec 84 msec 92 msec 9 ar6.mexmdf.avantel.net.mx (200.33.209.29) [AS 6503] 92 msec 100 msec 88 msec 10 na-62-239.na.avantel.net.mx (200.39.239.62) [AS 6503] 112 msec 96 msec 88 msec 11 200.13.38.129 [AS 3561] 144 msec 136 msec 128 msec multicasttech-2>show ip bgp 200.13.39.1 BGP routing table entry for 200.13.39.0/24, version 155431 Paths: (2 available, best #1, table Default-IP-Routing-Table) Advertised to non peer-group peers: 192.168.1.2 701 6503 157.130.46.53 from 157.130.46.53 (137.39.4.99) Origin IGP, localpref 100, valid, external, best 1239 1239 1239 5511 160.81.38.225 from 160.81.38.225 (144.228.242.54) Origin IGP, metric 48, localpref 100, valid, external NOT NORMAL multicasttech-2>trace 198.146.21.26 Type escape sequence to abort. Tracing the route to 198.146.21.26 1 207.ATM1-0.GW2.DCA8.ALTER.NET (157.130.46.53) 4 msec 12 msec 4 msec 2 0.so-3-0-0.XL1.DCA8.ALTER.NET (146.188.162.198) [AS 701] 4 msec 8 msec 8 msec 3 189.at-1-0-0.XR1.DCA6.ALTER.NET (152.63.33.77) [AS 701] 4 msec 8 msec 24 msec 4 0.so-2-1-0.XL1.DCA6.ALTER.NET (152.63.38.85) [AS 701] 8 msec 8 msec 8 msec 5 POS6-0.BR4.DCA6.ALTER.NET (152.63.41.229) [AS 701] 32 msec 12 msec 4 msec 6 204.255.169.98 [AS 701] 8 msec 8 msec 8 msec 7 wdc-core-01.inet.qwest.net (205.171.24.37) [AS 209] 8 msec 8 msec 4 msec 8 dca-core-02.inet.qwest.net (205.171.8.209) [AS 209] 4 msec 8 msec 8 msec 9 atl-core-02.inet.qwest.net (205.171.8.153) [AS 209] 28 msec 24 msec 24 msec 10 atl-edge-05.inet.qwest.net (205.171.21.54) [AS 209] 44 msec 24 msec 28 msec 11 63.144.0.110 [AS 209] 36 msec 40 msec 32 msec 12 * * * 13 208.63.129.1 [AS 19956] 32 msec 32 msec 32 msec 14 208.63.129.3 [AS 19956] 56 msec * 32 msec 15 208.63.129.1 [AS 19956] 36 msec 36 msec 32 msec 16 * 208.63.129.3 [AS 19956] 32 msec * 17 208.63.129.1 [AS 19956] 32 msec 100 msec 96 msec 18 * 208.63.129.3 [AS 19956] 36 msec * 19 208.63.129.1 [AS 19956] 36 msec 32 msec 32 msec 20 208.63.129.3 [AS 19956] 32 msec * 32 msec 21 208.63.129.1 [AS 19956] 32 msec 36 msec 44 msec 22 * * 208.63.129.3 [AS 19956] 40 msec 23 208.63.129.1 [AS 19956] 32 msec 40 msec 32 msec 24 * 208.63.129.3 [AS 19956] 32 msec * 25 208.63.129.1 [AS 19956] 36 msec 36 msec 40 msec 26 208.63.129.3 [AS 19956] 32 msec * 32 msec 27 208.63.129.1 [AS 19956] 32 msec 36 msec 40 msec 28 * 208.63.129.3 [AS 19956] 36 msec * 29 208.63.129.1 [AS 19956] 36 msec 36 msec 52 msec 30 * * * multicasttech-2>show ip bgp 198.146.21.26 BGP routing table entry for 198.146.21.0/24, version 696388 Paths: (2 available, best #1, table Default-IP-Routing-Table) Advertised to non peer-group peers: 192.168.1.2 701 209 19956 16473 157.130.46.53 from 157.130.46.53 (137.39.4.99) Origin incomplete, localpref 100, valid, external, best 1239 1239 1239 209 19956 16473 160.81.38.225 from 160.81.38.225 (144.228.242.54) Origin incomplete, metric 8, localpref 100, valid, external multicasttech-2> multicasttech-2>ping 198.146.21.26 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 198.146.21.26, timeout is 2 seconds: ..... Success rate is 0 percent (0/5) multicasttech-2> > >the most interesting thing is that the rtt increases.. > >and it does so by regular amounts, about 30ms in each hop > >i'd guess there is a routing loop going on there for sure, i'd also guess >its between two routers that are 30ms apart! > >perhaps it could be being caused by some sort of nat on the router so >there are actually two routers looping but one or both of the addresses >get nat'd as the replies come to you > >Steve > >On Tue, 18 Sep 2001, Ratul Mahajan wrote: > >> >> >> >> while playing around with traceroutes for a measurement study of bgp, i >> often come across the traceroute outputs similar to those appended below. >> i don't have a reasonable explanation of such behaviour (i don't think >> these are routing loops; they are not transient in any case). i am hoping >> someone on the list has a hang of traceroute implementations, and provide >> insights into under what circumstances this might happen. >> >> thanks, >> -- ratul >> >> -------------- >> >> $ traceroute 200.13.39.1 >> traceroute to 200.13.39.1 (200.13.39.1), 30 hops max, 38 byte packets >> 1 regina-GE1-2.cac.washington.edu (128.95.219.100) 1.098 ms 1.233 ms >> 2 uwbr2-GE3-0.cac.washington.edu (140.142.153.24) 0.349 ms 0.377 ms >> 3 cnsp1-wes-GE1-0.pnw-gigapop.net (198.107.150.1) 1.561 ms 1.005 ms >> 4 so-1-2-2.a07.sttlwa01.us.ra.verio.net (204.203.3.1) 21.690 ms 6.076 >> 5 ge-6-2-0.r03.sttlwa01.us.bb.verio.net (129.250.28.1) 8.481 ms 8.756 >> 6 p4-7-2-0.r06.plalca01.us.bb.verio.net (129.250.3.138) 29.934 ms >> 7 p16-3-0-0.r00.plalca01.us.bb.verio.net (129.250.2.162) 26.740 ms >> 8 p4-0.francetelecom.plalca01.us.bb.verio.net (129.250.9.134) 23.058 ms >> 9 P4-3.DALBB1.Dallas.opentransit.net (193.251.132.221) 84.523 ms >> 10 P5-1.FWHBB2.Fort-worth.opentransit.net (193.251.132.213) 86.653 ms >> 11 Sr9-0-0.FWHAR1.Fort-worth.opentransit.net (193.251.132.227) 88.507 ms >> 12 193.251.133.117 (193.251.133.117) 115.472 ms * 116.554 ms >> 13 193.251.133.117 (193.251.133.117) 145.386 ms 147.224 ms 148.333 ms >> 14 193.251.133.117 (193.251.133.117) 178.751 ms 172.224 ms * >> 15 193.251.133.117 (193.251.133.117) 208.640 ms 203.841 ms 199.946 ms >> 16 193.251.133.117 (193.251.133.117) 231.618 ms 233.234 ms 229.844 ms >> 17 193.251.133.117 (193.251.133.117) 259.227 ms 258.488 ms 262.034 ms >> 18 193.251.133.117 (193.251.133.117) 288.661 ms 292.598 ms 288.129 ms >> 19 193.251.133.117 (193.251.133.117) 321.982 ms 320.806 ms 318.364 ms >> 20 193.251.133.117 (193.251.133.117) 350.245 ms 349.834 ms 540.883 ms >> 21 193.251.133.117 (193.251.133.117) 539.971 ms 410.838 ms 419.743 ms >> 22 193.251.133.117 (193.251.133.117) 468.291 ms 409.761 ms 406.256 ms >> 23 193.251.133.117 (193.251.133.117) 432.990 ms 439.589 ms 434.184 ms >> 24 * 193.251.133.117 (193.251.133.117) 466.399 ms 465.287 ms >> 25 193.251.133.117 (193.251.133.117) 500.719 ms 498.601 ms 499.957 ms >> 26 193.251.133.117 (193.251.133.117) 530.089 ms 527.642 ms 528.999 ms >> 27 193.251.133.117 (193.251.133.117) 556.208 ms 555.552 ms 557.387 ms >> 28 193.251.133.117 (193.251.133.117) 586.776 ms 584.171 ms 586.944 ms >> 29 193.251.133.117 (193.251.133.117) 608.677 ms 610.789 ms 618.232 ms >> 30 193.251.133.117 (193.251.133.117) 641.141 ms 643.149 ms 639.050 ms >> >> ---------- >> >> $ traceroute 198.146.21.26 >> traceroute to 198.146.21.26 (198.146.21.26), 30 hops max, 38 byte packets >> 1 regina-GE1-2.cac.washington.edu (128.95.219.100) 4.395 ms 0.986 ms >> 2 uwbr2-GE2-0.cac.washington.edu (140.142.155.24) 0.326 ms 0.310 ms >> 3 cnsp1-wes-GE1-0.pnw-gigapop.net (198.107.150.1) 1.305 ms 1.113 ms >> 4 so-1-2-2.a07.sttlwa01.us.ra.verio.net (204.203.3.1) 4.219 ms 4.308 >> 5 ge-6-2-0.r03.sttlwa01.us.bb.verio.net (129.250.28.1) 4.096 ms 6.462 >> 6 p4-5-0-0.r06.plalca01.us.bb.verio.net (129.250.3.89) 25.469 ms >> 7 p4-0-0.r05.plalca01.us.bb.verio.net (129.250.2.129) 23.593 ms 22.371 >> 8 svl-brdr-01.inet.qwest.net (205.171.4.45) 24.093 ms 25.967 ms >> 9 svl-core-03.inet.qwest.net (205.171.14.109) 27.487 ms 22.669 ms >> 10 svl-core-01.inet.qwest.net (205.171.14.121) 22.500 ms 24.719 ms >> 11 chi-core-03.inet.qwest.net (205.171.8.50) 62.208 ms 55.153 ms >> 12 chi-core-01.inet.qwest.net (205.171.20.173) 57.742 ms 54.672 ms >> 13 chi-edge-01.inet.qwest.net (205.171.20.34) 54.261 ms 58.971 ms >> 14 208.46.63.202 (208.46.63.202) 88.583 ms 69.619 ms 67.605 ms >> 15 208.63.128.3 (208.63.128.3) 70.551 ms 67.581 ms 69.375 ms >> 16 208.63.128.1 (208.63.128.1) 65.115 ms 70.951 ms 66.083 ms >> 17 208.63.128.3 (208.63.128.3) 67.628 ms 65.488 ms 68.418 ms >> 18 208.63.128.1 (208.63.128.1) 72.197 ms 71.422 ms 69.517 ms >> 19 208.63.128.3 (208.63.128.3) 68.539 ms 68.976 ms 67.911 ms >> 20 208.63.128.1 (208.63.128.1) 72.373 ms 67.838 ms 66.468 ms >> 21 208.63.128.3 (208.63.128.3) 67.040 ms 69.136 ms 67.631 ms >> 22 208.63.128.1 (208.63.128.1) 66.317 ms 83.947 ms 70.693 ms >> 23 208.63.128.3 (208.63.128.3) 66.865 ms 69.521 ms 69.760 ms >> 24 208.63.128.1 (208.63.128.1) 69.604 ms 67.534 ms 70.447 ms >> 25 208.63.128.3 (208.63.128.3) 68.285 ms 69.772 ms 67.721 ms >> 26 208.63.128.1 (208.63.128.1) 71.915 ms 69.530 ms 72.403 ms >> 27 208.63.128.3 (208.63.128.3) 111.475 ms 69.670 ms 69.267 ms >> 28 208.63.128.1 (208.63.128.1) 68.883 ms 67.147 ms 72.106 ms >> 29 208.63.128.3 (208.63.128.3) 69.842 ms 67.889 ms 66.944 ms >> 30 208.63.128.1 (208.63.128.1) 70.986 ms 73.124 ms 68.452 ms >> >> >> >> > >-- >Stephen J. Wilcox >IP Services Manager, Opal Telecom >http://www.opaltelecom.co.uk/ >Tel: 0161 222 2000 >Fax: 0161 222 2008 > > Marshall Eubanks tme(a)21rst-century.com

1 0

looping traceroutes
by Ratul Mahajan 19 Sep '01

19 Sep '01

while playing around with traceroutes for a measurement study of bgp, i often come across the traceroute outputs similar to those appended below. i don't have a reasonable explanation of such behaviour (i don't think these are routing loops; they are not transient in any case). i am hoping someone on the list has a hang of traceroute implementations, and provide insights into under what circumstances this might happen. thanks, -- ratul -------------- $ traceroute 200.13.39.1 traceroute to 200.13.39.1 (200.13.39.1), 30 hops max, 38 byte packets 1 regina-GE1-2.cac.washington.edu (128.95.219.100) 1.098 ms 1.233 ms 2 uwbr2-GE3-0.cac.washington.edu (140.142.153.24) 0.349 ms 0.377 ms 3 cnsp1-wes-GE1-0.pnw-gigapop.net (198.107.150.1) 1.561 ms 1.005 ms 4 so-1-2-2.a07.sttlwa01.us.ra.verio.net (204.203.3.1) 21.690 ms 6.076 5 ge-6-2-0.r03.sttlwa01.us.bb.verio.net (129.250.28.1) 8.481 ms 8.756 6 p4-7-2-0.r06.plalca01.us.bb.verio.net (129.250.3.138) 29.934 ms 7 p16-3-0-0.r00.plalca01.us.bb.verio.net (129.250.2.162) 26.740 ms 8 p4-0.francetelecom.plalca01.us.bb.verio.net (129.250.9.134) 23.058 ms 9 P4-3.DALBB1.Dallas.opentransit.net (193.251.132.221) 84.523 ms 10 P5-1.FWHBB2.Fort-worth.opentransit.net (193.251.132.213) 86.653 ms 11 Sr9-0-0.FWHAR1.Fort-worth.opentransit.net (193.251.132.227) 88.507 ms 12 193.251.133.117 (193.251.133.117) 115.472 ms * 116.554 ms 13 193.251.133.117 (193.251.133.117) 145.386 ms 147.224 ms 148.333 ms 14 193.251.133.117 (193.251.133.117) 178.751 ms 172.224 ms * 15 193.251.133.117 (193.251.133.117) 208.640 ms 203.841 ms 199.946 ms 16 193.251.133.117 (193.251.133.117) 231.618 ms 233.234 ms 229.844 ms 17 193.251.133.117 (193.251.133.117) 259.227 ms 258.488 ms 262.034 ms 18 193.251.133.117 (193.251.133.117) 288.661 ms 292.598 ms 288.129 ms 19 193.251.133.117 (193.251.133.117) 321.982 ms 320.806 ms 318.364 ms 20 193.251.133.117 (193.251.133.117) 350.245 ms 349.834 ms 540.883 ms 21 193.251.133.117 (193.251.133.117) 539.971 ms 410.838 ms 419.743 ms 22 193.251.133.117 (193.251.133.117) 468.291 ms 409.761 ms 406.256 ms 23 193.251.133.117 (193.251.133.117) 432.990 ms 439.589 ms 434.184 ms 24 * 193.251.133.117 (193.251.133.117) 466.399 ms 465.287 ms 25 193.251.133.117 (193.251.133.117) 500.719 ms 498.601 ms 499.957 ms 26 193.251.133.117 (193.251.133.117) 530.089 ms 527.642 ms 528.999 ms 27 193.251.133.117 (193.251.133.117) 556.208 ms 555.552 ms 557.387 ms 28 193.251.133.117 (193.251.133.117) 586.776 ms 584.171 ms 586.944 ms 29 193.251.133.117 (193.251.133.117) 608.677 ms 610.789 ms 618.232 ms 30 193.251.133.117 (193.251.133.117) 641.141 ms 643.149 ms 639.050 ms ---------- $ traceroute 198.146.21.26 traceroute to 198.146.21.26 (198.146.21.26), 30 hops max, 38 byte packets 1 regina-GE1-2.cac.washington.edu (128.95.219.100) 4.395 ms 0.986 ms 2 uwbr2-GE2-0.cac.washington.edu (140.142.155.24) 0.326 ms 0.310 ms 3 cnsp1-wes-GE1-0.pnw-gigapop.net (198.107.150.1) 1.305 ms 1.113 ms 4 so-1-2-2.a07.sttlwa01.us.ra.verio.net (204.203.3.1) 4.219 ms 4.308 5 ge-6-2-0.r03.sttlwa01.us.bb.verio.net (129.250.28.1) 4.096 ms 6.462 6 p4-5-0-0.r06.plalca01.us.bb.verio.net (129.250.3.89) 25.469 ms 7 p4-0-0.r05.plalca01.us.bb.verio.net (129.250.2.129) 23.593 ms 22.371 8 svl-brdr-01.inet.qwest.net (205.171.4.45) 24.093 ms 25.967 ms 9 svl-core-03.inet.qwest.net (205.171.14.109) 27.487 ms 22.669 ms 10 svl-core-01.inet.qwest.net (205.171.14.121) 22.500 ms 24.719 ms 11 chi-core-03.inet.qwest.net (205.171.8.50) 62.208 ms 55.153 ms 12 chi-core-01.inet.qwest.net (205.171.20.173) 57.742 ms 54.672 ms 13 chi-edge-01.inet.qwest.net (205.171.20.34) 54.261 ms 58.971 ms 14 208.46.63.202 (208.46.63.202) 88.583 ms 69.619 ms 67.605 ms 15 208.63.128.3 (208.63.128.3) 70.551 ms 67.581 ms 69.375 ms 16 208.63.128.1 (208.63.128.1) 65.115 ms 70.951 ms 66.083 ms 17 208.63.128.3 (208.63.128.3) 67.628 ms 65.488 ms 68.418 ms 18 208.63.128.1 (208.63.128.1) 72.197 ms 71.422 ms 69.517 ms 19 208.63.128.3 (208.63.128.3) 68.539 ms 68.976 ms 67.911 ms 20 208.63.128.1 (208.63.128.1) 72.373 ms 67.838 ms 66.468 ms 21 208.63.128.3 (208.63.128.3) 67.040 ms 69.136 ms 67.631 ms 22 208.63.128.1 (208.63.128.1) 66.317 ms 83.947 ms 70.693 ms 23 208.63.128.3 (208.63.128.3) 66.865 ms 69.521 ms 69.760 ms 24 208.63.128.1 (208.63.128.1) 69.604 ms 67.534 ms 70.447 ms 25 208.63.128.3 (208.63.128.3) 68.285 ms 69.772 ms 67.721 ms 26 208.63.128.1 (208.63.128.1) 71.915 ms 69.530 ms 72.403 ms 27 208.63.128.3 (208.63.128.3) 111.475 ms 69.670 ms 69.267 ms 28 208.63.128.1 (208.63.128.1) 68.883 ms 67.147 ms 72.106 ms 29 208.63.128.3 (208.63.128.3) 69.842 ms 67.889 ms 66.944 ms 30 208.63.128.1 (208.63.128.1) 70.986 ms 73.124 ms 68.452 ms

2 1

Fw: NIPC Advisory 01-021, "Potential DDoS Attacks"
by Mike Lewinski 18 Sep '01

18 Sep '01

----- Original Message ----- From: "VanMeter, John" <John.VanMeter(a)ost.dot.gov> To: "Incidents (E-mail)" <INCIDENTS(a)SECURITYFOCUS.COM> Sent: Tuesday, September 18, 2001 4:12 AM Subject: NIPC Advisory 01-021, "Potential DDoS Attacks" > > > National Infrastructure Protection Center > "Potential Distributed Denial of Service (DDoS) Attacks" > Advisory 01-021 > 17 September 2001 > > The National Infrastructure Protection Center (NIPC) expects an increase in > Distributed Denial of Service (DDoS) attacks. NIPC Advisory 01-020, > "Increased Cyber Awareness" dated September 14, 2001 warned of threatened > vigilante hacking activity against organizations associated with the > perceived perpetrators of the September 11, 2001 terror attacks. > On September 12, 2001, a group of hackers named the Dispatchers claimed they > had already begun network operations against information infrastructure > components such as routers. The Dispatchers stated they were targeting the > communications and finance infrastructures. They also predicted that they > would be prepared for increased operations on or about Tuesday, September > 18, 2001. > There is the opportunity for significant collateral damage to any computer > network and telecommunications infrastructure that does not have current > countermeasures in place. The Dispatchers claim to have over 1,000 machines > under their control for the attacks. It is likely that the attackers will > mask their operations by using the IP addresses and pirated systems of > uninvolved third parties. > System administrators are encouraged to check their systems for zombie agent > software and ensure they institute best practices such as ingress and egress > filtering. The NIPC has made available the "Find DDoS" tool to determine if > your computer has been infected by the most common DDoS agents. The tool > may be downloaded from the following website: > http://www.nipc.gov/warnings/advisories/2000/00-055.htm. > Additionally, a list of best practices is available from the CERT/CC > website, located at: > http://www.cert.org/security-improvement. > Recipients of this advisory are encouraged to report computer intrusions to > their local FBI office > (http://www.fbi.gov/contact/fo/fo.htm) or the NIPC, and to the other > appropriate authorities. Incidents may be reported online at > http://www.nipc.gov/incident/cirr.htm. The .NIPC Watch and Warning Unit > can be reached at (202) 323-3204/3205/3206 or nipc.watch(a)fbi.gov. > > > > > ---------------------------------------------------------------------- ------ > This list is provided by the SecurityFocus ARIS analyzer service. > For more information on this free incident handling, management > and tracking system please see: http://aris.securityfocus.com > >

1 0

Somebody Doesn't Like QwestOutage.Com
by Allen Gwinn 18 Sep '01

18 Sep '01

The firewall is reporting SYN floods all across our class C :) They'll eventually give up and go away (or get caught), so keep trying and you'll eventually be able to access it. Allen Gwinn

1 0

Pattern matching odd HTTP request
by Jake Khuon 18 Sep '01

18 Sep '01

Anyone seeing a lot of these in their webserver logs? 208.202.180.4 - - [18/Sep/2001:11:19:31 -0700] "-" 408 - I'm attempting to pattern match this on my cisco so I can drop the packets at the front door. I can't seem to get a good pattern. Firing up snoop yields: ETHER: ----- Ether Header ----- ETHER: ETHER: Packet 262 arrived at 11:35:57.88 ETHER: Packet size = 60 bytes ETHER: Destination = 8:0:20:9d:e1:8a, Sun ETHER: Source = 0:1:96:24:c2:41, ETHER: Ethertype = 0800 (IP) ETHER: IP: ----- IP Header ----- IP: IP: Version = 4 IP: Header length = 20 bytes IP: Type of service = 0x00 IP: xxx. .... = 0 (precedence) IP: ...0 .... = normal delay IP: .... 0... = normal throughput IP: .... .0.. = normal reliability IP: Total length = 40 bytes IP: Identification = 19380 IP: Flags = 0x4 IP: .1.. .... = do not fragment IP: ..0. .... = last fragment IP: Fragment offset = 0 bytes IP: Time to live = 122 seconds/hops IP: Protocol = 6 (TCP) IP: Header checksum = 5ca8 IP: Source address = 208.178.66.12, 208.178.66.12 IP: Destination address = 208.178.117.2, Espresso.NEEBU.Net IP: No options IP: TCP: ----- TCP Header ----- TCP: TCP: Source port = 3082 TCP: Destination port = 80 (HTTP) TCP: Sequence number = 1100924065 TCP: Acknowledgement number = 2712346555 TCP: Data offset = 20 bytes TCP: Flags = 0x10 TCP: ..0. .... = No urgent pointer TCP: ...1 .... = Acknowledgement TCP: .... 0... = No push TCP: .... .0.. = No reset TCP: .... ..0. = No Syn TCP: .... ...0 = No Fin TCP: Window = 8760 TCP: Checksum = 0x6128 TCP: Urgent pointer = 0 TCP: No options TCP: HTTP: ----- HTTP: ----- HTTP: HTTP: "" HTTP: 0: 0800 209d e18a 0001 9624 c241 0800 4500 .. ......$.A..E. 16: 0028 4bb4 4000 7a06 5ca8 d0b2 420c d0b2 .(K.@.z.\...B... 32: 7502 0c0a 0050 419e c4a1 a1ab 1fbb 5010 u....PA.......P. 48: 2238 6128 0000 0000 0000 0000 "8a(........ -- /*====================[ Jake Khuon <khuon(a)GBLX.Net> ]======================+ | Chief Global Data Network Management Architect /~_ |_ () |3 /-\ |_ | | VOX: +1 (425) 391-2262 Fax: +1 (425) 391-6772 \_| C R O S S I N G | +=============[ 900 4th. Ave., Floor 12, Seattle, WA 98164 ]=============*/

6 8