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. 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.
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>
On Mon, 10 Mar 2003, chuck goolsbee wrote:
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:
traceroutes often die when there are firewalls and/or router acls
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?
the /8 is kinda large for me to test 'right now' but this one /32 looks ok: xxx.corp.us.uu.net:t 208.196.93.204 80 Trying 208.196.93.204... Connected to 208.196.93.204 (208.196.93.204). Escape character is '^]'. That seems to be a good port 80 connection. route-server.ip.att.net shows this prefix as: BGP routing table entry for 208.196.93.0/24, version 107200 Paths: (19 available, best #19, table Default-IP-Routing-Table) Advertised to non peer-group peers: 12.161.130.230 7018 701 14462, (received & used) Have you bothered to call ASN 14462 ? arin 14462 OrgName: EVS Holding Company, Inc. OrgID: EHC-8 Address: 1415 RT 70, Suite 620 City: Cherry Hill StateProv: NJ PostalCode: 08034 Country: US ASNumber: 14462 ASName: CYSHOP-COMMERCE ASHandle: AS14462 Comment: RegDate: 1999-12-16 Updated: 1999-12-16 TechHandle: MB745-ARIN TechName: Byrnes, Michael TechPhone: +1-856-429-9249 TechEmail: mikeb@cyshop.com Perhaps Michael Byrnes is lurking and can help you?
-- --chuck goolsbee geek wrangler, digital.forest inc, bothell, wa <http://www.forest.net>
OK... so I'm an idiot... end of a long day, apologies. The /8 was a jump to a bonehead conclusion on my part. The /24 & IP in question remains unreachable on any port from here, but I did get enough offlist clueXfours to follow up offlist and soothe our client for the time being. Thanks folks, -- --chuck goolsbee geek wrangler, digital.forest inc, bothell, wa <http://www.forest.net>
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Sean Donelan Sent: March 10, 2003 7:51 PM To: nanog@merit.edu Subject: 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.
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.
You're comparing two different situations, though: In your case, the people in the hotel that is doing the blocking will be the ones experiencing the problems. They notice that they can't reach 1-8xx-xxx-xxxx, so they call up the hotel management and yell. Hotel management calls the person in charge of their PBX, and the problem would be fixed. I could be wrong (hey, I'm in the DNS business, not the PSTN), but I can't imagine the 1-8xx number calling the hotel and getting the impression that the 1-8xx number's provider has problems... In the 69.0.0.0/8 case, though, the problem is bidirectional. You have people whose ISP/firewall/etc blocks access to 69.0.0.0/8 - presumably, if they can't reach some box on 69.0.0.0, they'll yell at their ISP (and, most likely, at the operator of the thing they're trying to reach, too, but said operator can tell them to yell at their ISP). But, you also have people on 69.0.0.0 who aren't able to reach other sites due to filtering on the other end, and those people are likely to yell at their ISP and blame their ISP for something the ISP can't fix. That second situation, I think, is the situation that this thread is about, and your hotel analogy doesn't address that. With the hotel analogy, basically, the people affected are the ones who have the relationship with the operator of the broken piece of hardware, not the ones with the 1-8xx number (though, if you want to be picky, you could argue they might lose a bit of business to this). With the 69.x.x.x situation, the people affected are the ones with the 69 IP space, and they don't have a relationship with whoever has the misconfigured hardware. Maybe moving the GTLD servers would be overkill... But certainly, the idea of asking Google or Yahoo to move seems like a good one. If people can't reach Google or Yahoo, they'll make their ISP look into the issue, and fix their filters. A random comment now I have been dragged into this thread: this issue is not new with 69.0.0.0/8. When we first got a block from 66.* from an ISP about two years ago, we had problems too with various people (mostly end users, though, I think) firewalling 66.*, and yet ARIN had been assigning 66.* blocks for probably a year or so before we got that IP space. Fortunately for us, though, most problems seemed to be people who wanted to reach us not being able to, and not us not being able to reach sites we wanted to talk to. Still, I suspect the Linux Firewall HOWTO was in large part responsible for the problems we had... Vivien -- Vivien M. vivienm@dyndns.org Assistant System Administrator Dynamic DNS Network Services http://www.dyndns.org/
participants (4)
-
Christopher L. Morrow -
chuck goolsbee -
Sean Donelan -
Vivien M.