Contacting Network Admins Of Large Internet Companies?
lisa asks: "I work as a sysadmin for a national DSL ISP. Unfortunately, we've recently found that @Home.com is not allowing connections to port 25 from some of our primary mail servers: this of course means that our customers can't send mail to theirs. I've called and talked to people in their tech support, and only after several calls have we been able to get them to acknowledge there may be a problem. The trouble is, I can't seem to get in contact with any network admins there. Even the tech support person I spoke with expressed less than hopeful sentiments about being able to get this issue escalated. Has anyone had trouble like this with @Home or other simliar Internet companies?"
"What is the best way to get in touch with a Network Admin or someone who actually can do something about a network issue in cases like these? It would be nice to know that just writing root@home.com would get to their systems department, but I was told all of that mail goes through support first."
You might want to look at this. It's a list of NOC contacts for many major providers.
I don't know how up-to-date it is, though.
--
Also, if you want to be taken seriously, don't mention that you use Linux if you can help it. 5 years ago it would've meant "hardcore programmer on the line escalate to admin", it now means "Windows dork trying to survive with Linux, much hand holding is about to occur. Shield busy admins from harm!"
Don't just drop techno babble. If the technicians don't understand what you said, they'll assume (for their own safety) that you don't know anything. They will not escalate you.
Flat out asking to speak to an admin will probably just make the technician feel insulted and less inclined to help you.
For best results, if possible, work with the technician, try their suggestions (and tell them that they all failed), make him take out a trouble ticket so the whole spiel is recorded and doesn't have to be repeated. In most cases they'll escalate it when all of their suggestions fail.
These are just my observations from the inside. *shrug*
I have a Pacific Bell DSL line, running my own mail server with my own domain name (actually a subdomain of stanford.edu). The problem isn't on Pac Bell's side; my parents use Earthlink, and my email to them was bouncing. Some investigation showed that they had configured their mail servers to reject any mail traffic from Pac Bell IP addresses other than the Pac Bell mail servers. This was an explicit decision on their part, again with the motivation of "reducing spam."
Fortunately, I was able to relay my SMTP traffic through Stanford's mail server (since I'm using a valid *.stanford.edu address) for each set of mail destinations that does this access control.
I think it's pretty stupid to assume that a DSL line is going to be using the ISP's email services as well--- especially since Earthlink has no problem _delivering_ mail to that account.
At the time I was working for a web site, basicly, and the problem we were having is that @home customers in san francisco couldn't get to the site. After talking to a few of these customers, I had a couple do a traceroute to our server, and somewhere in the middle of @home's network a split horizon (i think that's what they are called) happened. It was where the packet just kept getting bounced between 2 of their routers back and forth until one of them finally dropped it. This only happened to traffic destined for our little network. I called @Home and was escalated to the top tech, who finally believed me. Then I was called back by a sysadmin there who required a lot of convincing. So he finally acknowledged the problem and said that they would get to it. Before I left that company I don't think it had been fixed, but it might have by now. It actually seems like it was a problem with their RIP or IGRP config, so maybe when a router was rebooted it would fix it's tables. Who knows. But the short of it is that I got ahold of a sysadmin and nothing was done. So good luck when you get that far. The journey may still not be over.
-Nicodemus
Okay, first off, you're doing it wrong.
You need to call their NOC, *NOT* tech support. Get their NOC number, which is according to my records, 650-556-5599. If that's not the NOC, you can get the NOC number from them.
Once you get to the NOC, make them create a trouble ticket, and get ready to use your "I'm NOT HAPPY WITH YOU" techniques. The ONLY way anything will be done about it is if you ride them. Hard. They probably have the TT from Tech Support, so have that number ready, and give it to them. Start riding them hard. Demand supervisors, etcetera. Remember, the NOC is going to be setup with a front line defense (NOC techs), second line defense (NOC NetEng, NOC Unix Admin, etc), third line defense (NetEng, Unix Admins), and finally supervisors. That's NOT how it's managed, but how it's going to progress. Escalate often. Just keep calling them.
That's the only way I've ever gotten anything done with Crack-Home or any other moronic overly large ISP. If they're big enough to have a NOC, then rest assured you'll only get things done if it gets to the NOC. The NOC will likely scream at Tech Support if they get TT's from them (I know we did when I worked in one) and generally have a fit, and ignore the ticket as much as possible. NOC and Tech Support typically do not get along.
Hope this helps, and good luck.
your company here.
your company here.
shelby != ford
Currently working for a major provider (not AOL, I wouldn't sell out) in tech support, I have to say I get a lot of callers who say they've got an MCSE and a CS degree and they've been in the field for 20 years calling me that make most AOL users look like Linus Torvalds.
Best way to handle tech support is to tell them what you think the problem is, let them run through thier checklist so they can properly document the trouble ticket as required, and if you're cool and cooperative about it and try and be on the same level as the support geek, they'll escalate it for you.
To be honest, I love it when someone outside the Winmac realm calls, because they're almost always the easiest calls for me, ie they're the first to notice a widespread network outage and are very cooperative in giving me details I need to document while I run my tests and document that, it gets escalated to NOC and the problem's fixed by the end of the day, or they just had to reinstall thier OS and lost thier TCP/IP settings and all I have to do is read them off the user ticket...
One problem that slows down reporting of network issues a lot are technically illiterate people who get mad because they can't check thier email right now and won't cooperate with us making sure they're set up right or variations on that theme.
--
Help us build a better map!
We're all geeks over here>>> The Linux Pimp
--It's Pimptastic!--
There was a lot of hassle involved. Netcom, then owned by Mindspring, clearly had a massive wall between their system administrators and their support people, with no direct way of contacting the sysadmins. I'd email the support address, and get an email back from someone clearly too clueless to know what an SMTP server or MX address is, insisting the problem must be my end or with my ISP. In the end I basically had to persist, phoning their 1-800 number in the end, getting names of support staff involved, and following up every inch.
I found it tough. The more you point at RFCs and stuff, the more you look like, well, the sort of people you get on TV claiming you don't need a drivers licence because the states aren't constitutionally allowed to forbid you from using the roads or that banks are allowed to create money because of some legal loophole. The person you're talking to has no idea what an RFC is, or an MX record, or anything like that. All they can do is accept that you've tried it all different ways and can't send email.
In the end they put a ticket in with their system administrators, who knew exactly what the problem was and fixed it.
From what I can figure out, the problem was because my ISP's IP address block is smack in the middle of BellSouth's (BS providing the connectivity), and Mindspring had configured the Netcom servers only to accept email sent directly from BellSouth's email servers, not from BellSouth customer IP addresses - my bellsouth.net account continues to this day to have the same problems but I'm buggered if I'm going through the hassle again. This is stupid anyway, but of course as the complaints were coming from people who deliver their own email, or from people with ISPs in similar positions, of which there are probably relatively few, few enough for it to look like most email is being delivered perfectly and therefore it "obviously" being a problem on the deliverer's end.
Why they did this is anyone's guess. I think, given the problems I have being let onto any IRC servers these days, that a lot of the hacking being done at the moment is being done from Bellsouth.net addresses, but I haven't read anything anywhere to back that up. Mind you, the problems emailing ix.netcom.com started a year ago, whereas EFNet's clamp down is at most 4-5 months old.
My advice? To be honest, just keep trying, and keep piling on the pressure until they relent. Send email to the support addresses. If you don't get a response, start calling - preferably calling the @Home customer's 1-800 support line. Keep calling, get names of support people, and don't stop until the situation is resolved.
If Mindspring hadn't finally relented and put in a ticket to their system administrators, I'd probably have used Usenet or something similar to start embaressing them, a little log of an nslookup, telnet to an SMTP port, and then this posted on an appropriate newsgroup. But as it was, it got fixed.
--
You are not alone. This is not normal. None of this is normal.