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

Back to version history
Newer edit →
VisualWikitext
Peter A. Smode (talk | contribs)
administrator, Bureaucrats, family, kitsnet_adm, Administrators
2,612 edits
Created page with "= CAPsMAN Migration Plan = Courvoisier → Absolut (CHR) == Objectives == # Move CAPsMAN control from '''Courvoisier''' to '''Absolut''' # Preserve current SSIDs and datapath behavior during migration # Ensure '''no client traffic passes through Absolut''' # Avoid network disruption # Allow immediate rollback # Perform datapath cleanup '''after migration''' ---- == Phase 0 — Pre-Migration Verification == Verify current operational state. === On Courvoisier === <..."
 
Peter A. Smode (talk | contribs)
administrator, Bureaucrats, family, kitsnet_adm, Administrators
2,612 edits
No edit summary
Line 1: Line 1:
= CAPsMAN Migration Plan =
 
= CAPsMAN Migration Plan (Interim → Final) =
Courvoisier → Absolut (CHR)
Courvoisier → Absolut (CHR)


== Objectives ==
This revision reflects the updated priority:


# Move CAPsMAN control from '''Courvoisier''' to '''Absolut'''
# Complete the CAPsMAN migration first
# Preserve current SSIDs and datapath behavior during migration
# Temporary Guest-path inefficiency during migration is acceptable
# Ensure '''no client traffic passes through Absolut'''
# By the final state, client traffic must stay off Absolut
# Avoid network disruption
# Courvoisier must continue serving the KitsNetGN guest DHCP scope
# Allow immediate rollback
# Main SSID DHCP continues to come from radix.kitsnet.us (192.168.15.1)
# Perform datapath cleanup '''after migration'''
# Avoid mixing large redesign work into the controller cutover


----
----


== Phase 0 — Pre-Migration Verification ==
== Why this staged plan is needed ==


Verify current operational state.
The current configuration shows:


=== On Courvoisier ===
* Courvoisier central‑forwards Guest to BWF.KitsNetG and serves Guest DHCP there.
* Main SSID traffic lives on the main bridge where Radix provides DHCP.
* Absolut currently has datapaths configured for local forwarding and does not yet replicate the Guest bridge design.
* Baker 2.4 GHz provisioning lacks the IoT SSID compared with Able.


<pre>
Because of this the migration uses two stages:
/caps-man remote-cap print detail
</pre>


Expected:
* '''Interim state''' – Guest traffic temporarily traverses Absolut but is bridged back to Courvoisier so DHCP remains there.
* '''Final state''' – Guest traffic no longer traverses Absolut once an off‑CHR L2 path exists.


<pre>
----
identity="able"
identity="baker"
state="Run"
</pre>


=== On Able ===
== Stage A — Interim Migration State ==


<pre>
=== Design intent ===
/interface wireless cap print
</pre>


Verify:
* '''KitsNet''' – locally forwarded; DHCP from Radix on the LAN
* '''KitsNetIN''' – unchanged during migration
* '''KitsNetGN''' – temporarily central‑forwarded via Absolut then bridged back to Courvoisier


<pre>
This keeps the network functional while moving CAPsMAN.
enabled: yes
lock-to-caps-man: no
caps-man-addresses: 192.168.15.6
</pre>


=== On Baker ===
=== Interim prerequisites ===


Run the same command and confirm identical settings.
# Import Courvoisier CAPsMAN certificate and CA into Absolut
# Enable CAPsMAN on Absolut
# Create temporary Guest EoIP link between Absolut and Courvoisier
# Set DP.KitsNetG to central forwarding during migration
# Keep DP.KitsNet locally forwarded
# Correct Baker 2.4 GHz provisioning symmetry


=== Confirm Courvoisier owns the manager IP ===
=== Interim cutover sequence ===


<pre>
# Prepare Guest EoIP bridge on both routers
/ip address print
# Verify Absolut CAPsMAN configuration
</pre>
# Move Able to Absolut
# Validate Able
# Move Baker to Absolut
# Validate Baker
# Disable CAPsMAN on Courvoisier
# Re‑lock CAPs


Verify:
=== Interim success criteria ===


<pre>
* Able and Baker show '''Run''' on Absolut
192.168.15.6/23
* KitsNet clients obtain DHCP from Radix
</pre>
* KitsNetGN clients obtain DHCP from Courvoisier
* IoT devices remain functional
* Only Guest traffic temporarily traverses Absolut


----
----


== Phase 1 — Prepare Absolut ==
== Stage B — Final Controller‑Only State ==
 
This phase does '''not impact the network'''.


=== Enable CAPsMAN ===
=== Design intent ===


On Absolut:
By the end state, Absolut acts only as the CAPsMAN controller.


<pre>
Requirements:
/caps-man manager set enabled=yes
</pre>


Verify:
* DP.KitsNetG changed back to '''local‑forwarding=yes'''
* Temporary EoIP bridge removed
* Guest L2 path provided elsewhere on the wired network


<pre>
=== Final transition sequence ===
/caps-man manager print
</pre>


=== Verify CAPsMAN configuration objects exist ===
# Prepare off‑CHR Guest L2 transport
# Change DP.KitsNetG back to local forwarding
# Remove temporary EoIP bridge on Absolut
# Remove EoIP on Courvoisier
# Validate Guest DHCP and isolation


<pre>
=== Final success criteria ===
/caps-man configuration print
/caps-man provisioning print
/caps-man datapath print
</pre>


Ensure the following objects exist:
* CAPs remain attached to Absolut
 
* Main SSID DHCP still provided by Radix
* able-2.4-KitsNet
* Guest DHCP still provided by Courvoisier
* able-5.0-KitsNet
* No client traffic passes through Absolut
* baker-2.4-KitsNet
* Temporary EoIP removed
* baker-5.0-KitsNet
* slave-KitsNetGN
* slave-KitsNetIN
 
Do '''not modify datapaths yet'''.
 
=== Confirm forwarding behavior ===
 
<pre>
/caps-man datapath print
</pre>
 
Expected:
 
<pre>
local-forwarding: yes
</pre>


----
----


== Phase 2 — Copy Certificates ==
== Detailed Execution ==
 
Preserve CAP trust identity.


=== On Courvoisier ===
=== Phase 0 — Pre‑checks ===


List certificates:
On Courvoisier:


<pre>
<pre>
/certificate print
/caps-man remote-cap print detail
/caps-man datapath print detail
/ip dhcp-server print detail
/ip address print
</pre>
</pre>


Export the CAPsMAN certificate and CA:
Confirm both CAPs connected and Guest DHCP bound to BWF.KitsNetG.
 
<pre>
/certificate export-certificate <capsman-cert> export-passphrase=StrongPass
/certificate export-certificate <capsman-ca> export-passphrase=StrongPass
</pre>


Files created:
On Able and Baker:


<pre>
<pre>
<cert>.crt
/interface wireless cap print
<cert>.key
<ca>.crt
</pre>
</pre>


=== Copy files to Absolut ===
Verify:
 
Use SCP, WinBox, or FTP.
 
=== On Absolut ===
 
Import certificates:


<pre>
<pre>
/certificate import file-name=<cert>.crt
enabled: yes
/certificate import file-name=<cert>.key
lock-to-caps-man: no
/certificate import file-name=<ca>.crt
caps-man-addresses: 192.168.15.6
</pre>
</pre>


Assign them:
On Absolut:
 
<pre>
/caps-man manager
set certificate=<capsman-cert> ca-certificate=<capsman-ca>
</pre>
 
Verify:


<pre>
<pre>
/caps-man manager print
/caps-man manager print
/caps-man datapath print detail
/caps-man provisioning print detail
</pre>
</pre>


----
----


== Phase 3 — Migration (One CAP First) ==
=== Phase 1 — Prepare Absolut ===


Move '''Able''' first.
Apply the interim Absolut migration patch which:


=== On Able ===
* enables CAPsMAN
* creates temporary Guest bridge
* creates EoIP tunnel
* sets Guest datapath to central forwarding
* fixes Baker provisioning


Change manager address:
----
 
<pre>
/interface wireless cap
set caps-man-addresses=<absolut-ip>
</pre>


Example:
=== Phase 2 — Prepare Courvoisier ===


<pre>
Apply the interim Guest transport patch.
/interface wireless cap
set caps-man-addresses=192.168.15.25
</pre>


Expected behavior: within ~10 seconds Able disconnects from Courvoisier and connects to Absolut.
This creates the matching EoIP interface and adds it to BWF.KitsNetG.


----
----


== Phase 4 — Validate Able ==
=== Phase 3 — Migrate Able ===
 
=== On Absolut ===


<pre>
<pre>
/caps-man remote-cap print detail
/interface wireless cap set caps-man-addresses=&lt;ABSOLUT_IP&gt;
</pre>
</pre>


Expected:
Validate on Absolut:
 
<pre>
identity="able"
state="Run"
</pre>
 
=== Verify radios ===


<pre>
<pre>
/caps-man remote-cap print
/caps-man interface print
/caps-man interface print
</pre>
Expected:
<pre>
able-2.4-KitsNet
able-5.0-KitsNet
slave-KitsNetGN
slave-KitsNetIN
</pre>
=== Verify clients ===
<pre>
/caps-man registration-table print
/caps-man registration-table print
</pre>
</pre>


Test client connectivity for:
Rollback if necessary:
 
* KitsNet
* KitsNetGN
* KitsNetIN
 
----
 
== Phase 5 — Migrate Baker ==
 
On Baker:
 
<pre>
/interface wireless cap
set caps-man-addresses=<absolut-ip>
</pre>
 
Verify on Absolut:


<pre>
<pre>
/caps-man remote-cap print
/interface wireless cap set caps-man-addresses=192.168.15.6
</pre>
 
Expected:
 
<pre>
able  Run
baker  Run
</pre>
</pre>


----
----


== Phase 6 — Validate Full Operation ==
=== Phase 4 — Migrate Baker ===
 
Confirm:


<pre>
Repeat the same command on Baker.
/caps-man interface print
/caps-man registration-table print
/caps-man radio print
</pre>


----
----


== Phase 7 — Disable CAPsMAN on Courvoisier ==
=== Phase 5 — Retire Courvoisier CAPsMAN ===
 
Once migration is stable:


<pre>
<pre>
Line 282: Line 193:
</pre>
</pre>


----
Then re‑lock the CAPs.
 
== Phase 8 — Re-Lock CAPs ==
 
On Able:
 
<pre>
/interface wireless cap
set lock-to-caps-man=yes
</pre>
 
On Baker:
 
<pre>
/interface wireless cap
set lock-to-caps-man=yes
</pre>


----
----


== Phase 9 — Post-Migration Datapath Cleanup ==
=== Phase 6 — Final cleanup later ===
 
This will be performed '''after the migration''' as a separate exercise.
 
Possible improvements:


* correct IoT datapath usage
After the off‑CHR Guest path exists:
* enforce VLAN isolation
* ensure Able/Baker provisioning symmetry
* validate forwarding model


No datapath changes are made during the migration.
# Apply Absolut final controller patch
# Apply Courvoisier cleanup patch
# Verify DHCP and isolation


----
----


== Rollback Procedure ==
== Scope notes ==
 
If anything fails:
 
On Able:


<pre>
Included:
/interface wireless cap
set caps-man-addresses=192.168.15.6
</pre>
 
On Baker:
 
<pre>
/interface wireless cap
set caps-man-addresses=192.168.15.6
</pre>
 
CAPs will reconnect to Courvoisier within seconds.
 
----


== Final Sanity Checklist ==
* CAPsMAN migration
* Temporary Guest bridge
* Baker provisioning fix


Before migration confirm:
Deferred:


* Absolut CAPsMAN enabled
* VLAN redesign
* Certificates imported
* IoT policy redesign
* CAPs unlocked
* channel plan changes
* Provisioning objects present
* Datapaths unchanged
* Rollback command prepared

Revision as of 18:05, 12 March 2026

1 CAPsMAN Migration Plan (Interim → Final)[edit | edit source]

Courvoisier → Absolut (CHR)

This revision reflects the updated priority:

  1. Complete the CAPsMAN migration first
  2. Temporary Guest-path inefficiency during migration is acceptable
  3. By the final state, client traffic must stay off Absolut
  4. Courvoisier must continue serving the KitsNetGN guest DHCP scope
  5. Main SSID DHCP continues to come from radix.kitsnet.us (192.168.15.1)
  6. Avoid mixing large redesign work into the controller cutover

1.1 Why this staged plan is needed[edit | edit source]

The current configuration shows:

  • Courvoisier central‑forwards Guest to BWF.KitsNetG and serves Guest DHCP there.
  • Main SSID traffic lives on the main bridge where Radix provides DHCP.
  • Absolut currently has datapaths configured for local forwarding and does not yet replicate the Guest bridge design.
  • Baker 2.4 GHz provisioning lacks the IoT SSID compared with Able.

Because of this the migration uses two stages:

  • Interim state – Guest traffic temporarily traverses Absolut but is bridged back to Courvoisier so DHCP remains there.
  • Final state – Guest traffic no longer traverses Absolut once an off‑CHR L2 path exists.

1.2 Stage A — Interim Migration State[edit | edit source]

1.2.1 Design intent[edit | edit source]

  • KitsNet – locally forwarded; DHCP from Radix on the LAN
  • KitsNetIN – unchanged during migration
  • KitsNetGN – temporarily central‑forwarded via Absolut then bridged back to Courvoisier

This keeps the network functional while moving CAPsMAN.

1.2.2 Interim prerequisites[edit | edit source]

  1. Import Courvoisier CAPsMAN certificate and CA into Absolut
  2. Enable CAPsMAN on Absolut
  3. Create temporary Guest EoIP link between Absolut and Courvoisier
  4. Set DP.KitsNetG to central forwarding during migration
  5. Keep DP.KitsNet locally forwarded
  6. Correct Baker 2.4 GHz provisioning symmetry

1.2.3 Interim cutover sequence[edit | edit source]

  1. Prepare Guest EoIP bridge on both routers
  2. Verify Absolut CAPsMAN configuration
  3. Move Able to Absolut
  4. Validate Able
  5. Move Baker to Absolut
  6. Validate Baker
  7. Disable CAPsMAN on Courvoisier
  8. Re‑lock CAPs

1.2.4 Interim success criteria[edit | edit source]

  • Able and Baker show Run on Absolut
  • KitsNet clients obtain DHCP from Radix
  • KitsNetGN clients obtain DHCP from Courvoisier
  • IoT devices remain functional
  • Only Guest traffic temporarily traverses Absolut

1.3 Stage B — Final Controller‑Only State[edit | edit source]

1.3.1 Design intent[edit | edit source]

By the end state, Absolut acts only as the CAPsMAN controller.

Requirements:

  • DP.KitsNetG changed back to local‑forwarding=yes
  • Temporary EoIP bridge removed
  • Guest L2 path provided elsewhere on the wired network

1.3.2 Final transition sequence[edit | edit source]

  1. Prepare off‑CHR Guest L2 transport
  2. Change DP.KitsNetG back to local forwarding
  3. Remove temporary EoIP bridge on Absolut
  4. Remove EoIP on Courvoisier
  5. Validate Guest DHCP and isolation

1.3.3 Final success criteria[edit | edit source]

  • CAPs remain attached to Absolut
  • Main SSID DHCP still provided by Radix
  • Guest DHCP still provided by Courvoisier
  • No client traffic passes through Absolut
  • Temporary EoIP removed

1.4 Detailed Execution[edit | edit source]

1.4.1 Phase 0 — Pre‑checks[edit | edit source]

On Courvoisier: 

/caps-man remote-cap print detail
/caps-man datapath print detail
/ip dhcp-server print detail
/ip address print

Confirm both CAPs connected and Guest DHCP bound to BWF.KitsNetG.

On Able and Baker: 

/interface wireless cap print

Verify: 

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

On Absolut: 

/caps-man manager print
/caps-man datapath print detail
/caps-man provisioning print detail

1.4.2 Phase 1 — Prepare Absolut[edit | edit source]

Apply the interim Absolut migration patch which:

  • enables CAPsMAN
  • creates temporary Guest bridge
  • creates EoIP tunnel
  • sets Guest datapath to central forwarding
  • fixes Baker provisioning

1.4.3 Phase 2 — Prepare Courvoisier[edit | edit source]

Apply the interim Guest transport patch.

This creates the matching EoIP interface and adds it to BWF.KitsNetG.

1.4.4 Phase 3 — Migrate Able[edit | edit source]

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

Validate on Absolut: 

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

Rollback if necessary: 

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

1.4.5 Phase 4 — Migrate Baker[edit | edit source]

Repeat the same command on Baker.

1.4.6 Phase 5 — Retire Courvoisier CAPsMAN[edit | edit source]

/caps-man manager set enabled=no

Then re‑lock the CAPs.

1.4.7 Phase 6 — Final cleanup later[edit | edit source]

After the off‑CHR Guest path exists:

  1. Apply Absolut final controller patch
  2. Apply Courvoisier cleanup patch
  3. Verify DHCP and isolation

1.5 Scope notes[edit | edit source]

Included:

  • CAPsMAN migration
  • Temporary Guest bridge
  • Baker provisioning fix

Deferred:

  • VLAN redesign
  • IoT policy redesign
  • channel plan changes
Retrieved from "https://wiki.kitsnet.us/w/index.php?title=KitsNet_Network:LAN:absolut:CAPsMAN_Migration&oldid=2067"