Re: Uhaul not routing IPs
I do not know what this issue is, I am not uhaul. The server does not respond to pings/requests. It one way routes to their subnet via traceroute and just drops off after that. 95% of the time it is a firewall setting, the other 5% of the time it is a bgp issue on their edge routers, not being able to reply to our packets being sent(one way routing issue). We have a list of other little services that have the same problem, but because they are little, we can CGNAT all requests to their IP addresses from known good addresses. I've just got to assume that there is some common service that they all use that cause this problem. Assuming they accept BGP with proper filters and have a semi-sane firewall, there wouldn't be any issues as we don't do anything special with our BGP. On Fri, 5 Jul 2019 at 19:06, Neil Hanlon wrote: > Phone sent from the wrong email address and the list rejected it... Oops. > Sorry for the spam. > > Server does not respond on Port 80? Or are you not able to route there > at all. > > Seems like you need to get in touch with their team, but still a bit vague > as to exactly what issue you're having Eg, is it a firewall blocking > you or is there a route missing somewhere (this seems unlikely). > > Hopefully there's someone on list that can help.. Otherwise I think > wan@uhaul is your best option. > On Jul 5, 2019, at 20:59, Michael Crapse wrote: >> >> The server does not respond to our clients when they originate from a >> certain subnet, but they do with a different subnet >> >> On Fri, Jul 5, 2019, 6:57 PM Neil Hanlon < n...@neilhanlon.com> wrote: >> >>> Hi Michael, >>> >>> Wondering if you might be able to clarify a few points... I'm not from >>> uhaul but am a casual observer and have a couple questions. What does "not >>> routing ips" mean? Where is traffic stopping? >>> >>> Can you clarify "unable to load the page"? Have any example traceroutes? >>> Error messages? >>> >>> I'm also a a bit unsure what geolocolation or routing has to do with >>> this at all. Your message seems to go back and forth between being >>> application level and network level, so I think clearing up exactly the >>> symptoms of your issues would be helpful. >>> >>> -Neil >>> On Jul 5, 2019, at 20:32, Michael Crapse < mich...@wi-fiber.io> wrote: Our customers are trying to access uhauldealer.com and are unable to load the page. Classic case of incorrect geolocation and/or up filtering. Our emails to their webmaster/wan team have gone unanswered or bounced If anyone knows how to contact them please contact me off list >>>
Re: Uhaul not routing IPs
Forgot to attach our main subnet, 196.53.96.0/22 On Fri, Jul 5, 2019, 6:59 PM Neil Hanlon wrote: > Hi Michael, > > > Wondering if you might be able to clarify a few points... I'm not from > uhaul but am a casual observer and have a couple questions. What does "not > routing ips" mean? Where is traffic stopping? > > > Can you clarify "unable to load the page"? Have any example traceroutes? > Error messages? > > > I'm also a a bit unsure what geolocolation or routing has to do with this > at all. Your message seems to go back and forth between being application > level and network level, so I think clearing up exactly the symptoms of > your issues would be helpful. > > > -Neil > > > > > On Jul 5, 2019, at 20:32, Michael Crapse wrote: >> >> Our customers are trying to access uhauldealer.com and are unable to >> load the page. Classic case of incorrect geolocation and/or up filtering. >> Our emails to their webmaster/wan team have gone unanswered or bounced >> If anyone knows how to contact them please contact me off list >> >
Re: Uhaul not routing IPs
The server does not respond to our clients when they originate from a certain subnet, but they do with a different subnet On Fri, Jul 5, 2019, 6:57 PM Neil Hanlon wrote: > Hi Michael, > > Wondering if you might be able to clarify a few points... I'm not from > uhaul but am a casual observer and have a couple questions. What does "not > routing ips" mean? Where is traffic stopping? > > Can you clarify "unable to load the page"? Have any example traceroutes? > Error messages? > > I'm also a a bit unsure what geolocolation or routing has to do with this > at all. Your message seems to go back and forth between being application > level and network level, so I think clearing up exactly the symptoms of > your issues would be helpful. > > -Neil > On Jul 5, 2019, at 20:32, Michael Crapse wrote: >> >> Our customers are trying to access uhauldealer.com and are unable to >> load the page. Classic case of incorrect geolocation and/or up filtering. >> Our emails to their webmaster/wan team have gone unanswered or bounced >> If anyone knows how to contact them please contact me off list >> >
Uhaul not routing IPs
Our customers are trying to access uhauldealer.com and are unable to load the page. Classic case of incorrect geolocation and/or up filtering. Our emails to their webmaster/wan team have gone unanswered or bounced If anyone knows how to contact them please contact me off list
Re: CloudFlare issues?
Hey Sandy, At this time i3D.net is not able to fully implement RPKI for technical reasons: there are still some Brocade routers in our network which don't support it. We are making very good progress migrating the entire network over to Juniper routers which do support RPKI, and we will certainly deploy ROV when that is done, but with upwards of 40 default-free backbone routers spread over six continents it's not a logistically trivial task. That being said, a network doesn't need to use ROV to benefit from the routing security afforded by the RPKI protocol. Nearly all of the prefixes originated by AS49544 have been covered by RPKI ROAs for several years now. Those networks which have already deployed ROV are inoculated against route hijacks of i3D.net's IP space in scenarios where the bad paths would be marked as RPKI invalid. Considering that i3D.net was founded in The Netherlands and that a significant amount of our enterprise customers have businesses which are focused on the Dutch market, the fact that two of the major eyeball networks in the country (that'd be KPN & XS4ALL) are using ROV is already a huge win for everyone involved. And, let's not forget that the degree of protection afforded by this relatively passive participation in RPKI is directly proportional to the use of a non-ARIN TAL. Real-world example: Mark Tinka's remark concerning Seacom's connection to Cloudflare's IP space being affected by the hijack due to the ARIN TAL problem, despite both involved parties fully deploying RPKI by both signing ROAs and implementing ROV. Best regards, Martijn On 7/5/19 8:46 PM, Sandra Murphy wrote: > Martijn - i3D.net is not in the list Job posted yesterday of RPKI ROV > deployment. Your message below hints that you may be using RPKI. Are you > doing ROV? (You may be in the “hundreds of others” category.) > > —Sandy > > Begin forwarded message: > > From: Job Snijders > Subject: Re: CloudFlare issues? > Date: July 4, 2019 at 11:33:57 AM EDT > To: Francois Lecavalier > Cc: "nanog@nanog.org" > > I believe at this point in time it is safe to accept valid and unknown > (combined with an IRR filter), and reject RPKI invalid BGP announcements > at your EBGP borders. Large examples of other organisations who already > are rejecting invalid announcements are AT&T, Nordunet, DE-CIX, YYCIX, > XS4ALL, MSK-IX, INEX, France-IX, Seacomm, Workonline, KPN International, > and hundreds of others. > > > >> On Jul 4, 2019, at 5:56 AM, i3D.net - Martijn Schmidt via NANOG >> wrote: >> >> So that means it's time for everyone to migrate their ARIN resources to a >> sane RIR that does allow normal access to and redistribution of its RPKI >> TAL? ;-) >> >> The RPKI TAL problem + an industry-standard IRRDB instead of WHOIS-RWS were >> both major reasons for us to bring our ARIN IPv4 address space to RIPE. >> Unfortunately we had to renumber our handful of IPv6 customers because ARIN >> doesn't do IPv6 inter-RIR transfers, but hey, no pain no gain. >> >> Therefore, Cloudflare folks - when are you transferring your resources away >> from ARIN? :D >> >> Best regards, >> Martijn >> >> On 7/4/19 11:46 AM, Mark Tinka wrote: >>> I finally thought about this after I got off my beer high :-). >>> >>> Some of our customers complained about losing access to Cloudflare's >>> resources during the Verizon debacle. Since we are doing ROV and dropping >>> Invalids, this should not have happened, given most of Cloudflare's IPv4 >>> and IPv6 routes are ROA'd. >>> >>> However, since we are not using the ARIN TAL (for known reasons), this >>> explains why this also broke for us. >>> >>> Back to beer now :-)... >>> >>> Mark.
Re: CenturyLink/Level3 feedback
> On Jul 5, 2019, at 3:10 PM, Stephen Frost wrote: > > Greetings, > > I have to admit that I was hoping to be able to report to this list that > CL was able to spin up a new 1G in fairly short order (after all, this > is what they assured me of when discussing it with them...) but it's now > been over a month, with them telling me it'll be another couple weeks > because they need to send a tech out (the wiring and all of the > equipment has been ready to go, though that also took longer than it > should have imv...). > > And this in an already lit building in northern Virginia, not some back > of the woods location, small town, or something going across an ocean. Sometimes you’d be surprised, it may not be straightforward on their end. Remember, most people here are likely experts at some part or many parts, what we do is likely wizardry to others. I have a saying you’re welcome to steal if you don’t steal it too much: “We are moving at the speed the organization is capable”. I suspect that’s the case for them in a post-acquisition world trying to sort through all the integration work. - Jared
Re: CenturyLink/Level3 feedback
We tried to order a 100G circuit from them terminating in an existing Level3 FPP at a location that we've had at least two 1G circuits and a 10G circuit terminated at. They refused to process the order because they needed to "extend the demarc " to our suite. There is no suite. It's a FPP in the basement of the building. Our FPP is next to it. We've done this before... They said that the equipment (the FPP) may not be 100G compatible, and they may need to install a new one that can support 100G. We told them to just forget it and we'd order from Zayo... ... At 03:10 PM 05/07/2019, Stephen Frost wrote: Greetings, I have to admit that I was hoping to be able to report to this list that CL was able to spin up a new 1G in fairly short order (after all, this is what they assured me of when discussing it with them...) but it's now been over a month, with them telling me it'll be another couple weeks because they need to send a tech out (the wiring and all of the equipment has been ready to go, though that also took longer than it should have imv...). And this in an already lit building in northern Virginia, not some back of the woods location, small town, or something going across an ocean. Pretty disappointing. Thanks, * Mike Hammett (na...@ics-il.net) wrote: > Anything more than a week for things not requiring last mile construction is ridiculous. > > > > > - > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > - Original Message - > > From: "JASON BOTHE via NANOG" > To: "Mehmet Akcin" > Cc: "nanog" > Sent: Wednesday, June 5, 2019 9:56:14 AM > Subject: Re: CenturyLink/Level3 feedback > > Itâs taking over a year to get waves turned up in EU. Iâm currently willing to wager on what comes up first, them or amazon peering (thatâs taking just as long). After the merger, we have seen Level3 slide into the CL abyss becoming a pain to deal with. Pricing and ordering has been outsourced weâve been told and decisions are no longer at a regional level. Frustrating at best. > > > On Jun 4, 2019, at 09:30, Mehmet Akcin wrote: > > > > hi there, > > > > Just a general high-level question about Centurylink/Level3 post-merger, how is your overall experience with CenturyLink? if you could be sitting with the CEO of the company what is one thing you would ask him to fix? > > > > please keep it high level and general. i intend to pass these to him and his team in an upcoming meeting. > > > > Mehmet > > -- Clayton Zekelman Managed Network Systems Inc. (MNSi) 3363 Tecumseh Rd. E Windsor, Ontario N8W 1H4 tel. 519-985-8410 fax. 519-985-8409
Re: CenturyLink/Level3 feedback
Greetings, This looks to be former Qwest, from what I've been able to tell. IPs we were assigned were out of AS209. Thanks, Stephen * Mike Bolitho (mikeboli...@gmail.com) wrote: > Just out of curiosity, what network are they bringing you up on? > > - Mike Bolitho > > > On Fri, Jul 5, 2019 at 12:11 PM Stephen Frost wrote: > > > Greetings, > > > > I have to admit that I was hoping to be able to report to this list that > > CL was able to spin up a new 1G in fairly short order (after all, this > > is what they assured me of when discussing it with them...) but it's now > > been over a month, with them telling me it'll be another couple weeks > > because they need to send a tech out (the wiring and all of the > > equipment has been ready to go, though that also took longer than it > > should have imv...). > > > > And this in an already lit building in northern Virginia, not some back > > of the woods location, small town, or something going across an ocean. > > > > Pretty disappointing. > > > > Thanks, > > > > * Mike Hammett (na...@ics-il.net) wrote: > > > Anything more than a week for things not requiring last mile > > construction is ridiculous. > > > > > > > > > > > > > > > - > > > Mike Hammett > > > Intelligent Computing Solutions > > > > > > Midwest Internet Exchange > > > > > > The Brothers WISP > > > > > > - Original Message - > > > > > > From: "JASON BOTHE via NANOG" > > > To: "Mehmet Akcin" > > > Cc: "nanog" > > > Sent: Wednesday, June 5, 2019 9:56:14 AM > > > Subject: Re: CenturyLink/Level3 feedback > > > > > > It’s taking over a year to get waves turned up in EU. I’m currently > > willing to wager on what comes up first, them or amazon peering (that’s > > taking just as long). After the merger, we have seen Level3 slide into the > > CL abyss becoming a pain to deal with. Pricing and ordering has been > > outsourced we’ve been told and decisions are no longer at a regional level. > > Frustrating at best. > > > > > > > On Jun 4, 2019, at 09:30, Mehmet Akcin wrote: > > > > > > > > hi there, > > > > > > > > Just a general high-level question about Centurylink/Level3 > > post-merger, how is your overall experience with CenturyLink? if you could > > be sitting with the CEO of the company what is one thing you would ask him > > to fix? > > > > > > > > please keep it high level and general. i intend to pass these to him > > and his team in an upcoming meeting. > > > > > > > > Mehmet > > > > > > > > signature.asc Description: PGP signature
Re: CenturyLink/Level3 feedback
Just out of curiosity, what network are they bringing you up on? - Mike Bolitho On Fri, Jul 5, 2019 at 12:11 PM Stephen Frost wrote: > Greetings, > > I have to admit that I was hoping to be able to report to this list that > CL was able to spin up a new 1G in fairly short order (after all, this > is what they assured me of when discussing it with them...) but it's now > been over a month, with them telling me it'll be another couple weeks > because they need to send a tech out (the wiring and all of the > equipment has been ready to go, though that also took longer than it > should have imv...). > > And this in an already lit building in northern Virginia, not some back > of the woods location, small town, or something going across an ocean. > > Pretty disappointing. > > Thanks, > > * Mike Hammett (na...@ics-il.net) wrote: > > Anything more than a week for things not requiring last mile > construction is ridiculous. > > > > > > > > > > - > > Mike Hammett > > Intelligent Computing Solutions > > > > Midwest Internet Exchange > > > > The Brothers WISP > > > > - Original Message - > > > > From: "JASON BOTHE via NANOG" > > To: "Mehmet Akcin" > > Cc: "nanog" > > Sent: Wednesday, June 5, 2019 9:56:14 AM > > Subject: Re: CenturyLink/Level3 feedback > > > > It’s taking over a year to get waves turned up in EU. I’m currently > willing to wager on what comes up first, them or amazon peering (that’s > taking just as long). After the merger, we have seen Level3 slide into the > CL abyss becoming a pain to deal with. Pricing and ordering has been > outsourced we’ve been told and decisions are no longer at a regional level. > Frustrating at best. > > > > > On Jun 4, 2019, at 09:30, Mehmet Akcin wrote: > > > > > > hi there, > > > > > > Just a general high-level question about Centurylink/Level3 > post-merger, how is your overall experience with CenturyLink? if you could > be sitting with the CEO of the company what is one thing you would ask him > to fix? > > > > > > please keep it high level and general. i intend to pass these to him > and his team in an upcoming meeting. > > > > > > Mehmet > > > > >
Re: CenturyLink/Level3 feedback
Greetings, I have to admit that I was hoping to be able to report to this list that CL was able to spin up a new 1G in fairly short order (after all, this is what they assured me of when discussing it with them...) but it's now been over a month, with them telling me it'll be another couple weeks because they need to send a tech out (the wiring and all of the equipment has been ready to go, though that also took longer than it should have imv...). And this in an already lit building in northern Virginia, not some back of the woods location, small town, or something going across an ocean. Pretty disappointing. Thanks, * Mike Hammett (na...@ics-il.net) wrote: > Anything more than a week for things not requiring last mile construction is > ridiculous. > > > > > - > Mike Hammett > Intelligent Computing Solutions > > Midwest Internet Exchange > > The Brothers WISP > > - Original Message - > > From: "JASON BOTHE via NANOG" > To: "Mehmet Akcin" > Cc: "nanog" > Sent: Wednesday, June 5, 2019 9:56:14 AM > Subject: Re: CenturyLink/Level3 feedback > > It’s taking over a year to get waves turned up in EU. I’m currently willing > to wager on what comes up first, them or amazon peering (that’s taking just > as long). After the merger, we have seen Level3 slide into the CL abyss > becoming a pain to deal with. Pricing and ordering has been outsourced we’ve > been told and decisions are no longer at a regional level. Frustrating at > best. > > > On Jun 4, 2019, at 09:30, Mehmet Akcin wrote: > > > > hi there, > > > > Just a general high-level question about Centurylink/Level3 post-merger, > > how is your overall experience with CenturyLink? if you could be sitting > > with the CEO of the company what is one thing you would ask him to fix? > > > > please keep it high level and general. i intend to pass these to him and > > his team in an upcoming meeting. > > > > Mehmet > > signature.asc Description: PGP signature
Re: CloudFlare issues?
Martijn - i3D.net is not in the list Job posted yesterday of RPKI ROV deployment. Your message below hints that you may be using RPKI. Are you doing ROV? (You may be in the “hundreds of others” category.) —Sandy Begin forwarded message: From: Job Snijders Subject: Re: CloudFlare issues? Date: July 4, 2019 at 11:33:57 AM EDT To: Francois Lecavalier Cc: "nanog@nanog.org" I believe at this point in time it is safe to accept valid and unknown (combined with an IRR filter), and reject RPKI invalid BGP announcements at your EBGP borders. Large examples of other organisations who already are rejecting invalid announcements are AT&T, Nordunet, DE-CIX, YYCIX, XS4ALL, MSK-IX, INEX, France-IX, Seacomm, Workonline, KPN International, and hundreds of others. > On Jul 4, 2019, at 5:56 AM, i3D.net - Martijn Schmidt via NANOG > wrote: > > So that means it's time for everyone to migrate their ARIN resources to a > sane RIR that does allow normal access to and redistribution of its RPKI TAL? > ;-) > > The RPKI TAL problem + an industry-standard IRRDB instead of WHOIS-RWS were > both major reasons for us to bring our ARIN IPv4 address space to RIPE. > Unfortunately we had to renumber our handful of IPv6 customers because ARIN > doesn't do IPv6 inter-RIR transfers, but hey, no pain no gain. > > Therefore, Cloudflare folks - when are you transferring your resources away > from ARIN? :D > > Best regards, > Martijn > > On 7/4/19 11:46 AM, Mark Tinka wrote: >> I finally thought about this after I got off my beer high :-). >> >> Some of our customers complained about losing access to Cloudflare's >> resources during the Verizon debacle. Since we are doing ROV and dropping >> Invalids, this should not have happened, given most of Cloudflare's IPv4 and >> IPv6 routes are ROA'd. >> >> However, since we are not using the ARIN TAL (for known reasons), this >> explains why this also broke for us. >> >> Back to beer now :-)... >> >> Mark. >
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG. Daily listings are sent to bgp-st...@lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 06 Jul, 2019 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary BGP routing table entries examined: 760370 Prefixes after maximum aggregation (per Origin AS): 293074 Deaggregation factor: 2.59 Unique aggregates announced (without unneeded subnets): 366150 Total ASes present in the Internet Routing Table: 64764 Prefixes per ASN: 11.74 Origin-only ASes present in the Internet Routing Table: 55696 Origin ASes announcing only one prefix: 23947 Transit ASes present in the Internet Routing Table:9068 Transit-only ASes present in the Internet Routing Table:284 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 42 Max AS path prepend of ASN ( 27978) 31 Prefixes from unregistered ASNs in the Routing Table:22 Number of instances of unregistered ASNs:24 Number of 32-bit ASNs allocated by the RIRs: 27720 Number of 32-bit ASNs visible in the Routing Table: 22620 Prefixes from 32-bit ASNs in the Routing Table: 102165 Number of bogon 32-bit ASNs visible in the Routing Table:17 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space:217 Number of addresses announced to Internet: 2838933888 Equivalent to 169 /8s, 54 /16s and 177 /24s Percentage of available address space announced: 76.7 Percentage of allocated address space announced: 76.7 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 99.3 Total number of prefixes smaller than registry allocations: 252618 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes: 205898 Total APNIC prefixes after maximum aggregation: 61349 APNIC Deaggregation factor:3.36 Prefixes being announced from the APNIC address blocks: 201560 Unique aggregates announced from the APNIC address blocks:84128 APNIC Region origin ASes present in the Internet Routing Table:9868 APNIC Prefixes per ASN: 20.43 APNIC Region origin ASes announcing only one prefix: 2749 APNIC Region transit ASes present in the Internet Routing Table: 1476 Average APNIC Region AS path length visible:4.5 Max APNIC Region AS path length visible: 26 Number of APNIC region 32-bit ASNs visible in the Routing Table: 4868 Number of APNIC addresses announced to Internet: 770901888 Equivalent to 45 /8s, 243 /16s and 7 /24s APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-141625 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:225924 Total ARIN prefixes after maximum aggregation: 105561 ARIN Deaggregation factor: 2.14 Prefixes being announced from the ARIN address blocks: 225090 Unique aggregates announced from the ARIN address blocks:106979 ARIN Region origin ASes present in the Internet Routing Table:18511 ARIN Prefixes per ASN:12.16 ARIN Region
