Re: Server rental inside of One Wilshire in Los Angeles

[Siyuan Miao via NANOG]

CoreSite now charges a disconnect fee for all cross-connects in addition to
the MRC and connection fee.

If you don't plan to cross-connect at CoreSite LA1 (One Wilshire), you may
consider other nearby facilities. Most facilities are backhauled there
anyway.

On Thu, Aug 8, 2024 at 1:15 PM Saku Ytti  wrote:

> On Wed, 7 Aug 2024 at 20:05, Christopher Morrow 
> wrote:
>
> > I'd bet the real answer is that someone wants to connect a commodity
> > server to an IX and pretend to be
> > some network/asn and then do some not terrific things with that setup :(
> >
> > seen this in AMSIX and DECIX ... don't know that I've not seen it also
> > at 1-wilshire ;(
>
> This seems very plausible, considering the chosen demo. Thanks.
>
> --
>   ++ytti
>

Re: Opengear alternatives that support 5g?

[Siyuan Miao via NANOG]

We use GL.inet and set up WireGuard VPNs back to our distributed VPN
servers. Our console servers support dual uplink, so we just connect port 1
to the GL.inet LAN and port 2 to our management switch.

Currently, we're still using their LTE model, and it costs ~100 USD per
site, but their 5G models are expensive and cost around $500.

On Sun, Apr 28, 2024 at 6:33 PM Mark Tinka  wrote:

>
>
> On 4/27/24 17:49, Mel Beckman wrote:
> > Quite often I’m looking for OOBM at antenna sites or in remote DCs where
> there is no Plan B carrier. Cellular has always been the goto choice for
> this, but we keep getting pushed out of contracts by technology upgrades.
> 2g, then 3g, and  next 4g LTE are being deprecated.
> >
> > The main reason for network shutdowns is that the carriers have limited
> spectrum available for expansion. To deliver faster, more cost effective
> data service to customers, carriers must re-use existing spectrum licenses
> with newer, more efficient cellular technology. Old 2G/3G infrastructure
> makes way for new networks, and older cellular devices must be retired. 4g
> may have a decade left before complete absence, but its footprint is
> already shrinking where 5G is available.
> >
> > I’ve seen this first hand with 4g cellular alarm circuits: suddenly they
> get less reliable or fail completely, and the reason always turns out to be
> degraded RSSI due to 5G deployment.
> >
> > So 5G is imperative for cellular OOBM, hence the hunt for COTS drop-in
> replacements that won’t break the bank. Upgrading, for example, 100 antenna
> sites is also a major truck roll cost, so we want to get it right the first
> time.  Physical space and power limitations usually rule out 1U rackmount
> refurb Cisco terminal servers, which is why we need 0U gear. Yes, I can
> cobble together a raspberry pi and some hats and cables and dingles and
> dangles and make a science fair solution. But I need something that is
> commercially supported, won’t have me scratching my head later about what
> version of the Ubuntu is going to work, and won’t randomly fry its
> electronics during a power surge.
> >
> > It’s looking like that solution is firmly priced at ~$500 today.
>
> Fair enough - if the bulk of your OoB use-case is remote (cell) sites,
> your typical options won't work or will be limited.
>
> Oddly, in our parts, we find remote, non-city locations, tend to keep
> their 3G/4G status, or don't even get considered for 5G at all. But I
> guess this will vary by market the world over, so I could see a remote
> site in Norway, for example, having 5G vs. a remote site in, say, Egypt,
> doing the same.
>
> I think what you probably want to consider for the long-term is
> decoupling the device from the network media. If you can attach a MiFi
> router via a USB port to a cheap device (like Mikrotik), this would help
> keep costs down as mobile operators deprecate GSM data technologies in
> the future. I like Mikrotik because in addition to being cheap and
> feature-rich for basic network access, the firmware is regularly
> upgradeable unlike typical consumer-style CPE's.
>
> Mark.
>

Re: [anti-abuse-wg] Yet another BGP hijacking towards AS16509

[Siyuan Miao]

Amazon was only announcing 44.224.0.0/11 at first.

https://bgp.tools/prefix/44.235.216.0/24

On Tue, Aug 23, 2022 at 4:03 AM Ronald F. Guilmette 
wrote:

> In message <
> cao3camot9gc_evd-cczg06a-o_majmltxlhbxfnaudomyqo...@mail.gmail.com>,
> Siyuan Miao  wrote:
>
> >Hjacking didn't last too long. AWS started announcing a more specific
> >announcement to prevent hijacking around 3 hours later. Kudos to Amazon's
> >security team :-)
>
> Sorry.  I'm missing something here.  If the hijack was of 44.235.216.0/24,
> then
> how did AWS propagate a "more specific" than that?
>
>
> Regards,
> rfg
>
> --
>
> To unsubscribe from this mailing list, get a password reminder, or change
> your subscription options, please visit:
> https://lists.ripe.net/mailman/listinfo/anti-abuse-wg
>

Re: Yet another BGP hijacking towards AS16509

[Siyuan Miao]

Just noticed another thing:

➜  ~ whois -h whois.ripe.net -- "--list-versions AS1299" | tail -n10
2862  2022-07-11T14:44:49Z  ADD/UPD
2863  2022-07-27T11:17:25Z  ADD/UPD
2864  2022-08-02T08:43:02Z  ADD/UPD
2865  2022-08-10T12:11:29Z  ADD/UPD


*2866  2022-08-17T10:47:43Z  ADD/UPD2867  2022-08-18T12:53:37Z  ADD/UPD*
% This query was served by the RIPE Database Query Service version 1.103
(WAGYU)

➜  ~ whois -h whois.ripe.net -- "--show-version 2865 AS1299" | grep 209243
➜  ~ whois -h whois.ripe.net -- "--show-version 2866 AS1299" | grep 209243
import: from  AS209243 accept AS209243
mp-import:  afi ipv6 from AS209243 accept AS209243


*➜  ~ whois -h whois.ripe.net <http://whois.ripe.net> -- "--show-version
2867 AS1299" | grep 209243import: from  AS209243 accept
AS-SET209243mp-import:  afi ipv6 from AS209243 accept AS-SET209243*

Looks like the first thing that AS209243 had done after they got AS1299
transit is ... hijacking an Amazon prefix ..?

On Tue, Aug 23, 2022 at 1:51 AM Siyuan Miao  wrote:

> Hi folks,
>
> Recently I read a post regarding the recent incident of Celer Network and
> noticed a very interesting and successful BGP hijacking towards AS16509.
>
> The attacker AS209243 added AS16509 to their AS-SET and a more specific
> route object for the /24 where the victim's website is in ALTDB:
> (Below is our IRRd4 server NRTM logging, UTC timezone)
>
> irrd.log-20220817.gz:31106270-ADD 96126
>
> irrd.log-20220817.gz:31106280-
>
> irrd.log-20220817.gz:31106281-as-set: AS-SET209243
>
> irrd.log-20220817.gz:31106306-descr:  quickhost set
>
> irrd.log-20220817.gz:31106332-members:AS209243, AS16509
>
> irrd.log-20220817.gz:31106362:mnt-by: MAINT-QUICKHOSTUK
>
> irrd.log-20220817.gz:31106392-changed:cruss...@quickhostuk.net
> 20220816
>
> irrd.log-20220817.gz:31106438-source: ALTDB
>
> irrd.log-20220817.gz:31147549-ADD 96127
>
> irrd.log-20220817.gz:31147559-
>
> irrd.log-20220817.gz:31147560-route:  44.235.216.0/24
>
> irrd.log-20220817.gz:31147588-descr:  route
>
> irrd.log-20220817.gz:31147606-origin: AS16509
>
> irrd.log-20220817.gz:31147626:mnt-by: MAINT-QUICKHOSTUK
>
> irrd.log-20220817.gz:31147656-changed:cruss...@quickhostuk.net
> 20220816
>
> irrd.log-20220817.gz:31147702-source: ALTDB
>
>
> Then they started announcing the prefix ... under another AWS ASN (AS14618)
> I guess AS1299 Arelion doesn't check if the origin AS of an announcement
> is in the customer's AS-SET but it's pretty normal and understandable.
>
>
> https://stat.ripe.net/widget/bgplay#w.resource=44.235.216.0/24&w.ignoreReannouncements=true&w.starttime=1660694458&w.endtime=1661032798&w.rrcs=0&w.instant=null&w.type=bgp
>
>
> Type: A > announce Involving: 44.235.216.0/24
> Short description: The new route 34854 1299 209243 14618 has been
> announced
> Path: 34854, 1299, 209243, 14618,
> Community: 1299:35000,34854:3001
> Date and time: 2022-08-17 19:39:50 Collected by: 00-2.56.11.1
>
> Hjacking didn't last too long. AWS started announcing a more specific
> announcement to prevent hijacking around 3 hours later. Kudos to Amazon's
> security team :-)
>
> Type: A > announce Involving: 44.235.216.0/24
> Short description: The new route 58057 34549 5511 1299 16509 has been
> announced
> Path: 58057, 34549, 5511, 1299, 16509,
> Community: 5511:521,5511:666,5511:710,5511:5511,34549:100,34549:5511
> Date and time: 2022-08-17 23:08:47 Collected by: 00-194.50.92.251
>
> The attacker cleaned up the IRR objects on 17 Aug and surprisingly no one
> seems to notice them ...
>
> irrd.log-20220819.gz:26517714-ADD 96196
>
> irrd.log-20220819.gz:26517724-
>
> irrd.log-20220819.gz:26517725:as-set: AS-SET209243
>
> irrd.log-20220819.gz:26517750-descr:  quickhost set
>
> irrd.log-20220819.gz:26517776-members:AS209243, AS35437, AS37497
>
> irrd.log-20220819.gz:26517815-mnt-by: MAINT-QUICKHOSTUK
>
> irrd.log-20220819.gz:26517845-changed:cruss...@quickhostuk.net
> 20220817
>
> irrd.log-20220819.gz:26517891-source: ALTDB
>
>
>
> irrd.log-20220819.gz:26517910-DEL 96197
>
> irrd.log-20220819.gz:26517920-
>
> irrd.log-20220819.gz:26517921-route:  44.235.216.0/24
>
> irrd.log-20220819.gz:26517949-descr:  route
>
> irrd.log-20220819.gz:26517967-origin: AS16509
>
> irrd.log-20220819.gz:26517987-mnt-by: MAINT-QUICKHOSTUK
>
> irrd.log-20220819.gz:26518017-changed:cruss...@quickhostuk.net
> 20220816
>
> irrd.log-20220819.gz:26518063-source: ALTDB
>
>
>
> Nowadays hijacking a service by forging AS path is pretty easy and RPKI
> won't be able to solve this (as it validates origin AS and prefixes only)
> :-(
>
> Regards,
> Siyuan
>
>
>

Yet another BGP hijacking towards AS16509

[Siyuan Miao]

Hi folks,

Recently I read a post regarding the recent incident of Celer Network and
noticed a very interesting and successful BGP hijacking towards AS16509.

The attacker AS209243 added AS16509 to their AS-SET and a more specific
route object for the /24 where the victim's website is in ALTDB:
(Below is our IRRd4 server NRTM logging, UTC timezone)

irrd.log-20220817.gz:31106270-ADD 96126

irrd.log-20220817.gz:31106280-

irrd.log-20220817.gz:31106281-as-set: AS-SET209243

irrd.log-20220817.gz:31106306-descr:  quickhost set

irrd.log-20220817.gz:31106332-members:AS209243, AS16509

irrd.log-20220817.gz:31106362:mnt-by: MAINT-QUICKHOSTUK

irrd.log-20220817.gz:31106392-changed:cruss...@quickhostuk.net 20220816

irrd.log-20220817.gz:31106438-source: ALTDB

irrd.log-20220817.gz:31147549-ADD 96127

irrd.log-20220817.gz:31147559-

irrd.log-20220817.gz:31147560-route:  44.235.216.0/24

irrd.log-20220817.gz:31147588-descr:  route

irrd.log-20220817.gz:31147606-origin: AS16509

irrd.log-20220817.gz:31147626:mnt-by: MAINT-QUICKHOSTUK

irrd.log-20220817.gz:31147656-changed:cruss...@quickhostuk.net 20220816

irrd.log-20220817.gz:31147702-source: ALTDB


Then they started announcing the prefix ... under another AWS ASN (AS14618)
I guess AS1299 Arelion doesn't check if the origin AS of an announcement is
in the customer's AS-SET but it's pretty normal and understandable.

https://stat.ripe.net/widget/bgplay#w.resource=44.235.216.0/24&w.ignoreReannouncements=true&w.starttime=1660694458&w.endtime=1661032798&w.rrcs=0&w.instant=null&w.type=bgp


Type: A > announce Involving: 44.235.216.0/24
Short description: The new route 34854 1299 209243 14618 has been announced
Path: 34854, 1299, 209243, 14618,
Community: 1299:35000,34854:3001
Date and time: 2022-08-17 19:39:50 Collected by: 00-2.56.11.1

Hjacking didn't last too long. AWS started announcing a more specific
announcement to prevent hijacking around 3 hours later. Kudos to Amazon's
security team :-)

Type: A > announce Involving: 44.235.216.0/24
Short description: The new route 58057 34549 5511 1299 16509 has been
announced
Path: 58057, 34549, 5511, 1299, 16509,
Community: 5511:521,5511:666,5511:710,5511:5511,34549:100,34549:5511
Date and time: 2022-08-17 23:08:47 Collected by: 00-194.50.92.251

The attacker cleaned up the IRR objects on 17 Aug and surprisingly no one
seems to notice them ...

irrd.log-20220819.gz:26517714-ADD 96196

irrd.log-20220819.gz:26517724-

irrd.log-20220819.gz:26517725:as-set: AS-SET209243

irrd.log-20220819.gz:26517750-descr:  quickhost set

irrd.log-20220819.gz:26517776-members:AS209243, AS35437, AS37497

irrd.log-20220819.gz:26517815-mnt-by: MAINT-QUICKHOSTUK

irrd.log-20220819.gz:26517845-changed:cruss...@quickhostuk.net 20220817

irrd.log-20220819.gz:26517891-source: ALTDB



irrd.log-20220819.gz:26517910-DEL 96197

irrd.log-20220819.gz:26517920-

irrd.log-20220819.gz:26517921-route:  44.235.216.0/24

irrd.log-20220819.gz:26517949-descr:  route

irrd.log-20220819.gz:26517967-origin: AS16509

irrd.log-20220819.gz:26517987-mnt-by: MAINT-QUICKHOSTUK

irrd.log-20220819.gz:26518017-changed:cruss...@quickhostuk.net 20220816

irrd.log-20220819.gz:26518063-source: ALTDB



Nowadays hijacking a service by forging AS path is pretty easy and RPKI
won't be able to solve this (as it validates origin AS and prefixes only)
:-(

Regards,
Siyuan

Re: Peering with Google and Microsoft

[Siyuan Miao]

For Microsoft Peering you might need to create an Azure account. You can
find the how-to document below:

https://docs.microsoft.com/en-us/azure/internet-peering/howto-exchange-portal

On Wed, Aug 10, 2022 at 1:39 PM Oskar Borgqvist  wrote:

> Hi Nanog
>
> We have tried to get peering with Google but only get answers that they
> are making their peering system better. I have received this answer for
> over 1 year.
> The reason why we needed peering to Google is that they do not send out
> exact prefixes over IXP RS, which means that our traffic from Sweden down
> to Germany and up again to Sweden again.
> This has created a bit of a problem for us.
>
> If anyone could help us with this it would be appreciated. Or can give an
> explanation.
>
> Since then, we have also tried to get peering with Microsoft without
> success.  We have tried to contact them via their peering email without
> success.  Would appreciate help here as well.
>
> Sincerely,
> Oskar Borgqvist
> --
>
>
> *Oskar Borgqvist*CEO/Owner/Network Engineer
> Mail: os...@karabro.se
> Tele: +46 406 68 80 96
>
> *Vi bygger broar mellan internet och **människor*
>

Re: HE.net and BGP Communities

[Siyuan Miao]

They do have BGP communities ... but for black-hole only :-(

On Sun, Jul 24, 2022 at 9:39 PM Ryan Hamel 
wrote:

> Yes.
>
> Ryan
>
> -Original Message-
> From: NANOG  On Behalf Of
> Rubens Kuhl
> Sent: Sunday, July 24, 2022 12:36 PM
> To: Nanog 
> Subject: HE.net and BGP Communities
>
> The last mention I found on NANOG about HE.net and BGP communities for
> traffic engineering is from April 2021 and said they provided none.
>
> Is that still the case a year later ?
>
>
> Rubens
>
>

Re: ASN oddity in the routing

[Siyuan Miao]

The two networks are forging AS path and that's why you're seeing their IP
addresses announced under African ASNs.


On Tue, Jun 7, 2022 at 8:27 PM Ren C. via NANOG  wrote:

> Hello, I am unsure if there is a better place to ask. I am learning
> working on the enabling RPKI and authoritative IRR validation in my day job.
> However, I find some very strange ASN grouped together. I understand
> several do not bother with RPKI or IRR, especially many large tier 1, which
> don't really care or need about other people's transit, but this is very
> small and I do not heard of it before.
>
> In my  logs to see which routes have the broken or malformed , frequently
> it is just omission and incorrect, but there are some very odd situations,
> but it also appears to be verified in other BGP glass.
> Can someone please tell me whether these invalid is a bug in the routing?
> Why are there so many Africa networks going through a small Virginia
> provider and more than half the IP is bogon, but has an IRR entry for the
> wrong provider or it is unrelated? It does not look like the AS is related
> at all, and they are not in the same country, but there is a relationship
> peering.
>
> https://bgp.he.net/AS208254#_peers6
> https://bgp.he.net/AS398481#_peers6
>
> Thank you
>
>
>
> --
> Sent with https://mailfence.com
> Secure and private email
>

Re: Asia Apac networks

[Siyuan Miao]

Cogent didn't peer with NTT and PCCW in Asia so it's normal if they still
prefer local routes. Otherwise the latency might be at least 100ms.

On Fri, Mar 11, 2022 at 12:50 Lady Benjamin Cannon of Glencoe, ASCE <
l...@6by7.net> wrote:

> This sort of thing in general is not uncommon in my experience.  Many
> networks weight our outbound with local preferences.
>
> Ms. Lady Benjamin PD Cannon of Glencoe, ASCE
> 6x7 Networks & 6x7 Telecom, LLC
> CEO
> l...@6by7.net
> "The only fully end-to-end encrypted global telecommunications company in
> the world.”
>
> FCC License KJ6FJJ
>
> Sent from my iPhone via RFC1149.
>
> > On Mar 9, 2022, at 2:30 AM, Edvinas Kairys 
> wrote:
> >
> > 
> >   Hello,
> >
> > We've introduced Cogent network in Equinix Honk Kong DC. But seems via
> that link we're just receiving just only 5% of our traffic, other part of
> incoming traffic is received via our other ISPs like NTT, Simcentrc, and
> Equinix IXP.
> > I know it's very naïve to expect the traffic load balance equally
> between 3 ISPs (4 if IXP is counted) using just one /24 subnet. According
> to most of BGP looking glasses in Asia, traffic via Cogent is least
> preferred even when i've added 6x prepend AS on our other mentioned
> providers to make route via Cogent more attractive. But nothing helps -
> seems main providers in Asia made routes via Cogent least preferable by
> lowering the local preference to it, that why prepending from our side
> doesn't help.
> >
> > Maybe someone has experience or similar problems with ISPs in Asia
> network ?
> >
> >
>

Re: Geolocation accuracy

[Siyuan Miao]

You can try IPInsight.io.

We've been using it for years and its accuracy is better than MaxMind,
usually.

On Tue, Oct 19, 2021 at 8:28 PM Jeroen Massar via NANOG 
wrote:

> On 2021-10-19 13:39, Hank Nussbacher wrote:
> > Can anyone recommend a geo-location service with high city accuracy?
> > Maxmind, for most countries (broadband, which does move) is below 50%
> > accuracy (they claim 68% accuracy for USA cities):
> >
> https://www.maxmind.com/en/geoip2-city-accuracy-comparison?country=&resolution=city&cellular=excluding
>
> What is the purpose of the geo-locating?
>
> As that might influence how much it actually matters where the user is...
>
> Greets,
>   Jeroen
>
>

Re: Anyone else getting the 'spam' bomb threat?

[Siyuan Miao]

Yes, it's from the operator of bytefend and they have been sending numerous
threatening emails for months.

You can check the statement from the victim Frantech from the link below:

https://frantech.ca/

On Tue, Oct 19, 2021 at 9:34 PM Ray Bellis  wrote:

>
>
> On 19/10/2021 13:29, Travis Garrison wrote:
>
> > Yup, same here
>
> and here.
>
> For now we're just ignoring it, but if anyone wants to quote us (ISC, a
> DNS root server operator) in the event of law enforcement action please
> let me know.
>
> Ray
>
>

Re: Spamhaus ASN-DROP list

[Siyuan Miao]

It's not.

The ASN was assigned by RIPE in Sep 2019.

On Fri, Jul 23, 2021 at 3:20 PM Suresh Ramasubramanian 
wrote:

> This is probably an ex afrinic stolen block?
>
> In which case it’s for afrinic to sort out and reclaim
>
> --srs
> --
> *From:* NANOG  on behalf of
> Siyuan Miao 
> *Sent:* Friday, July 23, 2021 12:38:16 PM
> *To:* North American Network Operators' Group 
> *Subject:* Spamhaus ASN-DROP list
>
> Hi All,
>
> One of our ASNs has been listed in the Spamhaus ASN-DROP list before it
> was assigned to us.
>
> We emailed them last year but didn't get a response. Could anyone from
> Spamhaus contact us off the list?
>
> Best Regards,
> Siyuan
>
>

Spamhaus ASN-DROP list

[Siyuan Miao]

Hi All,

One of our ASNs has been listed in the Spamhaus ASN-DROP list before it was
assigned to us.

We emailed them last year but didn't get a response. Could anyone from
Spamhaus contact us off the list?

Best Regards,
Siyuan

Re: Any2 LAX

[Siyuan Miao]

Yea, it was down but both RS are online and feeding us unreachable nexthops
during the outage .

On Sat, Jun 12, 2021 at 1:27 AM Seth Mattinen  wrote:

> On 6/11/21 10:16 AM, Jon Lewis wrote:
> > On Fri, 11 Jun 2021, Seth Mattinen wrote:
> >
> >> Did Any2 LAX barf last night between about 1am and 8am Pacific time?
> >
> > More like 00:00-7:45 (Pacific time).
> >
> > Anyone know what broke, and why the IX was dead for nearly 8 hours?
> > This is our second recent issue with "an Any2 IX", having dealt with an
> > IX partition event at Any2 Denver just a few weeks ago.
> >
>
>
> What I saw was a lot of unreachable nexthops (I'm in LA2) on routes
> advertised through the route servers. Most of my direct BGP sessions
> were down, but a handful were still working including the route servers.
>
> For example, I was getting routes for AS29791 from the route servers,
> but nexthop 206.72.211.106 was dead to me. Not to pick on Internap other
> than a mutual customer called me directly at 1am and wanted to know why
> things were down.
>
> I killed the route server sessions and went back to sleep.
>
> Feels like LA1 and LA2 got split, but however the route servers
> interconnect still worked, which was problematic.
>

Re: Google IP Geolocation

[Siyuan Miao]

It seems that Geofeed is no longer working starting last week.

Can confirm this with other few server providers with VPN customers. The
geolocation is now the user's REAL location like Asia or Mid-East while the
IP itself is in the US.

On Tue, Mar 30, 2021, 03:54 Mike Hammett  wrote:

> I've had others at Google specifically say that portal should be used for
> that purpose, so maybe they need to make sure right and left hands know
> what the other is doing.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
> --
> *From: *"Josh Luthman" 
> *To: *"Christopher Morrow" 
> *Cc: *nanog@nanog.org
> *Sent: *Monday, March 29, 2021 1:52:48 PM
> *Subject: *Re: Google IP Geolocation
>
> https://isp.google.com
>
> I signed up for an account there and they said:
>
> "Currently, the Google ISP portal is designed for our partners of GGC, PNI
> or IX programs.
>
> The access to portal is granted on request only to our partners."
>
> Josh Luthman
> 24/7 Help Desk: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
>
>
> On Mon, Mar 29, 2021 at 2:08 PM Christopher Morrow <
> morrowc.li...@gmail.com> wrote:
>
>>
>>
>> On Mon, Mar 29, 2021 at 1:59 PM Josh Luthman 
>> wrote:
>>
>>> Google ISP specifically told me they didn't want to do deal with
>>> geolocation on the ISP portal.
>>>
>>>
>> unsure who 'google isp' is here, but ... I think if you point at a
>> properly formed geo-location data file it'll get eaten and produce proper
>> results for you.
>> you do have to add that in your isp portal:
>>tri-pipe-thingy -> configuration -> IP geolocation
>> and /register feed/ button on that page.
>>
>>
>>> Josh Luthman
>>> 24/7 Help Desk: 937-552-2340
>>> Direct: 937-552-2343
>>> 1100 Wayne St
>>> Suite 1337
>>> Troy, OH 45373
>>>
>>>
>>> On Sat, Mar 27, 2021 at 3:28 PM Christopher Morrow <
>>> morrowc.li...@gmail.com> wrote:
>>>
 As a note, on the ISP portal there's a place to put a link to your
 RFC8805 format geolocation feed...
 these are scraped out 'regularly' and help keep things oriented better
 for folks.

 the ietf noc folk use this method to tell google (and other folk who
 scrape out our data) where meetings are before the meetings get there:
   https://noc.ietf.org/geo/google.csv

 -chris
 volunteer noc persona

 On Fri, Mar 26, 2021 at 6:43 PM Michael K. Spears 
 wrote:

> Awesome, I think I’ve figured out the Google ISP portal signup, but it
> definitely seems semi-complicated in a way, notably finding the link…
>
>
>
> Thank you,
>
> Michael K. Spears
>
> 727.656.3347
>
>
>
> *From:* Mike Hammett 
> *Sent:* Friday, March 26, 2021 6:30 PM
> *To:* Michael K. Spears 
> *Cc:* nanog@nanog.org
> *Subject:* Re: Google IP Geolocation
>
>
>
> We're working on a video to show people how to sign up for the ISP
> portal and get to that part of the portal once signed up. We'll drop a 
> link
> to it near the Google section of our geolocation page.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
>
> --
>
> *From: *"Michael K. Spears" 
> *To: *nanog@nanog.org
> *Sent: *Friday, March 26, 2021 5:10:23 PM
> *Subject: *Google IP Geolocation
>
> Anyone have a good contact at Google who can help with IP geolocation?
> I have a /24 where anything related to Google is in the wrong language.
>
>
>
> Thank you,
>
> Michael K. Spears
>
>
>

>

Re: DOD prefixes and AS8003 / GRSCORP

[Siyuan Miao]

Hi Nick,

M0601699 was closed in 2006 according to Sunbiz (FL's official website):

http://search.sunbiz.org/Inquiry/CorporationSearch/SearchResultDetail?inquirytype=EntityName&directionType=Initial&searchNameOrder=GLOBALRESOURCESYSTEMS%20M06016990&aggregateId=forl-m0601699-a8147ffb-e7b4-41e1-a981-2bd8900de732&searchTerm=GLOBAL%20RESOURCE%20SYSTEMS%2C%20LLC&listNameOrder=GLOBALRESOURCESYSTEMS%20M06016990

The new GLOBAL RESOURCE SYSTEMS, LLC (M2009226) was registered
on 10/13/2020.

http://search.sunbiz.org/Inquiry/CorporationSearch/SearchResultDetail?inquirytype=EntityName&directionType=Initial&searchNameOrder=GLOBALRESOURCESYSTEMS%20M20092260&aggregateId=forl-m2009226-80a9eec9-7fe2-4426-b3cd-9ebaa3e4e3b6&searchTerm=GLOBAL%20RESOURCE%20SYSTEMS%2C%20LLC&listNameOrder=GLOBALRESOURCESYSTEMS%20M06016990

On Fri, Mar 12, 2021 at 7:52 PM Nick Hilliard  wrote:

> Siyuan Miao wrote on 12/03/2021 11:34:
> > My biggest concern is why the AS8003 was assigned to the company (GLOBAL
> > RESOURCE SYSTEMS, LLC) even before its existence.
>
> GRS LLC seems to have been around since 2006.
>
> > https://opencorporates.com/companies/us_fl/M0601699
>
> AS8003 was registered to them in Sep 2020:
>
> > ASNumber:   8003
> > ASName: GRS-DOD
> > ASHandle:   AS8003
> > RegDate:2020-09-14
> > Updated:2020-09-14
> > Ref:https://rdap.arin.net/registry/autnum/8003
>
> No doubt there is more information about the history of 8003 in WhoWas.
>
> Nick
>

Re: DOD prefixes and AS8003 / GRSCORP

[Siyuan Miao]

Hi John,

My biggest concern is why the AS8003 was assigned to the company (GLOBAL
RESOURCE SYSTEMS, LLC) even before its existence.

When we were requesting resources or transfers, ARIN always asked us to
provide a Certificate of Good Standing and we had to pay the state to order
it.

However, it appears that a Certificate of Good Standing is not required or
ARIN didn't validate it in this case.

Regards,
Siyuan

On Fri, Mar 12, 2021 at 7:17 PM John Curran  wrote:

> On 11 Mar 2021, at 7:56 AM, Siyuan Miao  wrote:
>
>
> Hi Folks,
>
> Just noticed that almost all DOD prefixes (7.0.0.0/8,11.0.0.0/8,22.0.0.0/8
> and bunch of /22s)  are now announced under AS8003 (GRSCORP) which was just
> formed a few months ago.
>
> It looks so suspicious. Does anyone know if it's authorized?
>
>
> Siyuan -
>
> If you have concerns, you can confirm whether these IP address blocks are
> being routed as intended by verification with their listed technical
> contacts - e.g. https://search.arin.net/rdap/?query=22.0.0.0
>
> As I noted on this list several weeks back - "lack of routing history is
> not at all a reliable indicator of the potential for valid routing of a
> given IPv4 block in the future, so best practice suggest that allocated
> address space should not be blocked by others without specific cause. Doing
> otherwise opens one up to unexpected surprises when issued space suddenly
> becomes more active in routing and is yet is inexplicably unreachable for
> some destinations."
>
> Thanks!
> /John
>
> John Curran
> President and CEO
> American Registry for Internet Numbers
>
>

Re: DOD prefixes and AS8003 / GRSCORP

[Siyuan Miao]

So this company (Global Resource Systems, LLC) was formed on 2020-10-13 and
ARIN assigned AS8003 to them even earlier than it.

Here's a simple timeline in case anyone want to have a check:

9/8/2020 GLOBAL RESOURCE SYSTEMS, LLC registered in Delaware
9/10/2020 Nameserver of grscorp.com was changed from AfterNIC (a website to
sell premium / expired domains) to UltraDNS
9/11/2020 GLOBAL RESOURCE SYSTEMS, LLC (FL) registered their organization
in ARIN
9/14/2020 GLOBAL RESOURCE SYSTEMS, LLC (FL) got AS8003 from ARIN
9/21/2020 MAINT-GRSL-AS8003 is registered in RADB
10/13/2020 GLOBAL RESOURCE SYSTEMS, LLC registered in Florida

Around 21/01/2021, AS8003 registered numerous route objects in RADB and
started announcing DOD space.
In addition to AS8003, they also added AS95 to their AS-set and registered
some objects under AS95.

Based on RIPEstats, Last seen of AS8003 before 2021 is around 2003.
And there's another GLOBAL RESOURCE SYSTEMS, LLC in FL which has been
inactive since 2013.


On Thu, Mar 11, 2021 at 10:31 PM Alain Hebert  wrote:

> I scratch it out to hiding in plain sight...
>
> -
> Alain Hebertaheb...@pubnix.net
> PubNIX Inc.
> 50 boul. St-Charles
> P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
> Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443
>
> On 3/11/21 9:14 AM, Filip Hruska wrote:
>
> Contacted HE NOC earlier regarding these announcements, they are
> "legitimate".
>
> Filip
>
> On 11/03/2021 14:56, Javier Henderson wrote:
>
>
> On Mar 11, 2021, at 8:43 AM, Eric Dugas via NANOG 
>  wrote:
>
> I would be really curious to see the LOA presented to AS6939 to announce
> 54 million IPs out of government IP space and what type of verification was
> done because it doesn't seem legit at all.
>
> Did you try calling the number on the WHOIS for AS8003, or maybe HE’s NOC
> to follow up?
>
> -jav
>
>
>

DOD prefixes and AS8003 / GRSCORP

[Siyuan Miao]

Hi Folks,

Just noticed that almost all DOD prefixes (7.0.0.0/8,11.0.0.0/8,22.0.0.0/8
and bunch of /22s)  are now announced under AS8003 (GRSCORP) which was just
formed a few months ago.

It looks so suspicious. Does anyone know if it's authorized?

Regards,
Siyuan

Re: Any2 Los Angeles down again

[Siyuan Miao]

It went down again today and last Sunday.

And yes, we can see 206.72.210.143 with heavy packet loss too. They said
that they will send us a RFO last Friday but I haven't got one.

On Tue, Feb 2, 2021 at 1:59 AM Seth Mattinen  wrote:

> On 1/26/21 3:51 AM, Siyuan Miao wrote:
> > Does anybody know if there's an alternative to Any2 Los Angeles
> > with predictable uptime and enough members in LA?
> >
> > It's the second outage this month and we've observed at least 7 outages
> > in the past year and we didn't even receive any maintenance notice or
> RFO.
> >
>
>
> Anyone else seeing problems with Any2 LAX right now (9:50 Pacific time)?
> I'm seeing packet loss to Microsoft AS8075 through 206.72.210.143 but
> not 206.72.211.94. Unsure if this is yet another repeat of recent Any2
> issues or limited to AS8075.
>

Re: Any2 Los Angeles down again

[Siyuan Miao]

Down again.

On Wed, Jan 27, 2021 at 12:19 AM Mike Lyon  wrote:

> Isn’t ANY2 LA collapsing  VLANs today? They sent a notice out about it
> yesterday AM.
>
> -Mike
>
> On Jan 26, 2021, at 04:55, Mike Hammett  wrote:
>
> 
> And instead of building out in LA where there's an obvious need, DE-CIX
> chose Chicago, where there are already several IXes running.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions <http://www.ics-il.com/>
> <https://www.facebook.com/ICSIL>
> <https://plus.google.com/+IntelligentComputingSolutionsDeKalb>
> <https://www.linkedin.com/company/intelligent-computing-solutions>
> <https://twitter.com/ICSIL>
> Midwest Internet Exchange <http://www.midwest-ix.com/>
> <https://www.facebook.com/mdwestix>
> <https://www.linkedin.com/company/midwest-internet-exchange>
> <https://twitter.com/mdwestix>
> The Brothers WISP <http://www.thebrotherswisp.com/>
> <https://www.facebook.com/thebrotherswisp>
> <https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg>
> --
> *From: *"Bob Purdon" 
> *To: *"Siyuan Miao" , "North American Network
> Operators' Group" 
> *Sent: *Tuesday, January 26, 2021 5:59:58 AM
> *Subject: *Re: Any2 Los Angeles down again
>
> On 26/01/2021 22:51, Siyuan Miao wrote:
> > Does anybody know if there's an alternative to Any2 Los Angeles
> > with predictable uptime and enough members in LA?
> >
> > It's the second outage this month and we've observed at least 7
> > outages in the past year and we didn't even receive any maintenance
> > notice or RFO.
>
> Likewise, I wouldn't be adverse to exploring options - I noticed a
> handful of peers disappear about an hour ago (most are still up).  A
> week or so back we lost most if not all...
>
> Then again, we had a different IX in San Francisco stop talking LACP
> with us out of the blue yesterday, for reasons still unknown but since
> fixed.
>
>
>

Any2 Los Angeles down again

[Siyuan Miao]

Does anybody know if there's an alternative to Any2 Los Angeles
with predictable uptime and enough members in LA?

It's the second outage this month and we've observed at least 7 outages in
the past year and we didn't even receive any maintenance notice or RFO.

--

Siyuan

Re: Neustar Geo Location Data

[Siyuan Miao]

Is this prefix leased from an IP broker?

If not, I would suggest not to use Neustar's data.

On Tue, Oct 6, 2020 at 9:38 PM John Von Essen  wrote:

> Anyone here have experience with Neustar’s Geo Location database feed?
>
> And by experience, I mean, how reliable it is to reality?
>
> I ask because I’m in the early stages of a project, and my initial take is
> the data is terrible.
>
> I’ve stumbled across several (like a few hundred, and thats just in the
> US) /22’s and /23’s that SWIP in Arin to small regional ISPs in the US, but
> in the Neustar geo data these /22s get broken out in many continuous /28’s
> and /27’s that appear to hop across the world.
>
> One case was a small rural WISP in St Louis, their /22 in Neustar’s data
> is spread across Brazil, Asia, Europe, I mean its all over the place. But
> in BGP, that /22 appears safe and sound coming from St Louis and also
> confirmed via traceroute.
>
> If it were just a few ranges, I’d say no big deal, but I’m seeing massive
> issues with the data - curious as to other people’s thoughts.
>
> Thanks
> John
>
>
>
>

Re: Project/Tool to deploy and maintain Edge Servers (VMs) remotely

[Siyuan Miao]

Saltstack / Chef may be the solution you need.

If you're already using ansible, how about ansible-pull?

On Fri, Sep 4, 2020 at 7:03 PM Jared Mauch  wrote:

>
>
> > On Sep 4, 2020, at 6:52 AM, Douglas Fischer 
> wrote:
> >
> > I'm looking for some tool to work as a Comand and Control of several
> remote nodes.
> >
> > The idea is to have many-many nodes of Virtual Machines running on every
> ASN voluntarily to deploy some services spread everywhere we can.
> >
> >
> > Something like a Call-Home, that allows the headquarter to track
> operation, health state, deploy commands.
> > (Re-reading this phrase, it could sound like a newbie
> >  hacker trying to create his own Mirai. haha...
> >  It's not the case... I'm not on the dark side of the force.)
> >
> >
> > I was thinking in use something like reverse ssh and ansible.
> > But I thought that I'm probably reinventing part of the wheel.
> >
> > I want to believe that there already some projects that would put-me
> some steps further on this project.
> >
> >
> > Could anyone give-me some-tip?
> >
>
> You may want to look at the NLNOG Ring both for examples, but also for how
> to have interesting views from around the world, similar to RIPE Atlas.
>
> - Jared
>
>

Re: Tips on dealing with illicit BGP announcements

[Siyuan Miao]

Adding a route object in RADB doesn't need to verify ownership of the IP
block.

You can send a removal request to RADB admins and their upstream, they will
be glad to remove it.

On Fri, Jul 24, 2020 at 2:05 PM Randy Carpenter 
wrote:

>
> I am working with a client that has recently purchased and transferred an
> IPv4 block.
>
> Sometime in between when the purchase and research was done and when the
> transfer was actually complete, an entity in Asia started illicitly
> announcing a larger block that includes the block in question. They even
> have gotten an RADB entry in place for it.
>
> Does anyone have some tips on how to deal with this? I have a feeling that
> dealing directly with the offending entity will not be very fruitful.
>
> thanks,
> -Randy
>

Re: favorite network troubleshooting tools (online)

[Siyuan Miao]

https://perfops.net/mtr-from-world
https://tools.ipip.net/ping.php

and RIPE Atlas :-)

On Thu, Jul 16, 2020 at 3:33 AM Brandon Svec 
wrote:

> I have been using papertrailapp.com a lot recently.  It is a cloud based
> syslog server with a free tier and nice GUI.  Email and webhook alerts can
> be created in a snap (and that is the part I like the most)
>
> Brandon
>
> On Jul 15, 2020, at 10:37 AM, Mehmet Akcin  wrote:
>
> hey there,
>
> I recently have come across this http://ping.pe/ website, I have no
> association with this but it's pretty awesome. This made me wonder what
> other tools out there which I do not know about it.
>
> what are your favorite network troubleshooting tools?
>
> In addition to ping.pe, I like https://bgp.he.net but would love to hear
> your thought about other tool recommendations as especially the ones that
> are distributed.
>
> Mehmet
>
>
>

Re: Best way to get foreign ISPs to shut down DDoS reflectors?

[Siyuan Miao]

It won't work.

Get a good DDoS protection and forget about it.

On Fri, Apr 24, 2020 at 5:17 AM Bottiger  wrote:

> Is there a guide on how to get foreign ISPs to shut down reflectors used
> in DDoS attacks?
>
> I've tried sending emails listed under abuse contacts for their regional
> registries. Either there is none listed, the email is full, email does not
> exist, or they do not reply. Same results when sending to whatever other
> email they have listed.
>
> Example Networks:
>
> CLARO S.A.
> Telefonica
> China Telecom
> Korea Telecom
>

AS16509 contacts in peering?

[Siyuan Miao]

Hello,

Anyone has peering contacts in AS16509 other than peering#amazon(dot)com?

We'd like to establish peering with additional locations to balance the
AnyCast traffic but unfortunately got no response in the last 6 months.

Also, they forgot to update PeeringDB records on PTT Metro SP.

Thanks,

Re: [E] Re: Cost Recovery Surcharge & Va Personal Property Tax Recovery for IP Transit

[Siyuan Miao]

It's in Reston (Fairfax County).

On Wed, Jan 8, 2020 at 12:22 AM Eilers, Laura via NANOG 
wrote:

> If your data center is in Ashburn, which is in Loudoun County, then the
> servers inside are considered personal property and are taxed as such. They
> explain it in the latter part of the article.
>
>
> https://datacenterfrontier.com/the-data-center-dividend-tax-revenue-surges-in-loudoun-county/
>
>
> Laura
>
>
>
>
>
>
>
> On Mon, Jan 6, 2020 at 2:19 PM Matthew Petach 
> wrote:
>
>>
>>
>> On Mon, Jan 6, 2020 at 10:17 AM Tom Beecher  wrote:
>>
>>> Both are quite likely to be negotiable.
>>>
>>> FCC Cost Recovery fees are the federally mandated ones they are allowed
>>> to pass on to you. Most anything else named 'Cost Recovery' is optional,
>>> and so named to try and confuse you into thinking it's the mandatory stuff.
>>>
>>
>>
>> The person getting charged FCC Cost Recovery was in Canada, however.
>>
>> Good to know the US annexed Canada and brought it under the jurisdiction
>> of the FCC recently... ^_^;
>>
>> Matt
>>
>>

Re: Cost Recovery Surcharge & Va Personal Property Tax Recovery for IP Transit

[Siyuan Miao]

Tried again and failed again. Perhaps it's time to go to CoreSite directly
and cancel the contract.

> Cost Recovery Surcharge (CRS) is to recover costs charged to 
by the infrastructure providers to comply with government regulatory
requirements and proceedings, including costs associated with
administration and support, compliance and reporting obligations. This also
includes additional charges for Federal Regulatory Fees to recover direct
and indirect costs associated with government programs including regulatory
fees and expenses assessed by the FCC, such as fees to fund
telecommunications services for the speech and hearing-impaired, North
American Numbering Plan administration, FCC Regulatory Assessment and other
regulatory fees. The CRS rate is 3.0%. VA Property Tax Recovery (PTR) helps
to recover costs assessed on network facilities operators and related
charges incurred from our underlying carriers, including government
property tax assessments, franchise fees, right-of-way fee costs, network
security and infrastructure management. The PTR rate is 1.8%.

Thanks guys for helping us figure this out.

On Mon, Jan 6, 2020 at 11:56 PM Siyuan Miao  wrote:

> I've checked my contract and there's a line:
>
> > If ’s costs to provide services to Customer increase due to
> reasons beyond ’s control, including annual escalations imposed
> by facility providers (often referred to as “Facility Cost Recovery
> Surcharges”),  has the right to increase the fees paid by
> Customer to cover such costs.
>
> > If any local, state, national, international, public or quasi-public
> governmental entity or foreign government or its political subdivision
> imposes any taxes (excluding taxes based on ’s net income or
> capital or any property taxes), fees, surcharges, or other charges or
> impositions on  as a result of ’s sale of Services or
> Customer’s use of Services, Customer shall pay any such impositions
> (“Additional Charges”) and indemnify  from any liability or
> expense associated with the Additional Charges. Taxes that arise in any
> jurisdiction, including, without limitation, value added, consumption,
> sales, use, excise, access, bypass, franchise, or other taxes, fees,
> duties, charges or surcharges, however designated, imposed on, incident to,
> or based upon the provision, sale or use of the Service.
>
> Though, I don't think it's okay to pay CRS and property tax for IPT
> service.
> Will try to negotiate with them again.
>
> Honestly, it's my first time to see these BS. We never have any similar
> issues with other providers.
>
> On Mon, Jan 6, 2020 at 11:29 PM William Herrin  wrote:
>
>>
>>
>> On Mon, Jan 6, 2020 at 6:40 AM Siyuan Miao  wrote:
>>
>>> NANOG,
>>>
>>> We've recently signed contract of colocation + IP transit with a local
>>> provider in Northern Virginia.
>>>
>>> Co-location services is okay but we found something unusual on our IP
>>> transit invoices.
>>>
>>> - Va Personal Property Tax Recovery (1.8%)
>>>
>>> - Cost Recovery Surcharge (3%)?
>>>
>>> We've talked with our providers but they told us:
>>>
>>> > we use a tax engine that provides the taxes/rates to our services. If
>>> you would like further language on them, please let me know and I will have
>>> some one send that over.
>>>
>>> Has anyone else ran into this? If this is a legit "surcharge"?
>>> Also, IP transit isn't a property, why is there a "Property Tax" for IP
>>> transit?
>>>
>>
>> Hi Siyuan,
>>
>> If it's not written in to your contract, it's a breach of contract.
>> Either way it's a deceitfully imposed surcharge, not a state tax. Virginia
>> does not tax the sale of services like transit and colo. More, the only
>> personal property tax I've heard of in Virginia is on motor vehicles.
>>
>> Regards,
>> Bill Herrin
>>
>> --
>> William Herrin
>> b...@herrin.us
>> <https://bill.herrin.us/>
>> https://bill.herrin.us/
>>
>

Re: Cost Recovery Surcharge & Va Personal Property Tax Recovery for IP Transit

[Siyuan Miao]

I've checked my contract and there's a line:

> If ’s costs to provide services to Customer increase due to
reasons beyond ’s control, including annual escalations imposed
by facility providers (often referred to as “Facility Cost Recovery
Surcharges”),  has the right to increase the fees paid by
Customer to cover such costs.

> If any local, state, national, international, public or quasi-public
governmental entity or foreign government or its political subdivision
imposes any taxes (excluding taxes based on ’s net income or
capital or any property taxes), fees, surcharges, or other charges or
impositions on  as a result of ’s sale of Services or
Customer’s use of Services, Customer shall pay any such impositions
(“Additional Charges”) and indemnify  from any liability or
expense associated with the Additional Charges. Taxes that arise in any
jurisdiction, including, without limitation, value added, consumption,
sales, use, excise, access, bypass, franchise, or other taxes, fees,
duties, charges or surcharges, however designated, imposed on, incident to,
or based upon the provision, sale or use of the Service.

Though, I don't think it's okay to pay CRS and property tax for IPT service.
Will try to negotiate with them again.

Honestly, it's my first time to see these BS. We never have any similar
issues with other providers.

On Mon, Jan 6, 2020 at 11:29 PM William Herrin  wrote:

>
>
> On Mon, Jan 6, 2020 at 6:40 AM Siyuan Miao  wrote:
>
>> NANOG,
>>
>> We've recently signed contract of colocation + IP transit with a local
>> provider in Northern Virginia.
>>
>> Co-location services is okay but we found something unusual on our IP
>> transit invoices.
>>
>> - Va Personal Property Tax Recovery (1.8%)
>>
>> - Cost Recovery Surcharge (3%)?
>>
>> We've talked with our providers but they told us:
>>
>> > we use a tax engine that provides the taxes/rates to our services. If
>> you would like further language on them, please let me know and I will have
>> some one send that over.
>>
>> Has anyone else ran into this? If this is a legit "surcharge"?
>> Also, IP transit isn't a property, why is there a "Property Tax" for IP
>> transit?
>>
>
> Hi Siyuan,
>
> If it's not written in to your contract, it's a breach of contract. Either
> way it's a deceitfully imposed surcharge, not a state tax. Virginia does
> not tax the sale of services like transit and colo. More, the only personal
> property tax I've heard of in Virginia is on motor vehicles.
>
> Regards,
> Bill Herrin
>
> --
> William Herrin
> b...@herrin.us
> <https://bill.herrin.us/>
> https://bill.herrin.us/
>

Cost Recovery Surcharge & Va Personal Property Tax Recovery for IP Transit

[Siyuan Miao]

NANOG,

We've recently signed contract of colocation + IP transit with a local
provider in Northern Virginia.

Co-location services is okay but we found something unusual on our IP
transit invoices.

- Va Personal Property Tax Recovery (1.8%)

- Cost Recovery Surcharge (3%)?

We've talked with our providers but they told us:

> we use a tax engine that provides the taxes/rates to our services. If you
would like further language on them, please let me know and I will have
some one send that over.

Has anyone else ran into this? If this is a legit "surcharge"?
Also, IP transit isn't a property, why is there a "Property Tax" for IP
transit?

Regards,
Siyuan Miao

Re: Arista Switch Suggestion

[Siyuan Miao]

Yes that's required.

On Sat, Dec 7, 2019 at 7:05 AM Mike Hammett  wrote:

> Am I reading correctly in that there has to be a layer 3 configuration on
> the VLAN for that to function?
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions <http://www.ics-il.com/>
> <https://www.facebook.com/ICSIL>
> <https://plus.google.com/+IntelligentComputingSolutionsDeKalb>
> <https://www.linkedin.com/company/intelligent-computing-solutions>
> <https://twitter.com/ICSIL>
> Midwest Internet Exchange <http://www.midwest-ix.com/>
> <https://www.facebook.com/mdwestix>
> <https://www.linkedin.com/company/midwest-internet-exchange>
> <https://twitter.com/mdwestix>
> The Brothers WISP <http://www.thebrotherswisp.com/>
> <https://www.facebook.com/thebrotherswisp>
> <https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg>
> --
> *From: *"Siyuan Miao" 
> *To: *"Mike Hammett" 
> *Cc: *"Steve Meuse" , "nanog" 
> *Sent: *Friday, December 6, 2019 4:49:45 PM
> *Subject: *Re: Arista Switch Suggestion
>
> I can confirm 7050X series do support this feature.We're using 7050SX and
> 7050S, 7050S isn't supported
>
>
> https://www.arista.com/en/um-eos/eos-section-11-6-ethernet-configuration-commands#ww1310058
>
>
>
>
>
> On Sat, Dec 7, 2019 at 6:42 AM Mike Hammett  wrote:
>
>> I have not found x-flow to have the accuracy I would like. Either there's
>> a loss of information due to sampling and such low-usage interfaces (or
>> VLANs in this case) are lost in the noise or there's information overload
>> due to no sampling at all.
>>
>>
>> I have seen very few platforms expose counter information about VLANs in
>> the same way they do regular interfaces. Some Juniper platforms, Mikrotik,
>> and I hear some Aristas as well.
>>
>>
>>
>> -
>> Mike Hammett
>> Intelligent Computing Solutions <http://www.ics-il.com/>
>> <https://www.facebook.com/ICSIL>
>> <https://plus.google.com/+IntelligentComputingSolutionsDeKalb>
>> <https://www.linkedin.com/company/intelligent-computing-solutions>
>> <https://twitter.com/ICSIL>
>> Midwest Internet Exchange <http://www.midwest-ix.com/>
>> <https://www.facebook.com/mdwestix>
>> <https://www.linkedin.com/company/midwest-internet-exchange>
>> <https://twitter.com/mdwestix>
>> The Brothers WISP <http://www.thebrotherswisp.com/>
>> <https://www.facebook.com/thebrotherswisp>
>> <https://www.youtube.com/channel/UCXSdfxQv7SpoRQYNyLwntZg>
>> --
>> *From: *"Steve Meuse" 
>> *To: *"Mike Hammett" 
>> *Cc: *"nanog" 
>> *Sent: *Friday, December 6, 2019 4:20:08 PM
>> *Subject: *Re: Arista Switch Suggestion
>>
>>
>> You should be able to do that with Sflow, which they all/most support.
>>
>> Also, this seems like standard Ifmib stuff, any snmp poller should be
>> able to handle that, from a metrics perspective .
>>
>> -Steve
>>
>>
>> On Fri, Dec 6, 2019 at 4:31 PM Mike Hammett  wrote:
>>
>>> I asked over at https://puck.nether.net/mailman/listinfo/arista-nsp a
>>> couple weeks ago, but didn't get an answer, so I have moved to a larger
>>> group.
>>>
>>> I understand that some Arista switches will expose each VLAN in SNMP so
>>> I can monitor traffic on a VLAN independently of over VLANs on that same
>>> physical interface. Some of them don't.
>>>
>>> Which ones do?
>>>
>>> I prefer a solid used switch.
>>>
>>>
>>> 10G ports are fine.
>>>
>>>
>>>
>>>
>>> -
>>> Mike Hammett
>>> Intelligent Computing Solutions
>>> http://www.ics-il.com
>>>
>>> Midwest-IX
>>> http://www.midwest-ix.com
>>>
>>
>>
>

Re: Arista Switch Suggestion

[Siyuan Miao]

I can confirm 7050X series do support this feature.We're using 7050SX and
7050S, 7050S isn't supported

https://www.arista.com/en/um-eos/eos-section-11-6-ethernet-configuration-commands#ww1310058





On Sat, Dec 7, 2019 at 6:42 AM Mike Hammett  wrote:

> I have not found x-flow to have the accuracy I would like. Either there's
> a loss of information due to sampling and such low-usage interfaces (or
> VLANs in this case) are lost in the noise or there's information overload
> due to no sampling at all.
>
>
> I have seen very few platforms expose counter information about VLANs in
> the same way they do regular interfaces. Some Juniper platforms, Mikrotik,
> and I hear some Aristas as well.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions 
> 
> 
> 
> 
> Midwest Internet Exchange 
> 
> 
> 
> The Brothers WISP 
> 
> 
> --
> *From: *"Steve Meuse" 
> *To: *"Mike Hammett" 
> *Cc: *"nanog" 
> *Sent: *Friday, December 6, 2019 4:20:08 PM
> *Subject: *Re: Arista Switch Suggestion
>
>
> You should be able to do that with Sflow, which they all/most support.
>
> Also, this seems like standard Ifmib stuff, any snmp poller should be able
> to handle that, from a metrics perspective .
>
> -Steve
>
>
> On Fri, Dec 6, 2019 at 4:31 PM Mike Hammett  wrote:
>
>> I asked over at https://puck.nether.net/mailman/listinfo/arista-nsp a
>> couple weeks ago, but didn't get an answer, so I have moved to a larger
>> group.
>>
>> I understand that some Arista switches will expose each VLAN in SNMP so I
>> can monitor traffic on a VLAN independently of over VLANs on that same
>> physical interface. Some of them don't.
>>
>> Which ones do?
>>
>> I prefer a solid used switch.
>>
>>
>> 10G ports are fine.
>>
>>
>>
>>
>> -
>> Mike Hammett
>> Intelligent Computing Solutions
>> http://www.ics-il.com
>>
>> Midwest-IX
>> http://www.midwest-ix.com
>>
>
>

Re: 44/8

[Siyuan Miao]

Did a fast lookup via ARIN WHOIS:

44/8 is now 44/9 + 44.128/10

NetRange:   44.0.0.0 - 44.191.255.255
CIDR:   44.0.0.0/9, 44.128.0.0/10
NetName:AMPRNET
NetHandle:  NET-44-0-0-0-1
Parent: NET44 (NET-44-0-0-0-0)
NetType:Direct Assignment
OriginAS:
Organization:   Amateur Radio Digital Communications (ARDC)
RegDate:1992-07-01
Updated:2019-07-18
Ref:https://rdap.arin.net/registry/ip/44.0.0.0



On Fri, Jul 19, 2019 at 11:04 AM Christopher Morrow 
wrote:

> On Thu, Jul 18, 2019 at 10:59 PM Majdi S. Abbas  wrote:
> >
> >
> > What's interesting about this is it was not an ARIN allocation,
>
> So.. this is/was a legacy allocation, right?  with some 'not great'
> contact/etc info...
> the ARIN folk could have said: "Well sure! if the current folk who
> control access can positively show they do AND they don't mind parting
> with a /10... ok?"
>
> This ends up with a /10 of a /8 with better registration information
> and MAYBE better records keeping over time, right?
> that seems like a win to the ARIN community?
>

Re: Intermittent "bad gateway"

[Siyuan Miao]

Hah do you mean CloudFlare 502?

On Tue, Jul 2, 2019 at 10:23 PM Ross Tajvar  wrote:

> Gotta be more specific than that...
>
> What carrier(s) are you using? If you do a traceroute do your packets take
> a weird path? Etc.
>
> On Tue, Jul 2, 2019, 10:19 AM Stephen Satchell  wrote:
>
>> Are we having another BGP problem this morning?
>>
>

Facebook outage

[Siyuan Miao]

Dear community,

It seems that Facebook network is partially down.

Here's a traceroute from some locations to fbcdn Hong Kong (157.240.15.37):

 Host
 Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. ???
 2. fra-in8-01sw.voxility.net
  0.6%   1810.5   0.6   0.4   4.9   0.5
 3. fra-in8-01c.voxility.net
 0.0%   181   14.7   3.7   0.3  44.1   8.5
 4. fra-in3-02gw.voxility.net
  0.0%   1810.9   3.5   0.7 195.2  14.5
 5. fra-eq5-02gw.voxility.net
  0.0%   1810.6   0.5   0.3   0.7   0.0
 6. fra-eq5-03gw.voxility.net
  0.0%   1810.6   0.7   0.4   6.6   0.7
 7. ae10.pr02.fra5.tfbnw.net
 0.0%   1811.2   3.5   0.8  35.0   5.2
 8. ???
 9. ae121.ar03.fra2.tfbnw.net
  0.0%   1814.4   2.1   1.0  21.1   2.2
10. ae32.bb02.fra2.tfbnw.net
 0.0%   1815.1   4.6   1.4  14.0   2.7
11. ae15.bb03.odn2.tfbnw.net
 0.0%   181   19.2  19.8  18.5  26.3   1.2
12. ae12.dr03.odn2.tfbnw.net
92.8%   181   27.8  24.4  18.3  43.4   8.4
13. ???

 Host
 Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. lax-cs1-02sw.voxility.net
  0.0%   1940.3   2.5   0.2  36.9   5.1
 2. lax-cs1-01c.voxility.net
 0.0%   1946.1   2.8   0.2  47.3   6.4
 3. lax-cs1-02gw.voxility.net
  0.0%   1940.2   0.1   0.1   0.3   0.0
 4. ce-0-13-0-1.r00.lsanca07.us.bb.gin.ntt.net
 0.0%   1940.9   0.5   0.4   1.0   0.0
 5. ae-3.r01.lsanca07.us.bb.gin.ntt.net
  0.0%   1940.5   0.5   0.4   0.9   0.0
 6. ae-0.tata-communications.lsanca07.us.bb.gin.ntt.net
  0.0%   1940.7   1.0   0.4  28.8   2.8
 7. if-et-20-2.hcore2.kv8-chiba.as6453.net
 0.0%   194  158.6 158.8 158.4 175.5   1.8
 8. if-et-1-2.hcore1.kv8-chiba.as6453.net
  0.0%   194  152.7 152.8 152.5 155.8   0.2
 9. if-ae-16-2.tcore1.hk2-hong-kong.as6453.net
 0.0%   194  162.1 163.0 162.0 213.5   4.9
10. ???

What do you think ?

Re: Amazon AS16509 peering... how long to wait?

[Siyuan Miao]

Same here.

We've received configuration details in Mar 12 and we've completed the
configuration on the same day.

Then we didn't hear any news from them.

On Mon, Apr 8, 2019 at 6:37 AM Ross Tajvar  wrote:

> From what I've heard, their peering department is really behind on
> processing new peer turn-ups.
>
> On Sun, Apr 7, 2019, 6:16 PM Mehmet Akcin  wrote:
>
>> I will connect you to right people offlist
>>
>> I am surprised its taking that long
>>
>> On Sun, Apr 7, 2019 at 16:41 John Von Essen  wrote:
>>
>>> I applied for peering, received an email, setup the BGP session, waited
>>> about a month. Then 3 weeks ago my BGP session with Amazom came up, but
>>> with zero routes. I assume I am in some kind of test/waiting period, but
>>> after three weeks, I thought I would be getting routes by now. Emails to
>>> the peeringdb POC have not returned anything. Anyone here from AS16509,
>>> can this be bumped? We are AS17185, and peering is on DE-CIX NYC.
>>>
>>>
>>> Thanks
>>>
>>> John
>>>
>>> --
>> Mehmet
>> +1-424-298-1903
>>
>

Banned by Akamai (or some websites hosted with Akamai)

[Siyuan Miao]

Hi,

I got some complaints from customers and found out that all IP addresses
announced in one of our ASN are banned by Akamai or some websites hosted
with Akamai.

I've tried to contact one of the website owners but didn't get any response.

Could someone from Akamai contact me off-list?

Regards,
Siyuan Miao

Re: softlayer.com

[Siyuan Miao]

Perhaps it won't work because their customer support will ask you for
bi-directional traceroute and refused to forward to backbone team.

Then they'll say it's not their fault and you can see the packet is dropped
outside our network.

Here's a sample traceroute from SoftLayer Washington, San Jose and Seattle
in case someone needs it:

aveline@iad02-sl01:~$ mtr 138.43.128.1 --report-wide
Start: Fri Mar 22 17:20:42 2019
HOST: iad02-sl01Loss%   Snt   Last   Avg
Best  Wrst StDev
  1.|-- [REDACTED] 0.0%101.4   1.5
 0.8   3.7   1.0
  2.|-- ae13.dar02.wdc01.networklayer.com  0.0%100.5   3.3
 0.4  28.6   8.8
  3.|-- ae9.bbr01.eq01.wdc02.networklayer.com  0.0%100.8   0.8
 0.7   1.0   0.0
  4.|-- eqix-dc5.intellifiber.com  0.0%100.8   1.2
 0.8   2.2   0.3
  5.|-- ae13-0.cr02.asbn01-va.us.windstream.net0.0%100.9   0.9
 0.9   1.0   0.0
  6.|-- ae11-0.cr01.atln02-ga.us.windstream.net0.0%10   15.6  16.1
15.6  17.4   0.5
  7.|-- ae0-0.pe06.atln02-ga.us.windstream.net 0.0%10   17.4  16.1
15.9  17.4   0.3
  8.|-- h43.88.198.64.static.ip.windstream.net 0.0%10   24.7  24.8
24.6  24.9   0.0
  9.|-- east.tndodge-21.static.tncsvl.blomand.net  0.0%10   22.6  22.8
22.5  23.8   0.0
 10.|-- ???   100.0100.0   0.0
 0.0   0.0   0.0

aveline@sjc03-sl01:~$ mtr 138.43.128.1 --report-wide
Start: Fri Mar 22 16:21:04 2019
HOST: sjc03-sl01Loss%   Snt   Last   Avg
Best  Wrst StDev
  1.|-- [REDACTED] 0.0%102.4   2.0
 0.3  14.3   4.3
  2.|-- ae0.dar02.sjc01.networklayer.com   0.0%101.0   0.5
 0.3   1.3   0.0
  3.|-- ae9.bbr01.eq01.sjc02.networklayer.com  0.0%100.8   0.8
 0.7   0.9   0.0
  4.|-- eqix-sv1.windstream.com0.0%100.9   0.9
 0.8   1.1   0.0
  5.|-- ae6-0.cr02.lsaj01-ca.us.windstream.net 0.0%10   11.6  11.5
11.5  11.6   0.0
  6.|-- ae-11-0.cr01.dlls01-tx.us.windstream.net   0.0%10   42.6  42.7
42.5  43.4   0.0
  7.|-- ae7-0.cr02.atln02-ga.us.windstream.net 0.0%10   64.0  65.6
63.9  74.2   3.4
  8.|-- ae1-0.pe06.atln02-ga.us.windstream.net 0.0%10   62.3  62.7
62.2  66.9   1.5
  9.|-- h43.88.198.64.static.ip.windstream.net 0.0%10   71.9  72.0
71.9  72.2   0.0
 10.|-- east.tndodge-21.static.tncsvl.blomand.net  0.0%10   69.9  68.8
68.6  69.9   0.3
 11.|-- ???   100.0100.0   0.0
 0.0   0.0   0.0

aveline@sea04-sl01:~$ mtr 138.43.128.1 --report-wide
Start: Fri Mar 22 08:19:09 2019
HOST: sea04-sl01Loss%   Snt   Last   Avg
Best  Wrst StDev
  1.|-- [REDACTED] 0.0%100.7   1.2
 0.7   1.8   0.0
  2.|-- ae12.dar02.sr01.sea01.networklayer.com 0.0%100.6   0.7
 0.5   1.3   0.0
  3.|-- ae9.bbr01.wb01.sea02.networklayer.com  0.0%101.2   1.0
 0.7   1.5   0.0
  4.|-- six.seattle-wa.us.windstream.net   0.0%101.5   1.0
 0.7   1.7   0.0
  5.|-- ae12-0.cr01.chcg01-il.us.windstream.net0.0%10   41.1  41.2
41.0  41.6   0.0
  6.|-- ae17-0.cr02.chcg01-il.us.windstream.net0.0%10   41.1  41.4
41.1  42.0   0.0
  7.|-- ae10-0.cr01.atln02-ga.us.windstream.net0.0%10   63.8  64.4
63.5  71.1   2.3
  8.|-- ae0-0.pe06.atln02-ga.us.windstream.net 0.0%10   63.7  63.7
63.5  64.0   0.0
  9.|-- h43.88.198.64.static.ip.windstream.net 0.0%10   71.6  71.8
71.5  72.8   0.0
 10.|-- east.tndodge-21.static.tncsvl.blomand.net  0.0%10   71.8  70.8
70.2  71.8   0.3
 11.|-- ???   100.0100.0   0.0
 0.0   0.0   0.0


Regards,
Siyuan Miao


On Fri, Mar 22, 2019 at 10:10 PM Nikolas Geyer  wrote:

> This is the best approach. Have run into this problem a few times and had
> zero success getting the filters removed without having SL customers log
> tickets with support. Verbiage needs to be “this prefix is blocked, please
> escalate to your backbone team”.
>
> Sent from my iPhone
>
> On Mar 22, 2019, at 9:56 AM, Forrest Christian (List Account) <
> li...@packetflux.com> wrote:
>
> Another idea...
>
> Have you tried reaching out to some of the blocked sites?  They likely
> have better contact information than is available publicly, especially a
> larger one like indeed.
>
> On Thu, Mar 21, 2019, 3:41 PM John Alcock  wrote:
>
>> Still looking for anyone from softlayer.com
>>
>> It has been a challenge.  Anything hosted by softlayer.com is being
>> blocked.
>>
>> Here is a small list so far
>>
>> windowbook.tpondemand.com
>> ahainstructornetwork.americanheart.org
>> clover.com
>> Cebroker.com
>> Softlayer.com
>> indeed.com & En

Re: Help on setting up a new block

[Siyuan Miao]

They block IP address from Iran, Cuba, North Korea, and Syria.

You can check
https://cloud.ibm.com/docs/overview/terms-of-use?topic=overview-terms#notices
for more details.

On Wed, Mar 20, 2019 at 11:37 PM Bryan Holloway  wrote:

>
> On 3/20/19 10:28 AM, John Alcock wrote:
> > I found an interesting pattern.  I see a lot of traffic stopping at
> > softlayer.com .  Big datacenter?  Could they be
> > doing some blocking?
> >
> > John
> >
>
> Could be. They were acquired by IBM a few years ago.
>

Re: well-known Anycast prefixes

[Siyuan Miao]

A Well-known BGP community will be better.

You'll need to rewrite next hop or do something similar if AnyCast prefixes
are learnt from a multi hop BGP feed, and it made the configuration more
complicated and difficult to debug.

On Wed, Mar 20, 2019, 01:48 Fredy Kuenzler  wrote:

> Am 19.03.19 um 18:39 schrieb Bill Woodcock:
> >> On Mar 19, 2019, at 10:12 AM, Fredy Kuenzler 
> >> wrote: I wonder whether anyone has ever compiled a list of
> >> well-known Anycast prefixes.
> >
> > I don’t know of one.
> >
> > It seems like a good idea.
> >
> > BGP-multi-hop might be a reasonable way to collect them.
> >
> > If others agree that it’s a good idea, and it’s not stepping on
> > anyone’s toes, PCH would be happy to host/coordinate.
>
> Thanks for the effort, much appreciated.
>
> Am 19.03.19 um 18:40 schrieb Joe Provo:
> > I think one would want that internal and no rely upon someone else
> > maintaining it.  You might check if Oracle followed up on the
> > Renesys/Dyn work documented:
> > https://dyn.com/wp-content/uploads/2014/07/NANOG59_Anycast.pdf
> >
> > ...where there were ~600 anycast v4 prefixes at the time.
>
> That's a lot %-]
>
> Maybe a well-known community (similar to RFC7999) could be defined and
> every Anycast operator could tag his prefixes? That's likely a better
> idea than manually maintain some list somewhere.
>
> --
> Fredy Kuenzler
>
> Init7 (Switzerland) Ltd.
> AS13030
> Technoparkstrasse 5
> CH-8406 Winterthur
> Skype:   flyingpotato
> Phone:   +41 44 315 4400
> Fax: +41 44 315 4401
> Twitter: @init7 / @kuenzler
> http://www.init7.net/
>
>

Looking for a AS15169 Google contact to update their PeeringDB records

[Siyuan Miao]

Hi,

We're noticed that PeeringDB records of AS15169 in IX.br (PTT.br) São Paulo
is outdated.

I've tried to contact AS15169 to update it via IX Session Turnup ticket and
n...@google.com but didn't get a reasonable response.

That's what I got from n...@google.com:

> Dear Team,
> Thank you for contacting the Google NOC, as 15169.
>
> With the details provided we were unable to identify the relevant link.
>
> Please provide following items to identify which session is impacted:
>
>  * Peering City
>  * BGP peering ASNs, including your own AS
>  * BGP peer IP addresses
>
> Thanks & Regards,
> [redacted]
>
> Google Network Operation Center (GNOC) |n...@google.com |
> [redacted]

Can someone contact me off list about this issue?

Regards,
Siyuan Miao

Re: Issue with Geolocation in Virginia US

[Siyuan Miao]

Hi Raja,

If you have peering with them (AS15169), you can submit Geolocation data
via ISP Portal (https://isp.google.com/).

Regards,
Siyuan

On Sat, Mar 9, 2019 at 3:03 PM Raja Sekhar Gullapalli <
ra...@qti.qualcomm.com> wrote:

> Hi Anthony,
>
>
>
> First one already tried & but no response.
>
>
>
> Who will help in getting geo updated which shows 3 results as per your
> email.
>
>
>
> Regards,
>
> Raja
>
>
>
> go/snitnet or go/itnet to request Network Services.
>
>
>
> *From:* Delacruz, Anthony B 
> *Sent:* Saturday, March 9, 2019 1:28 AM
> *To:* Raja Sekhar Gullapalli ; nanog@nanog.org
> *Subject:* [EXT] RE: Issue with Geolocation in Virginia US
>
>
>
> This sometimes helps
>
>
>
> https://support.google.com/websearch/contact/ip
>
>
>
> you should probably also seek out getting geo updated on at least 3
> different ones you have 3 different results.
>
>
>
> 129.46.232.65
>
> ip2location Raleigh NC
>
> neustarbutler TN
>
> maxmind Bridgewater NJ
>
>
>
> *From:* NANOG [mailto:nanog-boun...@nanog.org ] *On
> Behalf Of *Raja Sekhar Gullapalli
> *Sent:* Wednesday, February 27, 2019 11:32 PM
> *To:* nanog@nanog.org
> *Subject:* Issue with Geolocation in Virginia US
>
>
>
> Team,
>
>
>
> We are having issues in our Virginia US office & it shows geolocation in
> all browsers as Canada instead of US region when we access news.google.com
> in our PC.
>
>
>
> Our public ip is 129.46.232.65. This issue is being observed for more than
> 2 month.
>
>
>
> Can you help to whom we can contact to resolve the issue.
>
>
>
>
>
> Regards,
>
> Raja
>
>
>
>
>
> This communication is the property of CenturyLink and may contain
> confidential or privileged information. Unauthorized use of this
> communication is strictly prohibited and may be unlawful. If you have
> received this communication in error, please immediately notify the sender
> by reply e-mail and destroy all copies of the communication and any
> attachments.
>

Re: Announcing Peering-LAN prefixes to customers

[Siyuan Miao]

(Perhaps off-topic)

KINX are using 192.145.251.0/24 as their Peering IPv4 space.

However, I couldn't find any valid SWIP or IRR record created by IP
owner Hiawatha Broadband Communications, Inc.

Some ISP like Hurricane Electric will route this prefix to KINX but I'm not
sure if it's authorized by IP owner.

Regards,
Siyuan


On Wed, Jan 16, 2019 at 5:44 PM Job Snijders  wrote:

> On Wed, Jan 16, 2019 at 12:39 Christoffer Hansen 
> wrote:
>
>>
>> On 16/01/2019 08:56, Mark Tinka wrote:
>> > Running a few exchange points in Africa since 2002, the news was that
>> > the exchange point LAN should not be visible anywhere on the Internet.
>>
>> Do you use AS0 as origin on the RPKI objects for said exchange point
>> LAN(s) to prevent route propagation?
>
>
>
> Either AS 0, or the ASN of the IXP’s service network are valid options.
> Whatever ASN is listed in the RPKI ROA, should simply never announce the
> prefix.
>
> IXPs should make sure to not set MaxLength to allow anything more-l
> specific, it should be equal to the prefix length.
>
> Kind regards,
>
> Job
>

routeviews.org pending delete

[Siyuan Miao]

All,

routeviews.org is pending delete now.

Domain Name: ROUTEVIEWS.ORG
Registry Domain ID: D48496876-LROR
Registrar WHOIS Server: whois.networksolutions.com
Registrar URL: http://www.networksolutions.com
Updated Date: 2018-12-17T09:33:18Z
Creation Date: 2000-12-14T23:05:47Z
Registry Expiry Date: 2019-12-14T23:05:47Z
Registrar Registration Expiration Date:
Registrar: Network Solutions, LLC
Registrar IANA ID: 2
Registrar Abuse Contact Email: ab...@web.com
Registrar Abuse Contact Phone: +1.8003337680
Reseller:
Domain Status: clientTransferProhibited
https://icann.org/epp#clientTransferProhibited
Domain Status: autoRenewPeriod https://icann.org/epp#autoRenewPeriod
Registrant Organization: Network Solutions LLC
Registrant State/Province: FL
Registrant Country: US
Name Server: NS1.PENDINGRENEWALDELETION.COM
Name Server: NS2.PENDINGRENEWALDELETION.COM
DNSSEC: unsigned
URL of the ICANN Whois Inaccuracy Complaint Form https://www.icann.org/wicf/
)
>>> Last update of WHOIS database: 2018-12-17T12:28:37Z <<<


routeviews.org. 86400 IN NS ns2.pendingrenewaldeletion.com.
routeviews.org. 86400 IN NS ns1.pendingrenewaldeletion.com.

I was wondering if there is anyone here can contact them to renew it if
this project is still alive.

Regards,
Siyuan

Re: Dedicated Server and IP anycast provider recommendation

[Siyuan Miao]

I would recommend Vultr, you can bring your own IP address and set up BGP
session using VM.

Their BGP service are fully automated and provide well-documented BGP
community for traffic engineering.

--
Siyuan Miao
Misaka Network, Inc | https://misaka.io

On Tue, Aug 7, 2018 at 10:06 PM Anthony Leto  wrote:

> Hi,
>
> I would checkout NetActuate. They are pretty awesome when it comes to
> Anycast IPv4 /IPv6 and they do custom VM's.
>
> Anthony Leto
>
> On 8/7/2018 2:51:59 PM, John Kristoff  wrote:
>
> Friends,
>
> For those that may have used or know of a service like this. I know
> some exist, but it doesn't seem to be that popular or widely advertised
> as a standard service.
>
> I'm interested in pointers to a hosting/network provider that leases
> dedicated servers and can provide an anycast IP address assignment to
> two or more US-diversely connected POPs, but with reasonably consistent
> routing (e.g. peering, transit). A customer-shared prefix is OK. I'm
> interested in pointers to networks that would provide the prefix and
> handle all the routing.
>
> If you represent a network and sales is part of your job, I don't mind
> an off list pointer to a web page describing such a service, but please,
> this is not an invitation for "call me to discuss needs and options"
> replies nor an opportunity to get me on your customer prospect list.
> You likely ensure I never do business with you if you do either of
> those things. :-)
>
> Thank you,
>
> John
>

Looking for Facebook NOC

[Siyuan Miao]

Hi,

Our network in Asia Pacific region was always allocated to Ashburn / Lonodn
CDN.

I'll be very grateful if there's someone from Facebook NOC could give us a
hand to troubleshoot this off list.

Best Regards,
Siyuan Miao

Bogon prefix c0f:f618::/32 announced via Cogent

[Siyuan Miao]

Hi,

c0f:f618::/32 originated from AS327814 is announcing via Cogent for several
weeks.

I've tried to contact Cogent and AS327814 but didn't receive any reply.

Tue Jul 10 17:52:48.602 UTC
BGP routing table entry for c0f:f618::/32
Versions:
  Process   bRIB/RIB  SendTblVer
  Speaker   7640326976403269
Local Label: 61339
Last Modified: Jul  3 13:31:40.815 for 1w0d
Paths: (1 available, best #1)
  Advertised to peers (in unique update groups):
38.5.0.99
  Path #1: Received by speaker 0
  Advertised to peers (in unique update groups):
38.5.0.99
  327814
2001:550:0:1000::261c:166 (metric 119060) from
2001:550:0:1000::261c:153 (38.28.1.102)
  Origin incomplete, localpref 130, valid, internal, best, group-best
  Received Path ID 0, Local Path ID 0, version 76403269
  Community: 174:11100 174:20999 174:21101 174:22012
  Originator: 38.28.1.102, Cluster list: 38.28.1.83, 38.28.1.67, 38.28.1.92