juancb
Joined 10 years ago
Joined 10 years ago
I won't deny that sometimes it works but there's much more coverage on when it does that when it fails which only serves to amplify the survivorship bias around it.
Or ZFS or DRBD or whatever homegrown or equivalent non-proprietart alternative is available these days and you prefer.
That of course would make it optional like with most programmable keyboards but then there's the need to manage pairing via their wireless dongles and then it quickly becomes necessary.
Outside of it all being intentionally proprietary I don't see why they couldn't take an approach similar to VIA in managing their devices. There's also prior work for flashing microcontrollers from the web browser, I'm thinking of ESP32s specifically.
I've noticed weird little detours in areas where I'm familiar with but engaged navigation merely for an ETA. To me those little detours that don't save time or avoid construction suggest I'm being used to probe those side streets. It's like being a human ICMP packet.
Both asymmetric routing and ECMP routing are visible from L3. In the latter case, the routing decision can utilize some L4 data, so some L4 frobbing to get useful data points in practice is necessary for useful real-world diagnosis.
I agree with others that the OSI model is a good metaphor and a framework for reasoning about networking, but it is far from perfect, and the reality for those designing and operating network protocols and devices is messy.
MPLS is admittedly invisible and there isn't a thing you can do about it in the same way that you can't expect traceroute to give you a view of the switch ports it went through on a LAN. Of course it is useful to understand and keep in mind the fact that there may be, sometimes huge, gaps in your traceroutes. A sudden huge jump in RTT from one hop to the next can be confusing when trying to understand and troubleshoot a network issue.
The explanation is great for a toy network bu in today's Internet the vast majority of routes are going to be asymmetrical and that requires running traceroutes from both ends and interpreting the results to find the faulty hop.
The author also doesn't cover equal cost multipath (ECMP) which is everywhere. With ECMP you have multiple ports that lead to the same. Next hop and packets are hashed based on some part of the fourtuple, sometimes five tuple including the input Port. In order to track down the faulty link, you need to pro each and every one of the ports which requires that you use a higher level protocol like UDP. Using icmp in this case will not show you an issue some percent of time, providing false negatives which makes it less useful.
Why not rig it with explosives around the sensitive components and avoid the messy endeavor of trying to orient the plane for maximum destruction after ejection when that is likely to be unreliable at best?