William Herrin writes:
>
> The best path to me from Centurylink is: 3356 1299 20473 11875
>
> The path Centurylink chose is: 3356 47787 47787 47787 47787 53356
> 11875 11875 11875
>
> Do you want to tell me again how that's a reasonable path selection,
> or how I'm supposed to pass commu
Job Snijders via NANOG writes:
> >
> > > Would it not be advantageous to create at a minimum the 256 of the
> > > 'least-specific' objects?
> >
> > MK: That may be a reasonable approach. Do you see any adverse effects
> > in simplifying the IRR Route creation logic to just have
> > least-sp
I'm surprised that no one else has corrected this, so allow me to do
so for the record.
No, Mehmet's public IP was _not_ from the RFC 1918 172.16.0.0/16
range.
One of the public ipv4 ranges that AT&T assigns subscriber addresses
from is 172.0.0.0/12: [ 172.0.0.0 - 172.15.255.255 ]
https://whoi
Hi Chris,
It would be great if the Google Fiber / AS16591 folks could publish a
ROA in ARIN's hosted RPKI authorizing exactly 136.32.0.0/11 to be
originated only in AS16591. That ROA would have addressed this matter
from AS7018's point of view.
In the interim, I have added a temporary whitelist
0 19214 174
> 3356 4837 4808 i
> *144.228.241.130240 0 1239 4837
> 4808 i
> *162.250.137.2540 4901 6079
> 3356 4837 4808 i
> * 114.31.199.1
[No attempts at 01-April humor will be attempted in this message.]
Seeking help from routing engineers around the 'net:
ARIN documents that 192.139.135.0/24 has been allocated to Metro
Wireless International:
https://whois.arin.net/rest/net/NET-192-139-135-0-1
Further, the party to whom 192.
Sriram, Kotikalapudi (Fed) writes:
>
> >When we (as7018) were preparing to begin dropping invalid routes
> >received from peers earlier this year, that is exactly the kind of
> >analysis we did. In our case we rolled our own with a two-pass
> >process: we first found all the traffic to/from
On 12-March-2019, Steve Meuse writes:
> >
> > ps. Dear Kentik & Deepfield, please copy+paste this feature! We'll
> > happily share development notes with you, you can even look at pmacct's
> > source code for inspiration. :-)
>
> Thanks Job, I just wanted to reach back out to you and the NAN
> Congrats Jay, this is awesome news!
Thanks, Alex!
> I’m interested to hear what is preventing you from creating ROAs for all of
> your announcements.
>
> > We will publish more ROAs over time. Thusfar we have been utilizing
> > ARIN's hosted model, but down the road ARIN's delegated m
Job Snijders writes:
> Dear Jay, AT&T,
>
> On Mon, Feb 11, 2019 at 09:53:45AM -0500, Jay Borkenhagen wrote:
> > The AT&T/as7018 network is now dropping all RPKI-invalid route
> > announcements that we receive from our peers.
>
> Thanks for filtering us
valdis.kletni...@vt.edu writes:
> On Mon, 11 Feb 2019 09:53:45 -0500, Jay Borkenhagen said:
> > The AT&T/as7018 network is now dropping all RPKI-invalid route
> > announcements that we receive from our peers.
>
> Congrats!
Thanks!
> Are you able to comment
Compton, Rich A writes:
> That's great! Do you guys have plans to publish ROAs for your own
> netblocks? If so, can you please share info on your process (tools,
> pitfalls, etc.)? Thanks!
>
Hi Rich,
We do have ROAs published for a not insignificant fraction of our
address space. For e
FYI:
The AT&T/as7018 network is now dropping all RPKI-invalid route
announcements that we receive from our peers.
We continue to accept invalid route announcements from our customers,
at least for now. We are communicating with our customers whose
invalid announcements we are propagating, in
AT&T/as7018 is also now in the process of updating its as-path bogon
filters to match those cited below. We have long employed such
filters, and our changes at this time are primarily to extend them to
prohibit as23456 and the reserved blocks > as65535.
So to Job and Adam and anyone else who depl
David Hill writes:
> Anyone else noticing odd ipv6 traceroutes to www.att.net
> (2001:1890:1c01:2::40)?
>
David,
We see what's going on. It currently affects only a portion of the v6
Internet. Working on a fix...
Jay B.
Hi,
I depend on a number of shell tools for manipulating IPv4 addresses,
CIDR blocks, etc. like:
aggis
ipsort.pl
grepcidr
aggregate
I have not yet found much in terms of similar shell utilities for
IPv6. I've spoken to authors of some of these tools and they admit
they have not yet produced
16 matches
Mail list logo