Hello,
On Wed, 28 Oct 2020 at 16:58, Randy Bush wrote:
> tl;dr: diagnosed by comcast. see our short paper to be presented at imc
>tomorrow https://archive.psg.com/200927.imc-rp.pdf
>
> lesson: route origin relying party software may cause as much damage as
> it ameliorates
There
Hello,
On Tue, 2 Mar 2021 at 15:18, Pirawat WATANAPONGSE via NANOG
wrote:
> We just turned on our RPKI Route Origin Validation yesterday, then something
> weird happened:
> [Reference: We are running NLnet Labs’ Routinator 3000, feeding a
> Cisco ASR 1000 Series router. I know, I know, we haven
On Thu, 11 Mar 2021 at 18:10, Enno Rey wrote:
>
> Statement (in French) from Octave Klaba, containing some discussion of the
> development of the fire (starts at ~ 4:30):
>
> https://www.ovh.com/fr/images/sbg/index-fr.html
English:
https://www.ovh.com/fr/images/sbg/index-en.html
On Fri, 26 Mar 2021 at 20:21, William Herrin wrote:
>
> On Fri, Mar 26, 2021 at 12:14 PM Blake Hudson wrote:
> > And here I almost went as far as to suggest unnumbered IPs you're
> > plan is... well... diabolical in comparison.
>
> Hi Blake,
>
> I aim to please. I really wish the router vendo
On Fri, 26 Mar 2021 at 20:01, William Herrin wrote:
>
> On Fri, Mar 26, 2021 at 11:07 AM vom513 wrote:
> > As I said in the tl;dr - my main point of contention here is breaking up my
> > /24 I.e. use the very top /30s / /31s for ptp/loop. I would then have at
> > most the bottom /25 to use con
Hi Bill,
On Fri, 26 Mar 2021 at 22:16, William Herrin wrote:
>
> On Fri, Mar 26, 2021 at 1:42 PM Lukas Tribus wrote:
> > In production, you may be able to troubleshoot this a few months from
> > now, but how will the on-duty junior engineer handle this at 03 AM?
>
&
Hello,
On Tue, 15 Jun 2021 at 13:37, Deepak Jain wrote:
> Is this a “normal” or expected solution or just some local hackery?
It's absolutely normal and expected for a huge service like this to
keep round robin at the DNS server side. YMMV with client side DNS
based round robin (Amazon needs to
Hello,
> AWS is doing Geo-based load balancing and spitting things out,
> and networks with eyeballs are doing their own things for traffic
> management and trying to do shortest paths to things – and responsible
> operators want to minimize the non-desirable and non-deterministic
> behaviors.
Y
Hello,
there is a large eyeball ASN in Southern Europe, single homed to a Tier1
running under the same corporate umbrella, which for about a decade
suffered from periodic blackholing of specific src/dst tuples. The issue
occurred every 6 - 18 months, completely breaking specific production
traffic
Hello,
On Mon, 19 Jul 2021 at 15:04, Stephen Satchell wrote:
> The allocation of IPv6 space with prefixes shorter than /64 is indeed a
> consideration for bigger administrative domains like country
> governments, but on the other end, SOHO customers would be happy with
> /96, /104 or even /112 al
Hello,
On Mon, 26 Jul 2021 at 11:40, Mark Tinka wrote:
> I can count, on my hands, the number of RPKI-related outages that we
> have experienced, and all of them have turned out to be a
> misunderstanding of how ROA's work, either by customers or some other
> network on the Internet. The good ne
Hello!
On Mon, 26 Jul 2021 at 17:50, heasley wrote:
>
> Mon, Jul 26, 2021 at 02:20:39PM +0200, Lukas Tribus:
> > rpki-client 7.1 emits a new per VRP attribute: expires, which makes it
> > possible for RTR servers to stop considering outdated VRP's:
> > https://githu
On Tue, 27 Jul 2021 at 16:10, Mark Tinka wrote:
>
>
>
> On 7/26/21 19:04, Lukas Tribus wrote:
>
> > rpki-client can only remove outdated VRP's, if it a) actually runs and
> > b) if it successfully completes a validation cycle. It also needs to
> > do this
Hello,
On Tue, 27 Jul 2021 at 21:02, heasley wrote:
> > But I have to emphasize that all those are just examples. Unknown bugs
> > or corner cases can lead to similar behavior in "all in one" daemons
> > like Fort and Routinator. That's why specific improvements absolutely
> > do not mean we don
On Mon, 9 Aug 2021 at 17:47, Billy Croan wrote:
> Are there any big networks that drop or penalize announcements like this?
It's possible you could get your peering request denied for this. I
have put *reasonable* prefix aggregation into peering requirements for
some years now. If you are a small
On Wed, 11 Aug 2021 at 12:24, Tom Hill wrote:
>
> On 10/08/2021 07:15, Lukas Tribus wrote:
> >> Are there any big networks that drop or penalize announcements like this?
> > It's possible you could get your peering request denied for this. I
> > have put *rea
On Wed, 18 Aug 2021 at 11:33, Lars Prehn wrote:
>
> As I understand by now, it is highly recommended to set a max-prefix
> limit for peering sessions. Yet, I can hardly find any recommendations
> on how to arrive at a sensible limit.
>
> I guess for long standing peers one could just eyeball it, e
On Wed, 18 Aug 2021 at 12:03, Chriztoffer Hansen wrote:
> 'some' networks will input a value with headroom percentages already
> included.
That's what it's for.
There is no point in periodically copying the actual prefix-count into
peeringdb records, that would just be redundant data which wou
On Thu, 19 Aug 2021 at 19:21, Ryan Hamel wrote:
> Does anyone know of any US carriers that will accept more
> specific routes other than what’s required for the DFZ, like
> “le 31” or “upto /31” (junos speak)?
NTT was mentioned just a few days ago here:
https://mailman.nanog.org/pipermail/nanog/2
On Fri, 27 Aug 2021 at 18:45, Compton, Rich A wrote:
>
> Can't AfriNIC just create ROAs for the prefixes and point them to AS0?
Trying to resolve political, legal, financial, policy or other
non-technical problems with technical workarounds is a very flawed
idea. The world would be in a much bett
On Fri, 27 Aug 2021 at 19:15, Rubens Kuhl wrote:
>
> But that doesn't prevent the other RIRs issuing those since all TAs sign 0/0.
That's an extremely dangerous precedent to set. It would eradicate the
trust in the RPKI system.
How about letting this legal issue play out in court and avoid any
d
Hello,
On Wed, 8 Jan 2020 at 16:53, Octolus Development wrote:
> But here's the funny part, when connecting to their own website imperva.com
> from those IP's -- we are getting the exactly same error code that Sony are
> returning.
And what error code / full error is that *exactly*?
I assumed
Hello,
On Wed, 8 Jan 2020 at 18:26, Octolus Development wrote:
>
> The error it displays on both Sony, and Imperva (and whatever websites who
> uses their protection). So this problem is not with Sony, but rather Imperva
> blocking IP's wildly.
>
> The IP's are not blocks, it's a single IP and
Hello Mark,
On Fri, 10 Jan 2020 at 13:39, Mark Tinka wrote:
>
> So just an update on this.
>
> We've since completed the roll-out of dropping Invalids on eBGP sessions with
> customers as well.
>
> It also included some Cisco ME3600X routers that will ultimately be replaced
> this year by Cisc
Hello,
On Tue, 14 Jan 2020 at 07:21, Mark Tinka wrote:
> On 13/Jan/20 21:53, Jakob Heitz (jheitz) wrote:
> > Mark,
> >
> > Thanks for bringing this up again.
> > I remember this from nearly 3 years ago when Randy brought it up.
> > A bug was filed, but it disappeared in the woodwork.
> > I have
Hello Adam,
On Mon, 10 Feb 2020 at 13:37, wrote:
> Would like to take a poll on whether you folks tend to treat your
> transit/peering connections (BGP sessions in particular) as pets or rather as
> cattle.
Cattle every day of the week.
I don't trust control-plane resiliency and things like
Hello Baldur,
On Mon, 10 Feb 2020 at 19:57, Baldur Norddahl wrote:
> Many dual homed companies may start out with two routers and two
> transits but without dual links to each transit, as you describe
> above. That will cause significant disruption if one link goes
> down. It is not just about c
Hello,
On Thu, 20 Feb 2020 at 21:30, Daniel Sterling wrote:
> As has been continually noted, this issue goes away if you use v4 TCP or v6
> UDP.
IPv6 UDP is currently not broken, that doesn't mean v6 is the solution
to this problem. It's just means the particular ISP did not yet deploy
the sam
Hello,
On Sat, 28 Mar 2020 at 11:13, Radu-Adrian Feurdean
wrote:
>
> Are you talking about the same Free.fr that depeered HE a few days ago and
> expects all IPv6(*) traffic from HE to arrive via their only transit - Cogent
> ?
Cogent is not their only transit; at the moment at least I see bot
Telia's statement:
https://blog.teliacarrier.com/2020/07/31/bgp-hijack-of-july-30-2020/
(tl;dr: it was as-path filtering only, as opposed to prefix filtering,
the former has been removed as an option)
Hello Kevin,
On Tue, 7 Sept 2021 at 16:57, Kevin McCormick wrote:
>
> HBO did respond to contact form page on website.
>
>
> They referred us to Digital Elements.
It's IP geolocation done right, as per the white-paper [1]:
- distrusting WHOIS data
- distrusting ISP provided data
- not providin
Hello,
On Wed, 20 Oct 2021 at 13:38, Pascal Masha wrote:
>
> Apart from that, how do you all get them to quickly
> change their records especially for a block that
> you recovered from one country and moved to
> another within the same RIR region/continent?
There is no such thing as "get them al
On Thu, 21 Oct 2021 at 15:59, Sean Donelan wrote:
>
> Has anyone published "safe" geo-location defaults? By safe I mean default
> lat/lon coordinates for a country, state/province, city, postal code which
> do not resolve near a residence.
>
> It seems like too many people use "Find My " or other
Hello,
client side IPv6-only is one thing, but IPv6-only recursive DNS
resolution is probably so niche that content providers and CDN's do
not particularly care at this point in time.
On the other hand, there is probably no good reason to run
authoritative DNS servers without IPv6 connectivity.
On Wed, 27 Oct 2021 at 08:47, Mark Tinka wrote:
>
> On 10/27/21 01:58, Randy Bush wrote:
> > my old DRL RP instances produce MRTG graphs etc of the CA
> > fetching side, though nothing on the rpki-rtr side.
>
> Randy, I actually have an ongoing discussion with the Fort developers
> about this afte
Hello,
On Thu, 28 Oct 2021 at 21:35, wrote:
> Given that some routes may have mistaken ROAs that resolve to an
> invalid state, is there a standard/best practice for processing exceptions?
There is no point in ROV, unless you are dropping invalid routes.
Not dropping invalid routes is somethin
On Thu, 9 Dec 2021 at 17:39, Deepak Jain wrote:
> Google’s 14 corrupts the packet or maybe deliberately manipulates it? 1.1.1.1
> doesn’t do that.
8.8.8.8 truncates ICMP's responses, this is well known. Different
platforms will react differently to it.
lukas@dev:~$ ping 8.8.8.8 -c1 -s1000
PING
On Tue, 21 Dec 2021 at 08:11, Hank Nussbacher wrote:
> > Out of curiosity - does anyone know why Google is truncating ICMP
> > responses ?
>
> As Google has stated in many forums and I quote:
> "Google Public DNS is a Domain Name System service, not an ICMP network
> testing service."
The core is
On Mon, 17 Jan 2022 at 20:00, PAUL R BARFORD wrote:
> What we're curious about is why we're seeing a concentration of hops at a
> small number of routers that appear on international paths.
I suggest you share a few actual examples (IP addresses, traceroutes).
I don't think discussing your conc
Hello,
On Tue, 8 Feb 2022 at 18:56, Mike Hammett wrote:
>
> Yes, pinging public DNS servers is bad.
>
> Googling didn't help me find anything.
>
> Are there any authoritative resources from said organizations saying you
> shouldn't use their servers for your persistent ping destinations?
This w
Hello,
I suggest the mailops [1] list for this. Proofpoint personnel are present there.
lukas
[1] https://list.mailop.org/listinfo/mailop
On Wed, 11 May 2022 at 21:22, Grant Taylor via NANOG wrote:
>
> On 5/11/22 10:53 AM, Job Snijders via NANOG wrote:
> > This knob slightly increase your own memory consumption, but makes your
> > router more “neighbourly”! :-)
>
> I question how accurate "slightly" is.
>
> My understanding is that
On Mon, 25 Jul 2022 at 17:19, Brian Turnbow via NANOG wrote:
>
> Hi,
>
> >I do understand the reasoning behind preferring customer routes. However
> >in the case where a customer of a customer also connects to you directly via
> >peering doesn't it make sense to prefer the direct connection?
On Mon, 25 Jul 2022 at 16:23, Forrest Christian (List Account)
wrote:
>
> I do understand the reasoning behind preferring customer routes.
> However in the case where a customer of a customer also
> connects to you directly via peering doesn't it make sense to prefer
> the direct connection? or a
user?
If not, what is the actual benefit of this change, other than the 487
byte download of the TAL file not being necessary any more?
Which issues of the 2019 paper "Lowering Legal Barriers to RPKI
Adoption" [3] in your opinion does this change address?
Thank you,
Lu
On Fri, 11 Nov 2022 at 14:00, Christopher Morrow
wrote:
> Also, also, possibly the output path on the session(s) here is not
> filtering in an OV fashion.
ROV belongs on the input path, let's not ROV on the output towards
customers / route collectors.
Announcing bigger, ROV valid/unkown aggregat
Hello,
On Wed, 28 Dec 2022 at 17:41, Mike Hammett wrote:
>
> Does AS15169 have a speed test?
Stadia speedtest is still up today:
https://stadia.google.com/speedtest
Lukas
Hello,
so 100.64/10 is used in CGNAT deployments requiring service providers
(that is AS operators) to drop 100.64/10 on the border to other AS in
BGP and in the dataplane, as per RFC6598 section #6 Security
Considerations [1].
Within an AS though traffic from 100.64/10 can very well bypass CGNA
On Wed, 8 Mar 2023 at 00:05, William Herrin wrote:
> Hi Lukas,
>
> If you're using the team cymru bogon list at your customer border,
> you're doing it wrong.
I'm not.
I'm trying to educate people that bogon lists do not belong on hosts,
firewalls or intermediate routers, despite Team-cymru's ag
Hello,
> It is just that, marketing.
I disagree, authoritative and accurate product description and
documentation of the tools used by the public matter a lot. If a
ticket lands on my desk because a third party misuses a tool, I want
to point to a single authoritative source of information.
>
>> They talk about bogon prefixes "for hosts", provide configuration
>> examples for Cisco ASA firewalls,
>
> Which are perfectly valid use cases for some networks / situations.
Absolutely, everybody's free to drop whatever they like on their gear,
I'm sure there are networks, gear, applied and do
> You'll have to connect the dots for me here, I'm not seeing the
> problem. The ISP's local network is not "the public Internet."
It very much is.
An autonomous system can contain both "eyeballs" (possibly RFC6598
adressed) and services in datacenters/clouds, it's not *always* a
different ISP.
> The think that you have to remember to do is to exclude locally
> significant (100.64/10, RFC 1918, et al.) from those filters /or/
> account for them in another way.
You know all this if you are the network operator.
If you are the customer of the ISP, let's say a datacenter/cloud
customer and
Hello,
without PTRs you will probably get your prefixes listed in things like
Spamhouse PBL. So adding the correct PTR for a mailserver may not be
enough, as services like that love to classify entire IP blocks. Of
course Spamhaus provides the tools to fix this issue. But what if
there are 4 - 5
On Tue, 16 May 2023 at 05:38, Willy Manga wrote:
>
> Hi,
>
> DNS speaking, I can query G root servers; at least, that's the most
> important.
>
> However, from several sites, either on IPv4 or IPv6, I cannot ping(6)
> them. Is it by design, or it's an issue?
It's certainly not an outage:
https:/
On Fri, 1 Sept 2023 at 15:55, Saku Ytti wrote:
>
> On Fri, 1 Sept 2023 at 16:46, Mark Tinka wrote:
>
> > Yes, this was our conclusion as well after moving our core to PTX1000/10001.
>
> Personally I would recommend turning off LSR payload heuristics,
> because there is no accurate way for LSR to
Hello!
On Tue, Oct 15, 2019 at 12:46 PM Saku Ytti wrote:
>
> On Mon, 14 Oct 2019 at 09:30, Vincent Bernat wrote:
>
> > How much performance impact should we expect with uRPF?
>
> Depends on the platform, but often it's 2nd lookup. So potentially 50%
> decrease in performance. Some platforms it m
Hello,
On Fri, Oct 18, 2019 at 7:40 PM Saku Ytti wrote:
> It's interesting to also think, when is good time to break things.
>
> CustomerA buys transit from ProviderB and ProviderA
>
> CustomerA gets new prefix, but does not appropriately register it.
>
> ProviderB doesn't filter anything, so it
Hello,
> > Is this deployed like this in a production transit network? How does
> > this network handle a failure like in example 2? How does it
> > downstream customers handle the race conditions like in example 1?
>
> Yes, I've ran BGP prefix-list == firewall filter (same prefix-list
> verbatim
Hello,
On Wed, Nov 13, 2019 at 8:35 PM Saku Ytti wrote:
>
> On Wed, 13 Nov 2019 at 18:27, Matt Corallo wrote:
>
> > This sounds like a bug on Cloudflare’s end (cause trying to do anycast TCP
> > is... out of spec to say the least), not a bug in ECN/ECMP.
>
> Not true. Hash result should indicat
On Fri, 17 Nov 2023 at 15:17, Jamie Chetta via NANOG wrote:
>
> I am out of ideas on how to get this fixed. Long story short I am a customer
> of Comcast and am advertising my own /24 block I own through them. Comcast
> of course BGP peers with multiple ISPs. Other ISPs are accepting my prefi
On Mon, 20 Nov 2023 at 20:08, Rubens Kuhl wrote:
>
> You can get IRR from RADB or AltDB.
Which is not going to be useful forever ... see [1]:
> Please note that 'route' and 'route6' objects created after 2023-Aug-15
> in non-authoritative registries like RADB, NTTCOM, ALTDB won't be
> processed.
Hello,
On Fri, 17 Jan 2025 at 19:13, Brandon Martin wrote:
>
> Does anyone know of a good way to simulate oddball TCP happenings like:
>
> * Out of order delivery
> * Variable delivery delays
I would suggest to take a look at linux tc-netem
> * (Especially) Unusual segmentation e.g. splitting
63 matches
Mail list logo
