Re: Ubiquity<->Mzima routing loop
This is not a routing loop. It is simply a route that was not tied down via a static route to NULL with a weight of 254. ----- Original Message ----- From: "Paul Wall" [pauldotwall@gmail.com] Sent: 07/18/2008 06:57 PM AST To: "William Pitcock" <nenolod@systeminplace.net> Cc: nanog@merit.edu Subject: Re: Ubiquity<->Mzima routing loop 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 On Fri, Jul 18, 2008 at 3:27 PM, William Pitcock <nenolod@systeminplace.net> wrote:
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
Isn't that what a routing loop is, when it loops back out to the transit/interface from which it entered? Paul On Fri, Jul 18, 2008 at 7:07 PM, <Guy_Shields@stream.com> wrote:
This is not a routing loop. It is simply a route that was not tied down via a static route to NULL with a weight of 254.
----- Original Message ----- From: "Paul Wall" [pauldotwall@gmail.com] Sent: 07/18/2008 06:57 PM AST To: "William Pitcock" <nenolod@systeminplace.net> Cc: nanog@merit.edu Subject: Re: Ubiquity<->Mzima routing loop
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
On Fri, Jul 18, 2008 at 3:27 PM, William Pitcock <nenolod@systeminplace.net> wrote:
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
Paul Wall wrote:
Isn't that what a routing loop is, when it loops back out to the transit/interface from which it entered?
Of course. I think the sensitivity comes in to whether the diagnosis "routing loop" is one of the cause or effect. I.E. "this routing loop appears to show a network problem" vs "this routing loop is THE problem" Loops could happen due to human error in creating duplicate static routes, which would often be the ISP's responsibility to fix. They can also happen when the end-user takes their network down for maintenance, which is something the ISP can't usually fix (short of providing a naildown to prevent the loop from appearing, which doesn't really "fix" anything). I've been the recipient of angry emails accusing us of incompetence in cases where the customer had taken their network down intentionally. So we started putting in naildowns anywhere that might be likely to happen.
participants (3)
-
Guy_Shields＠Stream.Com -
Mike Lewinski -
Paul Wall