Segmenten, adressen en aansluitingen

Scheiding werkt in drie lagen: segmenten (VLAN’s) op de bundels van de servers, een routeringsdomein per zone in de fabric, en gedeclareerde netwerken met netwerkbeleid in de clusters.

Beheer, opslag, live-migratie en applicatieverkeer lopen over gescheiden netwerken: per verkeerssoort een eigen VLAN op één bundel, per zone een eigen routeringsdomein, opslag- en migratienetwerken zonder gateway, en geen route tussen opslag- en applicatienetwerken. Alleen het apparatuurbeheer is ook fysiek gescheiden, op een eigen poort op de beheer-leaf.

De opslagnetwerken volgen het opslagontwerp: het opslagclientnetwerk (VLAN 620) en het interne opslagnetwerk (VLAN 621) zijn nooit gerouteerd en hebben MTU 9000 van begin tot eind; de objecttoegang (VLAN 622) is gerouteerd. Er is geen route tussen applicatie- en opslagnetwerken.

Een segment zonder gateway isoleert op zichzelf niet. Daarom laten toegangslijsten op de leaf in het opslagclientnetwerk alleen verkeer naar de opslagknooppunten en de objectgateways toe, niet tussen werkers onderling. Dat netwerk is per cel een /22 uit Infoblox, geregistreerd in NetBox, want een /24 is te klein; iedere werker krijgt er een statisch adres uit een reeks per cluster, vastgelegd in de clusterdefinitie, zonder DHCP. Alleen werkers van clusters met directe opslagtoegang, buiten de herstelzone, krijgen er een secundaire interface.

Het VLAN-nummer van een segment is in beide cellen gelijk. Het L2-VNI is 10.000 plus het VLAN-nummer, behalve bij het EVPN-koppelvlak en de netwerken vanuit clusters; L3-VNI’s horen bij routeringsdomeinen, niet bij afzonderlijke subnetten.

De segmenten van de fabric met hun VLAN, L2-VNI, routeringsdomein en adresreeks per cel.

De reeksen in het segmentplan zijn toewijzingsregels, geen actuele configuratie: het definitieve subnet komt uit de registratie. Voor een netwerk vanuit een cluster volgen het concrete routeringsdomein en de adressen de goedgekeurde declaratie en registratie; ieder ander afzonderlijk segment volgt de registratie.

Gehoste clusters met een platformfunctie, zoals het bouwcluster, het portaalcluster en later het besturingscluster van het dienstennetwerk, staan niet in een afnemerszone maar in het platformdomein, elk met een eigen segment uit VLAN 700–709 en een /26 uit de platformreeks. Hun adressen komen, zoals bij afnemers, via DHCP-doorgifte naar Infoblox.

Ieder werker-VLAN van een applicatiecluster heeft een /26 in het routeringsdomein van zijn dienstprofiel. Werkers, het ingangsadres en de databaseadressen van het cluster delen die /26, en zij is de bron van de uitgaande verbindingen van het cluster: filterregels op de firewall noemen die clusterreeks als bron.

De vaste adressen, VLAN’s en AS-nummers van de fabric zelf.

Iedere server hangt met één LACP-bundel aan het leaf-paar van zijn rek; zijn rol bepaalt welke VLAN’s op de trunk staan, met VLAN 610 ongetagd.

Ieder applicatiecluster heeft een eigen netwerk. De automatisering maakt bij het aanmaken van het cluster een segment aan in het routeringsdomein van het dienstprofiel, met anycast-gateway en DHCP-doorgifte naar Infoblox, op de bundels van alle werkerknooppunten van de werkervirtualisatie in de cel, en verwijdert het bij beëindiging. Het leverpad gebruikt daarvoor dezelfde keten als iedere wijziging van de fabric: registratie, een wijzigingsvoorstel dat onder vaste voorwaarden automatisch wordt samengevoegd, uitrol op de leaves en nacontrole. Het segment is binnen 15 minuten gereed en laat na beëindiging geen restanten achter; de beleidstoetsing weigert een VLAN of reeks buiten het profiel.

De clusters gebruiken de fabric in patronen die van licht naar steeds dieper geïntegreerd lopen.

De eerste levering gebruikt alleen het segment per applicatiecluster. Route-aankondiging, EVPN vanuit clusters en een eigen routeringsdomein per afnemer volgen de routekaart, ieder na een proef in de leeromgeving; bij de acceptatie van de fase bevestigt de leverancier de ondersteuning.

Met route-aankondiging melden fysieke clusters hun dienstadressen en gedeclareerde netwerken zelf aan de leaves van hun rek, met een filter dat alleen geregistreerde reeksen toelaat. Dat vervangt de aankondiging via laag 2, waarbij al het verkeer voor een dienstadres via één werker loopt: werkers in meerdere rekken kondigen het adres dan tegelijk aan en het verkeer wordt verdeeld. Tot die fase werkt MetalLB in laag 2-modus.

EVPN vanuit clusters is de variant voor de migratie van bestaande toepassingen: een fysiek cluster neemt zelf deel aan de overlay en laat een bestaand netwerkverband tot in het cluster doorlopen, zodat een toepassing kan verhuizen zonder van adres te veranderen. Het werkt niet samen met IPsec of EgressIP, en een doorgetrokken laag 2-verband blijft binnen één cel.

Tunneleindpunten van clusters die zelf EVPN spreken, staan in de onderlaag (VLAN 660) en bereiken de leaves rechtstreeks, niet via de firewall. Hun sessies zijn beperkt tot BGP, BFD en VXLAN met vastgelegde buren en geregistreerde reeksen: het prefixfilter weigert een niet-geregistreerde reeks en de fabric een niet-geregistreerd VNI. In de onderlaag krijgt alleen het besturingsverkeer de beschermde verkeersklasse, niet het hele segment van de tunneleindpunten.

De datacenterregistratie draait NetBox 4.7.1 in eigen beheer, via de community-Helm-chart met een vastgezette beeldversie, met PostgreSQL 15 of hoger (met ltree) op CloudNativePG en Valkey of Redis 6 of hoger. Aanmelding loopt via OIDC met Keycloak, iedere automatiseringsidentiteit heeft een eigen API-token en er is een dagelijkse back-up. De Ansible-collectie netbox.netbox wordt tegen 4.7 aangetoond in de leeromgeving; anders gebruikt de automatisering de API rechtstreeks.

Adressen, namen, regelset en profielen per cel staan alleen in het detailontwerp per cel en in de registratie, zodat de gegevens per locatie op één plek staan.

Per cel moeten de werkelijke VLAN-toewijzingen, IP-adressen, interfaces, DNS-weergaven en firewallobjecten in de registratie worden vastgelegd.

Het adresplan van de eerste levering is IPv4. In groeipadstap 3 krijgen alleen het ingangssegment met de virtuele adressen van de externe verkeersverdeling, de koppeling met het RWS-netwerk en de zoneregels van extern naar ingang IPv6 naast IPv4; naar achteren en binnen het platform blijft het verkeer IPv4. De clusters blijven IPv4, zodat de afsluitende IPv4-regel van de EgressFirewall volstaat.

Een koppeling naar een bestemming met alleen IPv6 vertaalt het firewallcluster aan de rand (NAT46), aangetoond met de testset van de fabric in de fase van route-aankondiging en EVPN vanuit clusters. De terugvaloptie is een IPv4-adres aan de kant van de bron.