I’ve never heard of 123
I’ve used Cogent for several years now…
Price was good
10 gig link… for a few years
20 gig (2) 10 gigs lagged… for a year or so…
100 gig link for past few months…
The support is quick and easy to deal with.
DDOS RTBH is nice quick and easy (but different
NANOG,
We've performed the first announcement in this experiment yesterday,
and, despite the announcement being compliant with BGP standards, FRR
routers reset their sessions upon receiving it. Upon notice of the
problem, we halted the experiments. The FRR developers confirmed that
this issue is
* 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/d/1U42-HCi3RzXkqVxd8e2yLdK9okFZl77tWZv13EsEzO0/htmlview
After seeing this initial result I'm won
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/d/1U42-HCi3RzXkqVxd8e2yLdK9okFZl77tWZv13EsEzO0/htmlview
>
>
Dear all,
After reading the report, I agree with Job it was well written and a must-read
for everyone with an interest in RPKI, even outside the ARIN region. Well done!
As RIPE NCC is maintaining validator software, I would like to comment on point
2:
> 2. Developers of RPKI validation so
Hi Niels, we did run the experiment in a controlled environment with
different versions of Cisco, BIRD, and Quagga routers and observed no
issues. We did add FRR to the test suite yesterday for future tests.
On Tue, Jan 8, 2019 at 11:49 AM wrote:
>
> * cu...@dcc.ufmg.br (Italo Cunha) [Tue 08 Jan
Hey,
> After seeing this initial result I'm wondering why the researchers
> couldn't set up their own sandbox first before breaking code on the
> internet. I believe FRR is a free download and comes with GNU autoconf.
We probably should avoid anything which might demotivate future good
guys from
On Tue, 08 Jan 2019 17:48:46 +0100, niels=na...@bakker.net said:
> After seeing this initial result I'm wondering why the researchers
> couldn't set up their own sandbox first before breaking code on the
> internet. I believe FRR is a free download and comes with GNU autoconf.
Perhaps you'd li
niels=na...@bakker.net wrote on 08/01/2019 16:48:
After seeing this initial result I'm wondering why the researchers
couldn't set up their own sandbox first before breaking code on the
internet. I believe FRR is a free download and comes with GNU autoconf.
the researchers didn't break code -
* thomasam...@gmail.com (Tom Ammon) [Tue 08 Jan 2019, 17:59 CET]:
There are a fair number of open source BGP implementations now. It
would require additional effort to test all of them.
In the real world, doing the correct thing is often harder than doing
an incorrect thing, yes.
--
* valdis.kletni...@vt.edu (valdis.kletni...@vt.edu) [Tue 08 Jan 2019, 18:06
CET]:
(Personally, I'd never heard of FRR before)
Martin Winter of OSR/FRR has attended many a NANOG, RIPE and other
industry meetings, so it's not for their lack of trying
-- Niels.
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 Jan 8, 2019, at 12:06 PM, valdis.kletni...@vt.edu wrote:
>
> On Tue, 08 Jan 2019 17:48:46 +0100, niels=na...@bakker.net said:
>
>> After seeing this initial result I'm wondering why the researchers
>> couldn't set up their own sandbox first before breaking code on the
>> internet. I be
Hi Saku,
After seeing this initial result I'm wondering why the researchers
couldn't set up their own sandbox first before breaking code on the
internet. I believe FRR is a free download and comes with GNU autoconf.
We probably should avoid anything which might demotivate future good
guys fr
> On Jan 8, 2019, at 12:10 PM, niels=na...@bakker.net wrote:
>
> * thomasam...@gmail.com (Tom Ammon) [Tue 08 Jan 2019, 17:59 CET]:
>> There are a fair number of open source BGP implementations now. It would
>> require additional effort to test all of them.
>
> In the real world, doing the cor
8 Jan. 2019 г., 20:19 :
> In the real world, doing the correct thing
— such as writing RFC compliant code —
> is often harder than doing
> an incorrect thing, yes.
Evidently, yes.
>
There is no such thing as a fully RFC compliant BGP :
https://www.juniper.net/documentation/en_US/junos/topics/reference/standards/bgp.html
does not list 7606
Cisco Bug: CSCvf06327 - Error Handling for RFC 7606 not implemented for NXOS
This is as of today and a 2 second google search.. anyone
> 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 cool.
randy
On 1/8/19 9:31 AM, Töma Gavrichenkov wrote:
> 8 Jan. 2019 г., 20:19 :
>> In the real world, doing the correct thing
>
> — such as writing RFC compliant code —
>
>> is often harder than doing
>> an incorrect thing, yes.
>
> Evidently, yes.
I "grew up" during the early days of PPP. As a member o
> Steve Noble
> Sent: Tuesday, January 8, 2019 6:42 PM
>
> There is no such thing as a fully RFC compliant BGP :
>
Which RFC do you mean 6286, 6608, 6793, 7606, 7607, 7705 or 8212 when you say
fully RFC compliant BGP please?
> https://www.juniper.net/documentation/en_US/junos/topics/reference/s
FRR is undergoing a fairly rapid pace of development, thanks to the
cloud-scale operators and hosting providers which are using it in
production.
https://cumulusnetworks.com/blog/welcoming-frrouting-to-the-linux-foundation/
On Tue, Jan 8, 2019 at 11:55 AM Randy Bush wrote:
> > We plan to resume
>>> 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 cool.
>
> FRR is undergoing a fairly rapid pace of developm
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
* Job Snijders
> Given the severity of the bug, there is a strong incentive for people to
> upgrade ASAP.
The buggy code path can also be disabled without upgrading, by building
FRR with the --disable-bgp-vnc configure option, as I understand it.
I've been told that this is the default in Cumul
24 matches
Mail list logo
