Building my ARM-Based Homelab
Summary: I’m building a low-power ARM homelab running Kubernetes on an IPv6-only routed network. I’ll experiment with Open-Xchange, OpenStack, VXLAN, and AI frameworks like PyTorch and TensorFlow. [...]
Apparently I'm bored or something? Having to actively fight off the urge to buy a Banana Pi R4 with a tri-band Wifi7 adapter and use it as a 2x10G SFP+ AP with #VxLAN/#EVPN directly to the AP.
The core of my home network is 2x Arista 7050 L3 switches, and I want important infrastructure attached to both of them, ideally via 2x10G (or 40G) fiber. I try to avoid L2 links between infrastructure devices as much as possible and use EVPN to layer my L2 WiFi network, etc over the top of L3. This lets me completely avoid spanning tree and all of the performance/scalability issues that come with it. It works amazingly well. It was a pain to set up, but adding new EVPN devices (Linux, Juniper, or Arista) is fairly trivial, and it simplifies a lot of management issues.
Unfortunately, there really aren't any APs the fit this model today. I *think* Arista's top-tier models come close, but they're in the "don't ask" tier of pricing, with per-year, per-AP support costs that are probably more than I'm willing to pay in total for an AP.
The #BPI_R4 (and especially the new #BPI_R4_Pro) seems to be able to run Linux as a WiFi 7 AP, and it's big enough to run FRR (for OSPF, BGP, and EVPN) and probably be fast enough to make WiFi itself the performance bottleneck, not the CPU or wired network.
Big issues:
- It's a dumb idea. I have working WiFi. Leave it alone.
- The BPI R4 is supposed to work with OpenWRT out of the box, except OpenWRT is sort of the antithesis of what I want in a network device. Too much all-in-one, too much GUI, not enough CLI. Also, it doesn't really support OSPF or BGP, much less EVPN.
- It probably *would* be possible with VyOS, except (a) it likely doesn't have the right driver compiled in (b) their hostapd config generator doesn't seem to support multiple SSIDs or WiFi 7 and (c) I doubt they have a build that will boot on the hardware, so I'd probably end up needing an ARM build system just for this.
- Only 1 of my 4 APs today is really in a place where redundant fiber would be easy. 2 more would be fine, except I don't have 2 free strands to either location, so I'd need to pull another 12-strand MTP trunk to each. The final location would just need to be copper.
- I *really* don't need yet another project.
Как настроить EVPN/VXLAN на коммутаторе: разбираемся на примере KORNFELD
Привет, Хабр! Меня зовут Алексей Августинович, я принимаю участие в разработке операционной системы для линейки коммутаторов KORNFELD. В этом материале расскажу о возможностях нашей сетевой операционной системы, а именно — о поддержке функциональности L2 VXLAN. Настройка EVPN/VXLAN в сетях дата-центров — задача не из простых. Поэтому в материале я поделюсь шаблонами конфигураций, которые вы можете адаптировать под свои задачи, так как логика настройки и синтаксис у KORNFELD схожи с популярными вендорами.
Как мы отказались от транспондеров: практический переход на 400G ZR+
В самом начале всё выглядело достойно: надёжные Arista DCS-7170-64C-F с 64 портами по 100G, проверенные временем, отвечающие всем актуальным на тот момент требованиям. Мы развернули их по всем дата-центрам и чувствовали себя уверенно. Это выглядело оптимальным решением для текущего объёма задач. Но инфраструктура не стоит на месте, особенно когда бизнес растёт. Количество клиентов росло, вместе с ними — сложность и требования к сети. Понадобилось больше гибкости, изоляции, междатацентровой связности. Мы начали смотреть в сторону VXLAN — и тут выяснилось: профиль Q-in-Q в Arista сильно (реально сильно) ограничивает количество MAC-адресов. Не баг, не фейл — просто особенности архитектуры, которая не была рассчитана на те масштабы, в которые мы стремительно ворвались. Вывод был очевиден: пора готовиться к следующему этапу. VXLAN: модно, стильно, масштабируемо Когда требования ясны, становится проще принимать решения. Мы выбрали Huawei CloudEngine CE9855-32DQ — 1U-коммутаторы с поддержкой 400G. Они обеспечивали всё, что было нужно: производительность, надёжность, поддержку актуальных протоколов, включая поддержку VXLAN без ограничений. Именно на них мы реализовали полноценную VXLAN-инфраструктуру между дата-центрами. Всё поднялось без лишнего шума. Быстро, чисто, масштабируемо. Было приятно видеть, как идея превращается в работающий механизм, да ещё и с запасом на будущее (спойлер: как оказалось не очень-то и далекое). Апгрейд транспорта: от 200G DWDM к 400G ZR+ Параллельно с задачей внедрения VXLAN мы понимали, что физическая транспортная сеть требует апгрейда. До этого мы использовали Huawei транспондеры и мукспондеры на базе 200G и 400G DWDM (что, кстати, видно на первой фотографии).
https://habr.com/ru/articles/949758/
#dwdm #vxlan #qinq #network #network_engineer #huawei #arista_networks #zr_zr+ #power #cooling
Поднимаем BGP в облаке: как мы запустили «матрешку» тоннелей и ушли от L2-ограничений в новой локации Рег.облака
Привет, Хабр! На связи Евгений Мартынов, CIO Рег.облака. Сегодня мы подключили вторую зону доступности облака в Москве на базе дата-центра «Медведково-2» . И вместе с новым запуском провели значительный апгрейд технологический базы: пересобрали сетевую архитектуру, ушли от большого L2, навели порядок в изоляции трафика и перевели API на BGP-анонсы. В статье расскажу про конкретные решения — как и что мы пробовали, какие процессы отложили и к каким выводам пришли.
https://habr.com/ru/companies/runity/articles/947912/
#датацентр #датацентры #облако #сетевая_инфраструктура #api #bgp #тоннели #трафик #vxlan #ovn
Привет, Хабр! На связи Евгений Мартынов, CIO Рег.облака. Сегодня мы подключили вторую зону доступности облака в Москве на базе дата-центра «Медведково-2» . И вместе с новым запуском провели...
It looks like WiFi (802.11) has a MTU 2304 bytes vs 1500 bytes for normal Ethernet.
So does this mean that if I want to forward a bunch of VLANs between 2 hosts over WiFi using VxLAN (bridge the ethernet device on the source host to the VxLAN interface).
Can I get the 1500 byte Ethernet MTU payload transported over WiFi if both hosts are connected to the same AP or using point to point WiFi
I've made a bit of progress (tripped config export) https://gist.github.com/sjorge/accc0874b636aa20f7d3ae84d184c1e5
However it's not yet working.
My VM with a VNIC with vlan-id 500 is able to reach 10.24.50.1 with icmp.
I was also able to create a VXLAN interface on it, however no traffic seems to end up bridge1. If I use torch I can see the vxlan udp encapsulated traffic hitting the 'vxlans' interface on the bridge (so I know the traffic is reaching the switches IP), I can also see the un-encapsulated traffic with torsh on the vxlan100 interface.
It's just never hitting bridge1 again it seems.
Any #network engineers out there looking for a job? I'm looking for one or two good engineers to help me build a global network to make our company #selfhosted. Currently have PoPs in 7 countries with plans to expand.
Need to know #bgp, #mpls, #ospf and #vxlan. #linux and #automation skills are useful too.
The position is #fullyremote with occasional travel for hardware installs and maintenance.
Send me your CV or just DM me if you're interested.