2026-05-24T07:59:02Z https://yabu.me kasperd https://yabu.me/npub1jhpgfu25y30c3h9xrrlxhrhge7669h3xwphjs99nau4k66ctsnyqjxut5y https://static.westergaard.social/pleroma/c778a2fa-b3e2-4cc9-a8bd-ce771c3ea4e4/kasperd.png https://static.westergaard.social/pleroma/c778a2fa-b3e2-4cc9-a8bd-ce771c3ea4e4/kasperd.png https://yabu.me/nevent1qqsgqtv6seha636f7e287u88jkgtqajx6szkn4rfhdezs70a6zwlenqzyz2u9p832sj9lzxu5cv0u6uwar8mtgk7yecx72q5k0hjkmttpwzvsv0h92n In reply to <a href='/nevent1qqstaefhpy8v59zs3lhkt8wamyufx6nal26rn9jnd7sv3ht6e6p02qsjfyzuz'>nevent1q…yzuz</a><br/>_________________________<br/><br/>Do you really need .exe if you already have .com? 2026-04-22T18:47:25Z https://yabu.me/nevent1qqszx8d22j4xcjx5n2z2w0g662ta2ruf0mfnn22ps5q3rkvk3xhxz5czyz2u9p832sj9lzxu5cv0u6uwar8mtgk7yecx72q5k0hjkmttpwzvskv4p23 In reply to <a href='/nevent1qqsg5ztqaghfn5m63e8hc2c0t6dnyhg2w0v5637hjs5dlefgfzd8jsgc4gysx'>nevent1q…gysx</a><br/>_________________________<br/><br/>Client side failover is a necessity if you want reliability. Even when IPv4 is long gone, I predict the failover code is here to stay. The failover code may even get a little bit more sophisticated.<br/><br/>If we want to minimize client side complexity during the transition, then DNS64 is the way to go. Dual-stack and 464xlat both add complexity on the client side, which you can avoid when using DNS64.<br/><br/>I agree transition technologies should not stay forever. Had people been upgrading in due time, we would never have needed DNS64 and NAT64 in the first place. 2026-04-19T11:52:11Z https://yabu.me/nevent1qqsywx2uwefu8w085ghh789q8jvmwtrgrm8gj6u9du6fa609upyujqqzyz2u9p832sj9lzxu5cv0u6uwar8mtgk7yecx72q5k0hjkmttpwzvs9gndl8 In reply to <a href='/nevent1qqsp4kruugt5r4c7kjqd9kfqpqrqgmw9qnn35puqxaapfaxypsd0gpgl5p20a'>nevent1q…p20a</a><br/>_________________________<br/><br/>I assume you never operated a public NAT64 service. There are networks between the NAT64 gateway and the client which are completely outside of my control. But I can achieve high availability by running multiple NAT64 gateways in independent locations.<br/><br/>I have health checks of the gateways which automatically updates DNS64 accordingly. And I give clients addresses using multiple prefixes to allow for client-side failover. Client-side failover is crucial as sometimes individual clients are unable to reach specific gateways for reasons that are on networks that I don&#39;t use myself and thus outside the visibility of my health checks.<br/><br/>A client with a good implementation of fallback between AAAA records works great in this scenario. 464-xlat doesn&#39;t handle this as well. 2026-04-19T09:32:25Z https://yabu.me/nevent1qqsyagtksj774rr82uw8mykrqk9wcg74xwxg9wxcmdpyp8sslhmytngzyz2u9p832sj9lzxu5cv0u6uwar8mtgk7yecx72q5k0hjkmttpwzvsf6yclg In reply to <a href='/nevent1qqsyhy4r44u5cu68n2x6r528zx5epmzc7qpq8j7agmdg7gxkvsmsmncne9kxe'>nevent1q…9kxe</a><br/>_________________________<br/><br/>Yeah, ipv4only.arpa exists on authoritative DNS servers and is served essentially like a name would have been served from any other TLD. As far as I recall there is an RFC recommending that DNS recursors hard-code that particular name in order to not need depend on authoritative DNS for that name. But last I checked BIND 9 would query authoritative servers for the name.<br/><br/>DNS64 can work just fine without special casing ipv4only.arpa. It can just translate it like any other IPv4-only domain name, and clients can use that for discovery.<br/><br/>I can definitely confirm that Android supports ipv4only.arpa for NAT64 discovery by default. It might support other methods as well, and I haven&#39;t verified which order it will try the methods on a network that supports different methods. None of the NAT64 deployments I have personally encountered used the well-known prefix. So I think falling back to the well-known prefix isn&#39;t a great option.<br/><br/>As an operator of public NAT64 gateways I will say that using ipv4only.arpa for NAT64 discovery is not perfect, but all the alternatives I have seen are worse. An inherent drawback of ipv4only.arpa is that it cannot handle scenarios where different NAT64 prefixes are being used depending on IPv4 range. That part is supported when DNS64 is being used.<br/><br/>Another drawback is more of an implementation shortcoming. 464-xlat implementations usually don&#39;t support use of multiple NAT64 prefixes for redundancy and will rather just pick one and stick with it. And it&#39;s not guaranteed that a client will pick up changes of prefix in a timely fashion.<br/><br/>So if a NAT64 gateway goes down for maintenance it may be necessary for 464-xlat users to disconnect and reconnect in order to switch to a different prefix. Use of PREF64 is worse for that use case. Users actually have to change their router configuration in order to apply the changes. There appears to exist no standardized mechanism for a public NAT64 service to communicate prefix changes to routers of users.<br/><br/>In theory a router could make use of ipv4only.arpa to do NAT64 prefix discovery and communicate this downstream using PREF64. But I haven&#39;t heard of any implementation doing this, and I don&#39;t see any advantage of this over the client doing discovery directly using ipv4only.arpa. 2026-04-18T23:58:32Z https://yabu.me/nevent1qqsyawgwvsm3y2f6k2x2tdheh5a8spajuwhzvx8lrzhjgd4z44dpz7czyz2u9p832sj9lzxu5cv0u6uwar8mtgk7yecx72q5k0hjkmttpwzvsa5hwhn In reply to <a href='/nevent1qqs0uwethjs9gwx002p4dzw3ma43zv4g5kxd687n6mdz2vj7n440rtgmu3e4x'>nevent1q…3e4x</a><br/>_________________________<br/><br/>Problem is you can only do that if you have dual-stack on your own network. Some of us have IPv6-only networks. 2026-04-04T13:08:38Z https://yabu.me/nevent1qqszyhhf8s8ns9734vc86v8tpyrv2ctpzgaxr93ytngnav3xyjcuf0szyz2u9p832sj9lzxu5cv0u6uwar8mtgk7yecx72q5k0hjkmttpwzvs6t4t9m In reply to <a href='/nevent1qqst2ef2lcmfzwh95ue87l9gt5p0qn8yg36d9szr656d4hxvajmedzsc7ds06'>nevent1q…ds06</a><br/>_________________________<br/><br/>I see. Those are following the /64 mappings in RFC 6052. This is not exactly the purpose that RFC 6052 is intended for. And you already identified the scalability challenges of that approach.<br/><br/>I am guessing they use duplicate-address-detection to ensure two machines don&#39;t pick the same address. if that guess is correct you can easily verify what happens. Just make have a machine use all of the addresses ending in c0:0:0:0 ti c0:0:700:0 before the test machine connects to the network.<br/><br/>If the implementation is even just a little bit sensible it will see that its preferred IPv6 addresses are already in use and pick a random IPv6 address instead. It can still use any address in the 192.0.0.0/29 range locally. 2026-04-02T22:05:43Z https://yabu.me/nevent1qqs2v2ppr9mcft5upfe39qfz3rjcc25e37ea7q8vhrc0v49hc7s23tgzyz2u9p832sj9lzxu5cv0u6uwar8mtgk7yecx72q5k0hjkmttpwzvszf97t7 In reply to <a href='/nevent1qqsvymmdhet4mjqg0qf50q4apec7ajz68zguk0842yj07zduf96l9zqdaxy25'>nevent1q…xy25</a><br/>_________________________<br/><br/>Why would the scope of 192.0.0.2/29 expand beyond the individual host? 2026-04-02T18:39:14Z https://yabu.me/nevent1qqsg7avdwyafwue5ufjamj8ul03hql3ajfhhajrzvmtp046g7y2492gzyz2u9p832sj9lzxu5cv0u6uwar8mtgk7yecx72q5k0hjkmttpwzvsasl4za In reply to <a href='/nevent1qqspluqd673q8f287lxu699xu5smzzr4k640j2n0tarjma0vep5lc2s0mek86'>nevent1q…ek86</a><br/>_________________________<br/><br/>Something is very messed up with the rendering of that page.<br/> <img src="https://static.westergaard.social/pleroma/a7fbd107735b577dd9f5693593d562bc698dedb741f5bea53db935c5fbda39a4.png"> <br/> 2025-11-06T07:46:09Z https://yabu.me/nevent1qqs2kh5csk70y2sfw3x9pkv265v4ae8hn9x2cpx89ftwmwpw5n3rn3qzyz2u9p832sj9lzxu5cv0u6uwar8mtgk7yecx72q5k0hjkmttpwzvs0pwu2a In reply to <a href='/nevent1qqsy2yr85sdn6surljl7c9u7v2axdva2dv3umwv7jzfpnwtzslx9zzguq3lh3'>nevent1q…3lh3</a><br/>_________________________<br/><br/>Did they deliver a working product, and is the product what was agreed upon? 2025-05-25T15:39:56Z https://yabu.me/nevent1qqs0ltdqcz7mecvltnsm0a0tq9nsl43456sc9nn2d9qkh857plv58hczyz2u9p832sj9lzxu5cv0u6uwar8mtgk7yecx72q5k0hjkmttpwzvs8y6hw2 In reply to <a href='/nevent1qqsf5xfv9wsvalxsw7u8mqdhr06n0a2fhm0yd6hdmqvkdyqsakfw0mcyuv27w'>nevent1q…v27w</a><br/>_________________________<br/><br/>Will reducing the client MTU actually solve this problem in general?<br/><br/>I guess what happens when you do that is that the client knowing this lower MTU will advertise a smaller MSS so the server sends packets which are small enough to fit in the tunnel.<br/><br/>However I can think of a couple of scenarios where that would not help. If the protocol being used isn&#39;t TCP, but rather some other protocols such as one based on UDP, then you don&#39;t get the MSS negotiation. An application layer negotiation could help if the application layer protocol supports that. But then the applicaiton protocol also have to keep UDP payloads small enough, it couldn&#39;t take advantage of IP fragmentation since the IP layer is not going to know about the negotiated size.<br/><br/>Another scenario which won&#39;t work is if the client side is more than a single node. For example we have the need for clients to run a virtual network segment for Docker which communicates through a VPN connection. In that scenario the MSS sent by the client would be based on the Docker network and not the VPN tunnel. So the client will advertise an MSS of 1440, because that fits on the Docker network. The server will support that as well. Neither side knows about the VPN in advance, so PMTU discovery will need to work.<br/><br/>I think what&#39;s supposed to happen is that when the server sends a packet which won&#39;t fit in the PPPoE connection a packet-too-big error is returned to the server. And then WireGuard would need to take that into account for future packets. But if a misconfigured network drops the packet-too-big error messages, then that won&#39;t work. 2025-04-27T07:37:49Z https://yabu.me/nevent1qqswvghwx0dn60x4q2s7yqgmg3rhhm4c2hu4375qj47kmd0jcdn0ssczyz2u9p832sj9lzxu5cv0u6uwar8mtgk7yecx72q5k0hjkmttpwzvs79rvuh In reply to <a href='/nevent1qqsfyc9gy5paptxmv4x2zqkvgf9a6mn6623tk8uhch0tgt4lveugjns6t8pmt'>nevent1q…8pmt</a><br/>_________________________<br/><br/>What&#39;s the reason a few more weeks is enough? 2025-04-01T16:31:38Z https://yabu.me/nevent1qqsgpyrjfunh9he3kvn0aujfpuw96n6klf86lhhultfz8lljzk5wn8czyz2u9p832sj9lzxu5cv0u6uwar8mtgk7yecx72q5k0hjkmttpwzvscyqq6v In reply to <a href='/nevent1qqsx7cr9kdp09x5ak2ntzwknt5h3xf4ffdr72m4ueqrz2w2wrq0m2ksvkvpl7'>nevent1q…vpl7</a><br/>_________________________<br/><br/>IPv6 first is what everyone should be doing. I have a frontend on `116.202.1.213` that can be used to reach IPv6-only services by simply adding an A record. Works for all protocols using TLS-SNI and also works for HTTP and SMTP. 2025-03-20T19:18:47Z https://yabu.me/nevent1qqsy09tm5wjvxtvezw7ahhec6d5243utr38jprdpf9re60fz6vpzxtczyz2u9p832sj9lzxu5cv0u6uwar8mtgk7yecx72q5k0hjkmttpwzvs8vclcg In reply to <a href='/nevent1qqszkz6v09cyyygwwuq29lrs7qmskvjz39nwetejwt7cqqt6xhtpczqnqukhl'>nevent1q…ukhl</a><br/>_________________________<br/><br/>Your connection should include a static IPv4 address as well that you can use to connect to your home from the legacy networks on those hotels.<br/><br/>If you choose to run your home network as IPv6-only, then that&#39;s absolutely a choice I can respect. But as you realized it does come with some challenges. I am running a couple of public services to help anyone running IPv6-only, since I want to see more IPv6-only networks. 2025-03-20T19:06:41Z https://yabu.me/nevent1qqsrq5mkvfqtqa90ksxq4d2ys34zkz45llrvcjyy99p8t229gmwhcmczyz2u9p832sj9lzxu5cv0u6uwar8mtgk7yecx72q5k0hjkmttpwzvs2k7790 In reply to <a href='/nevent1qqst9pg7v5tknn56kvx0z35qt8nq9tqkvslqtjt3ry805x8s84svatca2wx95'>nevent1q…wx95</a><br/>_________________________<br/><br/>Does this indicate a weakness in LastPass? Or is it simply a matter of users having used a weak master password which is vulnerable to brute force? How much entropy does a master password for a password manager need in order to resist such attacks? 2025-03-07T17:04:03Z https://yabu.me/nevent1qqszzwjzc5rs0xj0e93swj0e7w545qgherem62cx8re5h90wfj04eyqzyz2u9p832sj9lzxu5cv0u6uwar8mtgk7yecx72q5k0hjkmttpwzvsvnry02 In reply to <a href='/nevent1qqst9883culmen9rrhr28dgfdw44rkxprvlf4xqylwrljmtrgv4pz3cwzgvp7'>nevent1q…gvp7</a><br/>_________________________<br/><br/>It looks better than modern desktops. 2025-03-05T20:39:10Z https://yabu.me/nevent1qqs8zf8rnayvscwwqnru2n674k0yw7x247s3ka6w0rzsuxm85q67l6szyz2u9p832sj9lzxu5cv0u6uwar8mtgk7yecx72q5k0hjkmttpwzvsdzexmv In reply to <a href='/nevent1qqs0acky26qvey8rcj7n4f3n28dzpwk6nkxxta8m2w84cwg4ktvp08cq2wljt'>nevent1q…wljt</a><br/>_________________________<br/><br/>The rationale was that spammers are lazy and don&#39;t implement the retry logic whereas legitimate senders will retry properly and the mail will get through once the greylisting period ends.<br/><br/>It would usually affect all senders equally (in principle a spamines score could be computed and used to adjust the greylisting period). However it will usually only affect the first mail from each sender. So people you communicate with repeatedly can email you without that delay.<br/><br/>If a particular sender generates a new sender address each time, they can be affected more often by greylisting than not.<br/><br/>Whether it&#39;s a good idea or not can be debated. Spam filters have unfortunately gotten so intrusive that sometimes they cause more harm than the spam they are intended to prevent. I will say that the delay caused by greylisting is a more acceptable behavior than completely blocking some legitimate mails.<br/><br/>Of course it&#39;s also entirely possible that it&#39;s just the one particular sender who has insufficient capacity. 2025-01-17T18:45:12Z https://yabu.me/nevent1qqszm62tkeat94u530krlc5syg99qgsyp4jax7xqwfg3kfkm4dqpsvczyz2u9p832sj9lzxu5cv0u6uwar8mtgk7yecx72q5k0hjkmttpwzvsmed0h0 In reply to <a href='/nevent1qqsdfqpjcvzr953ujkesvrr5e0w208rs842cqx72yg3wc87fyprjadg0qtvk4'>nevent1q…tvk4</a><br/>_________________________<br/><br/>Sometimes the delay is caused by the receiving server.<br/><br/>Greylisting is somewhat widespread. With greylisting the receiving server will initially respond to an email with a temporary error forcing the sender to wait and retry later.<br/><br/>The code setting the expiry time has no way of knowing how long that will take. 2025-01-17T03:23:59Z https://yabu.me/nevent1qqsgx2hzjmksauy3tcdkjsalw3n6dmeea5wsllvcq0e0e5w8rseqp9qzyz2u9p832sj9lzxu5cv0u6uwar8mtgk7yecx72q5k0hjkmttpwzvswsllup In reply to <a href='/nevent1qqsfuf6zuyfxlrftpdm25uzl45pggnzthff5ksa7ezsh8s6znf3qllcnnda4y'>nevent1q…da4y</a><br/>_________________________<br/><br/>For a moment I thought it said flags would be at half-staff due to the passing of democracy. 2025-01-04T18:31:47Z https://yabu.me/nevent1qqs2wz098sm5hfamg6dyf7et2v3knat4qqvfk7rtrp5ar3jv3tshrzqzyz2u9p832sj9lzxu5cv0u6uwar8mtgk7yecx72q5k0hjkmttpwzvs7twjc5 In reply to <a href='/nevent1qqsvsusdlnsmm2gmfvn2mgls0n3dzyelq5a7ylh8a92xy44nzf33ekcus7746'>nevent1q…7746</a><br/>_________________________<br/><br/>That means it can&#39;t be used as substitute for L2TP. There will be users on networks where UDP-based protocols are the only options. 2024-10-13T15:44:59Z https://yabu.me/nevent1qqst72qkhlmqfy554m5uzdg57mc24ayd76wmjfrrvjcxq5dk0px6rlgzyz2u9p832sj9lzxu5cv0u6uwar8mtgk7yecx72q5k0hjkmttpwzvsje3dva In reply to <a href='/nevent1qqsram4r0sssd7p5nm6ex8x8ngxqmku8wuxazj4umrr7t4m84e98scq2za20d'>nevent1q…a20d</a><br/>_________________________<br/><br/>Can that be used through NAT? A typical use case for L2TP involves a tunnel running through NAT444. 2024-10-13T14:57:48Z https://yabu.me/nevent1qqsrlh5r63369w0zfhrklg6dy3rk63yrxkw0czlxzpvf7rrvm8v3klczyz2u9p832sj9lzxu5cv0u6uwar8mtgk7yecx72q5k0hjkmttpwzvsq8rlxj In reply to <a href='/nevent1qqsyd9awdkhanlckmwjesa9jqelm9xwld2w5vh89nkgdsp9unpj53kq0ytcsy'>nevent1q…tcsy</a><br/>_________________________<br/><br/>What is the recommended protocol for use cases that only need tunneling and don&#39;t need the cryptography offered by a full-blown VPN?<br/><br/>I know that <span itemprop="mentions" itemscope itemtype="https://schema.org/Person"><a itemprop="url" href="/npub1sv0s3rznh6j6974qduqj8nyur5cts9kpcjcahuqspgk0lrmp9wmqnfrq9x" class="bg-lavender dark:prose:text-neutral-50 dark:text-neutral-50 dark:bg-garnet px-1"><span>Andrews & Arnold Ltd (AAISP)</span> (<span class="italic">npub1sv0…rq9x</span>)</a></span> is one well regarded ISP who includes L2TP tunnels as part of their offering. 2024-10-12T16:14:06Z https://yabu.me/nevent1qqs83mv6eluy42y940saq2jeenwvs9f5ext40ks06466xg056wn5chgzyz2u9p832sj9lzxu5cv0u6uwar8mtgk7yecx72q5k0hjkmttpwzvsqv52sj In reply to <a href='/nevent1qqsrqa22zazp752tf7hsfwl3qxkwnnvqfq4zrx0d9xg5u5r256w38jg65gw36'>nevent1q…gw36</a><br/>_________________________<br/><br/>I have often used MTU problems as an interview question. Good candidates would usually figure it out in 30 minutes. Not so good candidates would not figure it out in 60 minutes.<br/><br/>And then there was that one time I had a candidate who figured it out in 10 minutes. He was offered the position and then declined. 2024-09-02T15:58:30Z https://yabu.me/nevent1qqsyygrh5wne4v8vx4sss6578tv59sxzwgs2kchdn9z6jjpx96lse3gzyz2u9p832sj9lzxu5cv0u6uwar8mtgk7yecx72q5k0hjkmttpwzvs8s6pq0 In reply to <a href='/nevent1qqsfwyqsdmfkhhymqd4ah36ekxhu7vqsr4etxnc0vm20gmulurqsm2calg9qy'>nevent1q…g9qy</a><br/>_________________________<br/><br/>One example from my own experience is with DNS. Back in 2015 we had a series of outages due to the provider who was hosting our DNS zones.<br/><br/>First the provider had a six hour outage during which we could do nothing, and we couldn&#39;t even get in touch with the provider.<br/><br/>Then we tried redundancy across two different DNS providers, which lead to another two outages when the first provider did not handle redundant setups correctly.<br/><br/>At that point I said we will never want to go through this again. And we decided to operate our own DNS servers with redundancy across four different hosting providers.<br/><br/>We have now used that setup for over nine years and not had a single outage of our DNS zone. We have of course had individual DNS servers be down for some time every now and then, but we never had all four go down.<br/><br/>Such a track record of course helps when I am making arguments for multi provider redundancy. I can point at this setup and say over nine years with 100% uptime, had we used Cloudflare we wouldn&#39;t have had such a high uptime. 2024-08-26T21:46:53Z https://yabu.me/nevent1qqswp6kznzt45ekaer8c9vzx7xsmz8r2uyl97dcr5gtqmc2waw35lfczyz2u9p832sj9lzxu5cv0u6uwar8mtgk7yecx72q5k0hjkmttpwzvs9sf908 In reply to <a href='/nevent1qqsv4ntl2hkh57dpedsurx6gf04q0t0snuzkh8c027yc9c8mt7mmuggvlntpu'>nevent1q…ntpu</a><br/>_________________________<br/><br/>I am thinking one should never trust a single supplier no matter how big and trustworthy you think they are.<br/><br/>One opinion I have heard a few times goes like this: It&#39;s not a problem if we are completely dependent on CloudFlare, GCE, or Amazon. If they go down many other systems will go down as well, and customers won&#39;t blame us.<br/><br/>The problem with that line of thinking is, that the bigger the provider is, the less important each customer is to the provider. There have been stories about individual customers of big providers getting into trouble. 2024-08-26T20:28:58Z https://yabu.me/nevent1qqsxt98ggrjkuzrv6ayc3tmna4jsu523hanqeulvqesuqshq23ee0gqzyz2u9p832sj9lzxu5cv0u6uwar8mtgk7yecx72q5k0hjkmttpwzvswzu8l9 In reply to <a href='/nevent1qqs80dxehqm7jx6q7j9gmqkuc332djm8079v53w3awpegy4l3xhu34qjwt65y'>nevent1q…t65y</a><br/>_________________________<br/><br/>But why did your router send destination unreachable errors?<br/><br/>Using tcpdump I saw `ICMP6, destination unreachable, unreachable address 2a05:87c6:1:1cc8::1, length 88` coming from 2a00:1098:2::7. And in the traceroute output above that is indicated as `!H`<br/><br/>That behavior from your router is one I would only expect if the next hop address did not respond to neighbor solicitation.<br/><br/>Did you verify that the address you pinged was identical to the next hop address currently in the routing table on that particular router? 2024-08-25T14:25:21Z https://yabu.me/nevent1qqs8zpzazpss50hk7skjlu6tkpr8fpcpxe40w6v2acrvyu46pfsm2aqzyz2u9p832sj9lzxu5cv0u6uwar8mtgk7yecx72q5k0hjkmttpwzvs5g5vz8 In reply to <a href='/nevent1qqswpsj0xzmnk8l4ypk9kufej0n64zqhay7mvlckethspd0frggngfg4m678w'>nevent1q…678w</a><br/>_________________________<br/><br/>That&#39;s not what I saw. When I used traceroute I got destination unreachable errors from one of your routers. Here is the traceroute output I shared earlier:<br/>```<br/>traceroute to 2a05:87c6:1:1cc8::1 (2a05:87c6:1:1cc8::1), 30 hops max, 80 byte packets<br/> 1 2a00:1098:1::2d 0.284 ms 0.231 ms 0.217 ms<br/> 2 2a00:1098:2:ffff::9c 0.401 ms 0.387 ms 0.375 ms<br/> 3 2a00:1098:2:1::1c:1 0.437 ms 0.417 ms 0.453 ms<br/> 4 2a00:1098:2::7 0.323 ms 0.376 ms 0.365 ms<br/> 5 2a00:1098:2::7 3055.197 ms !H 3055.184 ms !H 3055.165 ms !H<br/>``` 2024-08-25T14:06:05Z https://yabu.me/nevent1qqsqn8pg2c279gzg4wxr5dsujtlacpgthhw0p6ax9xzqky66cfyd8ugzyz2u9p832sj9lzxu5cv0u6uwar8mtgk7yecx72q5k0hjkmttpwzvs8gmhrf In reply to <a href='/nevent1qqsyuwn2xyt0y4yhzq54aaf87nevjt82ywdct3v43wm34j4c5h0jrrs9utt42'>nevent1q…tt42</a><br/>_________________________<br/><br/>I agree that is one of the most likely explanations of the root cause. It is something which could have been automatically detected when receiving the advertisements from the route server. But I do not know if any BGP implementation has the logic to detect and filter such faulty advertisements. 2024-08-25T13:41:08Z https://yabu.me/nevent1qqszkdr62u8tlgzkrerddn8nn5j7qaxs8yr7cm9j4cuasaevmmkdkpszyz2u9p832sj9lzxu5cv0u6uwar8mtgk7yecx72q5k0hjkmttpwzvsttmn6z In reply to <a href='/nevent1qqs9ukfsnwj349syyjq7cugplg4sgfxefucaqmxumyvdnj6evgfwkpc74ue7f'>nevent1q…ue7f</a><br/>_________________________<br/><br/>It does not look specific to A&amp;A. One of the network paths confirmed to be affected did not go through A&amp;A.<br/><br/>It&#39;s confirmed which exchange the issue lies at. But it&#39;s unclear to me if the issue is with the destination network or the exchange itself. I do not have a presence at that exchange myself, so the only information I have to work from is output from traceroute and similar tools.<br/><br/>It looks to me like one aspect of the BGP implementation you are using is a contributing factor. But that may very well be standard behavior. For all I know it could be that all other BGP implementations would respond the same in this corner case. 2024-08-25T12:46:40Z https://yabu.me/nevent1qqspe6y4amm82l0hrm9jnmj8pzh2y0hqyrwpy0ejmxmayqhqgn2rdkczyz2u9p832sj9lzxu5cv0u6uwar8mtgk7yecx72q5k0hjkmttpwzvs5pv8eq In reply to <a href='/nevent1qqsvvg3g5rtk5pukzxfy39x4etd3aprufmjj0mjm0txzh8csfnef9cq4w24q9'>nevent1q…24q9</a><br/>_________________________<br/><br/>A router server is indeed what I imagine as the most likely way to get the same failure mode as what I saw with OSPF.<br/><br/>It&#39;s technically possible to verify that neighbor discovery works for the next hop that you receive from a route server. How to actually implement it depends on the underlying platform and could be complicated.<br/><br/>What did you verify on the data path? The traceroute command I tried failed before the packet reached the data path from 2a00:1098:2::7 to the next hop. 2024-08-25T11:29:47Z https://yabu.me/nevent1qqsr7ku90gd96t3g0uhahys3mj466cnt3ag5w6wrzvj0xcfs6pmvhvqzyz2u9p832sj9lzxu5cv0u6uwar8mtgk7yecx72q5k0hjkmttpwzvsfp4auc In reply to <a href='/nevent1qqsgv8p8g9mk7hze99w42wrfe8fawepds6sqpwzc0dmwspe5n7twhcqcuya79'>nevent1q…ya79</a><br/>_________________________<br/><br/>This reminds me of a failure mode I observed in OSPF. I don&#39;t know for certain if the same failure mode exists in BGP, but the symptoms sure look similar.<br/><br/>In OSPF the nodes connected to an Ethernet segment will elect a master. OSPF will verify that each node can communicate with the master, and this can be continuously verified with BFD.<br/><br/>OSPF will then assume that if two nodes can both communicate with the master, then they can also communicate directly with each other. If that assumption does not hold OSPF will configure routes which will always fail during the neighbor discovery step of the packet forwarding. I observed this behavior in two mainstream OSPF implementations.<br/><br/><span itemprop="mentions" itemscope itemtype="https://schema.org/Person"><a itemprop="url" href="/npub1wy538vq2ezvhg6vge72fdh4nnyk2l78hesm20pf84te3n260yngqud64vc" class="bg-lavender dark:prose:text-neutral-50 dark:text-neutral-50 dark:bg-garnet px-1"><span>Mythic Beasts</span> (<span class="italic">npub1wy5…64vc</span>)</a></span> <span itemprop="mentions" itemscope itemtype="https://schema.org/Person"><a itemprop="url" href="/npub1sv0s3rznh6j6974qduqj8nyur5cts9kpcjcahuqspgk0lrmp9wmqnfrq9x" class="bg-lavender dark:prose:text-neutral-50 dark:text-neutral-50 dark:bg-garnet px-1"><span>Andrews & Arnold Ltd (AAISP)</span> (<span class="italic">npub1sv0…rq9x</span>)</a></span> Does the BGP implementation that you are using accept routes for which the advertised next hop does not respond to neighbor solicitation? 2024-08-25T10:46:49Z https://yabu.me/nevent1qqsgv8p8g9mk7hze99w42wrfe8fawepds6sqpwzc0dmwspe5n7twhcqzyz2u9p832sj9lzxu5cv0u6uwar8mtgk7yecx72q5k0hjkmttpwzvsgcnftu In reply to <a href='/nevent1qqs0hzdafxtqvcjz9wp5g36e2knnn9e64er9wnxsn2mhdn08ss98ahsudmwqh'>nevent1q…mwqh</a><br/>_________________________<br/><br/>That hostname resolves to `2a05:87c6:1:1cc8::1` for me. I confirmed that the IP address is reachable from most networks I tried but it is not reachable from <span itemprop="mentions" itemscope itemtype="https://schema.org/Person"><a itemprop="url" href="/npub1wy538vq2ezvhg6vge72fdh4nnyk2l78hesm20pf84te3n260yngqud64vc" class="bg-lavender dark:prose:text-neutral-50 dark:text-neutral-50 dark:bg-garnet px-1"><span>Mythic Beasts</span> (<span class="italic">npub1wy5…64vc</span>)</a></span> or <span itemprop="mentions" itemscope itemtype="https://schema.org/Person"><a itemprop="url" href="/npub1sv0s3rznh6j6974qduqj8nyur5cts9kpcjcahuqspgk0lrmp9wmqnfrq9x" class="bg-lavender dark:prose:text-neutral-50 dark:text-neutral-50 dark:bg-garnet px-1"><span>Andrews & Arnold Ltd (AAISP)</span> (<span class="italic">npub1sv0…rq9x</span>)</a></span><br/><br/>The problem seems to affect both ssh and ping. With both protocols I get an ICMPv6 error message back:<br/>```<br/>ICMP6, destination unreachable, unreachable address 2a05:87c6:1:1cc8::1, length 88<br/>```<br/><br/>The origin of the ICMPv6 error message is 2001:8b0:0:53::109 or 2a00:1098:2::7 depending on which provider I connect from.<br/><br/>Here is an example traceroute output:<br/>```<br/>root@nat64-london:~# traceroute -n -I 2a05:87c6:1:1cc8::1<br/>traceroute to 2a05:87c6:1:1cc8::1 (2a05:87c6:1:1cc8::1), 30 hops max, 80 byte packets<br/> 1 2a00:1098:1::2d 0.284 ms 0.231 ms 0.217 ms<br/> 2 2a00:1098:2:ffff::9c 0.401 ms 0.387 ms 0.375 ms<br/> 3 2a00:1098:2:1::1c:1 0.437 ms 0.417 ms 0.453 ms<br/> 4 2a00:1098:2::7 0.323 ms 0.376 ms 0.365 ms<br/> 5 2a00:1098:2::7 3055.197 ms !H 3055.184 ms !H 3055.165 ms !H<br/>root@nat64-london:~# <br/>```<br/><br/>The last hop limit exceeded message came from the same IP as the unreachable address. The later error message was delayed by 3 seconds.<br/><br/>In my experience the 3 second delay is most often caused by a neighbor discovery timeout. That indicates that 2a00:1098:2::7 and 2001:8b0:0:53::109 have a route forward towards the destination, but the next hop is not responding to neighbor solicitation messages. 2024-08-25T10:05:54Z