d00bianista

> Not having two sets of firewall rules and two sets of everything. I always disable IPv6 because it can bite you so hard when you don't realize that you are wide open to IPv6 connections because of different firewalls.

nftables gives us a dualstack firewall, and it's so far the only one I've seen. It's not that bad, but I have occupational damage so I don't mind :D

https://wiki.nftables.org/wiki-nftables/index.php/Nftables_f...

We're all different, I find Cisco and Vyatta awkward because of different reasons. RouterOS is not the best there is but it's less awkward, in my opinion.

There may be more of us here, even in the FTTH-flavor.

There are some imperfections, mostly related to bonding+ospf and vrrp-grouping but if one does not mind some warnings and a little scripts, one can make things work nicely.

Let's just say that BGP-signaled redundant uplinks and routing as close to the customer as possible are to strive for, instead of starting with a L2 port-isolation-pyramid nightmare.

Back in the day... I used to maintain and manually scale a platform that ran a regionally large social site. It was written in PHP, by two geeks in a dorm, served by Apache and had a single MySQL database and host, in a respectable datacenter. At it's greatest moment, it had a pair of keepalived-hosts in front of around 7 Apache hosts and still that single database host.

That was expensive, but not in maintenance. The amount of moving parts in that, compared to all the doohickeys of modern times, seems like 1:100.

As someone who understands very little of modern web-doohickeys, I'm very afraid of the direction we are going in and it seems like my job-security is quite high, because schools don't produce infrastructure people any more... Just happy-go-lucky developers who know how to run things on top of a credit card, on someone else's computer.

That's because the DHCPv6 client in the modem generates a unique DUID for itself and the new one cannot know the fried modems DUID.

I'd like to disagree on IPv6 sucking and would like to steer this blame towards whoever decided to not be persistent. Firewalls can handle changing prefixes by masking it. Hosts can request certain addresses. Cheap dual-homing is something that IPv6 does not quite do, because that requires NAT66, which is controversial. Also, RIPE tells us to do persistent delegations:

https://www.ripe.net/publications/docs/ripe-690#5-2--why-non...

That would most likely be because of low latency and jitter. The app is in essentially the environment it was developed in and does not have to put effort into correcting errors that itself cause pauses in the visible video, since it tries to hide the parts where artefacts appear.

Ten years back I was told America likes to zap quickly through tv-channels with all the artefacts involved while Asia preferred a slower and artefact-free experience. Analog and keyframeless digital codecs are faster but not so bandwidth efficient.

Interesting, Winbox or WebFig/CLI? I find this clunkyness to be a good thing, compared to shiny and inflexible products. I have some experience of quite a few brands and so far Mikrotik is one of the most coherent and unified experiences. WebFig and CLI are the same across devices running RouterOS. Winbox is not my bag though.

RouterOS is not perfect but it does most things without being overly complicated. It's DHCPv6 relay agent is pretty much useless and I really look forward to WireGuard in RouterOS v7, if ever released as stable :D

It's quite a job to get closer to wire speed with 802.11ax still... Let's assume dual spatial streams and devices that not quite support anything past U-NII-1.

https://en.wikipedia.org/wiki/List_of_WLAN_channels#5_GHz_(8...

https://en.wikipedia.org/wiki/IEEE_802.11ax

This leaves us with 5x20MHz spectrum and while being good netizens we'll leave some of that free for others (and ourselves), so we use just 40Mhz of that.

With the tightest modulation and guard interval even, theoretically, we will acheive at best 573.6Mbit/s simplex and not the best of latency and jitter.

I'm not saying that 802.11ax is not worth the money. I am however saying that getting closer to garanteed Full Duplex 1Gbit/s is hard. And I still have 2.4Ghz-only -devices still in daily use.

I'd dare bet that the WiFi-radio and 1000BASE-T -ports are indeed not switched, but connected to the CPU, which as stated above looks very much like a router :)

There's sadly no block diagram released for these, which would document the internal topology. I also do not have this exact device anywhere to look this up from.

IPIP/IPsec and OSPF would do nicely for efficient site-to-site meshing.

But, adding docker to the equation makes it much more complicated. I'd prefer just operating the machines over IP and get rid of all remote desktop related latency all together.

It's actually not better tech, instead it's more complicated, more error prone and less durable ways to use the same technology that produces more space for a lower price. MLC is pretty much okay but TLC is a little too fragile and low performance in my opinion. I prefer spinning HDD's over QLC since the spinning drives have predictable performance.

This could be turned into a great, possibly awkward, movie.

You can always blow metal-free fiber in pipes. I'd use PE pressure pipe of suitable size, pull a string into it with a vacuum cleaner and pull fiber in... Hopefully the fiber survives.

With something as complicated as 9 separate locations, I'd definitely avoid unmanaged media converters. Managed ones will be able to tell you how well, or how poorly, your fiber links are doing.

I'd recommend using managed devices as opposed to using dumb media converters. If there are issues, you have no insight into the issues with unmanaged devices.

Like a good Unix tool, that's outside of WG's scope. User management is done with the likes of LDAP and such.

A trusted certificate is nice and all but if you have to rely on DNS to find the CNAME-record that translates to an A-record and so forth, it becomes complicated and simpler for malicious parties to MITM you. A self signed certificate is actually better in that sense that nothing trusts it and with the assumption that you can add permanent exceptions and pinning, you'll know immediately if something is wrong.

Aside from versioning being clear about how big the change is, Windows Installer has this [0-255].[0-255].[0-65535] limit that I hope people do not learn about in the hard ways.

It's not so fun to work around because Windows Installer tries to be smart about things, as opposed to the others that take a more robust approach.

https://docs.microsoft.com/en-us/windows/win32/msi/productve...

I again have phobias regarding Watchguard and other products that have the consumer style special WAN-ports and related configuration restraints. Many Mikrotik-devices come preconfigured like consumer devices but the recent CCR-series does not.

The firewall in Mikrotik-devices is among the cleanest I've seen and very hard to miss-configure as long as the firewall is otherwise configured to not let unauthorized traffic through.

And yes, people are people and this is why we educate people when needed.

Mikrotik has recently made bridging much saner, which makes their portfolio complete for datacenter use and pretty close on bridging users in the access layer.

Their CCR-series is very much bang per buck if L4-filtering is enough, which should be enough in today's world of end-to-end encrypted communications.

The CRS3xx-series as stated has become much saner with changes to bridging and with most features implemented are also worth the cost.

The upside with affordable devices and the licensing model they have, make it possible to keep cold spares available in case of disaster.

It does however make sense to study the management interfaces and disable all but SSH and HTTPS in order to minimize attack surface.

I would not trust any unofficial installer. Luckily many problems can be solved with a USB-Ethernet adapter and later configuration of the systen, since the issue usually lies in exotic network hardware.

What? There is no such thing as 'non-free' Debian. The Debian repositories do contain the 'non-free' section which is used to deliver non-free firmware among other things.

Yup, turning off snooping would have fixed the issue at hand but not the poor choice of relying on STP for redundancy.

I've seen this happen a few times in my life in production systems, designed by someone else. Overload a switch somehow and it goes straight in ludacris mode because of the topology. Properly configured networks suffer minor outages only in case of single device meltdowns.

Large L2-networks never work well, they all have some issues. Their existence is purely based on lazyness or believing that Ethernet works like the water main... I admit that I might be more obsessive compulsive than most but I find reconfiguring networks to be a whole lot of fun :)

And no matter how smart the peole on campus are, there will always be someone who cannot accept that someone else is more right. I have first hand experience of this since I have tunneled IPv6 at home and know pretty quickly if someone does not listen to ICMPv6 Packet Too Big -messages. Not the first time I contact people about it but so far the only one I have not been able to convince is exactly someone really smart on some campus somewhere. I wrote many emails and tried to explain that IPv6 allows MTU's as low as 1280 bytes and that ICMPv6 is a must allow protocol but nope.

> an attempted deployment of IPv6 caused packet storms in the MIT Computer Science and AI Lab's network

They were relying on Spanning Tree in a who knows how big broadcast domain. Firstly, that's just begging for things to hit the fan. A single device having a meltdown will cause exactly this, a broadcast storm that is able to take down the entire campus, because it was a single broadcast domain.

Secondly, it is a security nightmare. No amount of links or switch capacity will suffice in a single broadcast domain campus, relying on STP, if port isolation and proxy-arp is enabled, along with DHCP snooping, arp inspection etc. So, port isolation is not turned on. Isolation also creates a requirement for a pyramid-shaped network so nobody wants to do that anyway. But back on point, MITM-heaven, anyone can do what ever they want because the L2-infrastructure is not limiting anything. Ethernet does not care about security and Internet Protocol only implements or allows to implement security in gateways that interconnect subnets that reside on separate broadcast domains.

Routing is the answer and this is why I route on the access-layer, as well as on aggregation and core -layers. Route loops are very rare with OSPF and broadcast storms are limited to single switches if you route at access-layer. Also the posible issues with untested code-paths are minimized this way, since none of the switches are seeing more than the equal amount of hosts as it has ports.

I do not agree with SLAAC because I do not believe in broadcast domains the size of a /64 so I'd deploy DHCPv6 in every possible braodcast domain that does not have Android devices in them. Luckily there is no place for Android in wired networks and especially datacenters, so I can happily deploy DHCPv6 in those. And if I ever need to service Android-devices, I can dualstack and let the devices know of DNS-service with DHCPv4! Take that, Lorenzo! Hah! Outsmarted you there!

From what I've observed, a while back they at least stopped selling their products in the US and then appeared again with FCC approval and limited radio frequencies in the US-models. Non-US -models are unlimited and did not seem to disappear off the shelves during that time. All of the products available today, to my knowledge, come in both US and Non-US -variants.

Having been employed by an ISP and decided to do something with less night time hours and more floors above ground with windows, I have the habit of doing free consultations (meddling) in order to stay up to date.

Currently I warmly recommend Mikrotik (not their CRS-series though) since they have very little limitations. The most recent case involved pre-purchased AirOS-devices and it's lack of virtual AP:s. Why I find this a drawback is how Ethernet and Internet Protocol are designed. It was never meant to be that customers should share broadcast domains, a privilege that enterprise customers are granted but consumers rarely are.

To make a first class network experience for both ISP and customer, give every legal entity their own broadcast domain and subnet (read: routing in access layer). As WISP:s, you should be conservative on allowing unnecesary brodcast-packets to propagate, especially through half-duplex links. This also defends your network from rogue DHCP and what not that might bring the entire network more or less down. I've designed a few FTTH-networks this way and these networks have never been disturbed by customer shenanigans.

I route because my cheap devices can route ;)

Shrouds should help against out-of-band radiation. I'm no expert but I assume that they do more harm in a single radio environment than without but they should help when you have multiple radios next to each other.