|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: opening tickets with peers
>Is there a resource (phone list, email list, smoke-signal protocol) for >opening trouble tickets with peers? I've had a heck of a time opening >trouble tickets with Sprint among others. I've given up calling their >trouble center, since nobody seems to want to open a ticket unless you're >a customer. I've been able to get most issues resolved by contacting >engineers directly, but would much rather open a real ticket through the >NOC. While there are many proposed trouble ticket protocols, they all fail when there isn't management support to do something on the other end. As some providers like to remind me every once in a while, usually just before they do something incrediblely stupid like announcing the deaggregated global routing table from one of their customers, if opening up trouble tickets was important you should have put it in your peering agreement with them. I'm not sure why some managers think it is a more effecient use of their resources for me to get out my stash of businesss cards, and start calling various network engineers directly to get a problem fixed. But they do, so I start calling. If nothing else, it would let the managers keep better track of the problems they are having. However, this works both ways. If the other provider gave you their method for opening trouble tickets, and you don't follow it or you don't bother to tell your NOC staff about the other provider's procedures, then its your own fault. If you were told to call a particular phone number, or send e-mail to a particular address; and instead you sent it to the general customer support address; you will get the general customer support response. Some providers funnel both peers and customers through the same support center, others have seperate contact methods for reporting problems. Its like the small print on the back of your credit card bill, if you send the payment to any other address, it may delay things five working days. The same concept holds for making trouble reports with other providers. In general, you need to provide as much information (even more) as you would want to receive if the other person was reporting the problem. If you expect to get a ticket number from the other provider, you should provide your own ticket number. If you expect a response from the other provider, you should provide a call-back number and your e-mail address. Don't assume e-mail headers will pass unscathed through the other provider's trouble ticket system, if it is important include it in the text of the trouble report. If there is time-dependent information, be sure to include the timezone and confidence level the time period is correct. Saying someone broke into your machine a 9:00am doesn't help me if I don't know what timezone 9:00am is in. If you supply a traceroute, include the *SOURCE* of the traceroute as well as the destination. And so on. One important note, if it involves security issue, don't expect much information to come back via e-mail. If you haven't exchanged crypto keys, you might want to call ahead and find out the FAX number you should send the report. For some reason, if it requires involvement of the legal community, law enforcement and lawyers can deal with FAXes better than e-mail messages. >Most of the time the issues aren't time critical, but when another >provider is advertising a netblock that you own, being told that only >customers can open a ticket is more than a little frustrating. There are a different terms used for people who cause you harm, and people who will only stop causing harm if you pay them money. One of them involves treble damages. Unfortunately, reaching the correct level of management at some companies requires rather ugly actions. Although managers act shocked when a distaster hits, most disasters have precursors. Tit-for-tat is somewhat childish, but can be very effective in getting the other provider's attention. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation
|