Ubiquity<->Mzima routing loop

Hi,

Can someone at Ubiquity or Mzima fix this routing loop:

traceroute to hg.atheme.org (72.37.225.164), 30 hops max, 40 byte
packets
1 64.62.134.193 12.402 ms 12.370 ms 12.363 ms
2 ge5-0.cr01.ord01.mzima.net (206.223.119.62) 16.003 ms 15.985 ms
15.964 ms
3 ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 14.139 ms 14.858
ms 14.838 ms
4 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 15.875 ms 15.854 ms
16.497 ms
5 ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 14.747 ms 14.763
ms 14.745 ms
6 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 16.405 ms 8.773 ms
8.758 ms
7 ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 9.831 ms * *
8 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 4.417 ms 4.403 ms
4.381 ms
9 * * *
10 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 4.293 ms 4.933 ms
4.914 ms
11 * * *
12 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 14.527 ms 14.526 ms
14.438 ms
13 * * *
14 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 14.352 ms 14.335 ms
3.770 ms
15 * * *
16 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 3.684 ms 13.897 ms
13.897 ms
17 * * *
18 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 8.599 ms 8.581 ms
8.668 ms
19 * * ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 8.246 ms
20 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 8.584 ms 8.565 ms
8.545 ms
21 * * ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 8.119 ms
22 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 8.456 ms 8.931 ms
8.913 ms
23 * ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 6.049 ms *
24 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 15.862 ms 15.754 ms
15.736 ms
25 ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 7.132 ms * 7.092
ms
26 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 15.293 ms 15.998 ms
10.752 ms
27 ge0-ubiquity.cust.ord01.mzima.net (72.37.148.158) 5.353 ms 5.336
ms *
28 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 3.800 ms 3.854 ms
3.823 ms
29 * * *
30 ge0-12.cr01.ord01.mzima.net (72.37.148.157) 3.228 ms 4.426 ms
13.019 ms

Thanks!

William

How long ago did you contact Ubiquity or Mzima?

Hi,

common sense and courtesy says you should contact ubiquity, then mzima
before even thinking of hitting up nanog@
and, wild guess, it looks like it's probably on the ubiquity side of things.

<the more you know image>

I'm aware what side it's on. However, I didn't have contact information
for an actual human on either side of the link, so I posted on nanog@.

Normally, I wouldn't take such an action, but the availability of
services on that machine (revision control for several open source
projects as a starting point), makes the machine's availability
essential.

William

[snip]

I'm aware what side it's on. However, I didn't have contact information
for an actual human on either side of the link, so I posted on nanog@.

[snip]

There's a lot of rolodex resources out there that can get you a remote
site's noc or public-facing contact info:
whois/irr data for the asn (or ip space if they are run well)
Network Operations Home Page
http://www.peeringdb.com/

...just off the top of my head. Sometimes data will conflict; I suggest
trying them all. It is likely faster than a shotgun mailing list to
thousands of people who can't help you.

Cheers,

Joe

I'd like to rip on Mzima as much as the next guy, but I'm not sure how
they could "fix" this routing loop, shy of some creative ACLs.

You should try contacting Ubiquity, as this traceroute looks like an
issue on their (Mzima's customer's) side.

Paul Wall