I suspect many providers don't have good business processes for reclaiming
IP space that was assigned to customers who have either disconnected or
voluntarily returned the space.
The provider I started out with in the mid/late 90s bootstrapped itself
with IP space from MCI (now, CenturyLink... I
I have the same thing with a service that was disconnected a couple years ago.
Four IP blocks of /24 size are still swipped to us and we’re announcing them.
I don’t put any customers on them and just use them for temporary things for
fear that some day someone will want them back.
> On Oct
A service I disconnected more than 2 years ago still has a /24 of their
space SWIPED to me. Their NOC closed the ticket I opened to remove. Unknown
if it's actually in use for another customer.
I also had a conversation last week with another ISP (we were renegotiating
our contract) about this.
list takes only 100 seconds.
First time I uploaded/publish something to/on Github ... so please be kind:
https://github.com/FvDxxx/pfxaggr
In case you need it even faster (and can accept the little known issues
and that it's old, ugly and never reviewed):
> wc -l dfz-pfx-20201
This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.
The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.
Daily listings are sent to
I'm sitting here in the office on a Friday performing some IP
maintenance and I see that one of our upstreams is still filtering an IP
range we haven't used in years. I dig into it a bit more and it turns
out a major carrier still has them SWIPed to us.
This got me curious and I dug more
>> ok, i gotta ask. has someone tested to see if they all produce the
>> same result givem the same input? i do not mean to imply they do
>> not. i just have to wonder.
>
> Yes, of course. Marco and I collaborated on the tool's regression
> testing.
>
> job@bench $ aggregate6 < dfz_ipv4
This is what I have done using R:
https://github.com/meekj/netblockr
I still use similar tools in Perl with Net::Netmask
Jon
On Fri, Oct 2, 2020 at 11:50 AM Royce Williams
wrote:
> The recent thread on CIDR aggregation cleanup scripts reminds me that I'm
> looking for a similarly efficient
Cross-post from Russ on AusNOG list.
Telstra blog post on issue is now live -
http://exchange.telstra.com.au/an-update-on-our-september-30-bgp-issue/
Regards,
Mark
Sent from my iPhone
> On 30 Sep 2020, at 08:29, Mark Duffell wrote:
>
> Hi Ross,
>
> Just to confirm the AS1221 incident
The recent thread on CIDR aggregation cleanup scripts reminds me that I'm
looking for a similarly efficient implementation of a related tool. (I'm
gearing up to write my own in Perl, but don't want to reinvent the wheel.)
I'd like a fast, Unix-pipeline-ready tool that *replaces* all IPs within
On Fri, Oct 02, 2020 at 03:39:00AM -0700, Randy Bush wrote:
> > Marco Marzetti (PCCW) wrote an even faster compression tool!
> > https://github.com/lamehost/aggregate-prefixes
> >
> > Both these python implementations are meant as replacements for ISC's
> > vintage 'aggregate' Unix utility, with
> Marco Marzetti (PCCW) wrote an even faster compression tool!
> https://github.com/lamehost/aggregate-prefixes
>
> Both these python implementations are meant as replacements for ISC's
> vintage 'aggregate' Unix utility, with the notable difference that they
> also support IPv6.
ok, i gotta
On Thu, Oct 01, 2020 at 02:15:01PM -0300, Marcos Manoni wrote:
> Check https://github.com/job/aggregate6 (thank you, Job)
Marco Marzetti (PCCW) wrote an even faster compression tool!
https://github.com/lamehost/aggregate-prefixes
Both these python implementations are meant as replacements
13 matches
Mail list logo
