The HTTPS and HTTP conundrum

▼ The past few days I have added HTTPS support to bgpexpert.com and iljitsch.com. About ten years ago, I experimented a bit with SSL/TLS (HTTPS) support in Apache, and that was rather difficult.

But no more. Thanks to the efforts of Let's Encrypt and the ACME protocol as implemented in certbot, adding HTTPS support to your websites is now almost ridiculously easy: just install certbot, run it with --apache and a list of your domains... and that's it! (Remember those certs expire in 90 days, so set up automatic renewal.) I was initially worried about the number of subdomains I use, but 30 of them is not a problem.

However, there are complications, which all go back to the rather bad decision to use HTTPS rather than HTTP in URLs and use a separate port number for HTTPS. This means that you can't just negotiate the best security supported by both sides. Instead, HTTP is never encrypted, and HTTPS is always encrypted.

So that means if you just enable HTTPS and do nothing else, all the visitors to your website will still use HTTP. I'm actually fine with that, as I feel that providing the option to encrypt an HTTP session is sufficient. In my opinion, for the sites I'm running, being able to access them over HTTP should HTTPS not work is a pro, not a con. Should you wish to go further, the recommended approach is to have your web server redirect requests from HTTP to HTTPS.

What I'm doing here on iljitsch.com is just enable HTTPS and see what happens. I'm especially interested in seeing if/when/how Google will discover the new HTTPS capability. Once you're on on iljitsch.com using HTTPS, I want to keep you there, so I've changed all the links to use protocol-relative URLs. As I'm using subdomains for some stuff, I do need to specify www.iljitsch.com, but I do that by using //www.iljitsch.com/ rather than http://www.iljitsch.com/ or https://www.iljitsch.com/, so if you're on HTTP, the links will be HTTP links, but if you're on HTTPS, the links will be HTTPS links.

On bgpexpert.com, on the other hand, I want Google to find the HTTPS version of the site as soon as possible, so I've changed some of the scripts to redirect from HTTP to HTTPS, along with using relative or protocol-relative URLs everywhere. However, in the future I may remove these redirects and use other mechanisms to make Google prefer the HTTPS version rather than the HTTP version of the site. Not entirely sure yet what's the best way to do that.

One benefit of using HTTPS is that links to my images on other sites, including RSS readers, now work. So let me take advantage of that.

Permalink - posted 2021-11-22

Mijn internetsnelheden

▼ In de loop der jaren heb ik een flink aantal verschillende verbindingen naar het internet gehad, en uiteraard werden die steeds sneller. Toen ik ooit die lijn doortrok kwam ik uit op 256 terabit/s wanneer ik met pensioen ga. (De AOW-leeftijd was toen nog 65.)

Tijd om eens te zien of ik inderdaad nog steeds op dat pad zit. Alleen merkte ik dat ik niet echt helder meer had op welk moment ik wat voor lijn met wat voor snelheid had. Tijd voor wat uitzoekwerk dus, en ik zet het hier neer zodat ik het later weer terug kan vinden en kan lachen over hoe sloom alles was in het jaar 2021.

• 1993: 28 kbps. Toen je voor het eerst met SLIP kon inbellen bij XS4ALL. Waarschijnlijk was het 1993 en een 28k8 modem, kan me vergissen.
• 1995: 64 kbps ISDN.
• 1996: 64 kbps + 33 kbps. Naast mijn ISDN-lijn had ik een analoge huurlijn naar bART met daarop 33k6 modems. Dus ik was 24 uur per dag online zonder telefoontikken, maar kon inbellen met ISDN voor meer snelheid.
• 1998: 144 kbps. Dit was met Telindus 144 kbps baseband modems over een analoge huurlijn naar Pine Internet. Niet helemaal zeker over het jaar.
• 2003: 768/128 kbps ADSL over een ISDN-lijn via XS4ALL.
• 2004: 8/1 Mbps ADSL over ISDN via Leaseweb.
• 2008: 13/? Mbps ADSL via Tele2 in Spanje.
• 2012: 50/5 Mbps kabel via Ziggo.
• 2021: 300/30 Mbps, na min of meer jaarlijkse gratis upgrades van Ziggo.

  (Ik herinner me dat ik ergens rond 2000 - 2005 ook een tijdje zowel ADSL als kabel had, waarbij de ene 1 en de andere 2 megabit was. Ik kan alleen niks terugvinden over een kabelaansluiting in die tijd.)

  Hier in een grafiek. Groen is down-bandbreedte, blauw up-bandbreedte. De bolletjes geven aan wanneer ik overschakelde op een andere verbinding. Ik heb de lijnen doorgetrokken voor de duidelijkheid, uiteraard waren er ook tijden dat de snelheid een aantal jaar hetzelfde bleef.

  

  Op een logaritmische zie je de uploadsnelheid in een redelijk rechte lijn omhoog gaan van zo'n 30 kbps bijna 30 jaar geleden naar 30 Mbps nu. Dan gaat die 256 terabit dus nog zo'n 50 jaar duren—een paar jaar minder als we naar de downloadsnelheid kijken. Die maakt een éénmalige sprong in 2004, nadat ADSL en kabelinternet een stuk volwassener werden.

  Tot ongeveer 10 Mbps is een snelheidsverbetering goed te merken. Tussen 10 en 100 megabit al veel minder: er zijn geen of nauwelijks interactieve toepassingen die 100 Mbps nodig hebben, laat staan meer. Downloads (en uploads) worden natuurlijk nog wel sneller, maar meestal toch niet zo snel dat je erop gaat zitten wachten.

  Toch interessant dus dat de consumenten-ISPs nog hogere snelheden blijven uitrollen. Aan de andere kant: als op een enkele mega-downloader na klanten toch niet meer data gebruiken over een snellere lijn is gratis updates weggeven en met heel hoge snelheden adverteren natuurlijk een goede manier om te laten zien hoe stoer je bent.

  

  Ik kan nu 1000/50 Mbps over de kabel krijgen van Ziggo en 1000/500 via de glasvezel van KPN (waarbij je uit verschillende providers kan kiezen). Die 1 gigabit is natuurlijk wel een mooi rond getal, ik vraag me dus af of de race naar meer bandbreedte hierna even hard door zal gaan. 10 gigabit betekent flink wat apparatuur bij de consument vervangen Uiteindelijk zal het er wel van komen. Maar daarna...?

  Permalink - posted 2021-05-31

VLANs on the Mikrotik hAP ac³

▼ For my BGP lab/training setups I have a bunch of routers, real or virtual, that each need several IP addresses to talk to other routers. VLANs are the perfect way to keep all of this manageable: with VLANs, it's possible to have separate IP interfaces, but still just use a single Ethernet port to hook everything up. Simple unmanaged switches simply forward the packets to the right port without looking at the VLAN header, so no need to configure the network.

Until I got my Mikrotik hAP ac³ this week...

In its default configuration it will do what unmanaged switches do: ignore the VLAN header. In addition, you can add VLAN interfaces to the Mikrotik and give those an IP address. I even got IPv6 prefix delegation to work. For this, set up the DHCPv6 client to request a prefix. Then fill in the name of a pool. But don't create that pool yourself—that won't work. The pool will be created automatically. Then configured an IPv6 on a VLAN interface that I created and specified that the pool should be used for that. "Advertise" is enabled by default, which means that the Mikrotik will send out router advertisements and machines that have the VLAN configured will configure an IPv6 address for themselves on that VLAN interface.

Eventually I want to set up a guest network with its own VLAN and IPv4 NAT. For now I just set up IP addresses on the VLAN interfaces so the Mikrotik will be able to talk to my virtual BGP routers on these VLANs. That initially went well.

However, I also wanted have these BGP VMs talk to an old Cisco 2503 router, which doesn't support VLANs. So I wanted to set up an access port. The idea was that the Cisco would be part of VLAN 203 without the need for it to insert a VLAN TAG itself. On the other ports, VLAN 203 (and a few more) get a VLAN header. However, not exactly like a trunk port where all packets have a VLAN header: regular traffic to/from the internet goes out on these same ports untagged.

Mixed tagged/untagged ports turned out to be unsupported by the Atheros 8327 chip that powers the switch ports. What you can do is have one or more access ports and one or more trunk ports. This is already somewhat complex. The access ports need to be set up with a default VLAN. (Under "switch" and then "ports".) Makes sense. In the documentation, it says to use add-if-missing will add a VLAN header if there isn't one. Makes sense. However, it turns out that you need to do this on the outgoing port, i.e., not the access port itself, but the trunk port(s) that are part of the same VLAN. However, then (with a slight delay?) untagged traffic from the default VLAN won't work anymore.

The good news is that even though the hardware can't have mixed ports, the software can. So remove those settings above, and go to the bridge section of the configuration instead. There, select your bridge instance and turn on VLAN filtering. After that, you can go to the VLAN tab an add one or more VLANs there, where you can specify which ports should be tagged and untagged for that VLAN. So now we can have access ports and mixed ports. I do believe performance will be lower because VLAN traffic will need to be handled in software. Also not the PVID setting, which is the default VLAN untagged traffic. (1 out of the box.)

Unfortunately, the Mikrotik's IP addresses on the VLAN interface I tested with were now unreachable, and I couldn't figure out any settings to fix that. So after I was done with the Cisco 2503, I unchecked the "VLAN filtering" in the bridge settings... and the Mikrotek's IP addresses on VLAN interfaces came back to life.

Permalink - posted 2021-04-04

Ethernet cables in the post-gigabit era

▼ As I'm preparing for the arrival of more > 1000 Mbps Ethernet equipment, I did an inventory of the Ethernet cables I've collected over the years. Turns out there's more variety than expected: I have cat 5 UTP, cat 5e UTP, cat 5e STP and cat 6 STP. (The good news: crossover cables are no longer a thing. Even the red cable is a regular straight cable.)

Aside:

UTP is unshielded twisted pair. The cat 5 and cat 5e specifications don't require shielding, and I believe the same is true for cat 6 and cat 6a. Just the twisting already makes the cable pairs much less susceptible to interference than an untwisted cable. However, it's not uncommon to see twisted pair with shielding, which we may be tempted to call "STP". However, things are a bit more complex than that: there's two types of shielding and two places where it can be applied. There's foil shielding and braided shielding, and this can go around all four pairs together, or each pair can be shielded individually. Some examples:

• UTP: no shielding
• F/UTP: foil on the outside
• U/FTP: no outside shielding, foil around each pair
• S/UTP: braiding on the outside
• S/FTP: braiding on the outside, foil around each pair
• And so on

However, just "FTP" or "STP" are also used.

The most common types of twisted pair used for Ethernet are cat 5, cat 5e, cat 6 and cat 6a. New categories add more stringent crosstalk limits and typically have a higher MHz bandwidth rating. Note that each higher category is compatible with the lower categories. So if you want to use a cat 6a cable to hook up your phone, that'll work just fine.

Without going over all the specs, this table shows the compatibility between cable categories and Ethernet speeds. (As 10GE is barely showing up now in homes and offices, fifteen years after being standardized, I'm going to ignore possible speeds faster than 10GE.)

	GE	2.5GE	5GE	10GE
Cat 5	😀	⛔	⛔	⛔
Cat 5e	😀	😀	😀	⛔
Cat 6	😀	😀	😀	max 55 m
Cat 6a	😀	😀	😀	😀

(With 😀 meaning works with a maximum distance of 100 meters and ⛔ doesn't work.)

Update: to make sure 5GE works at the full 100 meter distance, it needs cat 6, as 5GE requires a bandwidth of 200 MHz. Cat 5e supports 100 MHz, cat 6 250 MHz and cat 6a 500 MHz. However, with NBASE-T downshift (with the N in NBASE-T meaning 2.5/5GE) the devices on both ends try the highest speed they have in common and "downshift" if that doesn't work reliably. So in practice you'll often get better speeds than expected for the cable type, especially for shorter cables and if there's no other cables running together for significant stretches. NBASE-T downshift can also be applied to 10GE, GE and 100 Mbps Ethernet.

So from the table above, it's pretty obvious that you'll want to avoid cat 5. Turns out that a good number of the (relatively short) Ethernet cables I have lying around are cat 5. I'll have to be careful to only use those in places where I won't be using GE+ speeds for the foreseeable future.

But... is it worth the trouble to use cat 6 or better?

Well, you definitely don't need cat 6a in a regular home, as you're not going to exceed cat 6's 55 meter limit for 10GE. So it's between cat 5e and cat 6.

A couple of years ago, I installed cat 6 between the living room where the cable modem resides and my home office. This was F/UTP. In addition to the shielding, there's a plastic spline in the cable that keeps the four twisted pairs apart. All of this makes the cable a lot thicker and harder to bend than regular cat 5e UTP. Connecting the shielding to shielded connectors at both ends also provides the opportunity for ground loops and the associated electrical shocks.

So I'd say that cheaper and easier to work with (and easier to get in the desired color!) cat 5e is probably a better choice in many cases. Although when laying down cabling that would be very hard to replace, it might be a good idea to install shielded cat 6 or cat 6a—with some extra length to make sure you can replace connectors that prove inadequate when you upgrade to 10GE.

Permalink - posted 2021-03-30

Review: Cable Matters USB 2.5 Gigabit Ethernet adapter

▼ I think it was in 2016 that 2.5 and 5 Gigabit Ethernet was standardized. After a year or two the first USB to 5GE adapters started to appear at about €/$ 100 and about two years ago the first €/$ 50 2.5GE ones. Right now, there's a ton of USB 2.5GE adapters at good prices.

The hardware

I got a Cable Matters one for € 31 off of Amazon. The adapter is a simple black rectangle with a short and relatively stiff (but not too short or too stiff) USB cable sticking out one end, and space for an RJ45 plug at the other end. There's an always-on blue light at the top of the adapter and a green link light and a yellow activity light where the Ethernet cable plugs in. The blue light is not annoyingly bright and the other two will probably face away from you in normal use. The USB cable is type A, but there's a USB-A to USB-C dongle attached to the cable in case you want to plug the adapter into a USB-C port.

The adapter supports 10, 100, 1000 and 2500 Mbps. Unlike even higher speeds (5GE and 10GE) 2.5GBASE-T (2.5GE) uses the same cat 5e wiring and the same 100 meter maximum cable length as 1000BASE-T (Gigabit Ethernet).

The system reports that the adapter requires a modest amount of power at 304 mA (1.5 W).

Drivers

Cable Matters points towards a RealTek download page to get a driver. There is one for MacOS 10.9 - 10.15. I tried installing the driver on a laptop running MacOS 11 "Big Sur", and... that didn't work.

However, even without installing a driver, MacOS recognizes the adapter and the basic features work. These are the features reported by the ifconfig command:

supported media:
    media none
    media autoselect
    media 10baseT/UTP full-duplex
    media 100baseTX full-duplex
    media 1000baseT full-duplex

(I removed the word "mediaopt".)

There is no support for jumboframes or any type of offloading. And: no half duplex, not even for the original 10 Mbps mode. However, the adapter will autonegotiate 2500 Mbps mode, even though the OS reports 1000 Mbps. So you do get the extra speed, even without installing the driver. But it does look like the computer has trouble sleeping with the adapter plugged in.

Under MacOS 10.14 "Mojave", the driver installs without issue. After that, it turns out the adapter has a range of additional capabilities:

capabilities=2b<RXCSUM,TXCSUM,VLAN_HWTAGGING,TSO4>
supported media:
    media none
    media autoselect
    media 10baseT/UTP half-duplex
    media 10baseT/UTP full-duplex
    media 10baseT/UTP full-duplex flow-control
    media 100baseTX half-duplex
    media 100baseTX full-duplex
    media 100baseTX full-duplex flow-control
    media 1000baseT full-duplex
    media 1000baseT full-duplex flow-control
    media 2500Base-T full-duplex
    media 2500Base-T full-duplex flow-control
    media 100baseTX full-duplex energy-efficient-ethernet
    media 100baseTX full-duplex flow-control energy-efficient-ethernet
    media 1000baseT full-duplex energy-efficient-ethernet
    media 1000baseT full-duplex flow-control energy-efficient-ethernet

So now the adapter can do half duplex at 10 and 100 Mbps, energy efficient Ethernet is supported at 100 and 1000 Mbps, as well as checksum offloading and TCP segmentation offloading for IPv4. Also, we can now enable jumboframes up to an MTU of 9194 at 1000 and 2500 Mbps. And wake-on-LAN works.

Performance

As my Ethernet switch tops out at 1000 Mbps, I connected the adapter to my Mac Mini with a direct cable to run some speed tests. I used iperf 3.1.4 for this, with the Mac Mini as the server and a 2016 MacBook Pro as the client. this means I only tested in one direction, which probably matters for the CPU usage I'll discuss below.

With or without the driver, iperf reports 280 megabytes per second (MB/s) and 2.35 Gbps for IPv4 and about a percent less at 277 MB/s and 2.32 Gbps for IPv6.

However, there is a significant difference in CPU usage for IPv4: the no driver 30-second iperf run used 0.8 s CPU time in user mode and 17.5 s for the system for a total of 18.3 s. So:

IPv4: 280 MB/s, 2.35 Gbps, 0.8 + 17.5 = 18.3 s
IPv6: 277 MB/s, 2.32 Gbps, 0.8 + 21.1 = 21.9 s

With the driver installed, that becomes:

IPv4: 280 MB/s, 2.35 Gbps, 1.3 + 9.3 = 10.6 s
IPv6: 277 MB/s, 2.32 Gbps, 0.7 + 19.7 = 20.3 s

So a 40% reduction in CPU use for IPv4 and only 7% for IPv6. This is probably because there is no TCP segmentation offloading for IPv6, only for IPv4. With TSO, the software delivers a very large packet to the Ethernet chip, which will then split that large packet into standard 1500-byte ones. And maybe without TSO6, the TCP checksum must also be calculated in software for IPv6 packets.

I retried my tests with larger packets, but only with the driver installed as this isn't supported without the driver. With a 9000-byte MTU, I got the following results:

IPv4: 270 MB/s, 2.27 Gbps, 1.7 + 8.5 = 10.2 s
IPv6: 294 MB/s, 2.47 Gbps, 0.7 + 5.9 = 6.6 s

So IPv6 got faster as expected, reaching 99% of the maximum line rate. IPv4, on the other hand, got slower, going from 94% efficiency to 91%. Turns out that something weird happens between the 8000- and 9000-byte maximum packet size, as these are the results for 8000 bytes:

IPv4: 284 MB/s, 2.38 Gbps, 1.1 + 5.3 = 6.4 s
IPv6: 294 MB/s, 2.47 Gbps, 0.7 + 5.7 = 6.4 s

IPv4 still isn't faster than without jumboframes, but at least it's not slower, and the CPU use is about a third for both IPv4 and IPv6.

Conclusions

This is a very nice USB Ethernet adapter. If you need a new USB Ethernet adapter, get this one or one like it, the Gigabit Ethernet era is coming to a close.

Permalink - posted 2021-03-03