Hi All,
On Wed, Jun 08, 2016 at 08:48:11AM -0400, Joe Provo wrote:
> On Wed, Jun 08, 2016 at 11:48:36AM +, Sriram, Kotikalapudi (Fed) wrote:
> > Thanks for the inputs about the inter-AS messaging and route-leak
> > prevention techniques between neighboring ASes. Certainly helpful
> > informati
On Thu, Jun 16, 2016 at 03:52:02PM +0200, Nurani Nimpuno wrote:
> A growing exchange point is not only a "nice-to-have" for those
> operating it, but vital to those networks who peer there. If you stop
> adding value to those networks peering at the IX, you will slowly
> become irrelevant.
I view
On Tue, Jun 21, 2016 at 06:13:10PM -0400, Christopher Morrow wrote:
> "the internet is on fire"
>
> not as helpful a troublereport as one might want.
>
> please provide at least (so everyone else can verify/help/troubleshoot):
> 1) from location X
> 2) site Y with protocol Z (which resolves t
Hi Philip,
I can't address your immediate concern, but I do have some hints
regarding traceroute:
1/ Please review the excellent presentation from RA{T,S}:
https://www.nanog.org/meetings/nanog47/presentations/Sunday/RAS_Traceroute_N47_Sun.pdf
https://www.youtube.com/watch?v=a1IaRAVGPEE
On Mon, Aug 15, 2016 at 10:40:40AM +0200, Randy Bush wrote:
> my poor memory says that, some years back, someone announced or
> mentioned an open tool which i, a small isp, could feed my netflow data
> and bgp and ask if i should peer with X or build out or ...
>
> anyone with a more precise memor
Dear nanog,
I'm asking the group to stay focussed on network operator topics.
While I appreciate the time and effort spend on the original legal
research in this thread, I fear the problem space of what defines libel
or slander is too far removed from the mailing list charter as described
here: h
On Mon, Sep 26, 2016 at 08:52:20AM -0400, Adam Greene wrote:
> We were alerted to this by https://radar.qrator.net.
>
> This seems wrong from a number of angles .
Maybe the alerting system was confused. I don't see this confirmed in
RIPE RIS: https://stat.ripe.net/AS4233852001#tabId=routing
Ther
On Fri, Oct 07, 2016 at 10:28:10AM +0100, Martin List-Petersen wrote:
> On 06/10/16 16:38, Sandra Murphy wrote:
> > Private reply:
> >
> > bgp.he.net sees it. For me.
> >
> > http://bgp.he.net/net/93.175.240.0/20
> >
> > I don’t know why they do and you do not.
>
> That just means, they "have"
Dear all,
Large BGP Communities are a novel way to signal information between
networks. An example of a Large BGP Communities is: 2914:4056024901:80.
Large BGP Communities are composed of three 4-octet integers, separated
by something like a colon. This is easy to remember and accommodates
advanc
Hi Eric,
On Wed, Oct 12, 2016 at 06:43:18PM -0400, Eric Tykwinski wrote:
> IPv4 routes did a quick bounce to 600,949 around 9:30AM EST, than went
> back down to 599,241 shortly after. Seemed like a big jump so I setup
> an alert, just wondering if anyone else noticed anything, I’m not
> overly co
:56PM +0200, Job Snijders wrote:
> Large BGP Communities are a novel way to signal information between
> networks. An example of a Large BGP Communities is: 2914:4056024901:80.
>
> Large BGP Communities are composed of three 4-octet integers, separated
> by something like a colon. This
Hi all,
Please consider our Mail List Charter and Policy: http://nanog.org/list
The NANOG mailing list is established to provide a forum for the
exchange of technical information and the discussion of specific
implementation issues that require cooperation among network service
providers.
In ord
Hi Erich, everyone,
On Sat, Nov 19, 2016 at 02:02:15PM -0600, Kaiser, Erich wrote:
> Anyone out there from PeeringDB, please contact me offlist, we are
> having trouble updating our records.
You can reach PeeringDB support at supp...@peeringdb.com. Feel free to
CC me.
Kind regards,
Job
On Sun, Nov 20, 2016 at 12:19:35PM -0800, Scott Weeks wrote:
> --- Begin forwarded message:
>
> Hi Ladies and Gentlemen,
>
> .
> Contact me for further details.
> -
>
> Did anyone get this? I hesitate to think a long time NANOG
> parti
On Fri, Dec 02, 2016 at 09:00:57AM +, Nick Hilliard wrote:
> Eric Germann wrote:
> > Basically trying to advertise 4 byte ASN’s + communities, and then
> > pick them off elsewhere in a private network. Can’t get the config
> > right for the route map to import them on the “receiving” side.
>
Hi all,
Ever since the IEEE started allocating OUIs (MAC address ranges) in a
randomly distributed fashion rather then sequentially, the operator
community has suffered enormously.
Time after time issues pop up related to MAC addresses that start with a
4 or a 6. I believe IEEE changed their stra
On Fri, Dec 02, 2016 at 09:13:25AM -0800, Eric Germann wrote:
> So from reading the draft, if I’m understanding it correctly, I should
> be able (with the patch) to encode the 32 bit ASN + a community in to
> this as
>
> as32:x:y
>
> Is that correct?
yes.
I recommend you take a look at
https:/
On Fri, Dec 02, 2016 at 09:32:37AM -0800, Leo Bicknell wrote:
> I also do not think this is an IEEE/MAC assignement problem. This is a
> vendor's box can't forward a particular payload problem.
On Fri, Dec 02, 2016 at 04:59:37PM +, Nick Hilliard wrote:
> Job Snijders w
re combinations, but we didn't iterate through all
possibilities.
Big thank you to Richard van Looijen (Flowmailer) for finding this
issue, Edwin Kalle (2hip) for pointing us at this thread, and Job
Snijders, his email which prompted us to investigate the intermediate
switches.
Kind regards,
Robert
Dear Alexandru,
> > > MACs that didnt make it through the switch when running 4.12.3.1:
> > >
> > > 4*:**:**:**:**:**
> > > 6*:**:**:**:**:**
> > > *4:**:**:**:**:**
> > > *6:**:**:**:**:**
> > > **:**:*B:**:6*:**
> > > **:**:*F:**:4*:**
> >
> > Can anyone explain the last
Hi Andrew,
On Thu, Dec 15, 2016 at 01:54:34PM -0500, Andrew Imeson wrote:
> Is it acceptable to prepend using another networks ASN as long as your
> ASN is the last one in the path? I can think of a few scenarios where
> this is helpful.
Your milage may vary. You risk introducing breakage instead
On Tue, Dec 20, 2016 at 02:15:31PM +, Rivera, Alberto wrote:
> I am searching for NTT Taipei 3 data center address. Do you have it by
> any chance?
I'll ping you off-list.
Kind regards,
Job
On Tue, Jan 10, 2017 at 03:51:04AM +0100, Baldur Norddahl wrote:
> If a transit link goes, for example because we had to reboot a router,
> traffic is supposed to reroute to the remaining transit links.
> Internally our network handles this fairly fast for egress traffic.
>
> However the problem is
On Mon, Jan 16, 2017 at 10:01:00PM +, Alistair Mackenzie wrote:
> So recently I've come across an issue with a large ISP announcing a
> /22 and /25 of IPv6 space. We are currently filtering <28 and >48
> which until now has worked fine for us.
>
> What are others using as their prefix filters
This is a clear case of broken mirroring. Unfortunately this is not immediately
apparent (for the operator) through the IRRd software. Usually this is resolved
by directly contacting the other side.
I've found RADB support staff to be responsive and courteous.
radb-supp...@merit.edu (mailto:rad
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
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
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 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
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 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
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
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
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
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,
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
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
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
(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
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
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
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
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.
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
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
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 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
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: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 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 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 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 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
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 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
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 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
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 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
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
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
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
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
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.
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
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
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 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
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 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 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 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 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
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 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 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 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
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
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
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
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
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
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
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/
Let’s please stay on topic.
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
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
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
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
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 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
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 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
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
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/
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
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 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 14:49 Mark Tinka wrote:
> On 16/Jan/19 11:38, Christoffer Hansen wrote:
>
> > Do you use AS0 as origin on the RPKI objects for said exchange point
> > LAN(s) to prevent route propagation?
>
> I don't operate any exchange points anymore, but I am not aware of any
> such ope
On Wed, Jan 16, 2019 at 15:24 Randy Bush wrote:
> > Do you use AS0 as origin on the RPKI objects for said exchange point
> > LAN(s) to prevent route propagation?
>
> but as0 does not exactly do that as it can be overridden by a different
> roa for the same prefix. as0 is pretty useless.
Why wo
101 - 200 of 518 matches
Mail list logo
