November 2014 - Test - lists.nanog.org

HTTP 302 with multiple Location: headers?
by Jeroen Massar 03 Nov '14

03 Nov '14

Ignoring the fact that Akamai IPv6 is broken on random nodes, thus you get either a working response or not from the same IP as some of the nodes are borked and thus just hang the connection.. (could be pmtu, hard to say without peeking inside the cluster).... see amongst others: https://www.sixxs.net/forum/?msg=general-12378937 But on a non-IPv4 note for once, I just noticed this funny one: $ telnet -4 www.akamai.com 80 Trying 95.101.216.85... Connected to e8921.dscx.akamaiedge.net. Escape character is '^]'. GET /html/technology/nocc.html HTTP/1.1 Host: www.akamai.com HTTP/1.1 302 Moved Temporarily Content-Length: 153 Content-Type: text/html Location: /esi/ui/html_head.html Location: /esi/ui/header.html Location: /esi/ui/technology-nav.html Location: /esi/ui/footer.html Location: /esi/ui/footer_js.html Location: /esi/webtrends.html Location: /esi/google-tag-manager.html Set-Cookie: cm_sessionid=47d4fed5001b00007c7457540ff80400b7650000; path=/ Set-Cookie: x_hd= Set-Cookie: x_hd= Set-Cookie: x_hd= Set-Cookie: x_hd= Set-Cookie: x_hd= Set-Cookie: x_hd= Set-Cookie: x_hd= ETag: "4c08f-206b-50353850ddb40" Cache-Control: max-age=70369 Date: Mon, 03 Nov 2014 12:26:36 GMT Connection: keep-alive <HTML> <HEAD> <TITLE>Error Page</TITLE> </HEAD> <BODY> An error (302 Moved Temporarily) has occured in response to this request. </BODY> </HTML> Connection closed by foreign host. Multiple Location: headers, really? and for head/footer/etc? Really? :) Chrome reports: --- Error code: ERR_RESPONSE_HEADERS_MULTIPLE_LOCATION --- Firefox: --- Corrupted Content Error The page you are trying to view cannot be shown because an error in the data transmission was detected. --- Note the irony in googling for Akamai NOC and getting such a page. I think there are a couple of b0rked nodes in the cluster that is attempting to serve me... Greets, Jeroen

2 1

Smart Data Pricing Questionnaire
by Gareth Tyson 03 Nov '14

03 Nov '14

Hi everybody, We're doing some research into the use of smart data pricing for enabling cheaper Internet access for the millions in the world who remain disconnected. We basically wish to understand which pricing models for data would be most attractive to network operators, as well as the challenges that might come with them. If you have a spare 10 minutes, it would be great if you could fill out the following questionnaire: https://docs.google.com/forms/d/1B-Vtl3mYJ2TJMWiFXxHySMrKSqxrhy0EzVNDlXKhPe… Many thanks! Best regards, Gareth. --- Dr. Gareth Tyson, CS 404 (Not Found), Electronic Engineering and Computer Science, Queen Mary University of London.

1 0

Is it unusual to remove defunct rr objects?
by Tim Howe 02 Nov '14

02 Nov '14

In the recent past, we've had another provider in our same market erroneously advertising prefixes for some of our customers. After we got it cleared up, I noticed that there were some old route objects in RADB that were entered for that provider years ago by 360. These route objects, in a sense, legitimized, the erroneous advertisements by matching the prefixes to that providers ASN. As that provider no longer uses 360/Zayo, I asked Zayo if they could remove the objects. Once the request made it to someone who understood what I was asking, they spent some time and effort over the next few weeks (much appreciated by me, I might add) in hunting down the info they needed to (I assume) manage the old 360 maintnr object. They then removed the offending objects (again, my thanks). One of the Zayo support folks mentioned to me, somewhat apologetically, that it took some time as nobody had ever made such a request before. So this got me wondering: is it really such a rare thing to manage ones route objects such that old defunct data is removed? I'm not under the impression that the issue I had would have been alleviated any by the related route objects having been removed beforehand, but their existence wasn't helping me any either. I've since found a disturbing number of defunct objects that relate to my customers (and me) in a similar way, and I have mostly had success in getting them cleared up. If my relatively small customer base is any indication, there are more incorrect objects out there than correct ones. I feel this is something I should have been looking into sooner. Is this a non-issue that I shouldn't worry about? Doesn't the quality of this data effect Origin Validation efforts? Sorry that this turned out so long; I wanted to give some context. --TimH

7 11

Re: Tail-F
by Scott Weeks 02 Nov '14

02 Nov '14

--- colton.conor(a)gmail.com wrote: From: Colton Conor <colton.conor(a)gmail.com> Can do simple command like show interface so even non-network techs and CSR's can get basic is the port up or down type stats without having to directly login to the network. ------------------------------------------------- Do an snmpget on the SNMP OIDs you want them to see. If they're not *nix savvy you could write a tiny shell script that'd do it for them. It won't be the output of sho int but the data will be the same. scott

1 0

Industry standard bandwidth guarantee?
by keith tokash 02 Nov '14

02 Nov '14

Hi *, sorry if this has been answered, I did look. Is there an industry standard regarding how much bandwidth an inter-carrier circuit should guarantee? Specifically I'm thinking of a sub-interface on a shared physical interface. I've not thought much about it but if there's a more generally-accepted guideline than, "when the customers start leaving / when you leave," I'm at least 5% ears. Thanks, Keith

18 25

TE offline tools
by Mohamed Kamal 02 Nov '14

02 Nov '14

Hello, I'm curious what is the "tools" for computing and validating TE tunnels over the network. I read on MPLS Enabled Applications that there are tools out there that can be used to do so. Anyone has a suggestion? Regards, -- Mohamed Kamal Network Engineer, Core Team NOOR Data Networks, SAE City Stars Capital 5 A4 Omar Ibn El Khattab Street Heliopolis, Cairo, Egypt Mobile GSM.: +2 0100 29 49 691 Land Line.: +20 2 16700 Ext.: 139 Fax.: +20 2 3748 2816 Email.: mkamal(a)noor.net

1 0

“The Devil had possessed his netbook”—and other tales of IT terror
by Miles Fidelman 01 Nov '14

01 Nov '14

A day late, but somewhat amusing..... http://arstechnica.com/information-technology/2014/10/the-devil-had-possess…

1 0

Hijacking machine: ASAS201640 / AS200002
by Ronald F. Guilmette 01 Nov '14

01 Nov '14

I don't routinely follow this list, so I'm not sure how much of this is common knowledge already, but... http://blogs.cisco.com/security/talos/help-my-ip-address-has-been-hijacked/ Current route announcements for AS201640: 36.0.56.0/21 probable hijack - China 41.92.206.0/23 probable hijack - Cameroon 41.198.80.0/20 probable hijack - South Africa 41.198.224.0/20 probable hijack - South Africa 61.242.128.0/19 probable hijack - China 119.227.224.0/19 probable hijack - India 123.29.96.0/19 probable hijack - Vietnam 177.22.117.0/24 probable hijack - Brazil 187.189.158.0/23 probable hijack - Mexico 202.39.112.0/20 probable hijack - Taiwan Network Information Center 210.57.0.0/19 probable hijack - Telstra/Japan It would appear that AS201640 may possibly exist at the present time only for the purpose of providing illicitly obtained IP space for spammers, including but not limited to the ""Mike Prescott" mentioned in the Cisco blog entry cited above. The spammer, "Mike Prescott"... not his real last name... has also been spotted spewing from IP space routed by AS200002, which is AS201640's only connection to the rest of the world. Coincidence? You be the judge. Regards, rfg P.S. If anybody is able to look up _all_ of the route announcements that have been made by AS201640 over the past few months, I for one would definitely like to see those. Please e-mail them to me off list. I already know that "Mike Prescott" has been spewing from at least one of the above current announcements (202.39.112.0/20) and probably all of the others too. But there are additional route announcements that have already been withdrawn, and I'd like to check those for "Mike Prescott" footprints also. P.P.S. To the real "Mike P."... on the off chance that he might see this... You can run, but you don't hide very well. You should have gotten out of the game in 1998 when you had the chance. Maybe the Powers That Be will lock you up this time.

7 7

Route Issue Level3 to GTT - Packet loss & Latency
by Dean Perrine 01 Nov '14

01 Nov '14

Hit a strange route issue earlier transiting Level3 network to GTT - Packet Loss & High Latency - caused some interruptions in critical traffic flow. Between Level3 hop 4.68.63.158 and GTT 144.136.105.226 - had a 20ms latency increase and packet loss. After about 1+ hours the route had shifted and latency dropped back down. Does anyone have details on this by any chance? Details below (If readable): *GOOD* *BAD* *route* *latency* *route* *latency* xe-11-1-2.bar2.houston1.level3.net [4.59.126.105] 53 xe-11-1-2.bar2.Houston1.Level3.net (4.59.126.105) 57.3 ae-2-3514.edge2.atlanta4.level3.net [4.69.150.165] 65 ae-2-3514.edge2.Atlanta4.Level3.net (4.69.63.158) 70.3 gtt-level3.atlanta4.level3.net [4.68.63.158] *65* gtt-level3.Atlanta4.level3.net (4.68.63.158) *70.3* xe-0-3-1.dal33.ip4.gtt.net [141.136.107.69] *70* xe-11-3-3.dal33.ip4.gtt.net (144.136.105.226) *98.3* gtt-gw.ip4.gtt.net [173.241.130.138] 70 gtt-gw.ip4.gtt.net (173.241.130.138) 97.1 66.171.224.26 70 66.171.224.34 97.8 Thanks, Dean

1 0