View source for KitsNet Network:LAN: KitsNet Wireless Architecture


= KitsNet Wireless Architecture (Post‑Migration) =
CAPsMAN Controller: '''absolut (CHR)'''
Edge Router / L2 Core: '''courvoisier'''
LAN DHCP Provider: '''radix.kitsnet.us (192.168.15.1)'''

This document describes the intended **steady‑state wireless architecture after the CAPsMAN migration** from Courvoisier to Absolut.

----

== Architecture Overview ==

The final design separates the **wireless control plane** from the **wireless data plane**.

* '''CAPsMAN Control Plane''' – runs on the CHR instance '''absolut'''
* '''Wireless Data Plane''' – remains on the physical network through the CAP devices
* '''Client traffic must never transit the CHR'''

This ensures:

* minimal latency
* no wireless throughput bottleneck on the virtual router
* simplified troubleshooting
* resilience if the CHR is restarted

----

== Controller Role (Absolut) ==

Absolut runs CAPsMAN only.

Responsibilities:

* CAP discovery
* wireless configuration distribution
* radio channel management
* provisioning of SSIDs
* monitoring and registration table

Absolut **does not forward client traffic**.

Typical verification:

<pre>
/caps-man manager print
/caps-man remote-cap print
/caps-man registration-table print
</pre>

----

== CAP Devices ==

Current CAP devices:

* '''able'''
* '''baker'''

Hardware: MikroTik cAP ac (RBcAPGi‑5acD2nD)

Each CAP provides:

* 2.4 GHz radio
* 5 GHz radio

Configuration is delivered by CAPsMAN provisioning rules.

----

== SSID Design ==

Three SSIDs are broadcast.

{| class="wikitable"
! SSID !! Purpose !! DHCP Provider !! Forwarding Model
|-
| '''KitsNet'''
| Trusted network
| radix.kitsnet.us
| Local forwarding
|-
| '''KitsNetIN'''
| IoT devices
| radix.kitsnet.us
| Local forwarding
|-
| '''KitsNetGN'''
| Guest network
| courvoisier
| Local forwarding to Guest L2
|}

----

== DHCP Architecture ==

=== Main and IoT networks ===

DHCP service is provided by:

'''radix.kitsnet.us (192.168.15.1)'''

Clients reach Radix because the CAP locally bridges these SSIDs into the main LAN broadcast domain.

----

=== Guest network ===

Guest DHCP remains on '''courvoisier'''.

Courvoisier owns:

<pre>
192.168.12.1/24
bridge: BWF.KitsNetG
DHCP server: DHCP.KitsNetG
</pre>

Guest traffic must reach this broadcast domain through the wired network.

----

== Data Plane Flow ==

=== Trusted WLAN (KitsNet) ===

Client → CAP radio  
CAP → LAN bridge  
LAN → radix DHCP / router  

No CAPsMAN traffic path involved.

----

=== IoT WLAN (KitsNetIN) ===

Client → CAP radio  
CAP → LAN bridge  
LAN → radix DHCP / router  

IoT isolation policies may later be enforced via VLANs or firewall rules.

----

=== Guest WLAN (KitsNetGN) ===

Client → CAP radio  
CAP → Guest L2 domain  
Guest bridge → courvoisier  
courvoisier → Guest DHCP + firewall policy

Guest network remains isolated from the trusted LAN.

----

== CAPsMAN Provisioning Model ==

Provisioning ensures that both CAPs operate symmetrically.

Example verification:

<pre>
/caps-man provisioning print
</pre>

Expected pattern:

* Able 2.4 GHz → KitsNet + IoT + Guest
* Able 5 GHz → KitsNet + Guest
* Baker 2.4 GHz → KitsNet + IoT + Guest
* Baker 5 GHz → KitsNet + Guest

Channel selection should avoid overlap between the two CAPs.

----

== Security Model ==

Key protections:

* CAPs locked to the authorized CAPsMAN controller
* Guest traffic isolated from trusted LAN
* IoT devices separated from user devices where possible
* management VLAN access restricted to administrators

To lock CAPs:

<pre>
/interface wireless cap set lock-to-caps-man=yes
</pre>

----

== Operational Verification ==

Useful commands on Absolut:

<pre>
/caps-man remote-cap print
/caps-man interface print
/caps-man registration-table print
</pre>

Useful commands on Courvoisier:

<pre>
/ip dhcp-server lease print
/interface bridge host print
</pre>

----

== Design Goals ==

The architecture aims to:

* keep the control plane centralized
* keep the data plane local to the wired network
* prevent wireless client traffic from transiting the CHR
* preserve existing DHCP placement
* maintain simple rollback if needed

----

== Future Improvements ==

Potential later improvements:

* full VLAN segmentation of SSIDs
* dedicated IoT VLAN
* automated channel planning
* monitoring integration with Zabbix