KitsNet Network:LAN:absolut:CAPsMAN Migration: Difference between revisions

Peter A. Smode (talk | contribs)
Peter A. Smode (talk | contribs)
No edit summary
Line 3: Line 3:


This document describes the complete migration of CAPsMAN control from
This document describes the complete migration of CAPsMAN control from
'''courvoisier''' to the CHR instance '''absolut''' while keeping wireless client
'''courvoisier''' to the CHR instance '''absolut''' while preserving the existing
traffic off the CHR in the final state.
DHCP architecture and ensuring that wireless client traffic does not
traverse the CHR in the final design.


The migration is performed in two stages:
The migration is performed in two stages:


# '''Interim migration state''' – CAPsMAN moves to Absolut while Guest traffic temporarily traverses the CHR.
# '''Interim migration state''' – CAPsMAN moves to Absolut while Guest traffic may temporarily traverse the CHR.
# '''Final controller‑only state''' – client traffic no longer traverses Absolut.
# '''Final controller-only state''' – wireless client traffic no longer passes through Absolut.


----
== Supporting Configuration Patch Files ==
* [[File:Courvoisier-final-post-migration-patch.rsc.txt]]
* [[File:Absolut-final-controller-only-patch.rsc.txt]]
* [[File:Courvoisier-interim-guest-transport-patch.rsc.txt]]
* [[File:Absolut-interim-migration-patch.rsc.txt]]
----
----


== Architecture Context ==
== Architecture Context ==
Final architecture goals:


{| class="wikitable"
{| class="wikitable"
Line 35: Line 26:
|-
|-
| '''radix.kitsnet.us (192.168.15.1)'''
| '''radix.kitsnet.us (192.168.15.1)'''
| DHCP server for main and IoT WLAN
| DHCP server for main LAN and IoT network
|}
|}


Wireless data traffic must remain on the physical network and must not
Wireless data traffic should remain on the physical LAN through the CAP
traverse the CHR once the migration is complete.
devices and should not traverse the CHR once migration is complete.


----
----
Line 48: Line 39:
! SSID !! Purpose !! DHCP Source
! SSID !! Purpose !! DHCP Source
|-
|-
| KitsNet
| '''KitsNet'''
| trusted WLAN
| trusted WLAN
| radix.kitsnet.us
| radix.kitsnet.us
|-
|-
| KitsNetIN
| '''KitsNetIN'''
| IoT devices
| IoT network
| radix.kitsnet.us
| radix.kitsnet.us
|-
|-
| KitsNetGN
| '''KitsNetGN'''
| guest WLAN
| guest WLAN
| courvoisier
| courvoisier
Line 67: Line 58:
Before beginning the migration verify:
Before beginning the migration verify:


=== CAP state ===
=== CAP registration ===


On Courvoisier:
On '''courvoisier''':


<pre>
<pre>
Line 82: Line 73:
=== CAP configuration ===
=== CAP configuration ===


On Able and Baker:
On '''able''' and '''baker''':


<pre>
<pre>
Line 98: Line 89:
=== Guest DHCP ===
=== Guest DHCP ===


On Courvoisier:
On '''courvoisier''':


<pre>
<pre>
Line 104: Line 95:
</pre>
</pre>


Confirm DHCP server bound to bridge:
Confirm the DHCP server is bound to bridge:


<pre>
<pre>
Line 112: Line 103:
----
----


== Stage A – Interim Migration State ==
== CAPsMAN Certificate Migration ==
 
The CAPsMAN controller identity must be preserved during migration.
The active CAPsMAN certificate and CA must be copied from '''courvoisier'''
to '''absolut'''.
 
This avoids CAP authentication failures or WPA handshake problems.
 
=== Step 1 – Identify certificates ===
 
On '''courvoisier''':
 
<pre>
/certificate print
</pre>
 
Identify:
 
* CAPsMAN certificate
* CA certificate
 
Typical names:
 
<pre>
CAPsMAN-488F5A87BE5
auto-ca-488F5A87BE5
</pre>
 
----
 
=== Step 2 – Export certificates ===
 
On '''courvoisier''':
 
<pre>
/certificate export-certificate CAPsMAN-488F5A87BE5 export-passphrase=StrongPass
/certificate export-certificate auto-ca-488F5A87BE5 export-passphrase=StrongPass
</pre>
 
Generated files will appear in:
 
<pre>
/file print
</pre>
 
Typical exported files:
 
* CAPsMAN-488F5A87BE5.crt
* CAPsMAN-488F5A87BE5.key
* auto-ca-488F5A87BE5.crt
 
----
 
=== Step 3 – Transfer certificates to Absolut ===
 
Copy the files to '''absolut''' using:
 
* WinBox file transfer
* SCP
* FTP
 
Example using SCP:
 
<pre>
scp *.crt admin@absolut:/
scp *.key admin@absolut:/
</pre>
 
----
 
=== Step 4 – Import certificates on Absolut ===
 
On '''absolut''':


During migration Guest traffic may temporarily traverse Absolut.
<pre>
This allows the CAPsMAN controller to move while keeping Guest DHCP
/certificate import file-name=CAPsMAN-488F5A87BE5.crt passphrase=StrongPass
hosted on Courvoisier.
/certificate import file-name=CAPsMAN-488F5A87BE5.key passphrase=StrongPass
/certificate import file-name=auto-ca-488F5A87BE5.crt
</pre>


=== Design ===
Verify:


* KitsNet → local forwarding → Radix DHCP
<pre>
* KitsNetIN → unchanged during migration
/certificate print
* KitsNetGN → temporarily central forwarded to Absolut and bridged back to Courvoisier
</pre>


----
----


== Prepare Absolut ==
=== Step 5 – Assign certificates to CAPsMAN ===


On Absolut:
On '''absolut''':


<pre>
<pre>
/caps-man manager set enabled=yes
/caps-man manager set enabled=yes \
certificate=CAPsMAN-488F5A87BE5 \
ca-certificate=auto-ca-488F5A87BE5
</pre>
 
Verify:
 
<pre>
/caps-man manager print
</pre>
</pre>


Import CAPsMAN certificates copied from Courvoisier.
----
 
== Stage A – Interim Migration State ==
 
During migration Guest traffic may temporarily traverse Absolut in order
to maintain connectivity with the Guest DHCP server on courvoisier.
 
=== Prepare Absolut ===


Create temporary Guest bridge:
Create temporary Guest bridge:
Line 142: Line 222:
</pre>
</pre>


Create EoIP transport to Courvoisier:
Create EoIP tunnel to courvoisier:


<pre>
<pre>
Line 151: Line 231:
</pre>
</pre>


Attach EoIP to bridge:
Attach the tunnel to the bridge:


<pre>
<pre>
Line 157: Line 237:
</pre>
</pre>


Change Guest datapath:
Update the Guest datapath:


<pre>
<pre>
Line 165: Line 245:
----
----


== Prepare Courvoisier ==
=== Prepare Courvoisier ===


Create matching EoIP interface:
Create the matching EoIP interface:


<pre>
<pre>
Line 188: Line 268:
=== Step 1 – Move Able ===
=== Step 1 – Move Able ===


On Able:
On '''able''':


<pre>
<pre>
Line 204: Line 284:


* KitsNet connectivity
* KitsNet connectivity
* KitsNetGN guest DHCP
* Guest DHCP
* IoT connectivity
* IoT connectivity
Rollback if needed:
<pre>
/interface wireless cap set caps-man-addresses=192.168.15.6
</pre>


----
----
Line 211: Line 297:
=== Step 2 – Move Baker ===
=== Step 2 – Move Baker ===


On Baker:
On '''baker''':


<pre>
<pre>
Line 217: Line 303:
</pre>
</pre>


Verify both CAPs on Absolut:
Verify both CAPs:


<pre>
<pre>
Line 225: Line 311:
----
----


=== Step 3 – Disable Courvoisier CAPsMAN ===
=== Step 3 – Disable CAPsMAN on Courvoisier ===


Once both CAPs are stable:
Once both CAPs are stable:
Line 243: Line 329:
== Validation ==
== Validation ==


On Absolut:
On '''absolut''':


<pre>
<pre>
Line 249: Line 335:
</pre>
</pre>


On Courvoisier:
On '''courvoisier''':


<pre>
<pre>
Line 255: Line 341:
</pre>
</pre>


Confirm:
Verify:


* clients on KitsNet obtain DHCP from Radix
* clients on KitsNet obtain DHCP from Radix
* guest clients obtain DHCP from Courvoisier
* guest clients obtain DHCP from Courvoisier
* both CAPs remain connected to Absolut
* CAPs remain connected to Absolut


----
----
Line 273: Line 359:
</pre>
</pre>


Re-enable CAPsMAN on Courvoisier if necessary:
Re-enable CAPsMAN:


<pre>
<pre>
Line 281: Line 367:
----
----


== Stage B – Final Controller‑Only State ==
== Stage B – Final Controller-Only State ==


After a permanent Guest L2 path exists outside the CHR:
After a permanent Guest L2 path exists outside the CHR:


On Absolut:
On '''absolut''':


<pre>
<pre>
Line 299: Line 385:
</pre>
</pre>


On Courvoisier:
On '''courvoisier''':


<pre>
<pre>
Line 311: Line 397:


* Absolut runs CAPsMAN only
* Absolut runs CAPsMAN only
* Courvoisier serves Guest DHCP
* Courvoisier continues Guest DHCP
* Radix serves LAN DHCP
* Radix provides LAN DHCP
* CAPs locally forward all client traffic
* CAPs locally forward client traffic
* no wireless data traffic transits the CHR
* No wireless data traffic traverses the CHR

Revision as of 18:40, 12 March 2026

1 CAPsMAN Migration: Courvoisier → Absolut[edit | edit source]

This document describes the complete migration of CAPsMAN control from courvoisier to the CHR instance absolut while preserving the existing DHCP architecture and ensuring that wireless client traffic does not traverse the CHR in the final design.

The migration is performed in two stages:

  1. Interim migration state – CAPsMAN moves to Absolut while Guest traffic may temporarily traverse the CHR.
  2. Final controller-only state – wireless client traffic no longer passes through Absolut.

1.1 Architecture Context[edit | edit source]

Component Role
absolut CAPsMAN controller (control plane only)
courvoisier edge router and Guest DHCP server
radix.kitsnet.us (192.168.15.1) DHCP server for main LAN and IoT network

Wireless data traffic should remain on the physical LAN through the CAP devices and should not traverse the CHR once migration is complete.


1.2 SSID Design[edit | edit source]

SSID Purpose DHCP Source
KitsNet trusted WLAN radix.kitsnet.us
KitsNetIN IoT network radix.kitsnet.us
KitsNetGN guest WLAN courvoisier

1.3 Preconditions[edit | edit source]

Before beginning the migration verify:

1.3.1 CAP registration[edit | edit source]

On courvoisier:

/caps-man remote-cap print detail

Expected:

  • able – Run
  • baker – Run

1.3.2 CAP configuration[edit | edit source]

On able and baker:

/interface wireless cap print

Verify:

enabled: yes
lock-to-caps-man: no
caps-man-addresses: 192.168.15.6

1.3.3 Guest DHCP[edit | edit source]

On courvoisier:

/ip dhcp-server print detail

Confirm the DHCP server is bound to bridge:

BWF.KitsNetG

1.4 CAPsMAN Certificate Migration[edit | edit source]

The CAPsMAN controller identity must be preserved during migration. The active CAPsMAN certificate and CA must be copied from courvoisier to absolut.

This avoids CAP authentication failures or WPA handshake problems.

1.4.1 Step 1 – Identify certificates[edit | edit source]

On courvoisier:

/certificate print

Identify:

  • CAPsMAN certificate
  • CA certificate

Typical names:

CAPsMAN-488F5A87BE5
auto-ca-488F5A87BE5

1.4.2 Step 2 – Export certificates[edit | edit source]

On courvoisier:

/certificate export-certificate CAPsMAN-488F5A87BE5 export-passphrase=StrongPass
/certificate export-certificate auto-ca-488F5A87BE5 export-passphrase=StrongPass

Generated files will appear in:

/file print

Typical exported files:

  • CAPsMAN-488F5A87BE5.crt
  • CAPsMAN-488F5A87BE5.key
  • auto-ca-488F5A87BE5.crt

1.4.3 Step 3 – Transfer certificates to Absolut[edit | edit source]

Copy the files to absolut using:

  • WinBox file transfer
  • SCP
  • FTP

Example using SCP:

scp *.crt admin@absolut:/
scp *.key admin@absolut:/

1.4.4 Step 4 – Import certificates on Absolut[edit | edit source]

On absolut:

/certificate import file-name=CAPsMAN-488F5A87BE5.crt passphrase=StrongPass
/certificate import file-name=CAPsMAN-488F5A87BE5.key passphrase=StrongPass
/certificate import file-name=auto-ca-488F5A87BE5.crt

Verify:

/certificate print

1.4.5 Step 5 – Assign certificates to CAPsMAN[edit | edit source]

On absolut:

/caps-man manager set enabled=yes \
 certificate=CAPsMAN-488F5A87BE5 \
 ca-certificate=auto-ca-488F5A87BE5

Verify:

/caps-man manager print

1.5 Stage A – Interim Migration State[edit | edit source]

During migration Guest traffic may temporarily traverse Absolut in order to maintain connectivity with the Guest DHCP server on courvoisier.

1.5.1 Prepare Absolut[edit | edit source]

Create temporary Guest bridge:

/interface bridge add name=BWF.KitsNetG

Create EoIP tunnel to courvoisier:

/interface eoip add name=EOIP.KitsNetG.to.Courvoisier \
 local-address=<ABSOLUT_IP> \
 remote-address=192.168.15.6 \
 tunnel-id=120

Attach the tunnel to the bridge:

/interface bridge port add bridge=BWF.KitsNetG interface=EOIP.KitsNetG.to.Courvoisier

Update the Guest datapath:

/caps-man datapath set [find name="DP.KitsNetG"] local-forwarding=no bridge=BWF.KitsNetG

1.5.2 Prepare Courvoisier[edit | edit source]

Create the matching EoIP interface:

/interface eoip add name=EOIP.KitsNetG.to.Absolut \
 local-address=192.168.15.6 \
 remote-address=<ABSOLUT_IP> \
 tunnel-id=120

Attach to Guest bridge:

/interface bridge port add bridge=BWF.KitsNetG interface=EOIP.KitsNetG.to.Absolut

1.6 Migration Procedure[edit | edit source]

1.6.1 Step 1 – Move Able[edit | edit source]

On able:

/interface wireless cap set caps-man-addresses=<ABSOLUT_IP>

Verify on Absolut:

/caps-man remote-cap print
/caps-man interface print

Test:

  • KitsNet connectivity
  • Guest DHCP
  • IoT connectivity

Rollback if needed:

/interface wireless cap set caps-man-addresses=192.168.15.6

1.6.2 Step 2 – Move Baker[edit | edit source]

On baker:

/interface wireless cap set caps-man-addresses=<ABSOLUT_IP>

Verify both CAPs:

/caps-man remote-cap print

1.6.3 Step 3 – Disable CAPsMAN on Courvoisier[edit | edit source]

Once both CAPs are stable:

/caps-man manager set enabled=no

Lock CAPs:

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

1.7 Validation[edit | edit source]

On absolut:

/caps-man registration-table print

On courvoisier:

/ip dhcp-server lease print

Verify:

  • clients on KitsNet obtain DHCP from Radix
  • guest clients obtain DHCP from Courvoisier
  • CAPs remain connected to Absolut

1.8 Rollback[edit | edit source]

If migration fails revert CAPs to Courvoisier.

On CAP:

/interface wireless cap set caps-man-addresses=192.168.15.6

Re-enable CAPsMAN:

/caps-man manager set enabled=yes

1.9 Stage B – Final Controller-Only State[edit | edit source]

After a permanent Guest L2 path exists outside the CHR:

On absolut:

/caps-man datapath set [find name="DP.KitsNetG"] local-forwarding=yes

Remove temporary EoIP:

/interface bridge port remove [find interface="EOIP.KitsNetG.to.Courvoisier"]
/interface eoip remove EOIP.KitsNetG.to.Courvoisier
/interface bridge remove BWF.KitsNetG

On courvoisier:

/interface bridge port remove [find interface="EOIP.KitsNetG.to.Absolut"]
/interface eoip remove EOIP.KitsNetG.to.Absolut

1.10 Final State[edit | edit source]

  • Absolut runs CAPsMAN only
  • Courvoisier continues Guest DHCP
  • Radix provides LAN DHCP
  • CAPs locally forward client traffic
  • No wireless data traffic traverses the CHR