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
On Wed, Jan 16, 2019 at 10:56 Mark Tinka wrote:
> On 3/Jan/19 22:08, Andy Davidson wrote:
>
> > There are no stupid questions! It is a good idea to not BGP announce
> and perhaps also to drop traffic toward peering LAN prefixes at
> customer-borders, this was already well discussed in the thread
On Wed, Jan 9, 2019 at 9:55 Randy Bush wrote:
> >>> We plan to resume the experiments January 16th (next Wednesday), and
> >>> have updated the experiment schedule [A] accordingly. As always, we
> >>> welcome your feedback.
> >> i did not realize that frr updates propagated so quickly. very coo
OOn Tue, Jan 8, 2019 at 19:59 Tom Ammon wrote:
> On Tue, Jan 8, 2019, 11:50 AM
>> * cu...@dcc.ufmg.br (Italo Cunha) [Tue 08 Jan 2019, 17:42 CET]:
>> >[A] https://goo.gl/nJhmx1
>>
>> For the archives, since goo.gl will cease to exist soon, this links to
>>
>> https://docs.google.com/spreadsheets/
Dear Christopher, David, NANOG community,
Thank you for your research and report. I found the report quite readable
(not having a legal background) and well structured. Definitely edifying
and worth the read! In this mail I’ll reply specifically to a few points
from the executive summary (and snip
Dear all,
NTT / AS 2914 deployed explicit filters to block this BGP announcement from
AS 4134. I recommend other operators to do the same.
I’d also like to recommend AS 32982 to remove the AS_PATH prepend on the
/24 announcement so the counter measure is more effective.
Kind regards,
Job
On Fr
At this moment it appears there are multiple rifts in the IPv6 default-free
zone (that don’t exist in the IPv4 realm), between various organizations.
Focusing on one particular partitioning may not help address the other
issues.
Kind regards,
Job
Dear Dominic,
On Thu, Dec 20, 2018 at 6:49 PM Dominic Schallert wrote:
> this might be a stupid question but today I was discussing with a colleague
> if Peering-LAN prefixes should be re-distributed/announced to direct
> customers/peers. My standpoint is that in any case, Peering-LAN prefixes
Dear Italo,
Thanks for giving the community a heads-up on your plan! I think your
announcement like these are the best anyone can do when trying legal
but new BGP path attributes.
I'll forward this message to other NOGs and make sure that our NOC
adds it to their calendar.
Kind regards,
Job
On
Dear Steve,
No worries, I have not forgotten the transitive properties of the
LOCAL_PREF BGP Path Attribute! :-) You are right that any LOCAL_PREF
modifications (and the attribute itself), are local to the Autonomous
System in which they were set, but the effects of such settings can
percolate fur
Hi Steve,
Lowering the LP would achieve the outcome you desire, provided there are
(stable) alternative paths.
What you advocate results in absolute outages in what may already be
precarious situations (natural disasters?) - what Saku Ytti suggests like a
less painful alternative with desirable p
On Tue, Dec 18, 2018 at 6:40 PM Randy Bush wrote:
>
> do you have rfd on? with what parms?
I assume rfd in this context means "Route Flap Dampening".
NTT / AS 2914 does *not* have Route Flap Dampening configured, as is
documented here
https://us.ntt.net/support/policy/routing.cfm#routedampening
Dear fellow BGP aficionados,
Over the last few months we've spend considerable time modernizing the
OpenBSD's BGP-4 implementation "OpenBGPD", with the explicit goal to
offer more diversity in the IXP Route Server space.
OpenBGPD now is faster, has RFC 8212 support, RFC 6811 Origin Validation
sup
Let’s please stay on topic.
The war is over.
In IETF the OSPF and ISIS working groups merged. Now all of it is
“link-state routing”.
https://datatracker.ietf.org/group/lsr/about/
On Fri, Nov 9, 2018 at 0:54 Eric Kuhnke wrote:
> https://news.ycombinator.com/item?id=18407173
>
> Quoting from the post:
>
> "
>
> Apparently bought in two chunks: 3.0.0.0/9 and 3.128.0.0/9.
>
> Previous owner was GE.
>
> Anecdotal reports across the Internet that AWS EIPs are now being assigned
ran wrote:
> On 25 Sep 2018, at 3:34 PM, Job Snijders wrote:
> > ...
> > What I'm hoping for is that there is a way for the ARIN TAL to be
> > included in software distributions, without compromising ARIN's
> > legal position.
> >
> > Perhaps
Dear all,
I'm very happy to see the direction this conversation has taken, seems
we've moved on towards focussing on solutions and outcomes - this is
encouraging.
On Mon, Oct 01, 2018 at 05:44:17PM +0100, Nick Hilliard wrote:
> John Curran wrote on 01/10/2018 00:21:
> > There is likely some on th
Perhaps the moderator and the presenters for this track can figure out (off
list!) if there is unanimous support to record the session and reconsider.
Kind regards,
Job
Hi all,
Speaking as presenter in this track, I’d be fine with video recording and
online distribution. In fact, I’d encourage it, I don’t assume any secrecy
or confidentiality in this meeting.
Perhaps for the NANOG74 meeting it is too late to organize video recording,
but going forward I’m a prop
On Wed, Sep 26, 2018 at 11:07:49AM +, John Curran wrote:
> > Let's Encrypt does not require an agreement from relying parties
> > (i.e. browser users), whereas ARIN does.
>
> That is correct; I did not say that they were parallel situations,
> only pointing out that the Let’s Encrypt folks al
On Tue, Sep 25, 2018 at 09:17:56PM +, John Curran wrote:
> On 25 Sep 2018, at 5:04 PM, Job Snijders wrote:
> >> It would be informative to know how many organizations potentially
> >> have concerns about the indemnification clause in the RPA but
> >> already agr
Dear John,
On Tue, Sep 25, 2018 at 08:28:54PM +, John Curran wrote:
> On 25 Sep 2018, at 3:34 PM, Job Snijders wrote:
> >
> > On Tue, Sep 25, 2018 at 03:07:54PM -0400, John Curran wrote:
> >> On Sep 25, 2018, at 1:30 PM, Job Snijders wrote:
> >>>
> &
On Tue, Sep 25, 2018 at 03:07:54PM -0400, John Curran wrote:
> On Sep 25, 2018, at 1:30 PM, Job Snijders wrote:
> >
> >"""Using the data, we can also see that the providers that have not
> >downloaded the ARIN TAL. Either because they were not aware
Dear NANOG,
I'd like to draw attention to a very concerning development: it appears
that the ARIN TAL is not as widely deployed as other RPKI TALs (such as
RIPE or APNIC's TAL). This means that ARIN members are needlessly put at
higher risk.
Ben Cartwright-Cox performed RPKI research a few weeks
On Tue, Sep 25, 2018 at 12:18:50PM -0400, Steve Meuse wrote:
> https://docs.microsoft.com/en-us/office365/enterprise/urls-and-ip-address-ranges
I think it is cool that companies take the time and effort to publish
such useful lists. Keep it up!
Kind regards,
Job
On Wed, Sep 19, 2018 at 01:07:42AM -0700, Christopher Morrow wrote:
> > it is about whether it is acceptable that RIRs (and more
> > specifically ARIN in this mailing list's context) notify affected
> > parties of their prefixes that suffer from stale ROAs.
>
> This I still think is a bad plan.. m
On Tue, Sep 18, 2018 at 06:18:00PM -0700, Owen DeLong wrote:
> That depends. If you ONLY allow the maintainer of NET-192.159.10.0/24
> to update the route objects for it, then the word ONLY is effectively
> present by the lack of any other route objects.
Ah, so you are now applying the RPKI Origin
On Tue, Sep 18, 2018 at 02:44:30PM -0700, Owen DeLong wrote:
> ROAs are useful for one hop level validation. At the second AS hop
> they are 100% useless.
This conversation cannot be had without acknowledging there are multiple
layers of defense in securing BGP. We should also acknowledge that the
On Tue, Sep 18, 2018 at 02:35:44PM -0700, Owen DeLong wrote:
> > "rir says owen can originate route FOO"
> > "ROA for 157.130.1.0/24 says OWEN can originate"
>
> Nope… ROA says (e.g.) AS1734 (or anyone willing to impersonate AS1734)
> can originate 192.159.10.0/24.
I'd phrase slightly different (
On Tue, Sep 18, 2018 at 12:04:19PM -0700, Owen DeLong wrote:
> > Perhaps said another way:
> >
> > "How would you figure out what prefixes your bgp peer(s) should be sending
> > you?"
> >(in an automatable, and verifiable manner)
>
> In theory, that’s what IRRs are for.
You may be overlook
Owen,
On Tue, Sep 18, 2018 at 10:23:42AM -0700, Owen DeLong wrote:
> Personally, since all RPKI accomplishes is providing a
> cryptographically signed notation of origin ASNs that hijackers should
> prepend to their announcements in order to create an aura of
> credibility, I think we should stop
On Mon, 17 Sep 2018 at 18:38, nusenu wrote:
> Dear NIST RPKI Monitor Team,
>
> thanks for creating and maintaining the RPKI Monitor
> https://rpki-monitor.antd.nist.gov/#rpki_adopters
> I've seen your graphs in multiple routing security presentations :)
>
> What do you think about adding graphs t
On Tue, Aug 14, 2018 at 05:28:13PM -0600, Grant Taylor via NANOG wrote:
> On 08/14/2018 03:38 PM, Randy Bush wrote:
> > so we started to wonder if, since we started protecting our bgp
> > sessions with md5 (in the 1990s), are there still folk trying to
> > attack?
>
> n00b response here
>
> I tho
Dear all,
Today marks the 10th anniversary of the famous Kapela-Pilosov
Man-in-the-middle BGP attack! It is a fantastic and innovative attack
that would be worthy of referencing in the next Mr Robot season. :-)
video: https://www.youtube.com/watch?v=S0BM6aB90n8
slide:
https://www.defcon.
Dear Michel,
This question is probably best answered by Andree Toonk from the
BGPMon project. I've CCed him.
Kind regards,
Job
On Thu, Aug 2, 2018 at 10:27 PM, Michel Py wrote:
> Hi Nanog,
>
> I received recently some of these messages, and I don't understand the logic
> of them.
> If there i
On Tue, 31 Jul 2018 at 23:29, Sean Donelan wrote:
> Its tought to prove a negative. I'm extremely confident the answer is yes,
> public internet multicast is not viable. I did all the google searches,
> check all the usual CAIDA and ISP sites. IP Multicast is used on private
> enterprise networks
We are reaching out off list!
Kind regards,
Job
On Mon, 30 Jul 2018 at 22:52, Christopher Morrow
wrote:
> job
>
> On Mon, Jul 30, 2018 at 4:49 PM Michel Py wrote:
>
> > Can someone from NTT US contact me off-list please ?
> > Preferably someone with some RPKI clue.
> >
> > Thanks,
> >
> > Mic
Dear Alex,
On Thu, 26 Jul 2018 at 19:11, Alex Band wrote:
> NLnet Labs recently committed to building a full RPKI Toolset, including a
> (Delegated) Certificate Authority, a Publication Server and Relying Party
> software. As an RP implementation was the easiest way to get going, we now
> have
On Wed, Jul 25, 2018 at 12:58:46PM +0200, Jérôme Nicolle wrote:
> From your initial list, I can still see some prefixes with the NLnog ring :
>
> http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=206.41.128.0
> http://lg.ring.nlnog.net/prefix_detail/lg01/ipv4?q=52.128.192.0
> http://lg.ring.nlnog
On Tue, Jul 24, 2018 at 11:36:21PM +0530, Anurag Bhatia wrote:
> Thanks a lot for your advice. I was aware of IXP Manager and there
> were certain issues we faced due to which we couldn't use it when we
> tried last time (which was a few months ago before the latest stable
> release). I wish to re-
On Mon, 23 Jul 2018 at 23:00, Anurag Bhatia wrote:
> We are running a small IX fabric (in Mumbai, India) and with multiple
> route servers based on a bird. There has been a demand of support of BGP
> communities from some of our members and I am trying to find a way to set
> it up in the bird. Id
er that we hope to deploy in the not too distant
future. Using RPKI ROAs in this way is an important step forward in this
process.
Kind regards,
Job Snijders
Post scriptum on prior work:
Dragon Research Labs implemented the idea in 2015:
https://github.com/dragonresearch/rpki.net/blob/
On Thu, Jul 19, 2018 at 11:19:12AM -0700, Kenneth Finnegan wrote:
> As for ARIN-WHOIS, I think I had gotten confused whether it was
> additive or exclusive of IRR objects for allowing prefixes.
Indeed, in arouteserver it is 'additive'. Documentation from ARIN is
here:
https://teamarin.net/2016/0
Dear Kenneth,
On Wed, Jul 18, 2018 at 09:38:23PM -0700, Kenneth Finnegan wrote:
> As part of setting up a new Internet Exchange in Fremont, California,
> we've been investigating prefix filtering on the route servers based
> on IRR.
Excellent, have you also considered using ARIN-WHOIS and RPKI as
On Wed, Jul 18, 2018 at 05:55:23PM -0400, Randy Bush wrote:
> > Can you elaborate what routers with what software you are using? It
> > surprises me a bit to find routers anno 2018 which can't do OV in
> > some shape or form.
>
> depends on how picky you are about "some shape or form."
I was thin
On Wed, Jul 18, 2018 at 07:30:48PM +, Michel Py wrote:
> Not in lieu, but when deploying RPKI is not (yet) possible. My
> routers are not RPKI capable, upgrading will take years (I'm not going
> to upgrade just because I want RPKI).
Can you elaborate what routers with what software you are us
On Tue, Jul 17, 2018 at 01:27:09PM +0200, Mark Tinka wrote:
> > Markus Weber from KPN is generating a daily report here and drew
> > similar conclusions: https://as286.net/data/ana-invalids.txt Markus
> > scrapes all routes from the AS 286 PEs and marks the routes for
> > which no valid or unknown
On Sat, Jul 14, 2018 at 11:03:16AM +0200, Mark Tinka wrote:
> On 14/Jul/18 09:11, Baldur Norddahl wrote:
> > In the RIPE part of the world there is no excuse for not getting
> > RPKI correct because RIPE made it so easy. Perhaps the industry
> > could agree on enabling RPKI validation on all europe
On Fri, Jul 13, 2018 at 02:53:30PM +0200, Mark Tinka wrote:
> That, though, still leaves the problem where you end up providing a
> partial routing table to your customers, while your competitors in the
> same market aren't.
I actually view it as a competitive advantage to carry a cleaner set of
r
On Fri, Jul 13, 2018 at 4:25 PM, Christopher Morrow
wrote:
> On Fri, Jul 13, 2018 at 11:19 AM Grant Taylor via NANOG
> wrote:
>> The reading I did on RPKI / OV yesterday made me think that it is
>> possible to have validated routes preferred over unknown routes which
>> are preferred over invalid
On Fri, Jul 13, 2018 at 02:37:32PM +0200, Mark Tinka wrote:
> Anyway, the operational issue we ran into was due to our aggressive
> policy to drop Invalids. The reason this became an issue was networks
> that ROA'd just their aggregates, but either forgot to or decided not to
> ROA the longer prefi
Hi all,
I wanted to share with you that a ton of activity is taking place in the
Dutch networker community to deploy RPKI based BGP Origin Validation.
The mantra is "invalid == reject" on all EBGP sessions.
What's of note here is that we're now seeing the first commercial ISPs
doing Origin Valida
On Thu, 5 Jul 2018 at 21:47, Matthew Crocker
wrote:
> I’m just getting started setting up communities for my network. Is there
> any standard convention for community numbering (*:666 for RTBH for
> example)? I’ve looked at some examples from other carriers and it looks
> like everyone does th
Dear alll,
Thank you all for your input. Just a heads-up - we deployed a few days ago.
NTT / AS 2914 now considers “2002::/16 le 128” and “192.88.99.0/24 le 32”
to be bogon prefixes, and no longer accepts announcements for these
destinations from any EBGP neighbor.
Kind regards,
Job
People - please just stop the off topic chatter. It is ludicrous that a
thread about bgp hijacks morphed into font discussions.
Either contribute to the operational issue at hand by evaluating your terms
& conditions (or abuse policies) and applying them to your operations, or
remain silent.
On Tue, Jun 26, 2018 at 09:57:14PM +0200, Radu-Adrian Feurdean wrote:
> On Tue, Jun 26, 2018, at 20:23, Job Snijders wrote:
> > I'm very happy FranceIX apply filters - however Bitcanal is known to
> > submit fabricated/falsified IRR information to databases like RADB
> &g
On Tue, 26 Jun 2018 at 12:28, Mike Hammett wrote:
> Any solution to that? Yell at the IRRs more?
Or more generally, everyone involved should consider to stop selling
services to well-known BGP hijackers.
Kind regards,
Job
Dear Simon,
On Tue, Jun 26, 2018 at 12:13:26PM -0600, Simon Muyal wrote:
> On the France-IX route servers, we are applying filters based on IRR
> DBs. I double checked the list https://pastebin.com/raw/Jw1my9Bb and
> these prefixes should be filtered if bitcanal starts announcing them.
> Currently
(I've updated the email subject to make it more accurate)
On Tue, Jun 26, 2018 at 12:18:19PM -0400, Stephen Fulton wrote:
> Unless of course they are not actually on an IXP listed.
Of course.
> Bitcanal is not a member of TorIX and as far as I recall, never has
> been. The IP they list in Peerin
On Mon, 25 Jun 2018 at 22:49, Ronald F. Guilmette
wrote:
> Without the generous support of Cogent, GTT, and Level3 this dumbass
> lowlife IP address space thief would be largely if not entirely toast.
> So what are they waiting for? Why don't their turf this jackass? Are
> they waiting for an e
Large BGP Communities are on the rise! :-)
-- Forwarded message -
From: Mirjam Kuehne
Date: Wed, 20 Jun 2018 at 07:51
Subject: [routing-wg] New on RIPE Labs: BGP Large Communities - Uptake by
the Community at Large?
To:
Dear colleagues,
In this new article on RIPE Labs we look
Dear all,
TL;DR: Perhaps it is time to add 2002::/16 to our EBGP bogon filters?
It is kind of strange that in the default-free zone (where we don’t
announce defaults to each other) - we will propagate what is effectively an
IPv4 default-route, in the IPv6 DFZ.
IETF has politely abandoned the pre
On Mon, Jun 11, 2018 at 05:01:24PM -0700, Ca By wrote:
> > I posit that the more miles a packet has to travel, the more likely
> > it is to be an IPv4 packet.
>
> Related. The more miles the traffic travels the more likely it is the
> long tail ipv4 15% of internet that is not the wales : google,
On Mon, Jun 11, 2018 at 10:03 PM, Ca By wrote:
> A similar take, is that big eyeballs (tmobile, comcast, sprint, att, verizon
> wireless) and big content (goog, fb, akamai, netflix) are ipv6. Whats left
> on ipv4 is the long tail of people asking for help on how to buy a /24
Joking aside, I susp
I suspect that this may not be an apples to apples comparison.
Perhaps lack of IPv6 is more prevalent in rural areas with poorer
connectivity to the rest of the Internet? Perhaps both these CDNs
serve content for different types of devices over the different AFIs
(maybe old mediaboxes with a slow
Hey Mike,
On Sun, Jun 10, 2018 at 8:48 PM, Mike Lyon wrote:
> Title says it all... Currently using IPPlan, but it is kinda antiquated..
This is always a good thing to review every 2-3 years or so.
My current favorites in the open source world are:
Netbox - https://github.com/digitalocean/netbo
On Thu, May 31, 2018 at 02:40:06PM +, Job Snijders wrote:
> Upon further inspection, it seems more likely that the bgp optimiser is
> in ColoAU's network. Given the scale of AS 4637, if it were deployed
> inside Telstra I'd expect more problem reports. AS 4637 may ac
On Thu, May 31, 2018 at 10:31:26AM -0400, Alain Hebert wrote:
> Thanks for the ideas and the hint. Good read.
>
> Will do.
Upon further inspection, it seems more likely that the bgp optimiser is
in ColoAU's network. Given the scale of AS 4637, if it were deployed
inside Telstra I'd expect more p
On Thu, May 31, 2018 at 09:49:47AM -0400, Alain Hebert wrote:
> Well bad news on the ColoAU front, they refused to cooperate.
>
> We'll pushback thru our GTT accounts... But I'm running out of ideas.
>
> If anyone has any good ideas how to proceed at this point feel free to
> share =D.
This fee
Dear Francois,
On Thu, May 17, 2018 at 10:14:19AM +, Francois Devienne wrote:
> The examples you mention confirm the issues are mainly due to poorly
> configured networks where routes are leaked out although they
> shouldn’t be. Adequate routers are able to filter out prefixes based
> on attri
On Tue, Apr 24, 2018 at 10:22:19PM +0200, Fredrik Korsbäck wrote:
> Id take it that 15169 accepted the prefix for some reason over a
> bilateral peering-sesssion (to the best of my knowledge the equinix
> routeservers does indeed do filter, but please correct me on this one)
> with 10297 and hence
Rod,
Please take the "Pre-Posting Guide" (https://nanog.org/list) into
consideration before diluting this mailing list with classifieds like
the one below.
Regards,
Job
On Mon, Apr 23, 2018 at 8:49 PM, Rod Beck
wrote:
> Hi,
>
>
> Please contact me off list. I have a 100 gig wave to discuss. It
Hi,
On Wed, 18 Apr 2018 at 11:39, Ryan Hamel wrote:
> I wanted to poll everyones thoughts on how to deal with attacks directly
> on BGP peering ranges (/30's, /127's).
>
> I know that sending an RTBH for our side of the upstream routing range
> does not resolve the issue, and it would actually m
Dear Jason,
On Fri, Apr 13, 2018 at 02:17:47PM -0400, Jason S. Cash wrote:
> Yes, ASN2 sees about 1-4 configuration related "rogue" announcements
> per month. What is going on right now does not appear to be a small
> misconfiguration.
>
> The only route we (University of Delaware) are annou
On Thu, 12 Apr 2018 at 11:52, Matt Harris wrote:
> On Thu, Apr 12, 2018 at 12:05 PM, wrote:
>
> > Have you tried their IRR entries? Bull appears to redirect to Atos now
> > (site-wise).
> >
> > notify: ed.gie...@atos.net
> > notify: charlie.mol...@atos.net
> > changed:christophe.fra.
On Mon, Apr 2, 2018 at 8:14 PM, Saku Ytti wrote:
> If they are for redundancy, wouldn't it be preferable to route them to
> different place to cover more fault scenarios.
>
> I would complain if they are routed to same place.
Better start complaining then :-)
Kind regards,
Job
Hi all,
I made a list of the IPv6 addresses in my home LAN, but have trouble
copy+pasting the list into a cloud spreadsheet. My address list is here:
http://pete.meerval.net/~job/
How do other folks do this? Just administrate things in text files?
Kind regards,
Job
Dear Mikael,
On Fri, Mar 30, 2018 at 12:27:52PM +0200, Mikael Abrahamsson wrote:
> I would like to bring attention to the following IETF draft:
>
> https://tools.ietf.org/html/draft-ietf-tsvwg-le-phb-04
>
> I believe this is well under way through the IETF process, and if someone
> has strong op
Silly question perhaps, but why would you do BFD on dark fiber?
Kind regards,
Job
On Tue, 20 Mar 2018 at 19:26, Ken Chase wrote:
> A reason to de-aggregate down to /24s, to make hijacks more difficult/less
> effective?
Or perhaps something less costly for everyone: a reason for HE to implement
prefix-based EBGP filters?
At any given moment there appear to be roughly 5500 pr
Dear Sean,
On Tue, Mar 13, 2018 at 10:38:49AM -0700, Sean Pedersen wrote:
> This is more or less the situation we're in. We contacted the customer
> and they informed us the matter is in dispute with the RIR and that
> their customer (the assignee) is in the process of resolving the
> issue. We ha
On Sat, 3 Mar 2018 at 01:23, Baldur Norddahl
wrote:
> So I want to buy additional ports at each IX. The slowest speed they offer.
> If I am lucky they have a free 100 Mbps. And then I just announce the
> prefix I want to blackhole. Doesn't matter that the port overloads. I am
> just going to null
On Sat, 3 Mar 2018 at 01:08, Bryan Holloway wrote:
>
> On 3/2/18 5:29 PM, Ca By wrote:
> > On Fri, Mar 2, 2018 at 2:13 PM Matthew Petach
> wrote:
> >
> >> On Tue, Feb 27, 2018 at 4:13 PM, Dan Hollis
> >> wrote:
> >>> OVH does not suprise me in the least.
> >>>
> >>> Maybe this is finally what i
On Tue, Feb 27, 2018 at 09:52:54PM +, Chip Marshall wrote:
> On 2018-02-27, Ca By sent:
> > Please do take a look at the cloudflare blog specifically as they
> > name and shame OVH and Digital Ocean for being the primary sources
> > of mega crap traffic
> >
> > https://blog.cloudflare.com/mem
Dear all,
Before the group takes on the pitchforks and torches and travels down to
the hosting providers' headquarters - let's take a step back and look at
the root of this issue: the memcached software has failed both the
Internet community and its own memcached users.
It is INSANE that memcache
You can always try whispering my name three times facing West, but
n...@ntt.net is a smoother running operation.
Kind regards,
Job
On Sun, Jan 28, 2018 at 04:02:44AM +0100, Baldur Norddahl wrote:
> The hierarchical as-set strategy has the problem that many fails to
> parse it correctly. We use it at NL-IX with the result that their
> portal believe we have no peers.
That sounds like a simple bug in that specific portal. If yo
On Sat, Jan 27, 2018 at 04:30:56PM -0500, Jared Mauch wrote:
> On Wed, Jan 24, 2018 at 02:48:58PM +0000, Job Snijders wrote:
> > --- thread hijack ---
> >
> > Coincidentally, I'm working to define something like "AS-SETs in
> > RPKI". There ar
On Wed, Jan 24, 2018 at 02:23:48PM +, Nick Hilliard wrote:
> Alain Hebert wrote:
> > Any feedback on best practices and "other avenue" about IRR naming?
>
> Known problem - you're asking for trouble unless you filter IRRDB
> queries by source:
>
> There isn't a global namespace for as-set nam
On Thu, 4 Jan 2018 at 20:13, Filip Hruska wrote:
> I have stumbled upon this site [1] which seems to offer /27 IPv4 leasing.
> They also claim "All of our IPv4 address space can be used on any network
> in any location."
>
> I thought that the smallest prefix size one could get routed globally is
Dear James,
On Tue, Jan 02, 2018 at 10:46:35PM +, James Breeden wrote:
> Before I take this to the ARIN PPML, wanted to get NANOG's thoughts.
>
> I'm amazed at the number of AS numbers that are assigned, but not
> actively being used. I'm not talking just like they are offline for a
> week or
Dear NANOG,
I'd like to share an update on some routing security activities that
ARIN, NTT Communications, YYCIX (Calgary Internet Exchange), the NLNOG
Foundation, and the arouteserver project have been collaborating on.
Quite some puzzles pieces were brought together! :)
Traditionally, there are
Some carriers view measures to improve routing security as a hinderance
rather than as a safeguard to enable business. The BGP protocol itself has
no inherent safety mechanisms, so the network operator has to ensure
adequate layers of protection are implemented on the boundary between their
own net
On Fri, Dec 8, 2017 at 10:44 PM, Ken Chase wrote:
> why not use 192.0.2.0/24 addrs?
>
> lots of other ranges you could probably use safely.
>
>https://en.wikipedia.org/wiki/Reserved_IP_addresses
>
> Using .0 you're asking to exercise bugs and undefined implimentation choices
> of various tcp s
On Fri, 8 Dec 2017 at 23:09, Christopher Morrow
wrote:
> On Fri, Dec 8, 2017 at 3:02 PM, Job Snijders wrote:
>
Nothing wrong with using xxx.0 or xxx::0 in the context of a host route
>> (/32 or /128).
>>
>
> note that in times past (perhaps even now marked historical
Nothing wrong with using xxx.0 or xxx::0 in the context of a host route
(/32 or /128).
On Wed, 6 Dec 2017 at 15:42, Mike Hammett wrote:
> I haven't brought it up with them, no. I didn't think it was a mass issue
> until last night. I wanted to check with other users before I went to them.
> Maybe I should have done the opposite.
Yes, you should’ve. The Qrator folks are good peop
On Fri, Dec 01, 2017 at 12:35:13PM -0500, Aliaksei Sheshka wrote:
> On Thu, Nov 30, 2017 at 3:07 PM, Job Snijders wrote:
> > I re-implemented the venerable 'aggregate' tool (by Joe Abley & co)
> > in python under the name of 'aggregate6'. The 'aggr
On Fri, Dec 01, 2017 at 09:09:38PM +1100, Julien Goodwin wrote:
> Will it catch cases like:
> 10.0.0.0/24 10.0.1.0/24 10.0.2.0/23 -> 10.0.0.0/22
Yes it does!
hanna:~ job$ echo 10.0.0.0/24 10.0.1.0/24 10.0.2.0/23 | aggregate6
10.0.0.0/22
hanna:~ job$
Kind regards,
Job
201 - 300 of 510 matches
Mail list logo
