Guides
DHCP
Servir le DHCP aux clients derrière SiHA (serveur embarqué sur un segment L2), ou relayer vers un serveur en amont.
SiHA distribue des adresses de deux façons, et vous choisissez par segment :
- Servir — un serveur DHCP embarqué distribue des baux depuis un pool, honore les réservations statiques MAC→IP et persiste les baux à travers les redémarrages. Un serveur par segment L2 (typiquement par VRF).
- Relayer — transférer les requêtes d’un segment vers un serveur DHCP en amont existant, accessible via le réseau routé.
Les deux sont des services que SiHA offre aux clients derrière lui — et non l’adresse propre de l’appliance (la NIC de management est une préoccupation distincte).
Servir
Un segment servi correspond à trois ressources qui fonctionnent ensemble. SiHA termine le
segment en tant que bridge L2 ; le BVI du bridge porte la passerelle, un tap
porte l’adresse du serveur DHCP, et le DHCPServer définit le pool.
# 1. The bridge — its BVI is the segment gateway (DHCP option "router").
type: Interfaces.link.siha
metadata: { namespace: link, id: lan }
spec:
kind: bridge
adminUp: true
members: [lan-nic] # the physical port(s) on the segment
bvi:
addresses: ["10.20.0.1/24"] # the gateway clients are handed
# vrf: tenant-a # omit for the default VRF
---
# 2. The server tap — its kernel IP is the DHCP server address.
type: Interfaces.link.siha
metadata: { namespace: link, id: dhcp-tap }
spec:
kind: tap
adminUp: true
hostKernel: dhcplan # host-side netdev name
hostAddresses: ["10.20.0.2/24"] # the DHCP server identifier
l2Bridge: lan # attach this tap to the bridge above
---
# 3. The DHCP server.
type: DHCPServers.dhcp.siha
metadata: { namespace: dhcp, id: lan }
spec:
bridge: lan
serverTap: dhcp-tap
subnet: 10.20.0.0/24
gateway: 10.20.0.1 # must equal the BVI address
pool: { start: 10.20.0.100, stop: 10.20.0.200 }
leaseSeconds: 3600
dns: ["10.20.0.1"]
domain: lan.internal
reservations:
- { mac: "aa:bb:cc:00:11:22", ip: 10.20.0.77 }
allowFrom: ["aa:bb:cc"] # see "Scoping clients" below
La passerelle (10.20.0.1, sur le BVI) et l’adresse du serveur (10.20.0.2, sur
le tap) sont délibérément deux adresses différentes sur le même segment. C’est cette
séparation qui permet à un client de renouveler proprement : il renouvelle auprès de l’adresse du serveur, et
le bridge la délivre directement au tap tandis que le BVI reste la passerelle.
Vous n’avez pas à y penser — donnez simplement au tap sa propre adresse dans le
sous-réseau, distincte de la passerelle.
config apply recoupe les trois : le serverTap doit être un kind: tap
dont le l2Bridge est le bridge, gateway doit être égal à l’adresse du BVI, et deux
serveurs ne peuvent pas partager un même tap.
Réservations
Une réservation fixe un client (par MAC) à une adresse figée. Les adresses de réservation doivent se trouver dans le sous-réseau, doivent différer de la passerelle et de l’adresse du serveur, et peuvent tomber à l’intérieur de la plage du pool (le serveur les saute lors de la distribution des baux dynamiques).
Restreindre les clients (allowFrom)
allowFrom est obligatoire et fail-closed : un serveur sans allowFrom
ne sert personne. Il fait correspondre l’adresse matérielle du client (chaddr) — chaque entrée est
une MAC complète (aa:bb:cc:dd:ee:ff) ou un préfixe OUI de 3 octets (aa:bb:cc). Une plage
d’IP source n’est pas acceptée : un client en train de découvrir une adresse n’a pas encore d’IP, si bien
que le filtrage par IP ne peut pas le conditionner. Pour servir tout le monde, listez explicitement
l’ensemble d’OUI générique.
Relayer
Là où un serveur DHCP en amont existe déjà, relayez vers lui au lieu de servir :
type: DHCPProxies.dhcp.siha
metadata: { namespace: dhcp, id: tenant-b }
spec:
vrf: tenant-b # the client-facing VRF (empty = default)
servers: ["10.99.0.10"] # upstream DHCP servers, reachable via the FIB
srcAddress: 10.30.0.1 # SiHA's relay-agent source address
Au plus un relais peut exister par VRF côté client.
Exploitation
S="sihactl --sihaconfig ~/.siha/config --addr <node-ip>:6443"
$S get dhcpserver # list servers + status (listening, leases used)
$S get dhcpserver lan -o yaml # full status: leases, offers/acks/naks, errors
$S get dhcpproxy # list relays
# On a client behind the segment:
dhclient -v eth0 # acquire
DHCPServerStatus rapporte si la socket est en écoute (listening), le
sous-réseau/passerelle/server-id reflétés, leasesUsed/leasesFree, les cumuls
offers/acks/naks/declines, et la dernière erreur. Les mêmes compteurs sont exposés au
plan de métriques.
Dans un fleet.yaml
Les exemples ci-dessus sont les ressources COSI brutes. Si vous générez votre configuration depuis
un fleet.yaml avec sihactl gen config, vous déclarez le bridge et le tap comme entrées
explicites dans network.interfaces, et le serveur DHCP sous dhcp.servers. Le serveur lui-même
déclare quel bridge et quel tap utiliser :
appliances:
- name: fw1
endpoint: "192.0.2.10:6443"
network:
interfaces:
- name: lan-nic
pci: "0000:06:00.0"
- name: lan
bridge:
members: [lan-nic]
bvi:
addresses: ["10.20.0.1/24"]
- name: dhcp-tap
tap:
hostDevice: dhcplan
hostAddresses: ["10.20.0.2/24"]
l2Bridge: lan
dhcp:
servers:
- name: lan
bridge: lan
serverTap: dhcp-tap
subnet: 10.20.0.0/24
gateway: 10.20.0.1
pool: { start: 10.20.0.100, stop: 10.20.0.200 }
allowFrom: ["fa:16:3e"]
gen config génère exactement les ressources montrées ci-dessus — la source fleet.yaml est
une commodité, pas un runtime différent. Le bridge reste une interface de première classe
(attachez-y ACL / NAT / VRRP). Les mêmes garde-fous s’appliquent au moment de la génération :
un bridge manquant, un serverTap qui n’est pas un tap attaché au bridge déclaré, une
passerelle qui n’est pas l’adresse du BVI, un allowFrom vide, ou une collision de nom sont
rejetés avant que vous n’appliquiez.
Sur une fabric cloud
Le modèle « servir » nécessite que la fabric du segment laisse passer le trafic DHCP de SiHA. Sur un cloud (ou tout pont virtuel filtrant), cela signifie que le réseau servi doit avoir l’anti-usurpation désactivée sur ses ports (ou le CIDR du pool de SiHA dans les paires d’adresses autorisées) et aucun second serveur DHCP dessus — sinon la fabric rejette les réponses de SiHA comme du DHCP-pirate, ou un second serveur entre en concurrence. Un segment L2 isolé avec ces deux réglages suffit ; rien d’autre n’est requis. Le relais est moins sensible à la fabric — il lui suffit que les serveurs en amont soient routables.
Le mode « servir » est validé de bout en bout (acquisition + renouvellement) en labo comme sur un cloud public.