Zayo Contact

2021-07-15 Thread Dave Browning
Anyone on the list from Zayo NOC who can assist with removing a couple of
/24's from their table that isn't actually being advertised to them?

Dave Browning | dlbNetworks
0413 579 391 | 07 3088 2274


Re: T-Mobile RF contact

2021-07-15 Thread Tom Beecher
It's more likely to be someone in the area. Friend of mine who runs a small
WISP has had similar problems with other companies who haven't been able to
upgrade equipment to Part 96 capable, yet still operate and walk all over
everyone else in the area.

The only somewhat sketchy licensing up your way is that Horry County
Telephone in South Carolina won some 105 licenses up there, and just
transferred them to South Park Telephone. Maybe a good reason, smells like
profiteering to me.:)

On Wed, Jul 14, 2021 at 2:43 PM Sean Heskett  wrote:

> I realize this isn’t an RF list but was hoping someone on here could point
> me in the right direction.
>
> Does anyone know how to get in touch with a T-Mobile RF engineer?
>
> Our CBRS network has been receiving heavy interference from what we
> believe is a new T-Mobile site at an American tower facility.
>
> The equipment isn’t registered with the SAS and appears to be operating in
> the part 90 portion of the band 3650-3700mhz as a part 90 device and not a
> part 96 CBRS device.
>
> American tower has been no help other than opening a ticket.
>
> Federated is our SAS vendor and they haven’t been any help either other
> than telling us it’s not in the SAS.
>
> I’ve also done an application search in the FCC auction 105 (CRBS) site,
> but T-mobile must have been bidding under a different name.
>
> Any help is much appreciated,
>
> -Sean Heskett
> 970-846-8065
> --
> Sean Heskett
>
> ZIRKEL
> Internet • WiFi • Phone • TV
> 970-871-8500 x100 - Office
>


Re: T-Mobile RF contact

2021-07-15 Thread Eric Kuhnke
Have you tried the contact information on some of their FCC Part 101 (PTP
microwave) licenses? All public data in the ULS, you can even download the
whole thing (12-14GB pipe delimited CSV file, last I checked).



On Wed, Jul 14, 2021 at 2:43 PM Sean Heskett  wrote:

> I realize this isn’t an RF list but was hoping someone on here could point
> me in the right direction.
>
> Does anyone know how to get in touch with a T-Mobile RF engineer?
>
> Our CBRS network has been receiving heavy interference from what we
> believe is a new T-Mobile site at an American tower facility.
>
> The equipment isn’t registered with the SAS and appears to be operating in
> the part 90 portion of the band 3650-3700mhz as a part 90 device and not a
> part 96 CBRS device.
>
> American tower has been no help other than opening a ticket.
>
> Federated is our SAS vendor and they haven’t been any help either other
> than telling us it’s not in the SAS.
>
> I’ve also done an application search in the FCC auction 105 (CRBS) site,
> but T-mobile must have been bidding under a different name.
>
> Any help is much appreciated,
>
> -Sean Heskett
> 970-846-8065
> --
> Sean Heskett
>
> ZIRKEL
> Internet • WiFi • Phone • TV
> 970-871-8500 x100 - Office
>


Re: Scanning activity from 2620:96:a000::/48

2021-07-15 Thread Nick Suan
I've noticed something similar on two networks, however it appears to be trying 
to scan port 80:

13:30:26.387183 IP6 2620:96:a000::5. > 2620:135:5005:71::b0c.80: Flags [S], 
seq 2063829402, win 65535, length 0
13:30:26.393445 IP6 2620:96:a000::5. > 2620:135:5006:7::703.80: Flags [S], 
seq 2158423190, win 65535, length 0
13:30:26.430259 IP6 2620:96:a000::5. > 2620:135:500e:3d::804.80: Flags [S], 
seq 3284825109, win 65535, length 0
13:30:26.432115 IP6 2620:96:a000::5. > 2620:135:5007:2d7::a.80: Flags [S], 
seq 109350720, win 65535, length 0
13:30:26.460045 IP6 2620:96:a000::5. > 2620:135:5009:998::a.80: Flags [S], 
seq 3938745191, win 65535, length 0
13:30:26.515579 IP6 2620:96:a000::5. > 2620:135:500b:c92::6.80: Flags [S], 
seq 430848867, win 65535, length 0
13:30:26.516136 IP6 2620:96:a000::5. > 2620:135:5006:14::b0c.80: Flags [S], 
seq 515087951, win 65535, length 0
13:30:26.542392 IP6 2620:96:a000::5. > 2620:135:500a:67::30a.80: Flags [S], 
seq 2626838356, win 65535, length 0
13:30:26.547341 IP6 2620:96:a000::5. > 2620:135:500f:b30::f.80: Flags [S], 
seq 939521116, win 65535, length 0
13:30:26.549701 IP6 2620:96:a000::5. > 2620:135:500c:b::95.80: Flags [S], 
seq 1015131109, win 65535, length 0
13:30:26.557200 IP6 2620:96:a000::5. > 2620:135:5009:50::f5.80: Flags [S], 
seq 217447395, win 65535, length 0
 

On Tue, Jul 6, 2021, at 4:53 AM, Tore Anderson wrote:
> A couple of hours after midnight UTC, the control plane policers for
> unresolved traffic on a couple of our CE routers started being clogged with
> ping-scanning activity from 2620:96:a000::/48, which belongs to «Internet
> Measurement Research (SIXMA)» according to ARIN.
> 
> Excerpt of this traffic (anonymised on our end):
> 
> 11:21:05.016914 IP6 2620:96:a000::10 > 2001:db8:1234::f5:7a69: ICMP6, 
> echo request, seq 0, length 16
> 11:21:05.016929 IP6 2620:96:a000::10 > 2001:db8:1234::12:ba74: ICMP6, 
> echo request, seq 0, length 16
> 11:21:05.060045 IP6 2001:db8:1234::3 > 2620:96:a000::10: ICMP6, 
> destination unreachable, unreachable address 2001:db8:1234::e7:f473, 
> length 64
> 11:21:05.060060 IP6 2001:db8:1234::3 > 2620:96:a000::7: ICMP6, 
> destination unreachable, unreachable address 2001:db8:1234::d4:c4a3, 
> length 64
> 11:21:05.060419 IP6 2001:db8:1234::3 > 2620:96:a000::7: ICMP6, 
> destination unreachable, unreachable address 2001:db8:1234::42:198a, 
> length 64
> 11:21:05.064464 IP6 2620:96:a000::10 > 2001:db8:1234::4a:d4cd: ICMP6, 
> echo request, seq 0, length 16
> 11:21:05.079645 IP6 2620:96:a000::10 > 2001:db8:1234::63:b58d: ICMP6, 
> echo request, seq 0, length 16
> 11:21:05.097337 IP6 2620:96:a000::10 > 2001:db8:1234::24:1038: ICMP6, 
> echo request, seq 0, length 16
> 11:21:05.111091 IP6 2620:96:a000::7 > 2001:db8:1234::8f:a126: ICMP6, 
> echo request, seq 0, length 16
> 11:21:05.124112 IP6 2001:db8:1234::3 > 2620:96:a000::7: ICMP6, 
> destination unreachable, unreachable address 2001:db8:1234::e6:70fc, 
> length 64
> 11:21:05.124417 IP6 2001:db8:1234::3 > 2620:96:a000::10: ICMP6, 
> destination unreachable, unreachable address 2001:db8:1234::bf:ca18, 
> length 64
> 11:21:05.137509 IP6 2620:96:a000::10 > 2001:db8:1234::12:f0df: ICMP6, 
> echo request, seq 0, length 16
> 11:21:05.142614 IP6 2620:96:a000::7 > 2001:db8:1234::8f:9ec6: ICMP6, 
> echo request, seq 0, length 16
> 
> While the CP policer did its job and prevented any significant operational
> impact, the traffic did possibly prevent/delay legitimate address resolution
> attempts as well as trigger loads of pointless address resolution attempts
> (ICMPv6 Neighbour Solicitations) towards the customer LAN.
> 
> We just blocked the prefix at our AS border to get rid of that noise. Those
> ACLs are currently dropping packets at a rate of around 600 pps.
> 
> I was just curious to hear if anyone else is seeing the same thing, and also
> whether or not people feel that this is an okay thing for this «Internet
> Measurement Research (SIXMA)» to do (assuming they are white-hats)?
> 
> Tore
> 
> 
> 
> 


Hotstar IP Notoriety

2021-07-15 Thread Eric C. Miller
Is there anyone here with a relationship with the Hotstar streaming service? We 
recently launched a new IP block and it's being blocked by them.

Eric


Re: EVPN P2MP Implementation

2021-07-15 Thread Pascal Thubert (pthubert) via NANOG
Hello Joel

Far from widely available but:

- we updated IPv6 ND for P2MP with RFC8505
- address ownership can be protected with RFC 8928
- early work is available for eVPN with 
https://datatracker.ietf.org/doc/html/draft-thubert-bess-secure-evpn-mac-signaling-00

All this is IPv6 only and not shipping yet. The rest is a matter of ask…

Regards,

Pascal

Le 14 juil. 2021 à 14:44, aj  a écrit :


Hi All,

Could anyone please share any ideas on how P2MP can be achieved using EVPN ?
--
Many Thanks,
Joel...