- NANOG - lists.nanog.org

RE: Move all 9-1-1 to 8-5-5
by McBurnett, Jim 11 Mar '03

11 Mar '03

After working at a CLEC for a while, I must say that I know of very few PBXs that can do this, that the avg customer can afford.. Of course the BIG Lucent Definity series, maybe a few of it's peers.. But the Lucent/AT&T partner/Magix systems, I am nearly positive(99.9%) they can't.. And forget about those 4 line toshiba's..... Anyway that is not a discussion for this list... Jim >-----Original Message----- >From: Mark Segal [mailto:MSegal@FUTUREWAY.CA] >Sent: Tuesday, March 11, 2003 9:04 AM >To: nanog(a)merit.edu >Subject: RE: Move all 9-1-1 to 8-5-5 > > > >> Whenever the North American Numbering Planning Administration >> releases a new toll-free prefix (e.g. 1-800, 1-888, 1-877, >> 1-866) there is always a lengthy delay for individuals >> operating some telephone switches to update their routing >> tables. Its common to be in hotels, and find the hotel PBX >> doesn't recognize a recent toll-free prefix. > >Yes.. But most people don't run translations for all NPA-NXXs >on their 4 >line PBX.... > >Regards, >Mark > >-- >Mark Segal >Director, Data Services >Futureway Communications Inc. >Tel: (905)326-1570 > > >> >> So to "fix" this problem, why don't we move all 9-1-1 numbers >> to the new toll-free prefix, which will break stuff for >> people who don't update their PBX's promptly. When they find >> out they can't report a fire in the hotel because their PBX >> is blocking the new prefix, then they'll fix the PBX. >> >> Let's get real, no one is going to break any "critical" >> resource just for the purpose of making people fix their systems. >> >> >> Rob's bogon lists are good, but unless you have the processes >> in place to keep it update to date (or hire an consulting >> firm to do it for you), its about as useful as putting a list >> of "invalid" phone numbers in your PBX. The lists change all >> the time, and unless you are a full-time LERG expert, it will >> probably get quickly out of date. >> >> Of course, we can always use LDAP to keep all the PBX's updated. >> >

1 0

RE: Issue with 208.192.0.0/8 - 208.196.93.0/24?
by McBurnett, Jim 11 Mar '03

11 Mar '03

Easy, question.. Sure I could do that, I could run NMAP, Nessus, or any number of probes to check the validity of the host reachability. N-Stealth... and the list goes on. BUT if a host is denying pings from the world round and it stops trace a couple hops away maybe a BOGON filter or ACL or........ Well If I can't http to it, and I can't ping it from multiple peering points, there is a filter somewhere.. It can't even be accessed via the Worldcom UUNet network.. HMMMM.. Yeah you can telnet to it... Yeah I got to it via telnet... Anyway.. Normally if you can't Ping it and can't HTTP to a web server.... J >-----Original Message----- >From: alex(a)yuriev.com [mailto:alex@yuriev.com] >Sent: Tuesday, March 11, 2003 8:50 AM >To: McBurnett, Jim >Cc: chuck goolsbee; nanog(a)merit.edu >Subject: RE: Issue with 208.192.0.0/8 - 208.196.93.0/24? > > >> >> Is anyone from Alter.net lurking? >> Just for grins I went to the DIGEX looking glass and I could >not ping it >> from MAE-Central, PAIX , MAE-East and also from AT&T Cerf router.... >> below are some of the traces.. Always dies on Alter... I wonder..... >> Alter? > >Brilliant. Why did not you try "telnet <target.ip> 80"? > >Just because random packets spewed by traceroute are dropped >on the floor >does not mean that the site is dead. > >Alex > >

1 0

RE: 69/8...this sucks -- Centralizing filtering..
by Michael Whisenant 11 Mar '03

11 Mar '03

Jon et al, First I appreciate your message that you sent to us at NASA late Friday regarding a new address block that you received from ARIN. In that message you suggest that the issue was a BOGON route filter that had not been updated. Then without allowing sufficient time to respond to your message (you sent it to an administrative account and not the NOC) you decided to flame NASA. You could reach MANY NASA locations, but those at one particular center, and that issue was related to a firewall update at ONLY one particular center. This filter was placed in after August when the cental bogon was removed at the ingress to the network. If you feel that you have any issue reaching a NASA resource then you can send a message to noc(a)nisn.nasa.gov and/or the tech/org/noc POC on any address space. NISN is NASA's ISP and as such announce via AS297 that address space. > Now, how can we force that? Sufficient reward for doing so, or > pain for failure. Evidently "some people can't reach you" isn't > enough pain, and having full reachability isn't enough reward. I think the only way that's relatively guaranteed to be effective is to move a critical resource (like the gtld-servers) into new IP blocks when previously reserved blocks are assigned to RIR's. I still have a couple hundred thousand IPs to check (I'm going to step up the pace and see if I can get through the list today), but I already have a list of several hundred IPs in networks that ignore 69/8. The list includes such networks as NASA, the US DoD, and networks in China, Russia, and Poland. Those are just a few that I've done manual whois's for. I haven't decided yet whether I'll send automated messages to all the broken networks and give them time to respond and fix their filters, or just post them all to NANOG when the list is complete. Are people interested in seeing the full list (at least the ones I find) of networks that filter 69/8? Does Atlantic.Net get an ARIN discount for doing all this leg work? :) ---------------------------------------------------------------------- Jon Lewis *jlewis(a)lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

3 3

RE: Move all 9-1-1 to 8-5-5
by Mark Segal 11 Mar '03

11 Mar '03

> Whenever the North American Numbering Planning Administration > releases a new toll-free prefix (e.g. 1-800, 1-888, 1-877, > 1-866) there is always a lengthy delay for individuals > operating some telephone switches to update their routing > tables. Its common to be in hotels, and find the hotel PBX > doesn't recognize a recent toll-free prefix. Yes.. But most people don't run translations for all NPA-NXXs on their 4 line PBX.... Regards, Mark -- Mark Segal Director, Data Services Futureway Communications Inc. Tel: (905)326-1570 > > So to "fix" this problem, why don't we move all 9-1-1 numbers > to the new toll-free prefix, which will break stuff for > people who don't update their PBX's promptly. When they find > out they can't report a fire in the hotel because their PBX > is blocking the new prefix, then they'll fix the PBX. > > Let's get real, no one is going to break any "critical" > resource just for the purpose of making people fix their systems. > > > Rob's bogon lists are good, but unless you have the processes > in place to keep it update to date (or hire an consulting > firm to do it for you), its about as useful as putting a list > of "invalid" phone numbers in your PBX. The lists change all > the time, and unless you are a full-time LERG expert, it will > probably get quickly out of date. > > Of course, we can always use LDAP to keep all the PBX's updated. >

2 1

RE: Issue with 208.192.0.0/8 - 208.196.93.0/24?
by Callis, Adam 11 Mar '03

11 Mar '03

>From your traceroute, you ascertain that the traffic is traversing the UUNET Backbone and is stopping just past the edge of the UUNET GW (Gateway) router as it leaves the UUNET Backbone. Thanks, Adam -----Original Message----- From: McBurnett, Jim [mailto:jmcburnett@msmgmt.com] Sent: Tuesday, March 11, 2003 8:43 AM To: chuck goolsbee; nanog(a)merit.edu Subject: RE: Issue with 208.192.0.0/8 - 208.196.93.0/24? Is anyone from Alter.net lurking? Just for grins I went to the DIGEX looking glass and I could not ping it from MAE-Central, PAIX , MAE-East and also from AT&T Cerf router.... below are some of the traces.. Always dies on Alter... I wonder..... Alter? route-server>trac 208.196.93.204 Type escape sequence to abort. Tracing the route to ecobeauty.org (208.196.93.204) 1 mdf1-gsr12-1-gig-1-1.lax1.attens.net (12.129.192.237) [AS 17233] 0 msec 4 msec 0 msec 2 mdf1-gsr12-1-gig-1-1.lax1.attens.net (12.129.192.237) [AS 17233] 0 msec 0 msec 0 msec 3 gar3-p320.la2ca.ip.att.net (12.122.255.249) [AS 7018] 0 msec 4 msec 0 msec 4 gbr5-p90.la2ca.ip.att.net (12.123.28.193) [AS 7018] 4 msec 0 msec 0 msec 5 tbr2-p013501.la2ca.ip.att.net (12.122.11.153) [AS 7018] 4 msec 0 msec 4 msec 6 ggr1-p3100.la2ca.ip.att.net (12.122.11.222) [AS 7018] 0 msec 4 msec 4 msec 7 POS4-3.BR1.LAX9.ALTER.NET (204.255.168.61) [AS 701] 4 msec 4 msec 4 msec 8 0.so-0-1-0.XL2.LAX9.ALTER.NET (152.63.113.18) [AS 701] 4 msec 4 msec 4 msec 9 0.so-0-0-0.TL2.LAX9.ALTER.NET (152.63.115.146) [AS 701] 4 msec 4 msec 4 msec 10 0.so-6-0-0.TL2.NYC9.ALTER.NET (152.63.13.10) [AS 701] 76 msec 76 msec 76 msec 11 0.so-3-0-0.XL2.NYC1.ALTER.NET (152.63.29.113) [AS 701] 76 msec 76 msec 76 msec 12 0.so-0-0-0.XR2.NYC1.ALTER.NET (152.63.19.97) [AS 701] 76 msec 76 msec 76 msec 13 208.ATM7-0.GW11.NYC1.ALTER.NET (152.63.29.189) [AS 701] 76 msec 80 msec 76 mse c 14 * * * and it dies.. 03/11/03 08:28:24 Fast traceroute 208.196.93.204 Trace 208.196.93.204 ... 1 66.191.223.2 0ms 0ms 0ms TTL: 0 (cpe-66-191-223-002.spart.sc.charter.com ok) 2 66.168.32.41 0ms 0ms 0ms TTL: 0 (cpe-66-168-32-041.spart.sc.charter.com ok) 3 12.123.21.78 10ms 0ms 0ms TTL: 0 (gbr6-p80.attga.ip.att.net bogus rDNS: host not found [authoritative]) 4 12.122.12.25 10ms 0ms 0ms TTL: 0 (tbr1-p013601.attga.ip.att.net bogus rDNS: host not found [authoritative]) 5 12.122.12.30 0ms 10ms 0ms TTL: 0 (ggr1-p340.attga.ip.att.net bogus rDNS: host not found [authoritative]) 6 204.255.174.149 0ms 10ms 10ms TTL: 0 (POS5-2.BR2.ATL5.ALTER.NET ok) 7 152.63.82.194 10ms 0ms 10ms TTL: 0 (0.so-2-3-0.XL2.ATL5.ALTER.NET ok) 8 152.63.10.106 0ms 10ms 10ms TTL: 0 (0.so-0-0-0.TL2.ATL5.ALTER.NET ok) 9 152.63.146.42 20ms 20ms 20ms TTL: 0 (0.so-7-0-0.TL2.DCA6.ALTER.NET ok) 10 152.63.34.130 20ms 20ms 20ms TTL: 0 (0.so-5-0-0.CL2.DCA1.ALTER.NET ok) 11 152.63.42.110 30ms 20ms 20ms TTL: 0 (194.at-4-0-0.CL2.PHL1.ALTER.NET ok) 12 152.63.38.201 20ms 20ms 30ms TTL: 0 (POS7-0.GW6.PHL1.ALTER.NET ok) And away to the bit bucket... >-----Original Message----- >From: chuck goolsbee [mailto:chucklist@forest.net] >Sent: Monday, March 10, 2003 10:14 PM >To: nanog(a)merit.edu >Subject: Issue with 208.192.0.0/8 - 208.196.93.0/24? > > > >Forgive the intrusion... > >We have a customer who uses some merchant services off of >208.196.93.204, which seems to be unreachable via any location I try. >Emails to UUnet's NOC are unaswered and the guy I talked to on the >phone @ UU wouldn't open a ticket because I'm not a customer (but his >traces were dying in the same place as mine: > >207.ATM6-0.GW11.NYC1.ALTER.NET (152.63.29.185)) > >Can anybody out there hit that IP (208.196.93.204) at the moment? Or >indeed much of anything in that /8? > > >-- >--chuck goolsbee >geek wrangler, digital.forest inc, bothell, wa <http://www.forest.net> >

1 0

RE: Issue with 208.192.0.0/8 - 208.196.93.0/24?
by McBurnett, Jim 11 Mar '03

11 Mar '03

Is anyone from Alter.net lurking? Just for grins I went to the DIGEX looking glass and I could not ping it from MAE-Central, PAIX , MAE-East and also from AT&T Cerf router.... below are some of the traces.. Always dies on Alter... I wonder..... Alter? route-server>trac 208.196.93.204 Type escape sequence to abort. Tracing the route to ecobeauty.org (208.196.93.204) 1 mdf1-gsr12-1-gig-1-1.lax1.attens.net (12.129.192.237) [AS 17233] 0 msec 4 msec 0 msec 2 mdf1-gsr12-1-gig-1-1.lax1.attens.net (12.129.192.237) [AS 17233] 0 msec 0 msec 0 msec 3 gar3-p320.la2ca.ip.att.net (12.122.255.249) [AS 7018] 0 msec 4 msec 0 msec 4 gbr5-p90.la2ca.ip.att.net (12.123.28.193) [AS 7018] 4 msec 0 msec 0 msec 5 tbr2-p013501.la2ca.ip.att.net (12.122.11.153) [AS 7018] 4 msec 0 msec 4 msec 6 ggr1-p3100.la2ca.ip.att.net (12.122.11.222) [AS 7018] 0 msec 4 msec 4 msec 7 POS4-3.BR1.LAX9.ALTER.NET (204.255.168.61) [AS 701] 4 msec 4 msec 4 msec 8 0.so-0-1-0.XL2.LAX9.ALTER.NET (152.63.113.18) [AS 701] 4 msec 4 msec 4 msec 9 0.so-0-0-0.TL2.LAX9.ALTER.NET (152.63.115.146) [AS 701] 4 msec 4 msec 4 msec 10 0.so-6-0-0.TL2.NYC9.ALTER.NET (152.63.13.10) [AS 701] 76 msec 76 msec 76 msec 11 0.so-3-0-0.XL2.NYC1.ALTER.NET (152.63.29.113) [AS 701] 76 msec 76 msec 76 msec 12 0.so-0-0-0.XR2.NYC1.ALTER.NET (152.63.19.97) [AS 701] 76 msec 76 msec 76 msec 13 208.ATM7-0.GW11.NYC1.ALTER.NET (152.63.29.189) [AS 701] 76 msec 80 msec 76 mse c 14 * * * and it dies.. 03/11/03 08:28:24 Fast traceroute 208.196.93.204 Trace 208.196.93.204 ... 1 66.191.223.2 0ms 0ms 0ms TTL: 0 (cpe-66-191-223-002.spart.sc.charter.com ok) 2 66.168.32.41 0ms 0ms 0ms TTL: 0 (cpe-66-168-32-041.spart.sc.charter.com ok) 3 12.123.21.78 10ms 0ms 0ms TTL: 0 (gbr6-p80.attga.ip.att.net bogus rDNS: host not found [authoritative]) 4 12.122.12.25 10ms 0ms 0ms TTL: 0 (tbr1-p013601.attga.ip.att.net bogus rDNS: host not found [authoritative]) 5 12.122.12.30 0ms 10ms 0ms TTL: 0 (ggr1-p340.attga.ip.att.net bogus rDNS: host not found [authoritative]) 6 204.255.174.149 0ms 10ms 10ms TTL: 0 (POS5-2.BR2.ATL5.ALTER.NET ok) 7 152.63.82.194 10ms 0ms 10ms TTL: 0 (0.so-2-3-0.XL2.ATL5.ALTER.NET ok) 8 152.63.10.106 0ms 10ms 10ms TTL: 0 (0.so-0-0-0.TL2.ATL5.ALTER.NET ok) 9 152.63.146.42 20ms 20ms 20ms TTL: 0 (0.so-7-0-0.TL2.DCA6.ALTER.NET ok) 10 152.63.34.130 20ms 20ms 20ms TTL: 0 (0.so-5-0-0.CL2.DCA1.ALTER.NET ok) 11 152.63.42.110 30ms 20ms 20ms TTL: 0 (194.at-4-0-0.CL2.PHL1.ALTER.NET ok) 12 152.63.38.201 20ms 20ms 30ms TTL: 0 (POS7-0.GW6.PHL1.ALTER.NET ok) And away to the bit bucket... >-----Original Message----- >From: chuck goolsbee [mailto:chucklist@forest.net] >Sent: Monday, March 10, 2003 10:14 PM >To: nanog(a)merit.edu >Subject: Issue with 208.192.0.0/8 - 208.196.93.0/24? > > > >Forgive the intrusion... > >We have a customer who uses some merchant services off of >208.196.93.204, which seems to be unreachable via any location I try. >Emails to UUnet's NOC are unaswered and the guy I talked to on the >phone @ UU wouldn't open a ticket because I'm not a customer (but his >traces were dying in the same place as mine: > >207.ATM6-0.GW11.NYC1.ALTER.NET (152.63.29.185)) > >Can anybody out there hit that IP (208.196.93.204) at the moment? Or >indeed much of anything in that /8? > > >-- >--chuck goolsbee >geek wrangler, digital.forest inc, bothell, wa <http://www.forest.net> >

3 2

69/8...this sucks
by jlewis＠lewis.org 11 Mar '03

11 Mar '03

Atlantic.Net has just joined the 69/8 club of ARIN members with assignments in this IP block that's apparently in numerous outdated bogon filters. As I posted I'd do earlier if given space from this block, I've written some code to check reachability to a large number of remote IPs from 2 source IPs...one in one of our older ARIN blocks, one in the new 69 block. I'm feeding this code a very large list of known mail server IPs, and having it ping each IP...only it'll ignore /24's once reachability from both the old and new IPs has been established to an IP in that /24. It's only just getting started on the list, but I've already found dozens of networks that appear to be problems. I've hand confirmed a couple and sent off emails to the ARIN contacts. It looks like there are going to be so many networks to notify, I'll have to write some more code to automate these emails. What have others in this situation done? Are you actually assigning 69/8 IP's to unsuspecting customers and hoping they won't notice parts of the internet ignoring them? According to ARIN's whois server, there are 95 subdelegations for NET-69-0-0-0-0...we're the 95th. I don't know if ARIN has other "less tainted" IP space to give out, but something ought to be said/asked about this at the next meeting. I realize ARIN can't guarantee global routability of IP space, but should they continue to give out IP blocks they absolutely know are not fully routable on the internet today? ---------------------------------------------------------------------- Jon Lewis *jlewis(a)lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

12 19

Re: Move all 9-1-1 to 8-5-5
by Michael.Dillon＠radianz.com 11 Mar '03

11 Mar '03

>Rob's bogon lists are good, but unless you have the processes in place to >keep it update to date (or hire an consulting firm to do it for you), its >about as useful as putting a list of "invalid" phone numbers in your PBX. >The lists change all the time, and unless you are a full-time LERG expert, >it will probably get quickly out of date. >Of course, we can always use LDAP to keep all the PBX's updated. Well, we use DNS to keep all of our resolvers updated with the latest IP address changes and it works so well that most people never even think about what is happening under the hood unless they are renumbering. Compare this to what happens when the root hints file changes. In that case you need processes and people or, more likely, you wait until something breaks and then hire a consultant who updates your root hints file for a nice fee. This is not the model I would use to solve the bogon problem. --Michael Dillon

1 0

69/8 compelling content?
by Simon Waters 11 Mar '03

11 Mar '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Surely the guys with 69/8 merely need to acquire compelling content. Offer some free hosting to whatever your favourite busy free service is. Something like freechess.org, or even www.asstr.org ;-) I think starting with the root DNS is silly, start with what people really care about! I use to remove the games from my Office servers when they were short of space, amazing how quickly disk space returned, the same technique may work on larger scale. -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+bbs9GFXfHI9FVgYRAmUdAJ93Jy6e/+vvM+Gj6x8/XsJ90E0IJgCeIT0U XNwinPrjKf3jjzt8bzW9vU0= =BLJm -----END PGP SIGNATURE-----

1 0

RE: 69/8...this sucks -- Centralizing filtering..
by Dr. Jeffrey Race 11 Mar '03

11 Mar '03

On Mon, 10 Mar 2003 23:19:38 -0500, McBurnett, Jim wrote: >If you read PPML, there is a HUGE push via Owen DeLong's Policy >2003-1a to help with some aspects of the whois Contact.. >his policy is mainly based on the abuse contact, But I think may >get extended to all contacts eventually... >Owen- Wanta jump in here??? > >And-- if you feel strong enough to be flamed on the ARIN PPML list >propose a Policy based on your comments.. I for one agree with you.. Cleaning up the database, establishing good abuse contacts, and purging the abusers is the essential first step to the strategy I draft-outline in <http://www.camblab.com/misc/univ_std.txt>. I hope volunteers will replicate Owen's efforts at RIPE, APNIC and LACNIC. As for subject above, all those whose miserable life needs a little uplift, please turn to <http://www.camblab.com/nugget/slang2.pdf> for your delectation :) Jeffrey Race

1 0