Re: Spain was offline
Date: Thu, 31 Aug 2006 08:50:29 -0400 From: Joe Abley [EMAIL PROTECTED] Subject: Re: Spain was offline [ SNIP ] You seem to be suggesting that ISPs run stealth slaves for these kinds of zones. This may have been a useful pointer for ISPs in days gone by, but I think today it's impractical advice. How so? Anyone can get a zone and turn up [a-m] on-net and outperform (response and uptime) many of the existing instances of root servers. I'm quite confident it would work as designed. Where's Dean Anderson when you need him? -M -- Martin Hannigan(c) 617-388-2663 Renesys Corporation(w) 617-395-8574 Member of Technical Staff Network Operations [EMAIL PROTECTED]
Media reports (was: Spain was offline)
[EMAIL PROTECTED] host www.red.es www.red.es is an alias for web.red.es. web.red.es has address 194.69.254.50 No idea what happened, and I don't read spanish, According to red.es, they believe that a possible hardware failure caused a file to be corrupted during the update. When this was discovered, they shifted to a backup file. Details here for those who do read Spanish: http://www.noticias.info/asp/aspComunicados.asp?nid=214866src=0 --Michael Dillon
The Cidr Report
This report has been generated at Fri Sep 1 21:45:31 2006 AEST.
The report analyses the BGP Routing Table of an AS4637 (Reach) router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/as4637 for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
25-08-06193182 126201
26-08-06193359 126010
27-08-06193402 126171
28-08-06193535 126275
29-08-06193607 126251
30-08-06193619 126342
31-08-06193751 126363
01-09-06193923 126391
AS Summary
22917 Number of ASes in routing system
9613 Number of ASes announcing only one prefix
1468 Largest number of prefixes announced by an AS
AS7018 : ATT-INTERNET4 - ATT WorldNet Services
91405056 Largest address span announced by an AS (/32s)
AS721 : DISA-ASNBLK - DoD Network Information Center
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 01Sep06 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 194068 1263926767634.9% All ASes
AS4134 1270 268 100278.9% CHINANET-BACKBONE
No.31,Jin-rong Street
AS4755 975 69 90692.9% VSNL-AS Videsh Sanchar Nigam
Ltd. Autonomous System
AS18566 958 145 81384.9% COVAD - Covad Communications
Co.
AS4323 987 290 69770.6% TWTC - Time Warner Telecom,
Inc.
AS721991 310 68168.7% DISA-ASNBLK - DoD Network
Information Center
AS22773 695 52 64392.5% CCINET-2 - Cox Communications
Inc.
AS9498 803 178 62577.8% BBIL-AP BHARTI BT INTERNET
LTD.
AS6197 1028 487 54152.6% BATI-ATL - BellSouth Network
Solutions, Inc
AS7018 1468 950 51835.3% ATT-INTERNET4 - ATT WorldNet
Services
AS19262 692 187 50573.0% VZGNI-TRANSIT - Verizon
Internet Services Inc.
AS19916 563 65 49888.5% ASTRUM-0001 - OLM LLC
AS17488 529 47 48291.1% HATHWAY-NET-AP Hathway IP Over
Cable Internet
AS855562 86 47684.7% CANET-ASN-4 - Aliant Telecom
AS11492 731 287 44460.7% CABLEONE - CABLE ONE
AS17676 497 62 43587.5% JPNIC-JP-ASN-BLOCK Japan
Network Information Center
AS18101 447 23 42494.9% RIL-IDC Reliance Infocom Ltd
Internet Data Centre,
AS3602 510 105 40579.4% AS3602-RTI - Rogers Telecom
Inc.
AS4766 701 310 39155.8% KIXS-AS-KR Korea Telecom
AS812415 29 38693.0% ROGERS-CABLE - Rogers Cable
Inc.
AS15270 457 74 38383.8% AS-PAETEC-NET - PaeTec.net -a
division of
PaeTecCommunications, Inc.
AS22047 454 94 36079.3% VTR BANDA ANCHA S.A.
AS6467 399 60 33985.0% ESPIRECOMM - Xspedius
Communications Co.
AS4812 395 60 33584.8% CHINANET-SH-AP China Telecom
(Group)
AS16852 365 53 31285.5% FOCAL-CHICAGO - Focal Data
Communications of Illinois
AS9583 952 661 29130.6% SIFY-AS-IN Sify Limited
AS16814 329 44 28586.6% NSS S.A.
AS8151 770 486 28436.9% Uninet S.A. de C.V.
AS6517 410 129 28168.5% YIPESCOM - Yipes
Communications, Inc.
AS19115 366 95 27174.0% CHARTER-LEBANON - Charter
Communications
AS17849 425 155 27063.5% GINAMHANVIT-AS-KR hanvit ginam
broadcasting comm.
BGP Update Report
Copies of this report are mailed to: nanog@merit.edu [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
[NANOG] Cogent having problems
From the ISC: We have received a report of the Cogent Data Center in Herndon, VA having connectivity problems. It appears to be localized. No need to innundate them with phone calls, I am sure they are working on it. One of our readers, Colin, called into the data center: I called their support staff and got through to a guy who described the situation as a network problem 'affecting all traffic in their data center'. More on this situation if more develops... Update #1It appears that sometime on Wednesday that the problems were more widespread, as they had some latency problems up in New York as well, as reported by another reader. However it appears that the problems had been resolved as of Thursday. No report yet on if the problem at the Herndon, Virginia office has been resolved. Happy Fridays .myke
Re: [NANOG] Resolved: Cogent having problems
On 1 Sep 2006, at 16:22, Myke Lyons wrote: From the ISC: We have received a report of the Cogent Data Center in Herndon, VA having connectivity problems. It appears to be localized. No need to innundate them with phone calls, I am sure they are working on it. One of our readers, Colin, called into the data center: I called their support staff and got through to a guy who described the situation as a network problem 'affecting all traffic in their data center'. More on this situation if more develops... Update #1It appears that sometime on Wednesday that the problems were more widespread, as they had some latency problems up in New York as well, as reported by another reader. However it appears that the problems had been resolved as of Thursday. No report yet on if the problem at the Herndon, Virginia office has been resolved. Happy Fridays .myke Apparently it was only scheduled (poorly communicated) maintenance on fibre links. .myke
Re: [NANOG] Cogent having problems
Myke Lyons wrote: Update #1It appears that sometime on Wednesday that the problems were more widespread, as they had some latency problems up in New York as well, as reported by another reader. However it appears that the problems had been resolved as of Thursday. No report yet on if the problem at the Herndon, Virginia office has been resolved. Cogent have been broken since Monday. They apparently lost an OC-192 with ATT, making the rest of their network run like a dying dog. I was seeing some crazy latency cross the North-East on Tuesday and Wednesday, but it mostly cleared up yesterday - Tuesday was bad, so I had them turned off all day from Monday ~8pm. They've not yet called me back in response to my calls requesting a credit, or a reasonable explanation why the run a degraded service for four days. David
RE: comast email issues, who else has them?
On Thu, 31 Aug 2006, Tony Li wrote: I've taken the rather extreme approach of bouncing everything through Gmail first. Let's see them block Google. ;-) Patient: Doctor, Doctor, It hurts when I do this. Doctor: Don't do that. There are lots of Mail Service Providers. AOL, Comcast, Gmail, Yahoo, Outblaze, whoever, each have their own quirks and problems. All have blocked various sources including each other at one time or another. Some people complain about some of the decisions made by each of them; while other people applaud the same decisions. Perhaps people are using the wrong tools to solve the problems? Trying to forward from one account to another through spam filters is probably not a good idea, especially since the primary filtering mechanism used by most anti-spam technologies is based on the connecting host. You generally can't trust the originating IP address information of other hops, if they are even present. For example, Gmail doesn't include the originating IP address in its email which makes it even more difficult for spam filters to judge its reputation. If a system forwards unfiltered e-mail in today's Internet, it is forwarding spam, viruses, and other malicious stuff, and will likely continue to trip defensive controls on systems. Different tools such as fetchmail, multi-mailbox POP/IMAP clients, etc may be more appropriate in today's Internet. Bulk forwarding of unfiltered e-mail is probably not a good idea. If systems are going to forward e-mail, it may be a good idea to use spam filters BEFORE forwarding the messages and use a distinct forwarding IP connections for those messages so the receiver can treat those messages as pre-filtered and direct complaints about those messages to the forwarder for handling. There are several other mailing lists covering the topics of e-mail, e-mail forwarding, spam technologies, etc.
ATT (SBCGLOBAL) problems?
Apologies to the list, but, I'm at Witts End on this problem.Can someone from SBCGLOBAL with 1/2 a clue please contact me?I'm seeing an issue between dist4-g9-3.pltnca.sbcglobal.net andbras2-g9-0.pltnca.sbcglobal.net with intermittent complete packetloss... Matt's traceroute [v0.54]owen Fri Sep 1 08:56:21 2006Keys: D - Display mode R - Restart statistics Q - Quit Packets PingsHostname %Loss Rcv Snt Last Best Avg Worst 1. delong-sjca-02-e1.delong.sj.ca.us 1% 509 511 1 1 4 118 2. zy652-a.delong.sj.ca.us 1% 509 511 2 1 2 11 3. sms0.sc.meer.net 2% 503 511 232 21 180 1332 4. metro2-transit.sc.svcolo.com 1% 505 511 241 22 178 1343 5. 339.ge-5-1-1.er10a.sjc2.us.above.ne 2% 502 511 175 21 193 1344 6. so-2-0-0.mpr3.sjc2.us.above.net 3% 499 510 107 21 182 1307 7. so-3-0-0.mpr2.sjc7.us.above.net 4% 494 510 118 21 181 1316 8. ex2-p4-1.eqsjca.sbcglobal.net 2% 504 510 140 21 188 1345 9. bb1-p6-0.crscca.sbcglobal.net 2% 500 510 364 23 189 125610. bb2-p5-0.pltnca.sbcglobal.net 2% 503 510 193 24 183 127511. dist4-g9-3.pltnca.sbcglobal.net 5% 487 510 192 24 176 129212. bras2-g9-0.pltnca.sbcglobal.net 46% 276 510 140 25 190 132313. adsl-69-105-41-206.dsl.pltn13.pacbe 49% 264 510 107 33 191 109414. adsl-69-105-74-210.dsl.pltn13.pacbe 49% 263 510 45 35 200 1266I am seeing this problem from multiple locations when trying to reachdestination 69.105.74.210.Your technical support department refuses to escalate the issue unlessI can come up with the DSL phone number for the affected customer.I can be reached at 408-921-6984.Owen PGP.sig Description: This is a digitally signed message part
BCP Question: Handling trouble reports from non-customers
I think my previous post may have touched on a more global issue. Given the number of such posts I have seen over time, and, my experiences trying to report problems to other ISPs in the past, it seems to me that a high percentage of ISPs, especially the larger ones, simply don't allow for the possibility of a non-customer needing to report a problem with the ability to reach one of their customers. I'm curious how people feel about this. As I see it, there are a number of possible responses: 1. Don't help the person at all. Tell them to contact the customer they are trying to reach and have the customer report the problem. This seems, by far, to be the most popular approach in my experience, but, it makes for a very frustrating experience to the person reporting the problem. 2. Accept any trouble report and attempt to resolve it or determine that it is outside of your network. This approach is the least frustrating to the end user, but, probably creates a resource allocation and cost problem. 3. Have a procedure for triage which allows a quick determination if the problem appears to be within your network. Using that procedure, reject problems which appear to be outside of your network while accepting problems that appear to be within your network. It seems to me that option 3 probably poses the best cost/benefit tradeoff, but, it is the approach least taken from my observations. So, I figured I'd try and start a discussion on the topic and see what people thought. Feel free to comment on list or directly to me (I'll summarize), but, if you want to tell me I'm off-topic or whatever, please complain directly to me without bothering the rest of the people on the list. I believe that this is an operational issue within scope of Nanog, but, I can see the argument that it's a business practices question instead. Owen PGP.sig Description: This is a digitally signed message part
Re: Spain was offline
On 1-Sep-2006, at 02:11, Martin Hannigan wrote: You seem to be suggesting that ISPs run stealth slaves for these kinds of zones. This may have been a useful pointer for ISPs in days gone by, but I think today it's impractical advice. How so? Anyone can get a zone and turn up [a-m] on-net and outperform (response and uptime) many of the existing instances of root servers. The root servers are easy; the zone is tiny and the update frequency is miniscule. We were talking about TLD servers. Joe
Re: BCP Question: Handling trouble reports from non-customers
At 12:26 PM 9/1/2006, Owen DeLong wrote: I think my previous post may have touched on a more global issue. Given the number of such posts I have seen over time, and, my experiences trying to report problems to other ISPs in the past, it seems to me that a high percentage of ISPs, especially the larger ones, simply don't allow for the possibility of a non-customer needing to report a problem with the ability to reach one of their customers. I think its more of an issue of being able to get through to the right people as opposed to customers or non customers reporting problems. We had an issue with one large ILEC here in Canada recently (but similar problems in the past with others) where they did some upgrades to their radius servers that busted non PAP logins. Some of our older VPN devices used scripted logins so these all broke. We only were regular customers, so we tried our best to work through the front line tech support. Basically we got stuff like we dont support UNIX. You need to call UNIX for help we dont have terminal servers, there is nothing wrong with R-A-Y-D-E-E-U-S or even the circumference, and other crap that was an obvious 'jettison customer' leaf in the decision tree. It was an incredibly frustrating situation for 3 days despite asking to escalate etc. Ultimately, we discovered the issue had security issues, so we used that as a pretext to use a net-sec contact to pass on the info and it was acted on almost right away. In general, the dilemma seems to be this-- customer calls up saying stuff that makes no sense to the front line tech. Does front line tech pass each and every, the customer is saying our ION-Dilithium deflector array is misalligned and needs to be refilled with dark neutrino particles and You have a bogus next hop route in your IGP... Pass it up the food chain ? Or just dismiss it. The answer seems to be, if there is a bogus next hop issue, our second line will catch it on their own so dont bother second line if you cant figure it out. Whether its a good business decision or not, dont know but that seems to be the popular thing to do in my experience. ---Mike
Re: comast email issues, who else has them?
on Fri, Sep 01, 2006 at 11:45:53AM -0400, Sean Donelan wrote: For example, Gmail doesn't include the originating IP address in its email which makes it even more difficult for spam filters to judge its reputation. You misspelled makes it a veritable haven for 419 scammers. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/ rambling, amusements, edifications and suchlike: http://interrupt-driven.com/
Comcast contact available?
It seems you are null-routing traffic heading towards our /20. If there are any comcast chaps on this list, please drop me a mail - this has been going on for a few days now and we're having trouble getting it escalated to someone with sufficient access to check it. Thanks, Ras
Re: Spain was offline
At 12:37 PM 9/1/2006, Joe Abley wrote: On 1-Sep-2006, at 02:11, Martin Hannigan wrote: You seem to be suggesting that ISPs run stealth slaves for these kinds of zones. This may have been a useful pointer for ISPs in days gone by, but I think today it's impractical advice. How so? Anyone can get a zone and turn up [a-m] on-net and outperform (response and uptime) many of the existing instances of root servers. The root servers are easy; the zone is tiny and the update frequency is miniscule. We were talking about TLD servers. I can't get a TLD zone? But back to the root servers. Are you agreering with me that if I announce F and I root's netblocks inside of my own network that everyone would be ok with that? C'mon Joe, straight answer on that one. :) -M -- Martin Hannigan(c) 617-388-2663 Renesys Corporation(w) 617-395-8574 Member of Technical Staff Network Operations [EMAIL PROTECTED]
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to [EMAIL PROTECTED] For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith [EMAIL PROTECTED]. Routing Table Report 04:00 +10GMT Sat 02 Sep, 2006 Analysis Summary BGP routing table entries examined: 196663 Prefixes after maximum aggregation: 107394 Unique aggregates announced to Internet: 95429 Total ASes present in the Internet Routing Table: 23014 Origin-only ASes present in the Internet Routing Table: 20043 Origin ASes announcing only one prefix:9613 Transit ASes present in the Internet Routing Table:2971 Transit-only ASes present in the Internet Routing Table: 64 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 29 Max AS path prepend of ASN (36728) 27 Prefixes from unregistered ASNs in the Routing Table: 4 Unregistered ASNs in the Routing Table: 4 Special use prefixes present in the Routing Table:1 Prefixes being announced from unallocated address space: 9 Number of addresses announced to Internet: 1578761004 Equivalent to 94 /8s, 25 /16s and 251 /24s Percentage of available address space announced: 42.6 Percentage of allocated address space announced: 60.4 Percentage of available address space allocated: 70.5 Total number of prefixes smaller than registry allocations: 98096 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:43107 Total APNIC prefixes after maximum aggregation: 17356 Prefixes being announced from the APNIC address blocks: 40746 Unique aggregates announced from the APNIC address blocks:18324 APNIC Region origin ASes present in the Internet Routing Table:2684 APNIC Region origin ASes announcing only one prefix:763 APNIC Region transit ASes present in the Internet Routing Table:400 Average APNIC Region AS path length visible:3.5 Max APNIC Region AS path length visible: 24 Number of APNIC addresses announced to Internet: 261990496 Equivalent to 15 /8s, 157 /16s and 168 /24s Percentage of available APNIC address space announced: 81.9 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911 APNIC Address Blocks 58/7, 60/7, 121/8, 122/7, 124/7, 126/8, 202/7 210/7, 218/7, 220/7 and 222/8 ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes: 99336 Total ARIN prefixes after maximum aggregation:58944 Prefixes being announced from the ARIN address blocks:73039 Unique aggregates announced from the ARIN address blocks: 27557 ARIN Region origin ASes present in the Internet Routing Table:10946 ARIN Region origin ASes announcing only one prefix:4131 ARIN Region transit ASes present in the Internet Routing Table:1010 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 29 Number of ARIN addresses announced to Internet: 296600064 Equivalent to 17 /8s, 173 /16s and 194 /24s Percentage of available ARIN address space announced: 76.9 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959 ARIN Address Blocks24/8, 63/8, 64/5, 72/6, 76/8, 199/8, 204/6, 208/7 and 216/8 RIPE Region Analysis Summary Prefixes being announced by RIPE Region ASes: 39576 Total RIPE prefixes after maximum aggregation:26409 Prefixes being announced from the RIPE address blocks:36515 Unique aggregates announced from the RIPE address blocks: 24624 RIPE Region origin ASes present in the Internet Routing Table: 8440 RIPE Region origin ASes announcing only one prefix:4436 RIPE Region transit ASes present in the
Re: Spain was offline
On 1-Sep-2006, at 13:47, Martin Hannigan wrote: I can't get a TLD zone? *You* can do anything, Marty! You are the man! :-) But back to the root servers. Are you agreering with me that if I announce F and I root's netblocks inside of my own network that everyone would be ok with that? I'm not involved with policy at ISC or RIPE, but I would expect that if someone hijacked their netblocks they would have something to say about it. C'mon Joe, straight answer on that one. :) That's as straight as it gets :-) Joe
Re: Spain was offline
At 02:36 PM 9/1/2006, Joe Abley wrote: On 1-Sep-2006, at 13:47, Martin Hannigan wrote: I can't get a TLD zone? *You* can do anything, Marty! You are the man! :-) Well, let's rephrase that. Anyone can't get a TLD zone? And no, you are the man. :) But back to the root servers. Are you agreering with me that if I announce F and I root's netblocks inside of my own network that everyone would be ok with that? I'm not involved with policy at ISC or RIPE, but I would expect that if someone hijacked their netblocks they would have something to say about it. C'mon Joe, straight answer on that one. :) That's as straight as it gets :-) Thanks! Much appreciated. What could F or I do if an operator were advertising those blocks internally? Consider them no different than blackholes. It's the same concept. The point is that there's little reason to believe that this couldn't be done by any operator or other entity (OpenDNS?) technically, legally and legitimately. [ Note: F and I are just the simple examples. ] -- Martin Hannigan(c) 617-388-2663 Renesys Corporation(w) 617-395-8574 Member of Technical Staff Network Operations [EMAIL PROTECTED]
Re: Spain was offline
On 1-Sep-2006, at 15:07, Martin Hannigan wrote: Well, let's rephrase that. Anyone can't get a TLD zone? While there are many smaller TLD zones that don't get updated very often and which have wide-open AXFR to all and sundry, I'm betting that the majority of zones that people on this list care about either update sufficiently rapidly that zone synchronisation is non-trivial, or have zone transfer restrictions in place, or both. What could F or I do if an operator were advertising those blocks internally? Consider them no different than blackholes. It's the same concept. If you want an answer worth reading, then ask ISC or RIPE. I'm sure this is something that has occurred to them to think about. I could pontificate about the freedom of individual operators to do whatever they please versus the wider issue of coherence and consistency in the DNS, but it'd just be so much Friday-afternoon noise. Joe
Re: Spain was offline
At 03:50 PM 9/1/2006, Joe Abley wrote: On 1-Sep-2006, at 15:07, Martin Hannigan wrote: Well, let's rephrase that. Anyone can't get a TLD zone? While there are many smaller TLD zones that don't get updated very often and which have wide-open AXFR to all and sundry, I'm betting that the majority of zones that people on this list care about either update sufficiently rapidly that zone synchronisation is non-trivial, or have zone transfer restrictions in place, or both. Good information. Thanks. What could F or I do if an operator were advertising those blocks internally? Consider them no different than blackholes. It's the same concept. If you want an answer worth reading, then ask ISC or RIPE. I'm sure this is something that has occurred to them to think about. I could pontificate about the freedom of individual operators to do whatever they please versus the wider issue of coherence and consistency in the DNS, but it'd just be so much Friday-afternoon noise. Now I'm disappointed because I know you have some likely excellent thoughts on this topic regardless of who you are working for, or have worked for, but I completely understand. Thanks, I enjoyed it. :) /me back to lurk -- Martin Hannigan(c) 617-388-2663 Renesys Corporation(w) 617-395-8574 Member of Technical Staff Network Operations [EMAIL PROTECTED]
Re: Spain was offline
Joe Abley wrote: Well, let's rephrase that. Anyone can't get a TLD zone? While there are many smaller TLD zones that don't get updated very often and which have wide-open AXFR to all and sundry, I'm betting that the majority of zones that people on this list care about either update sufficiently rapidly that zone synchronisation is non-trivial, or have zone transfer restrictions in place, or both. It has been some years since I had to worry about these issues wearing a Nominet hat, but I would say that for majority of well-managed TLD operators, data mining is a very serious concern. There have various incidents in the past where squatters, scammers or spammers have made strenuous efforts to reverse-engineer registry data for their own ends. Sometimes even significant technical prevention is not enough, and legal remedy is also required. Restricting AXFRs is only the most entry-level counter-measure against such abuses. My understanding is that best TLD registry practice is to only allow AXFRs to boxes which are either under control of or contract to the registry, or at the very least to a 3rd parties with whom a restricted redistribution agreement is in place. Keith
Re: BCP Question: Handling trouble reports from non-customers
On Fri, 1 Sep 2006, Owen DeLong wrote: I think my previous post may have touched on a more global issue. Given the number of such posts I have seen over time, and, my experiences trying to report problems to other ISPs in the past, it seems to me that a high percentage of ISPs, especially the larger ones, simply don't allow for the possibility of a non-customer needing to report a problem with the ability to reach one of their customers. Anybody trying to put together such a BCP should first give some consideration to what sorts of calls from non-customers a service provider should be expected to accept. Based solely on Owen's earlier post, this looks to me like a good example of why service providers are sometimes reluctant to accept trouble reports from non-customers. From DNS and whois, it looks like the IP address Owen sited earlier is an individual DSL customer. The equipment Owen says is dropping packets looks like DSL concentration equipment in a local POP. Owen says he's having trouble reaching the address from multiple locations. If we look at this from the service provider's perspective, we see some random person calling up to complain that somebody else, whose phone number the caller doesn't know, is having trouble with their DSL service. That's probably not a call they get a lot of, and it probably seems pretty strange. If that DSL customer were really having problems getting anywhere, wouldn't they call it in themselves? If there were a problem with the whole POP, the random outside person calling in would be more believable, but the people in the call center would probably have their hands full dealing with actual customers. There are DSL customers who use their DSL circuits to host actual services that others might want to access, or IP phones that somebody might want to call. There are big hosting companies who specialize in making content available to lots and lots of end users, who still don't like taking calls from non-customers. In those cases, it's at least obvious why a non-customer might call and complain, but there are scaling issues because of which somebody might not want to accept such a call. The cost of passing bits through to somebody with thousands or millions of customers may be significantly less than the cost of taking phone calls from the customers' customers. Transit providers therefore tend to expect such organizations to handle their own customer support, and to call the transit provider themselves if there's a problem. That way the transit provider knows who they're dealing with, and only has to explain things once. This isn't to say there aren't valid reasons for network operators to contact other network operators they don't have relationships with. Packet loss affecting only the providers' customers may not count, but a call saying hi, your customer, who isn't answering their phone, is sourcing unauthorized routes to my address space probably should be taken seriously. Of course, the challenge there is determining that the person calling *is* authorized to tell you not to announce the space. Same for customers sourcing attacks, and the like. Some questions you might want to consider would be: What sorts of problems should a non-customer legitimately be reporting? Which non-customers should be reporting such things? Affected individuals? Other network operators (as defined by who?)? CERTs? Law enforcement? What channels should be used for such contacts? Phone? E-mail? INOC-DBA? Where should the contact information be published and who should have access to it? How should identity of callers be determined? Also, note that lots of solutions to many of these problems have already been tried at various times with varying degrees of success, and that some of them are working fairly well. You'd probably do better to build on existing systems and practices than to start from scratch. -Steve
Re: BCP Question: Handling trouble reports from non-customers
On 1-Sep-2006, at 18:48, Steve Gibbard wrote: On Fri, 1 Sep 2006, Owen DeLong wrote: I think my previous post may have touched on a more global issue. Given the number of such posts I have seen over time, and, my experiences trying to report problems to other ISPs in the past, it seems to me that a high percentage of ISPs, especially the larger ones, simply don't allow for the possibility of a non- customer needing to report a problem with the ability to reach one of their customers. Anybody trying to put together such a BCP should first give some consideration to what sorts of calls from non-customers a service provider should be expected to accept. Based solely on Owen's earlier post, this looks to me like a good example of why service providers are sometimes reluctant to accept trouble reports from non-customers. A long time ago, I was a backbone engineer at 6461. There was one particular 6461 customer who ran online games, and whose customers were encouraged to submit noc tickets to 6461 every time they had an issue with network performance. This resulted in a lot of tickets. Gamers being their naturally twitchy selves, though, there were lots of times when we got really early notice of problems that monitoring hadn't picked up and which weren't reported by anybody else until much later (if at all). So, there is *some* benefit in accepting tickets from non-customers and churning them through the support process, even if it's not especially cheap to do. Joe
Re: BCP Question: Handling trouble reports from non-customers
You're absolutely right, but your struggle is uphill. Some considerable time ago my XO (James Aldridge) had a big hand in RFC2142, but in spite of it being Standards Track and otherwise receiving universal approval, real uptake was patchy. In fact, in spite of most peering contracts (which started to emerge at the time) being very specific about listing 24*7 problem resolution contact information, any issues beyond the truly banal required one to resort to private, carefully maintained lists of names and telephone numbers, many of which were gleaned from business cards (just about the only useful thing to come out of Finance Administration) exchanged at NANOG meetings. Has anything changed since then? Probably not ... Vive le NANOGue! Probably, in fact, increasingly dense interconnectivity between especially upper level providers has outright masked the absence of out-of-band communication, and a truly catastrophic routing problem could well separate the Net. If a really huge problem were to occur these days, could you expect to be able to email somebody about it? Probably not, in fact. Maybe RFC2142 should be revived and turned into something much more extensive and formal? -- Per
Re: comast email issues, who else has them?
On Sep 1, 2006, at 6:33 PM, Brandon Galbraith wrote: I never understood why Gmail didn't put an X-Originating-From header in mail sent out by web users. Seconded! It may not be a requirement but the omission is certainly inconsistent with most web-based email services, particularly a popular one like Gmail. A lot of abuse ends at a dead-end because trying to deal with security/abuse @ gmail is a losing cause. -david
Re: comast email issues, who else has them?
Ack: X-Originating-From should be mandatory. $.02, - ferg -- David Ulevitch [EMAIL PROTECTED] wrote: On Sep 1, 2006, at 6:33 PM, Brandon Galbraith wrote: I never understood why Gmail didn't put an X-Originating-From header in mail sent out by web users. Seconded! It may not be a requirement but the omission is certainly inconsistent with most web-based email services, particularly a popular one like Gmail. A lot of abuse ends at a dead-end because trying to deal with security/abuse @ gmail is a losing cause. -david -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
Clueful contact at Register.Com?
Anyone have a clueful contact at Register.Com? Their front-line customer support is saying we need to talk to a dept that is supposedly 24/7 but they won't give its name or its extension. Our customer has asked to help them resolve an issue regarding a domain that is on registrar-hold and register.com is not telling anyone why or who over there can resolve it or when. If they were still public this customer is would be issuing a huge press release to the overnight wires... they are big enough. Thanks, DJ
Re: BCP Question: Handling trouble reports from non-customers
On Fri, 1 Sep 2006, Owen DeLong wrote: I'm curious how people feel about this. As I see it, there are a number of possible responses: I think you omitted at least one other option. Contact your own ISP, i.e. the provider you pay, and report the problem. You make the choice how much support you want to pay for when you select your provider, including what type of inter-provider contacts they maintain. Your own provider can confirm who you are, knows your history about reporting problems, perform preliminary diagnostics and sectionalization to confirm a problem exists, maintain contacts to the next provider in the chain, etc. Other ISPs are more likely to recognize the reputation of an ISP they maintain a relationship than random callers. If you want high touch support, your provider will probably charge you a high price. Other people may be prefer a low price and are satisfied with that service, as apparent by the other customer not opening a trouble ticket with their ISP. The Internet does not have uniform service levels, nor uniform pricing for any level of service. This method seems to work better in other industries with customer contacts, e.g. you call your credit card company about problems not the merchant's credit card company, you call your shipping company about problems not the transit carriers a package may have traversed, you call your telephone company about problems dialing another telephone number not other phone companies, and so forth.
