Re: BGP route hijack by AS10990

[Aftab Siddiqui]

Not a single prefix was signed, what I saw. May be good reason for Rogers,
Charter, TWC etc to do that now. It would have stopped the propagation at
Telia.

On Fri, 31 Jul 2020 at 8:40 am, Baldur Norddahl 
wrote:

> Telia implements RPKI filtering so the question is did it work? Were any
> affected prefixes RPKI signed? Would any prefixes have avoided being
> hijacked if RPKI signing had been in place?
>
> Regards
>
> Baldur - who had to turn off RPKI filtering at the request of JTAC to stop
> our mx204s from crashing :-(
>
> tor. 30. jul. 2020 18.59 skrev Töma Gavrichenkov :
>
>> Peace,
>>
>> On Thu, Jul 30, 2020, 5:48 AM Clinton Work  wrote:
>>
>>> We saw a bunch of our IP blocks hijacked by AS10990 from 19:15 MDT until
>>> 20:23 MDT.   Anybody else have problems with that.
>>>
>>
>> Here's what we discovered about the incident.  Hope that brings some
>> clarity.
>>
>> https://radar.qrator.net/blog/as10990-routing-optimization-tale
>>
>> --
>> Töma
>>
>>> --
Regards,

Aftab A. Siddiqui

Re: BGP route hijack by AS10990

[Baldur Norddahl]

Telia implements RPKI filtering so the question is did it work? Were any
affected prefixes RPKI signed? Would any prefixes have avoided being
hijacked if RPKI signing had been in place?

Regards

Baldur - who had to turn off RPKI filtering at the request of JTAC to stop
our mx204s from crashing :-(

tor. 30. jul. 2020 18.59 skrev Töma Gavrichenkov :

> Peace,
>
> On Thu, Jul 30, 2020, 5:48 AM Clinton Work  wrote:
>
>> We saw a bunch of our IP blocks hijacked by AS10990 from 19:15 MDT until
>> 20:23 MDT.   Anybody else have problems with that.
>>
>
> Here's what we discovered about the incident.  Hope that brings some
> clarity.
>
> https://radar.qrator.net/blog/as10990-routing-optimization-tale
>
> --
> Töma
>
>>

Re: BGP route hijack by AS10990

[Patrick Schultz]

I'd like to direct you to Job's writeup on this :) 
https://mailman.nanog.org/pipermail/nanog/2017-August/191897.html
While these "optimizers" CAN be beneficial to the individual operator, they're 
apparently used incorrectly in some instances.
Telia should've filtered, that's for sure. But the leak shouldn't have occured 
in the first place.

Am 30.07.2020 um 20:09 schrieb Florian Brandstetter:
> Never read something that silly, bgp optimizers are perfectly fine
> and every network operator is well within the right to run optimizers,
> you should much more ask Telia as to why they accepted the prefixes,
> and EVEN MORE ask the operator of 7219 for what specific reason they
> are blowing out their full table to 1299. Anyone with a sane mind has
> export filters where a specific community or tag serves as some kind
> of "do advertise" sign, as opposed to announcing anything BUT external.
> 
> May I know the specific reason for such poor attempt of shifting
> responsibility for this incident to bgp optimizers instead of those
> who clearly don't have a single clue about proper filtering policies?
> 
> -- 
> Greetings,
> 
> Florian Brandstetter
> Chief Executive Officer
> SquareFlow Corporation
> www.squareflow.net
> 
> Confidential: Please be advised that the information contained in this
> email message, including all attached documents or files, is privileged
> and confidential and is intended only for the use of the individual or
> individuals addressed. Any other use, dissemination, distribution or
> copying of this communication is strictly prohibited.
> 
> On 2020-07-30 19:09, Patrick Schultz wrote:
>> so, bgp optimizers... again?
>>
>> -- 
>> Patrick
>> Am 30.07.2020 um 18:58 schrieb Töma Gavrichenkov:
>>
>>> Peace,
>>>
>>> On Thu, Jul 30, 2020, 5:48 AM Clinton Work 
>>> wrote:
>>>
 We saw a bunch of our IP blocks hijacked by AS10990 from 19:15 MDT
 until 20:23 MDT.   Anybody else have problems with that.
>>>
>>> Here's what we discovered about the incident.  Hope that brings some
>>> clarity.
>>>
>>> https://radar.qrator.net/blog/as10990-routing-optimization-tale
>>>
>>> -- 
>>> Töma
>>>

Re: BGP route hijack by AS10990

[Job Snijders]

On Thu, Jul 30, 2020 at 07:09:07PM +0200, Patrick Schultz wrote:
> so, bgp optimizers... again?

We should stop calling them 'optimizers'... perhaps "BGP Polluters"?

Kind regards,

Job

Re: BGP route hijack by AS10990

[Owen DeLong]

> On Jul 30, 2020, at 09:45 , Yang Yu  wrote:
> 
> On Thu, Jul 30, 2020 at 9:37 AM Owen DeLong  wrote:
>> 
>> Looks like the real question here is why doesn’t 7219 do a better job of 
>> filtering what they accept.
>> 
>> Has anyone reached out to them?
> 
> You mean 1299? 7219 and 10990 are the same entity.

In that case, sure, up to 1299.

Owen

Re: BGP route hijack by AS10990

[Tom Beecher]

It's not like there are scorecards, but there's a lot of fault to go
around.

However, again, BGP "Optimizers" are bad. The conditions by which the
inadvertent leak occur need to be fixed , no question. But in scenarios
like this, as-path length generally limits impact to "Oh crap, I'll fix
that, sorry!." Once you start squirting out more specifics, you get to own
some of the egg on the face.

On Thu, Jul 30, 2020 at 1:35 PM Sadiq Saif  wrote:

> On Thu, 30 Jul 2020, at 13:09, Patrick Schultz wrote:
> > so, bgp optimizers... again?
> >
> > --
> > Patrick
>
> More like shame on Telia for not filtering properly.
>
> If Tulix used a so called BGP "optimizer" and didn't have a proper export
> filter in place it is their mistake but as a major transit provider, Telia
> bears the brunt of the responsibility of making sure that Tulix's mistake
> doesn't affect the rest of us.
>
> --
>   Sadiq Saif
>   https://sadiqsaif.com/
>

Re: BGP route hijack by AS10990

[Töma Gavrichenkov]

Peace,

On Thu, Jul 30, 2020, 8:09 PM Patrick Schultz 
wrote:

> so, bgp optimizers... again?
>

Looks so.  Upstream filters are also to blame, though, but BGP optimization
is the root of all evil.

--
Töma

>

Re: BGP route hijack by AS10990

[Sadiq Saif]

On Thu, 30 Jul 2020, at 13:09, Patrick Schultz wrote:
> so, bgp optimizers... again?
> 
> -- 
> Patrick

More like shame on Telia for not filtering properly.

If Tulix used a so called BGP "optimizer" and didn't have a proper export 
filter in place it is their mistake but as a major transit provider, Telia 
bears the brunt of the responsibility of making sure that Tulix's mistake 
doesn't affect the rest of us.

-- 
  Sadiq Saif
  https://sadiqsaif.com/

Re: BGP route hijack by AS10990

[Patrick Schultz]

so, bgp optimizers... again?

-- 
Patrick

Am 30.07.2020 um 18:58 schrieb Töma Gavrichenkov:
> Peace,
>
> On Thu, Jul 30, 2020, 5:48 AM Clinton Work  > wrote:
>
> We saw a bunch of our IP blocks hijacked by AS10990 from 19:15 MDT until 
> 20:23 MDT.   Anybody else have problems with that.
>
>
> Here's what we discovered about the incident.  Hope that brings some clarity.
>
> https://radar.qrator.net/blog/as10990-routing-optimization-tale 
> 
>
> --
> Töma
>

Re: BGP route hijack by AS10990

[Töma Gavrichenkov]

Peace,

On Thu, Jul 30, 2020, 5:48 AM Clinton Work  wrote:

> We saw a bunch of our IP blocks hijacked by AS10990 from 19:15 MDT until
> 20:23 MDT.   Anybody else have problems with that.
>

Here's what we discovered about the incident.  Hope that brings some
clarity.

https://radar.qrator.net/blog/as10990-routing-optimization-tale

--
Töma

>

Re: BGP route hijack by AS10990

[Yang Yu]

On Thu, Jul 30, 2020 at 9:37 AM Owen DeLong  wrote:
>
> Looks like the real question here is why doesn’t 7219 do a better job of 
> filtering what they accept.
>
> Has anyone reached out to them?

You mean 1299? 7219 and 10990 are the same entity.

Re: BGP route hijack by AS10990

[Owen DeLong]

Looks like the real question here is why doesn’t 7219 do a better job of 
filtering what they accept.

Has anyone reached out to them?

Owen


> On Jul 29, 2020, at 23:31 , Aftab Siddiqui  wrote:
> 
> Looks like the list is too long.. none of them have any valid ROAs as well. 
> 
> = 104.230.0.0/18  206313 6724 1299 7219 10990
> = 104.230.64.0/18  206313 6724 1299 7219 10990
> = 107.184.0.0/16  206313 6724 1299 7219 10990
> = 107.185.0.0/16  206313 6724 1299 7219 10990
> = 107.189.192.0/19  206313 6724 1299 7219 10990
> = 107.189.224.0/19  206313 6724 1299 7219 10990
> = 108.49.0.0/17  206313 6724 1299 7219 10990
> = 108.49.128.0/17  206313 6724 1299 7219 10990
> = 135.19.192.0/19  206313 6724 1299 7219 10990
> = 135.19.224.0/19  206313 6724 1299 7219 10990
> = 137.119.140.0/23  206313 6724 1299 7219 10990
> = 137.119.142.0/23  206313 6724 1299 7219 10990
> = 142.113.0.0/17  206313 6724 1299 7219 10990
> = 142.113.128.0/17  206313 6724 1299 7219 10990
> = 147.194.0.0/20  206313 6724 1299 7219 10990
> = 147.194.16.0/20  206313 6724 1299 7219 10990
> = 162.157.0.0/17  206313 6724 1299 7219 10990
> = 162.157.128.0/17  206313 6724 1299 7219 10990
> = 166.48.0.0/18  206313 6724 1299 7219 10990
> = 166.48.64.0/18  206313 6724 1299 7219 10990
> = 167.100.80.0/22  206313 6724 1299 7219 10990
> = 167.100.84.0/22  206313 6724 1299 7219 10990
> = 172.103.112.0/20  206313 6724 1299 7219 10990
> = 172.103.96.0/20  206313 6724 1299 7219 10990
> = 172.112.0.0/14  206313 6724 1299 7219 10990
> = 172.116.0.0/14  206313 6724 1299 7219 10990
> = 173.160.0.0/14  206313 6724 1299 7219 10990
> = 173.164.0.0/14  206313 6724 1299 7219 10990
> = 173.28.224.0/21  206313 6724 1299 7219 10990
> = 173.28.232.0/21  206313 6724 1299 7219 10990
> = 173.48.0.0/17  206313 6724 1299 7219 10990
> = 173.48.128.0/17  206313 6724 1299 7219 10990
> = 173.90.0.0/16  206313 6724 1299 7219 10990
> = 173.91.0.0/16  206313 6724 1299 7219 10990
> = 174.1.56.0/23  206313 6724 1299 7219 10990
> = 174.1.58.0/23  206313 6724 1299 7219 10990
> = 174.108.0.0/15  206313 6724 1299 7219 10990
> = 174.110.0.0/15  206313 6724 1299 7219 10990
> = 174.223.0.0/18  206313 6724 1299 7219 10990
> = 174.223.64.0/18  206313 6724 1299 7219 10990
> = 174.228.0.0/18  206313 6724 1299 7219 10990
> = 174.228.64.0/18  206313 6724 1299 7219 10990
> = 174.231.128.0/18  206313 6724 1299 7219 10990
> = 174.231.192.0/18  206313 6724 1299 7219 10990
> = 177.132.112.0/20  206313 6724 1299 7219 10990
> = 177.132.96.0/20  206313 6724 1299 7219 10990
> = 198.166.0.0/17  206313 6724 1299 7219 10990
> = 198.166.128.0/17  206313 6724 1299 7219 10990
> = 198.52.176.0/23  206313 6724 1299 7219 10990
> = 198.52.178.0/23  206313 6724 1299 7219 10990
> = 204.195.0.0/18  206313 6724 1299 7219 10990
> = 208.79.152.0/22  206313 6724 6939 10990
> = 208.79.153.0/24  206313 6724 6939 7219 10990
> = 216.10.190.0/24  206313 6724 1299 7219 10990
> = 216.10.191.0/24  206313 6724 1299 7219 10990
> = 24.102.64.0/19  206313 6724 1299 7219 10990
> = 24.102.96.0/19  206313 6724 1299 7219 10990
> = 24.197.208.0/21  206313 6724 1299 7219 10990
> = 24.197.216.0/21  206313 6724 1299 7219 10990
> = 24.201.64.0/19  206313 6724 1299 7219 10990
> = 24.201.96.0/19  206313 6724 1299 7219 10990
> = 24.205.160.0/20  206313 6724 1299 7219 10990
> = 24.205.176.0/20  206313 6724 1299 7219 10990
> = 24.48.0.0/19  206313 6724 1299 7219 10990
> = 24.48.32.0/19  206313 6724 1299 7219 10990
> = 24.57.0.0/17 

Re: BGP unnumbered examples from data center network using RFC 5549 et al. [was: Re: RFC 5549 - IPv4 Routes with IPv6 next-hop - Does it really exists?]

[Mark Tinka]

On 30/Jul/20 12:00, Simon Leinen wrote:

> As Nick mentions, the hostnames are from the BGP hostname extension.
>
> I should have noticed that, but we use "BGP unnumbered"[1][2], which
> uses RAs to discover the peer's IPv6 link-local address, and then builds
> an IPv6 BGP session (that uses RFC 5549 to transfer IPv4 NLRIs as well).
>
> Here are some excerpts of the configuration on such a leaf router.
>
> General BGP boilerplate:
>
> --
> router bgp 65111
>  bgp router-id 10.1.1.46
>  bgp bestpath as-path multipath-relax
>  bgp bestpath compare-routerid
> !
>  address-family ipv4 unicast
>   network 10.1.1.46/32
>   redistribute connected
>   redistribute static
>  exit-address-family
>  !
>  address-family ipv6 unicast
>   network 2001:db8:1234:101::46/128
>   redistribute connected
>   redistribute static
>  exit-address-family
> --
>
> Leaf switch <-> server connection: (we use a 802.1q tagged subinterface
> for the BGP peering and L3 server traffic; the untagged interface is
> used only for netbooting the servers when (re)installing the OS.  Here,
> servers just get IPv4+IPv6 default routes, and each server will only
> announce a single IPv4+IPv6 (loopback) address, i.e. the leaf/server
> links are also "unnumbered".  Very simple redundant setup without any
> LACP/MLAG protocols... it's all just BGP+IPv6 ND.  You can basically
> connect any server to any switch port and things will "just work"
> without special inter-switch links etc.)
>
> --
> interface swp1s0
>  description s0001.s1.scloud.switch.ch p8p1
> !
> interface swp1s0.3
>  description s0001.s1.scloud.switch.ch p8p1
>  ipv6 nd ra-interval 3
>  no ipv6 nd suppress-ra
> !
> [...]
> router bgp 65111
>  neighbor servers peer-group
>  neighbor servers remote-as external
>  neighbor servers capability extended-nexthop
>  neighbor swp1s0.3 interface peer-group servers
>  !
>  address-family ipv4 unicast
>   neighbor servers default-originate
>   neighbor servers soft-reconfiguration inbound
>   neighbor servers prefix-list DEFAULTV4-PERMIT out
>  exit-address-family
>  !
>  address-family ipv6 unicast
>   neighbor servers activate
>   neighbor servers default-originate
>   neighbor servers soft-reconfiguration inbound
>   neighbor servers prefix-list DEFAULTV6-PERMIT out
>  exit-address-family
> !
> ip prefix-list DEFAULT-PERMIT permit 0.0.0.0/0
> !
> ipv6 prefix-list DEFAULTV6-PERMIT permit ::/0
> --
>
> Leaf <-> spine:
>
> --
> interface swp16
>  description sw-o port 22
>  ipv6 nd ra-interval 3
>  no ipv6 nd suppress-ra
> !
> [...]
> router bgp 65111
>  neighbor fabric peer-group
>  neighbor fabric remote-as external
>  neighbor fabric capability extended-nexthop
>  neighbor swp16 interface peer-group fabric
>  !
>  address-family ipv4 unicast
>   neighbor fabric soft-reconfiguration inbound
>  !
>  address-family ipv6 unicast
>   neighbor fabric activate
>   neighbor fabric soft-reconfiguration inbound
> --
>
> Note the "remote-as external" - this will accept any AS other than the
> router's own AS.  AS numbering in this DC setup is a bit weird if you're
> used to BGP... each leaf switch has its own AS, all spine switches
> should have the same AS number (for reasons...), and all servers have
> the same AS because who cares.  (We are talking about three disjoint
> sets of AS numbers for leaves/spines/servers though.)

Interesting.

Data centre bits are, interesting :-).

Thanks for sharing.

Mark.

Re: Massive Spectrum Outage

[Tom Beecher]

There was a train derailment in Tempe, AZ yesterday AM that partially
collapsed a bridge that had a bunch of glass running over it. Possibly
related.

On Wed, Jul 29, 2020 at 10:37 PM Kenneth McRae via NANOG 
wrote:

> Anyone outside of S. California affected?
>
>
>

Looking for 1G / 10G IP Transit LA

[James Braunegg]

Dear NANOG

I am looking to add another IP Transit provider to our current mix in LA for 
AS38880, with services delivered at One Wilshire (Core Site)

If you can provide IP transit services (Either a Tier 1 provider or a blended 
Tier 2 service) then please contact me off list.

BGP community support for traffic engineering is a requirement, if you want any 
more details please contact me

Kindest Regards

James Braunegg



[cid:image001.png@01D280A4.01865B60]

1300 769 972 / 0488 997 207

ja...@micron21.com

www.micron21.com/


[cid:image002.png@01D280A4.01865B60]


[cid:image003.png@01D280A4.01865B60]

[cid:image004.png@01D280A4.01865B60]

Follow us on Twitter for important service and 
system updates.


This message is intended for the addressee named above. It may contain 
privileged or confidential information. If you are not the intended recipient 
of this message you must not use, copy, distribute or disclose it to anyone 
other than the addressee. If you have received this message in error please 
return the message to the sender by replying to it and then delete the message 
from your computer.

BGP unnumbered examples from data center network using RFC 5549 et al. [was: Re: RFC 5549 - IPv4 Routes with IPv6 next-hop - Does it really exists?]

[Simon Leinen]

Mark Tinka writes:
> On 29/Jul/20 15:51, Simon Leinen wrote:

>> 
>> Neighbor   V   AS MsgRcvd MsgSent   TblVer  InQ OutQ  Up/Down 
>> State/PfxRcd
>> sw-o(swp16)465108  953559  938348000 03w5d00h
>>   688
>> sw-m(swp18)465108  885442  938348000 03w5d00h
>>   688
>> s0001(swp1s0.3)465300  748971  748977000 03w5d00h
>> 1
>> [...]
>> 
>> Note the host names/interface names - this is how you generally refer to
>> neighbors, rather than using literal (IPv6) addresses.

> Are the names based on DNS look-ups, or is there some kind of protocol
> association between the device underlay and its hostname, as it pertains
> to neighbors?

As Nick mentions, the hostnames are from the BGP hostname extension.

I should have noticed that, but we use "BGP unnumbered"[1][2], which
uses RAs to discover the peer's IPv6 link-local address, and then builds
an IPv6 BGP session (that uses RFC 5549 to transfer IPv4 NLRIs as well).

Here are some excerpts of the configuration on such a leaf router.

General BGP boilerplate:

--
router bgp 65111
 bgp router-id 10.1.1.46
 bgp bestpath as-path multipath-relax
 bgp bestpath compare-routerid
!
 address-family ipv4 unicast
  network 10.1.1.46/32
  redistribute connected
  redistribute static
 exit-address-family
 !
 address-family ipv6 unicast
  network 2001:db8:1234:101::46/128
  redistribute connected
  redistribute static
 exit-address-family
--

Leaf switch <-> server connection: (we use a 802.1q tagged subinterface
for the BGP peering and L3 server traffic; the untagged interface is
used only for netbooting the servers when (re)installing the OS.  Here,
servers just get IPv4+IPv6 default routes, and each server will only
announce a single IPv4+IPv6 (loopback) address, i.e. the leaf/server
links are also "unnumbered".  Very simple redundant setup without any
LACP/MLAG protocols... it's all just BGP+IPv6 ND.  You can basically
connect any server to any switch port and things will "just work"
without special inter-switch links etc.)

--
interface swp1s0
 description s0001.s1.scloud.switch.ch p8p1
!
interface swp1s0.3
 description s0001.s1.scloud.switch.ch p8p1
 ipv6 nd ra-interval 3
 no ipv6 nd suppress-ra
!
[...]
router bgp 65111
 neighbor servers peer-group
 neighbor servers remote-as external
 neighbor servers capability extended-nexthop
 neighbor swp1s0.3 interface peer-group servers
 !
 address-family ipv4 unicast
  neighbor servers default-originate
  neighbor servers soft-reconfiguration inbound
  neighbor servers prefix-list DEFAULTV4-PERMIT out
 exit-address-family
 !
 address-family ipv6 unicast
  neighbor servers activate
  neighbor servers default-originate
  neighbor servers soft-reconfiguration inbound
  neighbor servers prefix-list DEFAULTV6-PERMIT out
 exit-address-family
!
ip prefix-list DEFAULT-PERMIT permit 0.0.0.0/0
!
ipv6 prefix-list DEFAULTV6-PERMIT permit ::/0
--

Leaf <-> spine:

--
interface swp16
 description sw-o port 22
 ipv6 nd ra-interval 3
 no ipv6 nd suppress-ra
!
[...]
router bgp 65111
 neighbor fabric peer-group
 neighbor fabric remote-as external
 neighbor fabric capability extended-nexthop
 neighbor swp16 interface peer-group fabric
 !
 address-family ipv4 unicast
  neighbor fabric soft-reconfiguration inbound
 !
 address-family ipv6 unicast
  neighbor fabric activate
  neighbor fabric soft-reconfiguration inbound
--

Note the "remote-as external" - this will accept any AS other than the
router's own AS.  AS numbering in this DC setup is a bit weird if you're
used to BGP... each leaf switch has its own AS, all spine switches
should have the same AS number (for reasons...), and all servers have
the same AS because who cares.  (We are talking about three disjoint
sets of AS numbers for leaves/spines/servers though.)
-- 
Simon.

[1] https://cumulusnetworks.com/blog/bgp-unnumbered-overview/
[2] 
https://support.cumulusnetworks.com/hc/en-us/articles/212561648-Configuring-BGP-Unnumbered-with-Cisco-IOS

Re: BGP route hijack by AS10990

[Stephane Bortzmeyer]

On Thu, Jul 30, 2020 at 11:21:04AM +0300,
 Hank Nussbacher  wrote 
 a message of 48 lines which said:

>See:

And:

https://stat.ripe.net/widget/bgp-update-activity#w.starttime=2020-07-16T05%3A00%3A00=2020-07-30T05%3A00%3A00=AS10990

Re: BGP route hijack by AS10990

[Hank Nussbacher]

  
  
On 30/07/2020 05:46, Clinton Work
  wrote:


See:
https://bgpstream.com/event/245264
https://bgpstream.com/event/245265


-Hank


Caveat: The views expressed above are
  solely my own and do not express the views or opinions of my
  employer 




  We saw a bunch of our IP blocks hijacked by AS10990 from 19:15 MDT until 20:23 MDT.   Anybody else have problems with that. 

ASpath:  1299 7219 10990

50.92.0.0/17	AS10990
198.166.0.0/17	 AS10990
198.166.128.0/17	AS10990
162.157.128.0/17	AS10990
162.157.0.0/17	AS10990
50.92.128.0/17	AS10990



--
Clinton Work
Airdrie, AB




  

Re: BGP route hijack by AS10990

[Aftab Siddiqui]

Looks like the list is too long.. none of them have any valid ROAs as well.

= 104.230.0.0/18 206313 6724 1299 7219 10990
= 104.230.64.0/18 206313 6724 1299 7219 10990
= 107.184.0.0/16 206313 6724 1299 7219 10990
= 107.185.0.0/16 206313 6724 1299 7219 10990
= 107.189.192.0/19 206313 6724 1299 7219 10990
= 107.189.224.0/19 206313 6724 1299 7219 10990
= 108.49.0.0/17 206313 6724 1299 7219 10990
= 108.49.128.0/17 206313 6724 1299 7219 10990
= 135.19.192.0/19 206313 6724 1299 7219 10990
= 135.19.224.0/19 206313 6724 1299 7219 10990
= 137.119.140.0/23 206313 6724 1299 7219 10990
= 137.119.142.0/23 206313 6724 1299 7219 10990
= 142.113.0.0/17 206313 6724 1299 7219 10990
= 142.113.128.0/17 206313 6724 1299 7219 10990
= 147.194.0.0/20 206313 6724 1299 7219 10990
= 147.194.16.0/20 206313 6724 1299 7219 10990
= 162.157.0.0/17 206313 6724 1299 7219 10990
= 162.157.128.0/17 206313 6724 1299 7219 10990
= 166.48.0.0/18 206313 6724 1299 7219 10990
= 166.48.64.0/18 206313 6724 1299 7219 10990
= 167.100.80.0/22 206313 6724 1299 7219 10990
= 167.100.84.0/22 206313 6724 1299 7219 10990
= 172.103.112.0/20 206313 6724 1299 7219 10990
= 172.103.96.0/20 206313 6724 1299 7219 10990
= 172.112.0.0/14 206313 6724 1299 7219 10990
= 172.116.0.0/14 206313 6724 1299 7219 10990
= 173.160.0.0/14 206313 6724 1299 7219 10990
= 173.164.0.0/14 206313 6724 1299 7219 10990
= 173.28.224.0/21 206313 6724 1299 7219 10990
= 173.28.232.0/21 206313 6724 1299 7219 10990
= 173.48.0.0/17 206313 6724 1299 7219 10990
= 173.48.128.0/17 206313 6724 1299 7219 10990
= 173.90.0.0/16 206313 6724 1299 7219 10990
= 173.91.0.0/16 206313 6724 1299 7219 10990
= 174.1.56.0/23 206313 6724 1299 7219 10990
= 174.1.58.0/23 206313 6724 1299 7219 10990
= 174.108.0.0/15 206313 6724 1299 7219 10990
= 174.110.0.0/15 206313 6724 1299 7219 10990
= 174.223.0.0/18 206313 6724 1299 7219 10990
= 174.223.64.0/18 206313 6724 1299 7219 10990
= 174.228.0.0/18 206313 6724 1299 7219 10990
= 174.228.64.0/18 206313 6724 1299 7219 10990
= 174.231.128.0/18 206313 6724 1299 7219 10990
= 174.231.192.0/18 206313 6724 1299 7219 10990
= 177.132.112.0/20 206313 6724 1299 7219 10990
= 177.132.96.0/20 206313 6724 1299 7219 10990
= 198.166.0.0/17 206313 6724 1299 7219 10990
= 198.166.128.0/17 206313 6724 1299 7219 10990
= 198.52.176.0/23 206313 6724 1299 7219 10990
= 198.52.178.0/23 206313 6724 1299 7219 10990
= 204.195.0.0/18 206313 6724 1299 7219 10990


*= 208.79.152.0/22  206313 6724 6939 10990=
208.79.153.0/24  206313 6724 6939 7219 10990*=
216.10.190.0/24 206313 6724 1299 7219 10990
= 216.10.191.0/24 206313 6724 1299 7219 10990
= 24.102.64.0/19 206313 6724 1299 7219 10990
= 24.102.96.0/19 206313 6724 1299 7219 10990
= 24.197.208.0/21 206313 6724 1299 7219 10990
= 24.197.216.0/21 206313 6724 1299 7219 10990
= 24.201.64.0/19 206313 6724 1299 7219 10990
= 24.201.96.0/19 206313 6724 1299 7219 10990
= 24.205.160.0/20 206313 6724 1299 7219 10990
= 24.205.176.0/20 206313 6724 1299 7219 10990
= 24.48.0.0/19 206313 6724 1299 7219 10990
= 24.48.32.0/19 206313 6724 1299 7219 10990
= 24.57.0.0/17 206313 6724 1299 7219 10990
= 24.57.128.0/17 206313 6724 1299 7219 10990
= 24.89.16.0/20 206313 6724 1299 7219 10990
= 24.90.64.0/19 206313 6724 1299 7219 10990
= 24.90.96.0/19 206313 6724 1299 7219 10990
= 35.211.0.0/17 206313 6724 1299 7219 10990
= 35.211.128.0/17 206313 6724 1299 7219 10990
= 45.48.0.0/15 206313 6724 1299 7219 10990
= 45.50.0.0/15 206313 6724 1299 7219 10990
= 47.218.0.0/23 206313 6724 1299 7219 10990
= 47.218.2.0/23 206313 6724 1299 7219 10990
= 47.32.64.0/19 206313 6724 1299 7219 10990
= 47.32.96.0/19 206313 6724 1299 7219 10990
= 47.36.0.0/19 206313 6724 1299 7219 10990
= 47.36.32.0/19 206313 6724 1299 7219 10990
= 47.39.64.0/19 206313 6724 1299 7219 10990
= 47.39.96.0/19 206313 6724 1299 7219 10990
= 50.88.0.0/16 206313 6724 1299 7219 10990
= 50.89.0.0/16 206313 6724 1299 7219 10990
= 50.92.0.0/17 206313 6724 1299 7219 10990
= 50.92.128.0/17 206313 6724 1299 7219 10990
= 66.65.0.0/18 206313 6724 1299 7219 10990
= 66.65.64.0/18 206313 6724 1299 7219 10990
= 66.68.0.0/16 206313 6724 1299 7219 10990
= 66.69.0.0/16 206313 6724 1299 7219 10990
= 67.149.198.0/24 206313 6724 1299 7219 10990
= 67.149.199.0/24 206313 6724 1299 7219 10990
= 67.247.112.0/20 206313 6724 1299 7219 10990
= 67.247.96.0/20 206313 6724 1299 7219 10990
= 70.83.128.0/19 206313 6724 1299 7219 10990
= 70.83.160.0/19 206313 6724 1299 7219 10990
= 72.137.0.0/17 206313 6724 1299 7219 10990
= 72.137.128.0/17 206313 6724 1299 7219 10990
= 72.140.0.0/16 206313 6724 1299 7219 10990
= 72.141.0.0/16 206313 6724 1299 7219 10990
= 72.53.64.0/20 206313 6724 1299 7219 10990
= 72.53.80.0/20 206313 6724 1299 7219 10990
= 74.56.192.0/19 206313 6724 1299 7219 10990
= 74.56.224.0/19 206313 6724 1299 7219 10990
= 74.59.128.0/19 206313 6724 1299 7219 10990
= 74.59.160.0/19 206313 6724 1299 7219 10990
= 74.76.0.0/15 206313 6724 1299 7219 10990
= 74.78.0.0/15 206313 6724 1299 7219 10990
=