>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
