Steven M. Jordan

ArubaOS Mobility Lab

2026-11-01T12:34:28.262-06:00

Abstract

First day impressions with Aruba Mobility Conductor.

I spent the day standing up an ArubaOS 8 lab. I’d never touched the platform before. The goal wasn’t to become fluent in their CLI (very similar to Cisco IOS, btw). It was an exercise to understand the architecture and compare it to familiar technology.

Limitations

The lab had no Aruba licenses. Nevertheless, the Conductor successfully registered the vMC, established an authenticated IKEv2/IPsec connection, and delivered configuration to the managed controller. License limitations prevented testing Wi-Fi client associations.

This lab skips any GUI. Straight up configuration and validation.

Lab Roles

The Conductor manages configuration, while the controller handles wireless network operations. Aruba's AOS 8 documentation confirms that division.

MM: Mobility Master / Mobility Conductor

This is the management and orchestration brain.

N.B., Aruba renamed Mobility Master to Mobility Conductor.

It owns configuration hierarchy, distributes configuration to managed controllers, and provides centralized management and licensing.

vMC: Virtual Mobility Controller

The managed controller terminates AP tunnels, applies wireless security and user policies, and forwards client traffic.

CHR: MikroTik Cloud Hosted Router

This is our independent switching and routing infrastructure.

It provides gateways, VLAN routing, firewall rules, and traffic inspection.

It also allows us to test network reachability without relying on Aruba's wireless licensing.

Table 2
Lab Nodes, interfaces, VLANs, and IPs

Node	Interface	VLAN	IP Address	Purpose
MM	GE 0/0/0	20	10.10.10.2/24	Aruba Control-Plane
MM	`mgmt`	Untagged	172.16.42.65/24	OOB management
vMC	GE 0/0/0	20	10.10.10.3/24	Aruba Control-Plane
vMC	`mgmt`	Untagged	172.16.42.66/24	OOB management
CHR	`ether3_aruba`	110, 120, 130	NA	Mobility trunk
CHR	`vlan110`	110	10.110.0.1/24	Corporate WLAN gateway
CHR	`vlan120`	120	10.120.0.1/24	Guest WLAN gateway
CHR	`vlan130`	130	10.130.0.1/24	IoT WLAN gateway

Note. The conductor and controller communicate over VLAN 20. Dedicated management interfaces connect separately to the management network. The CHR provides Layer 3 gateways for the corporate, guest, and IoT wireless VLANs.

Registration and the trust relationship

Registration between the MM and vMC initially failed. The process required matching IPsec pre-shared keys from the /mm context:

cd /mm
configure terminal
localip 10.10.10.3 ipsec <matching-PSK>
write memory

After that, the IKEv2/IPsec SAs came up and the Conductor accepted the vMC as a managed device.

Aruba Structure

The Mobility Conductor holds a hierarchy of system nodes, groups, and individual device nodes.

Configuration inheritance flows downward through the hierarchy, from the root node to its child nodes. Each child inherits its parent's configuration while allowing more specific settings or overrides at the group or individual device level.

Table 2.
Configuration Inheritance

Configuration location	Scope
`/`	Global configuration
`/md`	All managed devices
`/md/LAB`	LAB group-specific devices
`/md/LAB/00:15:5d:e7:09:1d`	Individual vMC configuration
`/mm/mynode`	Mobility Conductor-specific configuration

Mobility Conductor-specific

We can define all nodes from the root. But we can also create exceptions at the group or device level. Note everything is overridable.

configure terminal applies to whatever node you’re currently in. Change the node first and the same command lands in a different scope. Configuration defined at /md/LAB is inherited by devices beneath it. The device node itself can create some exceptions at the group or device level.

That inheritance model is native. It is not something you have to assemble from modules the way you do in Terraform or OpenTofu. IaC methodology can provide similar results through explicit references, but Aruba builds the hierarchy into the system.

Composition Rules

Inheritance decides where the configuration belongs in the hierarchy. Composition decides how wireless objects are configured.

I configured composition rules for each SSID. Its configuration was composed into separate profiles. The AP group references a Virtual AP, which in turn references the SSID and AAA objects:

CORP-AP-GRP
    └── CORP-VAP
         ├── CORP-SSID (WPA2-PSK-AES)
         ├── CORP-AAA (authentication-dot1x default)
         └── VLAN 110

Note, two dependency issues: It rejected WPA2-PSK-AES mode until a pre-shared key was added. It also rejected the SSID profile until its AAA profile included an 802.1X profile (even though the SSID used PSK).

After the commit, we validate that the group-defined profiles resolved into the vMC’s configuration:

show configuration effective

That confirmed inheritance. It did not prove the running controller had fully applied the change.

Mapping similar technology

The Conductor hierarchy and the wireless object model had a familiar feel to similar technology.

Concept	ArubaOS 8	Terraform / OpenTofu	MikroTik CAPsMAN	Juniper WLC
Central management	Mobility Conductor	GIT Repository	CAPsMAN controller	WLC or Ringmaster
Shared configuration	Config groups	Shared modules	Profiles	Profiles
Devices	Device nodes	Device and/or root modules	Managed CAPs	Managed APs
Reusable objects	SSID, AAA, VAP profiles	Modules and resources	Security, channel, datapath profiles	SSID, security, and radio profiles
Configuration inheritance	Parent-to-child nodes	Explicit module composition and variables	Profile assignment/ provisioning	Profile assignments
Deployment	Conductor to controller	Orchestration scripts	Provision APs	Provision APs

Aruba’s hierarchy is native. Terraform and OpenTofu give you the framework to build something similar, but you have to supply the structure yourself. Juniper’s WLC and CAPsMAN sit closer to the operational side of the comparison. Both push wireless configuration to APs. Both lean hard on policy and templates over configuration inheritance.

The Next Lab

The next step would expand the lab beyond wireless management and explore Aruba's broader architecture.

I'd introduce a second managed gateway on a separate routed network, to examine remote-site connectivity, VPN concentration, and SD-WAN path selection.

I'd also like to integrate Aruba ClearPass Policy Manager to explore their centralized authentication, role-based access control, and dynamic policy enforcement through RADIUS and 802.1X.

Finally, I'd like to compare the AOS 8 architecture with AOS 10 and Aruba Central. The goal would be to understand the architecture, operational benefits, and tradeoffs.

What Amazon Thinks I Do

2026-10-12T16:46:22.119-05:00

Can I use this as a professional reference? 🤣

Amazon's AI Assessment:

Interests & Hobbies: Frequently reads books about IT management, operations, and security.
Home & Family: Likely works as IT infrastructure expert.
Brands: Specializes in Mikrotik Enterprise networks.
Brands: Specializes in Cisco networks.
Brands: Specializes in Juniper networks.

Rolling out IPv6 on AT&T

2026-10-08T15:52:14.431-05:00

Abstract

Wrangling IPv6 on AT&T. Deployment tips for Prefix Delegation, Router Advertisements, Neighbor Discovery, and stateful firewalling.

The Low-Down

This post walks through IPv6 for AT&T Internet (a non-SLA service behind an AT&T residential gateway). Unlike Spectrum, which hands out a generous /56, AT&T delegates a single /64. Yep. One measly /64. Needlessly small, but we can work with it.

Goal is isolated IPv6 connectivity for a single Windows test VM, with the MikroTik handling the prefix and the firewall keeping the rest of the world out.

Network Topology

ISP: AT&T Business Internet (non-SLA)
Upstream Edge: AT&T Residential Gateway (RG)
Core Router: MikroTik CCR2004-16G-2S+ (RouterOS 7.20)
CCR WAN Interface: ether1_untrust
CCR LAN Bridge: bridge_ipv6
CCR Physical Port: ether16_ipv6
Hypervisor: Microsoft Hyper-V host running a Windows VM

This example works for any RouterOS hardware. ether16_ipv6 is assigned to bridge_ipv6 and patches directly into a dedicated Hyper-V virtual switch isolated from hypervisor management.

Note: IPv4 IP passthrough does not affect IPv6. The AT&T gateway handles IPv6 routing and prefix delegation independent of IPv4. You cannot bypass its IPv6 stack entirely.

Requesting the Prefix

Configure the IPv6 client to request a prefix on the WAN interface:

/ipv6 dhcp-client
add interface=ether1_untrust \
    request=prefix \
    pool-name=att_pd \
    pool-prefix-length=64 \
    add-default-route=yes \
    accept-prefix-without-address=yes

Breakdown:

request=prefix — Requests DHCPv6 Prefix Delegation (IA_PD).
pool-name=att_pd — Creates a dynamic IPv6 pool named att_pd.
pool-prefix-length=64 — Controls the subnet size RouterOS carves out of the pool for downstream interfaces (not the size the ISP gives you).
accept-prefix-without-address=yes — Accepts a delegated prefix even if AT&T does not hand out an IA_NA address on the WAN.
add-default-route=yes — Installs an IPv6 default route via the DHCPv6 client.

Verify the binding:

/ipv6 dhcp-client print detail

Expected output:

interface=ether1_untrust status=bound dhcp-server-v6=fe80::3aa0:67ff:fe81:d662
request=prefix pool-name=att_pd pool-prefix-length=64
prefix=2600:1700:1335:452f::/64

A /64 is the smallest routable subnet, so options are limited: DHCPv6 server, SLAAC, or Unique Local Addresses if you need to route beyond this single segment. ULAs are not used in this lab.

Assign the PD to the LAN Bridge

Bind the /64 to the bridge so it stays current if the ISP renumbers:

/ipv6 address
add interface=bridge_ipv6 \
    from-pool=att_pd \
    advertise=yes

Verify:

/ipv6 address print

2600:1700:1335:452f::/64 FROM-POOL=att_pd INTERFACE=bridge_ipv6 ADVERTISE=yes

RouterOS shows the network address by default for pool assignments. If you want to ping the router itself (for example ::1), explicitly bind that ID:

/ipv6 address add interface=bridge_ipv6 from-pool=att_pd eui-64=::1

Dynamic and static in one.

Router Advertisements and SLAAC

Unlike IPv4, IPv6 clients can auto-configure with SLAAC. The router advertises the prefix via Neighbor Discovery and the clients build their own addresses.

/ipv6 nd
add interface=bridge_ipv6 \
    advertise-dns=yes \
    managed-address-configuration=no \
    other-configuration=no

Check existing ND settings first (/ipv6 nd print detail). RouterOS includes a default *all entry. Make sure you are not advertising back out ether1_untrust toward the AT&T gateway.

Windows natively supports DNS from RAs. Point RDNSS at your preferred resolvers:

/ipv6 nd
set [find where interface=bridge_ipv6] \
    dns=2001:4860:4860::8888,2001:4860:4860::8844 \
    advertise-dns=yes

Not every device supports RDNSS. Android and Xbox often need dual-stack and fall back to IPv4 DNS. Plan accordingly.

Neighbor Discovery Quick Refresher

IPv4 finds neighbors with broadcasts (ARP). IPv6 uses multicast and ICMPv6 Neighbor Discovery.

Router Discovery (Types 133/134): Client multicasts a Router Solicitation to ff02::2. Router replies with a Router Advertisement containing default routes, MTU, lifetimes, and prefixes.
Address Resolution (Types 135/136): Replaces ARP. Uses Neighbor Solicitations to a solicited-node multicast address derived from the target IP. Far less noise than broadcast ARP.

The CCR handles WAN-side NDP to the AT&T gateway automatically over link-local addresses (fe80::/10). No static neighbor entries needed on the WAN.

Hardening IPv6

Global addresses expose devices directly to the Internet. Stateful firewall rules on the WAN are required.

Input chain (protect the router):

/ipv6 firewall filter
add chain=input action=accept connection-state=established,related comment="Accept established/related"
add chain=input action=drop connection-state=invalid comment="Drop invalid"
add chain=input action=accept protocol=icmpv6 comment="Accept essential ICMPv6"
add chain=input action=accept in-interface=ether1_untrust protocol=udp src-port=547 dst-port=546 comment="Allow DHCPv6 reply from RG"
add chain=input action=accept in-interface-list=trust comment="Allow trusted management"
add chain=input action=drop in-interface=ether1_untrust comment="Drop all other unsolicited WAN input"

Forward chain (protect the LAN):

/ipv6 firewall filter
add chain=forward action=accept connection-state=established,related comment="Accept established/related"
add chain=forward action=drop connection-state=invalid comment="Drop invalid"
add chain=forward action=accept protocol=icmpv6 comment="Allow ICMPv6 pass-through"
add chain=forward action=accept in-interface=bridge_ipv6 out-interface=ether1_untrust comment="Allow test LAN outbound"
add chain=forward action=drop in-interface=ether1_untrust out-interface=bridge_ipv6 comment="Block unsolicited WAN to LAN"

Do not drop link-local traffic on the WAN. This rule looks tempting and breaks everything:

# DO NOT USE
/ipv6 firewall raw
add chain=prerouting action=drop in-interface=ether1_untrust src-address=fe80::/10

Legitimate control traffic (RAs, Neighbor Discovery, DHCPv6-PD) relies on fe80::/10 sources. Dropping it collapses the protocol between the WAN interface and the AT&T gateway.

Validate

From the Windows test VM:

ipconfig /all

Look for:

Valid fe80:: link-local address
Valid global address matching the AT&T /64
Default gateway set to the MikroTik’s link-local address
RDNSS DNS resolvers

Quick checks:

ping -6 2001:4860:4860::8888
nslookup google.com 2001:4860:4860::8888
tracert -6 2001:4860:4860::8888

Don’t panic if tracert shows asterisks. Many transit routers deprioritize or drop ICMPv6 Time Exceeded while still forwarding traffic at line rate.

Troubleshooting

During testing I hit an intermittent failure:

The test VM could ping the local bridge and the AT&T RG’s internal interface.
Outbound packets left ether1_untrust.
Public IPv6 traffic died. Replies never came back.
Opening the firewall completely did not fix it.

The fix was simple: renew the DHCPv6 client.

/ipv6 dhcp-client renew 0

RouterOS re-bound to the same prefix and the AT&T gateway immediately started forwarding again. Short-term workaround is to schedule that renew every few hours. Long-term is getting AT&T to look at the residential gateway.

This points to stale routing or NDP state inside the AT&T box. It kept the DHCPv6 lease but dropped the dynamic route or neighbor entry until a fresh exchange forced an update.

Two client tweaks worth testing:

use-interface-duid=yes — Builds the DUID from the WAN interface MAC instead of the router-wide base DUID.
allow-reconfigure=yes — Accepts server-initiated reconfigure requests so the upstream gateway can trigger a renewal.

Summary

IPv6 on RouterOS 7 behind AT&T works once the control plane is sorted:

DHCPv6-PD brings the prefix from the ISP; SLAAC hands addresses to clients via RAs.
Build explicit stateful filters on input and forward. Never drop fe80::/10 on the WAN.
Dynamic GUAs from the pool keep the LAN current if the prefix changes.
Watch the upstream gateway. A simple DHCPv6 renew clears the occasional stuck state.

That’s all folks.

Mobile Mikrotik IKEv2 VPN

2026-10-07T10:43:00.548-05:00

Goal

Configure a MikroTik router as an IKEv2 VPN server for mobile and remote clients, including Windows, Android, and Apple iOS/iPadOS.

Clients authenticate using X.509 certificates and receive an address from a dedicated VPN address pool.

Why IKEv2?

IKEv2 provides a standards-based IPsec VPN that is well suited to mobile clients. It is supported natively by Windows and Apple operating systems and is widely supported by Android VPN clients.

Compared with older VPN protocols, IKEv2 provides strong cryptography, certificate-based authentication, NAT traversal, and reliable reconnection when a mobile device changes networks.

Configuration Overview

The configuration consists of four basic components:

Certificates: Create a Certificate Authority, server certificate, and client certificates.
Client addressing: Create an IP pool and configure DNS and routing information supplied through IKEv2 Mode Config.
IPsec: Configure the IKEv2 profile, proposal, peer, identity, and policy template.
Firewall and NAT: Permit IKEv2/IPsec negotiation and control what authenticated VPN clients may access.

Step 1: Certificates

IKEv2 certificate authentication requires three certificate types:

Certificate Authority (CA)
IKEv2 server certificate
IKEv2 client certificate

The CA signs both the server and client certificates, establishing the chain of trust used during IKEv2 authentication.

Create the Certificate Authority

Create the CA certificate that will sign the server and client certificates.

/certificate
add name=Domain_CA common-name=Domain_CA key-usage=key-cert-sign,crl-sign

Configure the Certificate Revocation List

Specify the public address from which the Certificate Revocation List can be retrieved.

/certificate
set Domain_CA ca-crl-host=8.x.x.x

Use the router's public IP address or a DNS name reachable by VPN clients.

The CRL location is published through the CA certificate. It does not need to be configured separately on the server or client certificates.

Sign the Certificate Authority

/certificate
sign Domain_CA

Create the IKEv2 Server Certificate

Create a certificate identifying the VPN server and sign it with Domain_CA.

The server certificate should contain the VPN server's DNS name in both the Common Name and Subject Alternative Name.

CN: ikev2.example.com
SAN: DNS:ikev2.example.com

The certificate should include the tls-server key usage. After creating it, sign it with Domain_CA and mark the CA and server certificates as trusted.

Create Client Certificates

Create an individual certificate for each VPN client or user.

For maximum client compatibility, use the same identity in the Common Name and Subject Alternative Name.

CN: steven
SAN: DNS:steven

The certificate should include the tls-client key usage.

Sign the certificate with Domain_CA, mark it as trusted, and export the certificate and private key as PKCS#12 (.p12) for installation on the client.

Using individual certificates allows a single client to be revoked without affecting every other VPN user.

Step 2: VPN Client Address Pool

Dedicate a subnet or address range to remote VPN clients.

/ip pool
add name=ikev2-pool ranges=10.168.88.100-10.168.88.110

This address space should not overlap existing LAN or remote networks.

The pool may be shared with other remote-access VPN services when appropriate, although separate pools can simplify firewall policy and troubleshooting.

Step 3: Configure IPsec

Mode Config

Mode Config supplies network configuration to connecting VPN clients.

/ip ipsec mode-config
add name=ikev2-modecfg \
    address-pool=ikev2-pool \
    address-prefix-length=32 \
    system-dns=no \
    static-dns=192.168.88.10

The client receives an address from ikev2-pool, a /32 client address, and 192.168.88.10 as its DNS server.

For a split-tunnel VPN, internal networks may also be advertised using split-include.

/ip ipsec mode-config
set ikev2-modecfg split-include=192.168.88.0/24

Mode Config determines what routes the client is asked to install. Firewall policy still determines what the client is actually permitted to access.

Phase 1 Profile

The IPsec profile defines the cryptographic parameters used during IKE negotiation.

/ip ipsec profile
add name=ikev2-profile \
    dh-group=modp2048 \
    enc-algorithm=aes-256,aes-128 \
    hash-algorithm=sha256

Phase 2 Proposal

Create a dedicated proposal for IKEv2 traffic.

/ip ipsec proposal
add name=ikev2-proposal \
    auth-algorithms=sha256 \
    enc-algorithms=aes-256-cbc,aes-128-cbc \
    pfs-group=none

A dedicated proposal is preferable to modifying the RouterOS default because unrelated IPsec tunnels will not inherit the remote-access VPN configuration.

Policy Group and Template

Create a policy group for dynamically generated IKEv2 client policies.

/ip ipsec policy group
add name=ikev2-policies

Create the corresponding policy template.

/ip ipsec policy
add group=ikev2-policies \
proposal=ikev2-proposal \
template=yes

RouterOS uses this template to generate IPsec policies dynamically as clients connect.

IKEv2 Peer

Create a passive IKEv2 peer that listens for incoming client connections.

/ip ipsec peer
add name=ikev2-peer \
    exchange-mode=ike2 \
    passive=yes \
    profile=ikev2-profile \
    send-initial-contact=no

Because the MikroTik is acting as the VPN server, remote clients initiate the connection.

IKEv2 Identity

Associate certificate authentication, Mode Config, and dynamic policy generation with the IKEv2 peer.

/ip ipsec identity
add peer=ikev2-peer \
    auth-method=digital-signature \
    certificate=IKEv2_Server \
    generate-policy=port-strict \
    mode-config=ikev2-modecfg \
    policy-template-group=ikev2-policies

The router verifies that each connecting client presents a certificate signed by a trusted CA.

A specific remote-certificate is deliberately not configured. Specifying one would bind the identity to a particular client certificate. Leaving certificate matching generic allows multiple clients signed by the trusted CA to authenticate.

Step 4: Firewall and NAT

The firewall performs two separate functions: permitting establishment of the IKEv2/IPsec tunnel and controlling what authenticated VPN clients may access after the tunnel is established.

Allow IKEv2 and IPsec

At minimum, the router must accept IKE and NAT Traversal from the Internet.

/ip firewall filter
add chain=input action=accept protocol=udp dst-port=500,4500 \
comment="Allow IKEv2 / IPsec NAT-T"

If native ESP must be accepted separately:

/ip firewall filter
add chain=input action=accept protocol=ipsec-esp \
comment="Allow IPsec ESP"

These rules must appear before the router's general WAN input-drop rule.

Allow VPN Clients to Reach the LAN

Access from authenticated VPN clients into internal networks should be explicitly permitted according to policy.

/ip firewall filter
add chain=forward action=accept \
    src-address=10.168.88.0/24 \
    dst-address=192.168.88.0/24 \
    ipsec-policy=in,ipsec \
    comment="IKEv2 clients to LAN"

Traffic not specifically authorized should remain blocked by the normal firewall policy.

NAT Considerations

Existing masquerade rules should not accidentally NAT traffic between VPN clients and internal networks.

Where necessary, place an IPsec NAT-bypass rule before the Internet masquerade rule.

/ip firewall nat
add chain=srcnat action=accept \
    src-address=10.168.88.0/24 \
    dst-address=192.168.88.0/24 \
    comment="Do not NAT IKEv2 clients to LAN"

The exact firewall and NAT configuration depends on whether the VPN is LAN-only split tunnel, includes multiple internal networks, or provides full-tunnel Internet access through the MikroTik.

Mode Config provides addressing and routing information. The firewall determines authorization.

That's It!

NPS Extension Certificate Error

2026-08-05T12:49:00.000-05:00

NPS Azure AD Extension Certificate Renewal

The NPS Azure AD Extension creates a self-signed certificate that’s only valid for two years. If you forget to renew it, authentication will eventually start failing when that certificate expires.

Renewal

Renewing the certificate is simple. Just rerun the Azure MFA NPS Extension configuration script:

C:\Program Files\Microsoft\AzureMfa\Config\AzureMfaNpsExtnConfigSetup.ps1

This will generate a new certificate and update the extension to use it.

PowerShell Error

When you run the script, you might see an error like:

The package source https://www.powershellgallery.com/api/v2 is not reachable or resolved.

This usually means PowerShell isn’t using a modern TLS version when it tries to connect to the PowerShell Gallery.

Fix

Windows Server 2016, 2019, and newer support TLS 1.2, but PowerShell may still default to older protocols, depending on .NET and cryptography settings.

The quickest fix is to force TLS 1.2 in your PowerShell session and then rerun the script:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

Once TLS 1.2 is enabled, the script can reach the PowerShell Gallery and the NPS Azure AD Extension certificate is renewed without further issues.

IaC: What, Me Cluster?

2026-07-11T22:11:00.000-05:00

Abstract

Decoupling the SRX cluster. Replacing Juniper SRX chassis clusters with standalone nodes and declarative Infrastructure as Code (IaC).

The Low-Down

High-availability firewall design was supposed to be simple: take two identical SRXs and cluster them together. A Juniper cluster ties two nodes together with a control and fabric link. It provides one management plane and a stateful failover.

It looks darn good on paper. For example, its ISSU was sold as a system that never goes down during patching. In reality, a small hiccup can turn a simple update into a pants-on-fire split-brain event.

If I could do it all over again I might have chosen a boring alternative. Ditch the cluster. Run independent nodes and lean hard on dynamic routing and Infrastructure as Code (IaC). Let BGP (or OSPF) handle all failover. Use OpenTofu or Terraform as the external control plane so security policy stays in sync among both nodes. No shared control plane. No reth interfaces. Maintenance becomes a dream. If one blows up during patching? So what? 🤣 The other node carries the load. No sweat. No drama . All by design.

Standalone pair + dynamic routing

Live and die by dynamic routing. And why not? It’s time proven for over 30 years. It just works. Frankly, it’s intuitive. Traffic steering lives in the routing protocol. You want traffic to exit node0? Give it local preference 300. You want it to default out node1? Give node0 the default preference and node1 preference 300. Boom!💥

Granted, you lose stateful session connection tracking during failover. But 1997 called, and they want their session-dependent apps back! Most web and cookie/token-based traffic barely notice a disruption. The next transit request arrives on the next node with a fresh binding. Nearly seamless to the end user. Perhaps a 10-second delay at most.

External control plane

That single management plane is nice... while it lasts. But it only works for two-node clusters. It still leaves every other firewall, router, and switch to fend for themselves. It's not rainbows and unicorns.

However, there is one CLI to rule them all. Say hello to my little friend, OpenTofu (i.e., Terraform).

It's darn near the holy grail of management. Git for version control and an audit trail. A validation step before anything touches a node. And an orchestrator that can push the same stanza to every device you manage. You edit the security policy once. The change lands on both SRXs. The nodes are not clustered! It's a single management pane for unlimited nodes. 😉

The Git repo can live wherever you prefer. A small server on an isolated management network works fine. Or you can use GitHub, Azure DevOps, or whatever cloud service you already trust. Either way the workflow is the same: branch, edit, pull request.

A policy change in practice

Say you need to open SSH from a new jump-box subnet. You edit the HCL instead of the CLI:

variable "firewalls" {
  type = map(object({
    host_ip    = string
    untrust_ip = string
  }))
  default = {
    "srx-node1" = { host_ip = "10.10.0.11", untrust_ip = "203.0.113.10/30" }
    "srx-node2" = { host_ip = "10.10.0.12", untrust_ip = "203.0.113.14/30" }
  }
}

resource "junos_security_zone" "trust" {
  for_each         = var.firewalls
  name             = "TRUST"
  inbound_services = ["ssh", "ping"]
}

resource "junos_security_zone" "untrust" {
  for_each = var.firewalls
  name     = "UNTRUST"
}

resource "junos_security_policy" "mgmt_access" {
  for_each  = var.firewalls
  from_zone = junos_security_zone.untrust[each.key].name
  to_zone   = junos_security_zone.trust[each.key].name

  policy {
    name                      = "ALLOW-JUMPBOX"
    match_source_address      = ["10.250.0.0/24"]
    match_destination_address = ["any"]
    match_application         = ["junos-ssh"]
    then                      = "permit"
  }
}

Commit it, open a PR, and let someone else validate your work. Then:

tofu plan

You should see the identical delta for both nodes. Only after that does the apply run. OpenTofu opens NETCONF to both boxes, commits the candidate, and finishes. Both SRXs now have the same policy. If someone later hand-edits one of them, the next plan calls it out.

But wait, there’s more! The same methodology works for the rest of the fleet. All the firewalls. All the routers. All the switches. One repo, one plan, one apply. You become the white wizard. 🤣

Benefits

Configuration drift shows up instead of hiding until something breaks. Git becomes the audit trail. Reverting a bad change on both firewalls is a revert plus an apply. Upgrades and hardware failures no longer risk taking the whole cluster down. Failover is simple BGP logic.

Honest limits

You traded firewall session synchronization for independence. Pure long-lived TCP flows can still break (and the immediately reestablish). Most web and cookie/token traffic barely notice. The next request arrives on the surviving node with a fresh NAT binding. The application session stays intact. BGP convergence takes a few seconds, not sub-second. The Junos Terraform provider covers most everything, but some features are still easier with a CLI command, a targeted NETCONF call, or an Ansible playbook. NAT and return-path symmetry still require deliberate packet flow.

None of that makes the system wrong. It a trade-off: standalone hardware, routed failover, and consistent policy instead of a fragile shared control plane.

That's all Folks!

SolarWinds: The Dark Side

2026-04-15T12:59:00.000-05:00

Price Hikes:

End of an era. Perfectly aligns with all the AI hype and the death of SaaS narrative.

Email to SolarWinds:

Bruh... Was that invoice an April Fools’ joke?
or did you really raise our rate 300% and call it a discount?

Last year we paid $3500 for our maintenance agreement.

Your new invoice shows $10,681 🤣🤣🤣🤣🤣
Is “300% is the new 3%”?

One Brave Reply:

Hey Steven, I wish it was April fools haha.

We were acquired by a PE firm at the start of last year.
They've made it a completely different model.
You are not the only one this has happened to.

We were a Subscription First, before we got purchased. They moved to Subscription only. Which is why you are seeing that ridiculous almost out of control uplift.

But it is what it is. ... Thanks, and sorry Steven. Have a good day man!

My Reply:

I appreciate the candid reply. I hope things work out for you.

Deploy Spectrum IPv6

2026-04-05T14:44:00.000-05:00

Deploying Spectrum IPv6 with MikroTik

A practical guide to DHCPv6 Prefix Delegation, SLAAC, router advertisements, and dynamic IPv6 routing across multiple routers.

The Low-Down

Got Spectrum? Want IPv6? Want to route those prefixes? We can build that.

Why route IPv6 prefixes on something as ordinary as a home network? Because a flat network isn't a requirement. Conventional wisdom suggests we bridge a single Layer 2 network straight to the AP. That works. You can also go your own way.

A single broadcast domain has two problems: security and noise. Cheap and beefy firewalls (hello, MikroTik) changed the math entirely. Each routed segment is its own security zone. Policy becomes intuitive: this interface talks to that one, this zone to that zone, and everything else is a rule.

The other win is isolation. Chatty Wi-Fi clients throw broadcasts and multicast at everyone on the same domain. That noise is not stuck on the wireless side. It hits the wired LAN too. Ever try a wireless printer from your phone? The rest of the network feels broken. Not that I would know. 🤣

Routed segments fix that. Client isolation and private VLANs help, but they still live in one broadcast domain. Routing adds a real boundary.

Our Spectrum deployment demonstrates this architecture using two MikroTik routers:

The Primary Firewall: The Internet edge router receiving Spectrum's /56.
Secondary AP: A downstream router receiving a /58 from Martha and distributing /64 networks to its clients.

The result is a routed IPv6 network with automatic prefix assignment and routing, without NAT66 or static routes for the delegated global prefixes.

This article examines how that architecture works and why Router Advertisements, DHCPv6-PD, and Unique Local Addresses each have distinct roles.

Network topology

Spectrum provides a dynamically delegated /56 IPv6 prefix.

The primary firewall receives that prefix and manages its distribution.

The AP receives a /58 from the primary firewall and uses that delegated block to assign /64 prefixes to its internal networks.

Three distinct functions:

1. Prefix delegation: Determines which router owns which IPv6 prefix.
2. Routing: Determines where packets should be forwarded.
3. Host configuration: Clients acquire addresses, gateways, and DNS.

Understanding Spectrum's /64 delegation

Spectrum provides a /64 by default. That's great if you have a very simple network and limited expectations. It's bound to a single layer-2 network. It can't be divided into further subnets for routing purposes. Not without taxing additional routing tricks. Boo.

Understanding Spectrum's /56 delegation

Ask and you shall receive. They delegate a /56 prefix through DHCPv6-PD -as long as you ask nicely!

For illistration, Spectrum assigns:

2001:db8:1234:5600::/56

Note: 2001:db8::/32 is reserved for documentation. This is not the actual Spectrum prefix.

A /56 contains 256 individual /64 networks. For example:

2001:db8:1234:5600::/64

2001:db8:1234:5601::/64

2001:db8:1234:5602::/64

...

2001:db8:1234:56ff::/64

This provides considerably more flexibility than a single /64.

Each /64 can be assigned to a separate routed LAN, VLAN, wireless network, or other Layer 3 segment. A /64 is also SLAAC friendly.

How many networks can we delegate?

A /56 contains:

256 × /64 networks
64 × /58 networks
16 × /60 networks

Our design delegates one /58 to the AP.

That /58 contains 64 separate /64 networks. 🤯

The remaining address space can support other internal segments or downstream routers, provided the allocations do not overlap. That's exactly what we want -options.

Configure prefix delegation on the primary firewall

The edge firewall runs a DHCPv6 client on its Spectrum-facing WAN interface.

The client requests a prefix and places the delegation into a RouterOS IPv6 pool:

/ipv6 dhcp-client
add interface=<spectrum-wan> \
    request=prefix \
    pool-name=spectrum_ipv6 \
    pool-prefix-length=56 \
    add-default-route=no

Replace with the actual interface name.

The important settings are:

Setting	Function
`request=prefix`	Requests IPv6 Prefix Delegation
`pool-name=spectrum_ipv6`	Creates a dynamic pool from Spectrum's delegation
`pool-prefix-length=56`	Allocates /56 networks from that pool
`add-default-route=no`	Leaves default-route discovery to Router Advertisements

The actual Spectrum configuration uses Router Advertisements for default-route discovery.

Verify the prefix

/ipv6 dhcp-client print detail
/ipv6 pool print detail

We expect the DHCPv6 client to report status=bound and a delegated prefix of length /56.

The pool should contain the dynamically delegated address space.

Why not hardcode the prefix?

Spectrum's delegation is dynamic.

Although an ISP may consistently assign the same prefix, there is no guarantee it will remain unchanged.

Hardcoding the global prefix into downstream interfaces would create additional maintenance work if Spectrum renumbers the connection.

Using a dynamic pool allows RouterOS to update the assigned global prefixes when the upstream delegation changes.

IPv6 default routes: Router Advertisements versus DHCPv6

An important architectural distinction is that DHCPv6 Prefix Delegation does not inherently supply a default gateway.

In IPv6, Router Advertisements are the standard mechanism for discovering default routers.

On the Spectrum WAN, the edge firewall receives an RA from the upstream router.

The RA identifies the default router through its link-local address.

The resulting route conceptually resembles:

::/0
    gateway=fe80::xxxx%<spectrum-wan>

The %interface notation identifies the interface associated with the link-local next hop.

This is necessary because link-local IPv6 addresses are scoped to a particular link.

Why link-local next hops?

IPv6 routers do not need globally routable addresses to communicate with directly connected neighbors.

A link-local address is sufficient for forwarding traffic to the next router. This is normal behavior.

The edge firewall receives a global /56 through PD. It independently learns its default route through an RA.

These are separate control-plane functions.

RouterOS consideration

RouterOS must be configured to accept Router Advertisements to learn its IPv6 default route.

For example:

/ipv6 settings
set accept-router-advertisements=yes

Enabling RA acceptance does not replace DHCPv6-PD.

6. Delegating a /58 to the AP

This is where the architecture becomes interesting.

The AP is simultaneously:

A DHCPv6-PD client toward Spectrum.
A DHCPv6-PD server toward the AP.

The AP requests a prefix from the edge firewall.

The AP allocates a /58 from Spectrum's delegated /56.

Using our documentation prefix, one possible allocation is:

Spectrum delegates:
2001:db8:1234:5600::/56

Edge firewall delegates to AP:
2001:db8:1234:5640::/58

That /58 contains the /64 networks beginning at 5640 through 567f.

The exact allocation is determined by the pool and client configuration.

Configure a delegation pool

The Spectrum-facing DHCPv6 client creates the upstream dynamic pool spectrum_ipv6.

To delegate /58s, the AP must have a suitable nonoverlapping allocation mechanism that makes /58 prefixes available to its downstream DHCPv6 server.

A RouterOS dynamic pool created with pool-prefix-length=64 is intended to allocate /64s, not /58s. The pool arrangement must therefore support the /58 request.

For example, the upstream client could be configured to create /58 allocations:

/ipv6 dhcp-client
set [find where pool-name=spectrum_ipv6] \
    pool-prefix-length=58

Changing the pool prefix length on a running network can affect existing assignments.

Configure the DHCPv6 server

The DHCPv6 server on the edge firewall serves the link towards the AP:

/ipv6 dhcp-server
add name=dhcpv6_to_ap \
    interface=<ap-facing-interface> \
    address-pool=<pd-pool>

The selected pool must provide the /58 delegations.

The server receives a prefix request from the AP, allocates the prefix, and associates that delegation with the downstream router.

This is not the same as assigning an IPv6 address to the AP's WAN interface.

A delegated prefix represents address space. It is not the same an IPv6 address.

Configure the AP as a DHCPv6-PD client

The AP runs a DHCPv6 client toward the edge firewall.

The client requests a prefix and places it into a local pool:

/ipv6 dhcp-client
add interface=<edge-uplink> \
    request=prefix \
    pool-name=spectrum_pool \
    pool-prefix-length=64 \
    add-default-route=no

The /64 allocation size is intentional. The AP receives a /58 but subdivides that prefix into /64s for its internal networks.

The hierarchy is:

Spectrum
     |
Edge Firewall /56
     |
Access Point  /58
     |
Wireless Clients /64

This is routing. It's not address translation.

Every global IPv6 address and subnet belongs to the original Spectrum /56.

Assign /64 networks to internal interfaces

The AP can assign /64 networks from its delegated pool to internal interfaces:

/ipv6 address
add interface=bridge_wifi \
    from-pool=spectrum_pool \
    advertise=yes

RouterOS selects an available /64 from the delegated pool and assigns it to bridge_wifi.

The interface then advertises that prefix to wireless clients.

What about bridge_lan?

The existing topology distinguishes between two networks:

bridge_lan
Receives a global /64 advertised by the edge firewall through SLAAC.

bridge_wifi
Receives a global /64 from the AP's delegated /58.

This is a useful distinction.

On the bridge_lan, the AP participates as a host on the upstream link, receiving a global address through SLAAC.

On the bridge_wifi, the AP acts as the router advertising a delegated /64 to downstream clients.

The two interfaces therefore have different addressing and routing.

Router Advertisements and SLAAC

The AP provides Router Advertisements on the wireless bridge.

/ipv6 nd
add interface=bridge_wifi \
    advertise-dns=yes \
    managed-address-configuration=no \
    other-configuration=no

ND advertises its /64 to clients. Clients receiving these advertisements can automatically configure global IPv6 addresses using SLAAC.

RAs can provide:

Default-route
Prefix information
MTU
Router lifetime
DNS resolvers through RDNSS

DHCPv6 IA_NA and SLAAC

The design also incorporates DHCPv6 IA_NA service on bridge_wifi.

Note the distinction between PD, DHCPv6, and SLAAC.

DHCPv6-PD: Delegates prefixes to routers.
DHCPv6 IA_NA: Assigns individual IPv6 addresses to clients.
SLAAC: Allows clients to generate their own addresses using advertised prefixes.

Why incorporate both SLAAC and DHCPv6 service? It's all about the clients. Some only support SLAAC, some only DHCPv6, some only support SLAAC but do not accept RDNSS 🤣. If you want to support Windows, and Mac IOS, and Android, and Xbox... It's best to support SLAAC and provide DHCPv6.

To advertise that stateful DHCPv6 addressing is available, the RA Managed flag can be enabled:

/ipv6 nd
set [find where interface=bridge_wifi] \
    managed-address-configuration=yes

The DHCPv6 server and address pool must also be configured. The Managed flag alone does not create a DHCPv6 server.

Return routing

The major advantage for this design is that the edge firewall does require a static route for every delegated /64.

When It delegates a /58 to the AP, the DHCPv6-PD server can install a route for that delegated prefix through its DHCPv6 client.

Conceptually:

Destination:
2001:db8:1234:5640::/58

Next hop:
AP

The actual next hop may use the AP's link-local address. This is a critical feature of routed prefix delegation.

IPv6 firewall considerations

Globally routable IPv6 addresses, without controls, provide unrestricted two-way Internet access.

A stateful firewall policy is the primary tool that makes IPv6 functionally secure. It should block all unsolicited traffic on both the inbound and forward chains. It should permit defined control traffic on the inbound chain and permit outbound traffic on the forward chain. It should drop everything else.

It's conceptually similar to a solid IPv4 firewall filter. Review an example of IPv6 firewall configuration here.

The AP should apply equivalent principles to traffic entering its own routed networks.

17. Conclusion

My Spectrum IPv6 deployment demonstrates a clean approach to routing using RouterOS.

Spectrum delegates a /56 to my edge firewall.

My edge firewall allocates a /58 to my AP.

My AP subdivides that /58 into /64 networks for its internal interfaces.

Router Advertisements provide default-router discovery and host configuration, while DHCPv6-PD manages the delegation hierarchy and associated routes.

The resulting architecture supports globally routable IPv6 addresses throughout the network without NAT66.

More importantly, it establishes a foundation for expansion.

Additional VLANs, wireless networks, downstream routers, and branch segments can be incorporated without changing the architecture.

The underlying principle is simple: delegate prefixes to routers, advertise prefixes to hosts, and route between networks.

That's it!

Role-based Shells

2026-02-16T14:24:00.000-06:00

You Gotta Keep 'em Separated

PowerShell, Bash, Cisco IOS, RouterOS. Terminal fatigue is real. After a while they all blend together. Windows Terminal puts them all under one roof. One clone after another gets old fast. I wanted each environment to reflect its own role.

Role-based shells to the rescue! Windows Terminal owns the look. PowerShell and Bash each own their own environment. SSH launches directly into remote device. The secret sauce is the division of labor.

PowerShell

Show something useful instead of a blank prompt. Winfetch does that:

Install-Module -Name Winfetch -Scope CurrentUser

Then the profile is two lines. Find it with $PROFILE, create the file if it doesn’t exist, and add this:

Clear-Host
winfetch

New tab, screen clears, system info appears. Windows Terminal never has to know about it. Just remember that Windows PowerShell 5.1 and PowerShell 7 keep separate profiles, so run $PROFILE from the one you actually use.

Ubuntu WSL2

Same idea for Linux. Install the tools:

sudo apt update
sudo apt install neofetch figlet

Then at the bottom of ~/.bashrc:

clear
figlet "Ubuntu WSL2"
neofetch

Source it or open a fresh tab. You get the big banner, the Ubuntu art, and the stats. 🤯

Other nodes

The last piece was including a small transparent logo in the bottom-right of each profile. I can tell at a glance which system I’m on. Each system gets its own PNG. Store them where Terminal can see them (e.g., RoamingState folder) and point at them like this:

"backgroundImage": "ms-appdata:///Roaming/ubuntu.png",
"backgroundImageAlignment": "bottomRight",
"backgroundImageStretchMode": "none",
"backgroundImageOpacity": 0.20

The shared defaults handle the common stuff: Cascadia Code, acrylic at 85% opacity, and a filled-box gold cursor. Individual profiles override color and logo. Cisco ended up dark royal green (#1B4D3E) with the gold cursor. MikroTik is deep navy with steel-blue text (#A0C4FF). Both stay readable and neither looks like a Christmas tree.

My Cisco and MikroTik profiles launch straight to SSH sessions. The remote device owns the CLI. Terminal only owns the window it appears in. Don’t bake credentials into settings.json.

Repeat after me

I dedicate a folder for settings.json, the PowerShell profile, a copy of .bashrc, and the four images. If I break something or move to a new machine -no big deal. I drop those files back in place, reinstall the two tools, and I’m done. The gold cursor was an experiment that stuck. Everything else was just making sure the right layer owned the right job.

That's It!

IaC Monkey Business

2025-10-11T18:33:00.000-05:00

Abstract

Terraform provides the tools to manage Infrastructure as Code (IaC) configuration, but architecture, shared policy, and deployment remain our responsibility. My five-layer IaC methodology is one way to structure those responsibilities. It's simple enough for individual devices, yet scalable across entire fleets. A disciplined approach prevents the monkey business that turns IaC into module soup.

Background

A co-worker once asked me, "What do you think about Terraform and Ansible?" I replied, "Any monkey can push a button." After all, it's only a glorified network configuration manager (NCM), isn't it? The answer to that question is more fun than a barrel of monkeys.

CLI vs NCM vs IaC

Network management is entirely situational. There's no perfect one-size-fits-all solution. I respect a clean CLI. It's a quick and satisfying way to make changes. Indeed, the CLI paired with a solid NCM solution is entirely justifiable. It gives you form and function with the ability to roll back changes from previous versions. But the truth is, the CLI and NCM have limitations.

The CLI is single purpose. It's designed around interacting with one device at a time, which is entirely defensible if you manage ten to twenty devices. But it becomes inefficient at scale. What happens if you need to manage one hundred devices? Five hundred?

Beyond logistics, scale introduces the potential for mistakes or drift. People make mistakes. Mistakes have consequences. They can lock you out of a device. They can bring down service. They can open ports that leave your resources vulnerable to exploits. In some ways, the only difference between a net admin and a monkey is version control.

Even when CLI is scripted across many devices, it remains fundamentally device-centric. Infrastructure as Code (IaC) is different. It makes desired state explicit, repeatable, and manageable.

Monkey Wrench

CLI is like a handsaw. Measure once and cut. It's maximum simplicity and control over a single device. NCM + CLI is like upgrading to a circular saw and then measuring twice. Your work can quickly be rolled back to a previous state from any device. IaC is like working with a table saw, for when repeatable accuracy matters most.

But a table saw doesn't automatically produce better work. It produces more efficient work—the same repeatable cuts at scale. However you cut it, the final work depends on the craftsman behind the blade. The same is true of IaC. The tool is only as useful as the architecture.

Methodology

IaC can work like all three tools: a simple handsaw, a circular saw, or a beefy table saw. The difference boils down to how we structure the work. What follows is a custom Five-Layer IaC abstraction model. It is vendor-neutral and reusable beyond any particular tool or platform. Each layer answers a distinct question, and each is dependent on the previous. Each layer is insufficient on its own.

Layer 1: Structure

Where does everything belong?

Define the Git repository and how its components are organized.

Local, server, or cloud-based repository
Comprised of a flat Git repository
Scope wide and never deep

Without a deliberate structure, the repository becomes a disorganized junk drawer. At scale, you cannot find what you need, changes drift, and the next administrator inherits the mess. Structure is the foundation that makes every other layer possible.

Layer 2: Roles

How are components related?

Decide how devices and groups are classified and related. Child directories align perfectly with roles:

Device_intent: Dedicated 1:1 folders for managed nodes. Each folder contains respective configuration files. Terraform applies all files to the node.

Shared_policy: Dedicated 1:N folders for groups of managed nodes. Each nested folder contains respective configuration files that disseminate to all devices within the group. All files are applied to all devices in the group.

Templates: Dedicated 1:1 folders per model. Configuration contains placeholder stanzas intended for new rollouts. Simply copy the template to its respective new device or group directory.

Structure alone does not tell you how devices relate to one another. Roles make the relationships explicit: which devices are unique, which share policy, and which are starting points for new deployments. This prevents both duplication and accidental divergence.

Layer 3: Identity

How do we consistently identify nodes and shared policy?

We implement a naming convention that represents more than simple identification:

Device names: City-Vendor-Function-Model-ID (e.g., chi-jun-fw-1500-n0)
Group names: Group_identifier-city-vendor-function (e.g., Grp-mke-mt-fw)
TF Config Files: Align with vendor configuration stanza (e.g., ip_firewall_filter.tf)

Consistent identity makes automation reliable and allows human review. Each resource name encodes location, vendor, function, and role. It turns a directory listing into a map.

Layer 4: Policy

How do we enforce configurations and behaviors?

Policy determines how group and local device configurations apply in tandem.
Apply naming convention to configuration statements or comments (-grp / -loc).
Determine explicit precedence and order of operation.

This is where the methodology becomes concrete. For example, our RouterOS configuration establishes a "group" forwarding chain shared among its respective nodes. That chain includes a jump rule to a similar "device" chain. Configuration for the respective chain is entirely optional and configured per device. This process provides exceptions and preserves the default-deny ACL located in the group stanza.

Roles and identity tell you what exists and how it is named. Policy decides what actually happens when shared and local configurations meet. Without explicit precedence, you get silent overrides, surprising behavior, and configurations that cannot be reasoned about.

Policy impacts both group and individual devices. It's not a setting you can toggle. It's all derived from our custom methodology. It's the secret sauce that makes IaC unique.

Layer 5: Orchestration

How do we review and deploy changes?

Orchestration defines how configurations are reviewed and deployed. Its operational processes can include Git revisions, OpenTofu plans, reviewed applies, and Bash deployment scripts.

Each device maintains independent state, even when multiple devices consume the same shared policy. Shared configuration does not imply shared deployment fate. Our Bash orchestration is intentionally simple: select a group, iterate through its device roots, review plans, apply deliberately, and stop on failure. No elaborate management platform is required.

The previous layers produce a desired state. Orchestration is how that state is safely deployed. Independent state means a failure on one device does not cascade. The deliberate, reviewable process ensures the human-in-the-loop. It's monkey see and monkey do—in the best possible way. Engineering solutions do not require complexity.

RBAC vs IaC

I use a methodology similar to RBAC, but adapted for infrastructure as code. The roles are not security groups—they are the managed nodes and the groups those nodes belong to. The organization of the repository and the naming conventions do the heavy lifting. Everything is kept flat so I can quickly identify and work with a single device or an entire group.

The primary distinction is between the device directory and the shared policy directory. The device directory holds configuration that is unique to that node. The shared policy directory holds configuration that applies to every device in a given group. Reconciling the two is deliberate: shared policy is applied first, then local exceptions are layered on top under explicit precedence rules, with a final default deny. That keeps group consistency without preventing device-specific overrides.

These are different mechanisms from traditional RBAC, but they share a useful conceptual pattern: roles establish relationships, and those relationships determine how policies are applied. In both cases, the role is a layer of indirection that keeps the rules themselves simpler and more maintainable. The difference is what the role is organizing—authorization on one side, configuration ownership on the other.

See, Hear, and Speak no Evil

IaC without a coherent system is one more banana peel to slip on. However, a well-designed IaC approach is arguably the top-banana approach. It gives the next administrator a readable configuration, a transparent history, and a predictable evaluation process we can deploy at scale. If that's the case, I say the monkey can have his button. Just don't mistake it for the system behind it. 🐒

Wi-Fi Without VLANs

2025-07-11T18:45:00.000-05:00

Layer-3 Wi-Fi Fabric

Wi-Fi is like a layer-2 Oscar-Mayer hotdog. It looks better than it tastes. Every access point belongs to the same foot-long fabric. Does wireless mobility truly require that digital heartburn? Or is there a better choice on the menu?

The Low-Down

Most Wi-Fi designs extend Layer 2 so a client can keep the same IP while it roams. That gives you one big broadcast domain, tunnels, controllers in the data path, and extra glue when you leave the building. VLANs show up everywhere because the fabric itself never really left Layer 2.

I wanted something simpler. Treat the client’s IP as a stable identity. Announce it as a /32 host route in BGP from whichever access point the client is currently on. When the client moves, the route moves with it. No bridges, no GRE-style tunnels, no shared broadcast domain, and no VLANs.

The controller never sees client traffic. It only watches associations and pushes or withdraws the /32 on the APs. BGP does the rest.

Why bother?

A flat Layer 2 network (or a tunneled one) gives you a few familiar problems:

ARP and mDNS floods hit every radio at the lowest management rate.
Controllers become single points of failure and performance bottlenecks.
Trunks, VLANs, and spanning tree touch every AP.
Client isolation is usually a CPU-heavy bridge filter that breaks other things.
Going between sites means yet another overlay.

A purely routed fabric sidesteps most of that. Each client lives on its own isolated segment. The IP follows the device. Policy can ride on BGP communities. Distance becomes just another BGP peer. And there are no VLANs to provision or trunk.

Layer-3 Roaming

Client associates to a new AP. Syslog fires. Controller sees the event, withdraws the /32 from the old AP, and announces it on the new one. BGP converges. Traffic follows.

With BFD and tight timers the whole thing can stay under a second on a small fabric. Existing TCP sessions survive. The client does not need to know anything changed.

Four pieces

1. Access points

MikroTik APs acting as leaves. Each runs BGP to the core. Base config is almost identical. The controller adds and removes network statements over the API. If the controller dies, existing routes stay up and traffic keeps flowing.

2. BGP core

Route reflector (CHR or physical). It accepts the client /32s tagged with the right communities and rejects everything else. Policy lives here. One connection-tracking rule can cover the whole client pool.

3. Controller

Lightweight Python container. Listens to CAPsMAN syslog, keeps a MAC→IP→AP table, and drives the RouterOS API. Never in the data path. Failure only stops new associations.

4. Dashboard

Shows who is where, roam history, BGP session health, and a simple isolation toggle. The BGP table itself is the second source of truth.

Communities for policy

Every /32 carries a community that says what the device is allowed to do:

65000:100  Corporate
65000:200  Guest
65000:300  IoT
65000:900  Quarantine

The controller maps authentication context to the community at association time. The spine enforces it. No per-client firewall rules, no VLAN sprawl. Change the community and the policy moves with the route.

What this buys you

Roaming works from anywhere. The controller can be down the hall, on another floor, across the campus, or on the other side of the state.
The IP belongs to the device. Firewall rules and logs follow the client, not the AP or the subnet.
No vendor licensing. It's simply aligning dynamic routing with clients.
HA is simple. Just add another controller and use local preference. Existing sessions survive controller failure.
Client isolation is topological instead of filter-based.
No VLANs anywhere in the client path.

Requirements for a small POC

Two MikroTik APs that support containers (RB5009, L009, hAP ax³). The older hAP ac² does not.
One BGP route reflector (CHR or physical).
A couple of client devices, including at least one Android.
RouterOS 7.x on the controller host.
Python container with a syslog listener, librouteros, and SQLite. Target is under 500 lines.

Optional later: 802.1X so communities come from RADIUS attributes, RSSI polling for flap prevention, mDNS reflection if you need discovery across the isolated segments.

Compared with the usual options

TCP session on roam: L2 bridge drops, L2 tunnel survives only while the controller is up, L3 per-AP subnet drops, this design survives.

Controller in data path: L2 bridge no, L2 tunnel yes, L3 per-AP no, this design no.

Broadcast scope: L2 bridge fabric-wide, L2 tunnel fabric-wide, L3 per-AP per AP, this design per client.

Geographic scale: L2 bridge poor, L2 tunnel moderate, L3 per-AP good, this design excellent.

Role-based policy: L2 bridge none, L2 tunnel proprietary, L3 per-AP static, this design BGP communities.

Licensing: L2 bridge low, L2 tunnel high, L3 per-AP low, this design zero.

Caveats

Convergence time. Aggressive BGP and BFD timers will help. Roam events, reassociation timing, and queueing must be measured. The first working version is MikroTik-specific even if the idea is not.

None of that makes the approach nonsense. It's simply applying something BGP already does well to the access layer. The concept should be welcome for anyone who has fought with L2 roaming, GRE tunnels, or inter-controller mobility.

The controller and dashboard are still in POC shape. The fabric itself is mostly ordinary BGP and RouterOS. That is the point.

Transfer FISMO Roles with PowerShell

2025-05-09T14:23:00.000-05:00

Problem

You need to move the FSMO roles, and you would rather do it in PowerShell than click through the old MMC snap-ins.

Solution

Use the Active Directory PowerShell module. If it is not already loaded, import it first.

Import-Module ActiveDirectory

See who has the forest roles

Get-ADForest contoso.com | ft DomainNamingMaster, SchemaMaster

See who has the domain roles

Get-ADDomain contoso.com | ft InfrastructureMaster, PDCEmulator, RIDMaster

Move one role

This hands the PDC Emulator role to the domain controller named DCX.

Move-ADDirectoryServerOperationMasterRole -Identity "DCX" PDCEmulator

PowerShell also accepts the role as a number:

0 = PDCEmulator
1 = RIDMaster
2 = InfrastructureMaster
3 = SchemaMaster
4 = DomainNamingMaster

Move several roles

Move-ADDirectoryServerOperationMasterRole -Identity "DCX" -OperationMasterRole DomainNamingMaster,PDCEmulator,RIDMaster,SchemaMaster,InfrastructureMaster

Move all of them by number

Move-ADDirectoryServerOperationMasterRole "DCX" -OperationMasterRole 0,1,2,3,4

That's it. Same command either way. Name the destination domain controller, then list the roles you want it to take.

References

Move-ADDirectoryServerOperationMasterRole

Migrating FSMO roles from Windows Server 2012 R2 to 2016

Clear BGP Sessions

2024-05-30T15:29:00.000-05:00

Problem:

How to reset BGP peering and re-announce BGP routes. Inbound traffic is supposed to traverse through the preferred ISP. However, traffic splits between different ISPs after maintenance or short outages.

Solution:

Clear BGP sessions to update BGP routes after an outage or maintenance.

Command:

clear bgp neighbor soft

This processes re-announces BGP routes to upstream neighbors. Clear a BGP session whenever inbound/outbound policy changes are made; or after outages or maintenance.

Before:

After:

That's it!

GPO Slow Link Detection

2019-11-19T18:13:00.001-06:00

GPOs don't work on the VPN?

Problem:

Branch office or managed laptops are missing group policies.

Definition: Group Policy Slow Link Detection

Slow-link detection identifies slow connections: Slow transfer rates or high latency. This process can trigger applications to scale back feature and function. For example, slow link detection may interfere with distributed file systems (DFS). In other situations, slow link detection can prevent remote workstations from receiving GPO updates.

Background:

Wide-spread high-speed Internet connections (e.g., 100 Mbps) were uncommon before c. 2009. Older network protocols were less efficient (e.g., SMB2 vs SMB3). Slow-link detection was designed to compensate for poor connections. This legacy process continues to impact modern network services (e.g., Windows 2019).

Group Policy Slow Link Detection:

Connection rates are measured between the domain controllers and the client. Group policy changes are not distributed when this transfer rate is less than 500 kbps.

500 kbps may seem reasonable -but it's not.

Solution:

Disable slow link detection:

GPO: Policies\Administrative Templates\System\Group Policy\Slow Link Detection

Options: Enable this policy.

Enter 0 to disable slow-link detection.
Alternately, set high connection speed rate (e.g., 10000 Kbps is ~10 Mbps).

That's it!

References:

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc978717(v=technet.10)

Set the Network Location

2019-07-31T17:09:00.002-05:00

How to Assign Active Network Location with PowerShell.

Step 1: Identify networks and associated NICs.

Get-NetConnectionProfile

Name             : domain.com

InterfaceAlias   : Ethernet (Domain)

InterfaceIndex   : 1

NetworkCategory  : DomainAuthenticated

IPv4Connectivity : Internet

IPv6Connectivity : NoTraffic



Name             : Unidentified network

InterfaceAlias   : RDMA

InterfaceIndex   : 2

NetworkCategory  : Public

IPv4Connectivity : NoTraffic

IPv6Connectivity : NoTraffic

The above examples shows two NICs that belong to two different networks.

Step 2. Change the NetworkCategory:

Set-NetConnectionProfile -InterfaceIndex 13 -NetworkCategory Private

This example changes the active network for the NIC named RDMA. The network location changed from Public to Private. Confirm with Get-NetConnectionProfile.

That't It!

References:

https://docs.microsoft.com/en-us/powershell/module/netconnection/get-netconnectionprofile?view=win10-ps

Domain Controller Preference Order

2018-07-16T17:45:00.001-05:00

Outline:

How to configure locator preferences for domain controllers (DCs). How to set priority and weight on domain controllers. Force clients to consistently connect to the same domain controller.

Problem:

Clients connect to different DCs within the same site. IPv4 DNS server search has no effect on this random behavior.

Solution:

(a) Assign priority and weights to DNS SRV-records via GPO (i.e., registry changes);

(b) Or, change subnet topology for simple DC Subnet Prioritization;

Assumptions:

All DCs are located within the same Active Directory (AD) site.

Domain Controller Priority within a Site

Domain DNS SRV-records assign priority and weight values that determine DC preference. Clients connect to the domain controller (DC) with the lowest priority value. By default, priority for all DCs is set to zero. For example, assume a site has two DCs:

· DC-X with a priority of 0 (i.e., preferred).
DC-Y with a priority of 2.

In this example, Windows clients connect to DC-X because it has the lowest priority value. Clients only connect to DC-Y when DC-X is unavailable (e.g., maintenance).

Domain Controller Weights

What happens when all the DCs share the same priority? In this situation, DC preference is determined by SRV-record weight values. Unlike priority, clients prefer higher weight values over lower values.

What happens if all DCs have the same weight values? By default, DCs weight value is set to 100. Clients connect round-robin when all DCs use the same priority and weight values.

What happens when same-site DCs have the same priority and different weight values? Weight is not absolute. Weight is proportionate. In other words, clients may disproportionately connect to any available DC.

Clients are more likely to connect to DCs with higher weights. Clients are less likely to connect to lower weights DCs. Weight preference uses a simple formula: DC weight (i.e., single server) divided by the sum of all DCs weights:

For Example, assume three DCs within a single AD site (Table 1):

Table 1
Determine domain controller preference based on weights.

Domain Controller	Priority (Default)	Weight	Formula	Connection Odds
DC10	0	10	10/(10+20+30) = 10/60 = 1/6	17%
DC20	0	20	20/(10+20+30) = 20/60 = 2/6	33%
DC30	0	30	30/(10+20+30) = 30/60 = 1/2	50%

Note: This assumes client and domain controllers reside in the same site and use the same priority values.

DC Preference Configuration

Set priority and weight via the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
Create new 32-bit DWORDs:
LdapSrvWeight
LdapSrvPriority
Assign DC priority and weight values.
Restart the NETLOGON service to publish to SRV records

Subnet Prioritization

Clients prefer to connect to DCs on the same IP subnet. For example, let’s say we have a single AD site. This site consists of one Windows 10 client and two DCs (Table2):

Table2
Subnet Prioritization

Host	Priority	Weight	IP address	Preferred DC
WIN-10			192.168.1.1/24
DC-X	0	100	192.168.1.100/24	Yes
DC-Y	0	100	192.168.2.100/24	No

Note: All hosts reside in the same AD site. DC01 and DC02 use default weight and priority values.

In this situation, all hosts belong to the same AD-site. Both DCs have the same preference values (i.e., default). WIN-10 and DC-X belong to the same IP subnet. However, DC-Y resides on a separate IP subnet. DC-X is the preferred DC. Clients only connect to DC-y when DC-X is unavailable (e.g., maintenance).

Additional Thoughts:

I recommend minimal registry changes –especially to DCs. Implement priority and weight changes with caution. Also consider, registry changes can be difficult to troubleshoot. Therefore, it’s prudent to push these changes out via GPO.

Subnet Prioritization seems to be the simplest approach. That is, if you’re comfortable with internetworking. Simply create a new gateway. Add routes. Assign the subnet to the second DC. Done.

That’s It!

References:

https://blogs.msmvps.com/acefekay/2010/01/03/the-dc-locator-process-the-logon-process-controlling-which-dc-responds-in-an-ad-site-and-srv-records/

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc733142(v=ws.10)

http://techgenix.com/domain-controllers-weight-priority/

https://www.blackmanticore.com/1a64083f14eccc1d32a755a850c2ea3d

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc772592%28v%3dws.10%29

Fix Shutdown Event Tracker in RDP

2018-07-10T20:38:00.002-05:00

Problem:

How to disable the unexpected shutdown prompt for remote desktop users. The remote desktop server (RDS) displays the shutdown tracker warning after patching updates. This shutdown error causes confusion and unnecessary help desk calls.

Solution:

Remove local\Users group permissions from shutdown.exe: c:\windows\system32\shutdown.exe

Both local administrators and local users, have read and execute permissions, on this system file. Remove the local user group in order to hide unwanted shutdown messages. Also note, this change may require ownership changes from the Trusted Installer to the local administrator group.

That's It!

SRX: How to Copy & Paste in JUNOS

2018-06-23T22:31:00.001-05:00

Problem:

How copy and paste configuration text with Juniper SRX.

Solution:

Paste text into the config with the "load replace terminal" command.

Return to the router prompt with either CTRL-D or ^D.

Example:

root@SRX# load replace terminal    
[Type ^D at a new line to end input]
interfaces 
    ge-0/0/0 {
        unit 0 {
            family inet {
                address 192.168.1.1/24;
            }
        }
    }
    ge-0/0/1 {
        unit 0 {
            family inet {
                    address 192.168.1.2/24;
            }
        }
    }
}
load complete
[edit]
root@SRX# commit

That's It!

SSH Between SRX Nodes

2018-06-23T21:53:00.001-05:00

Problem:

How to SSH from Node0 to Node 1 within a Juniper SRX cluster.
How to connect from the primary node to the secondary node.

Solution:

SRX 300 Series:

{primary:node0}
smj@SRX> request routing-engine login node 1
SRX 1500 Series:

smj@SRX% rlogin -T node1

That's It!

How to Setup a Virtual Smart Card

2018-06-22T17:29:00.000-05:00

Fun with Virtual Smart Cards!

Outline:

Steps on how to enable a virtual smart card.

Assumptions:

Virtual smart cards require a computer with an initialized TPM. N.B., Windows 10 initializes the TPM by default.

Virtual Smart Card Configuration:

tpmvscmgr.exe create /name VSC /pin prompt /puk prompt /adminkey random /generate

Reset the Virtual Smart Card:

tpmvscmgr.exe destroy /instance root\smartcardreader\0000

PINs, PUKs, and Keys:

Smart Card Personal Identity Number (PIN). The PIN is essentially a password. The PIN can be changed by the end user from any domain computer:

CRTL-ALT-Delete → Change Password → Change PIN.
Smart Card Personal Unlock Key (PUK). Windows locks the PIN after three unsuccessful attempts. End users can use their PUK to unblock their PIN:

CRTL-ALT-Delete → Change Password → Unblock Smart Card.

The PUK is optional but I recommend it. It's simply too easy to lock the PIN!

The PUK changes the PIN. Keep the PUK safe and only use it when its absolutely necessary.

In addition, Windows does not include native tools to change the PUK. In order to choose a new PUK, the virtual smart card must first be deleted (i.e., destroyed) and then recreated. Of course, this process deletes all certificates on the smart card.
Admin Key. The key benefit to the admin key is that it allows Administrators to generate certificate keys for enrolling-on-the-behalf of others. Organizations that do not use enrollment stations should simply generate a random admin key.

References:

https://docs.microsoft.com/en-us/windows/security/identity-protection/virtual-smart-cards/virtual-smart-card-get-started

Quickly Uninstall Single KB Update

2018-05-08T07:01:00.000-05:00

Problem:

Uninstalling Windows Updates is a pain in the neck!

The Windows Update GUI provides a long list of KB updates.
Updates are organized by date and not by KB numbers.
It lacks a built-in search function!

Figure 1. Windows Update History:
No search for you (CRL+F)! :(

Solution:

Use the command line to search and uninstall specific updates.

List installed patches:

wmic qfe list

Uninstall specific patch:

wusa /uninstall /kb:xxxxx

That's It!

Container Does Not Exist on the Smart Card

2018-05-07T20:33:00.000-05:00

T-Shoot Yubikey Minidriver

Problem:

RDP fails to authenticate Yubikey smart card.

Error:

The requested key container does not exist on the smart card (Figure 1).

Figure 1. Smart card container error.

Assumptions:

Yubikey runs as PIV smart card.
Smart card has multiple authentication certificates.
Certificates reside on slots 81-95.

Solution:

By default, Windows uses the NIST SP 800-73 PIV smart card driver. Multiple certificates require the Yubikey smart card Minidriver. Install this driver on both the client and the server.

Important:

The Yubikey smart card MSI package does not install the Minidriver on remote servers or virtual machines. Nor does it provide an error.

The MSI installer only works when a smart card is directly connected (e.g., workstation).

To reiterate, the MSI package only updates the NIST driver when a smart card is attached to the local USB port.

Instead, use the Yubikey limited INF installer on VMs or via RDP.

Figure 2. How to Install the Yubikey Minidriver.

Right-click on ykmd.inf. Left-click on install. That's It!

Fix Chrome Extensions in RDP

2018-02-23T18:17:00.000-06:00

Problem:

RDP users cannot install Chrome extensions from the Chrome Web Store.

Errors:

Could not install package
COULD_NOT_GET_TEMP_DIRECTORY

Figure 1: Chrome Temp Directory Error

Solution:

User logs onto RDP. User does not open Chrome.
Admin creates a new directory on the system drive. This new directory holds user Chrome AppData. For example: c:\\mkdir c:\Temp\RDP\
Move user’s Chrome AppData to the new directory. For example:
c:\move "c:\users\stevenjordan\AppData\Local\Google\Chrome" "c:\temp\RDP\stevenjordan\"
Delete original folder if necessary.
Create new symbolic junction where the old data was located. This junction links to the new location:


c:\mklink /j c:\users\stevenjordan\AppData\Local\Google\Chrome\
"c:\temp\RDP\stevenjordan\Chrome\"

Junction created for c:\users\smjordan\AppData\Local\Google\Chrome\
=== c:\temp\RDP\stevenjordan\Chrome\

Figure 2: New Symbolic Junction for Chrome extension.

Analysis:

Chrome extensions reference DOS device paths. Let's consider how dynamic profile disks use symbolic junctions that point to different disks:

c:\Users  dir 
02/23/2018  11:29 AM  bgates {\??\Volume{a5ae22c7-18b8-11e8-968e-00145de79140}

The junction link causes the problem. Ironically, a second junction link fixes this issue:


c:\Users\bgates\AppData\Local\Google dir
 
 Directory of c:\Users\bgates\AppData\Local\Google

02/20/2018  10:58 AM   DIR
02/20/2018  10:58 AM   DIR
02/20/2018  10:58 AM   JUNCTION  Chrome c:\temp\RDP\bgates\Chrome
09/16/2015  07:46 AM   DIR       Chrome Cleanup Tool
05/14/2014  06:09 AM   DIR       CrashReports
03/11/2014  04:26 PM   DIR       Google Talk
12/04/2017  02:27 AM   DIR       Software Reporter Tool

0 File(s)              0 bytes
7 Dir(s)  36,942,458,880 bytes free

Note how the new junction link points to the system drive.

Additional Thoughts:

This solution is implemented on a per-user basis. It does not universally "fix" Chrome extensions for all RDP users.  Nonetheless, it may be a good fit because it narrows the scope of untrusted applications.

Alternatively, use Group Policy to change user environmental variables:

Group Policy
→ Computer Configuration
  → Administrative Templates
→ System
→ Group Policy
→ Configure user Group Policy loopback processing mode:
Enabled: On
Mode: Merge

→ User Configuration
  → Windows Settings
→ Preferences
→ Environment (right-click) → New
→ New Environment Properties:
Action: Update
User Variable=Check
Name=Temp
Value=c:\Temp\RDP\%USERNAME%
→ Environment (right-click) → New
Action: Update
User Variable=Check
Name=TMP
Value=c:\Temp\RDP\%USERNAME%

This change has a wider-scoping impact. It affects all related AppData programs -not just Chrome. It impacts all RDP users (without GP filtering). Avoid the system drive if possible -use a secondary disk instead. In addition, loopback processing applies user configurations to computer objects (i.e., RDP servers).

That's It!

References:
https://blogs.technet.microsoft.com/grouppolicy/2009/05/13/environment-variables-in-gp-preferences/
https://devtidbits.com/2009/09/07/windows-file-junctions-symbolic-links-and-hard-links/
https://blogs.msdn.microsoft.com/jeremykuhne/2016/04/21/path-format-overview/
https://blog.brankovucinec.com/2017/01/09/users-cant-install-google-chrome-extensions-on-rds-farm/

Fix Broken Checkpoints

2018-02-13T15:28:00.002-06:00

Summary:

How to delete Hyper-V checkpoints that cannot be deleted.

Problem:

Checkpoint cannot be removed from the Hyper-V Manager.

Symptoms:

Hyper-V Manager shows a checkpoint. No option to remove checkpoint.

VM disk directory has VHDX and AVHD files:

Solution:

1. Use PowerShell to view existing snapshot:

PS C:\Users Get-VMSnapshot -VMName tfs.stevenjordan.net

VMName  Name    SnapshotType CreationTime           
------  ----    ------------ ------------          
tfs     tfs     (2/13/2018 - 2:52:36 PM) Standard

2. Remove VM-Snapshot.


PS C:\User Get-VMSnapshot -VMName tfs | Remove-VMSnapshot

3. Confirm Snapshot has been removed.


PS C:\Users Get-VMSnapshot -VMName tfs
PS C:\Users

That's It!

How to Setup BranchCache

2018-02-02T18:34:00.000-06:00

Guide:

Quick and Easy BranchCache Setup.

Overview:

This article provides instructions on how to implement BranchCache.

Topology:

Three office locations:

Primary office in Atlanta (ATL).
Branch offices in Chicago (CHI) and Washington D.C (DCA).

CHI and ATL host local file servers (i.e., hosted cache mode).
DCA is the only office without a dedicated file server (i.e., distributed cache mode).
All clients use Windows Enterprise.

Implement BranchCache:

Install the BranchCache Role and Feature.
BranchCace SSL Certificates.
BranchCache Group policy.

Step 1. Add Roles and Features.

Run the Add Roles and Features Wizard on each file server. Install the (a) BranchCache for Network Files Role; and (b)the BranchCache Feature.

PowerShell:

Install-WindowsFeature BranchCache -IncludeManagementTools
Enable-BCHostedServer -RegisterSCP

Step 2. Adjust Caching.

BranchCache stores files in two directories: (a) HashCache and (b) DataCache.

File servers store file hashes in the HashCache directory. Remote Hosted Cache servers, as well as Distributed Cache clients, use files hashes for content tracking and updates.

The DataCache directory stores content derived from the hash. This directory contains cached remote content (i.e., files) that are served to local clients. Both directories are stored on the system drive -not good!

Adjust the Cache Location:

netsh branchcache set publicationcache directory=D:\BranchCache\
netsh branchcache set localcache directory=D:\LocalCache\

The default HashCache size is a measly 1% of the system disk. The Data Cache is slightly improved with 5% of total disk. Now consider that most system drives hold less that than 100GB. 5GB does not provide enough storage to make BrachCache worthwhile. Let's make BrachCache useful:

Adjust the Cache Size:

Netsh branchcache set publicationcachesize size=5 percent=TRUE
Netsh branchcache set localcachesize size=5 percent=TRUE

Additional caching attributes will be configured via Group Policy (Step 4).

Step 3. BranchCache SSL

BranchCache SSL certificates support Windows 7 clients. It's not necessary for organizations with only Windows 8 or Windows 10 clients. Of course, the file server will probably require certificates for other services -just not BranchCache.

Any trusted SSL certificate will work with BranchCache. We simply need to associate the server certificate with BranchCache:

Add a server certificate in the personal certificate directory for each BranchCache hosted cache server (e.g., ATL and CHI).
Bind the SSL certificate hash (i.e., thumbprint) to the hosted cache server. Use the following command: NETSH HTTP ADD SSLCERT IPPORT=0.0.0.0:443 CERTHASH=xxxxxxxxxxx APPID={d673f5ee-a714-454d-8de2-492e4c1bd8f8}

N.B., CERTHASH is the certificate's thumbprint. Further certificate information found here.

Step 4. Group Policy

Use Group Policies to adjust caching attributes and client settings.

Policies for the File Servers:

Table 1. BranchCache Policy for File Servers.

Policy	Path	Setting	Function
Turn on BranchCache	ComputerConfiguration/ Administrative Templates/ Network/ BranchCache	Enabled
Hash Publication for BranchCache	ComputerConfiguration/ Administrative Templates/ Network/ LanmanServer	Enabled: Value 2	(Hash publication for all shared folders).
MinContentLength Registry Key	ComputerConfiguration/ Preferences/ Windows Settings/ Registry/ MinContentLength	Reg_D WORD: 32768 (Decimal)	Default caching 64KB. New caching 32K. Set as low as 4KB. N.B., Low values may impact performance.

Policies for Windows clients:

Table 2. BranchCache policies for Win 8 and Win 10:

Policy	Path	Setting
Turn on BranchCache	ComputerConfiguration/ Administrative Templates/ Network/BranchCache	Enabled
Configure BranchCache for network files	Computer Configuration/ Administrative Templates/ Network/ BranchCache	Enabled Value:10
Enable Automatic Hosted Cache Discovery by Service Connection Point	Computer Configuration/ Administrative Templates/ Network/ BranchCache	Enabled
Set BranchCache Distributed Cache mode	Computer Configuration/ Administrative Templates/ Network/ BranchCache	Enabled

Note: BranchCache for network files uses round trip latency. Value 10 = 10ms. Hosted Cache mode is for location with dedicated file servers. Distributed Caching is for locations without dedicated file servers.

BranchCache Firewall Policies:

BranchCache requires inbound and outbound client firewall rules.

Table 3. BranchCache Inbound Firewall Group Policies

Policy	Path	Action
BranchCache Content Retrieval (HTTP-In)	Computer Configuration/ Policies/ Windows Settings/ Security Settings/ Windows Firewall with Advanced Security/ Inbound Rules	a. Right-click Inbound Rules. b. Left-click New Rule. c. Add predefined BranchCache rules.
BranchCache Hosted Cache Server (HTTP-In)
BranchCache Peer Discovery (WSD-In)
BranchCache Content Retrieval (HTTP-Out)	Computer Configuration/ Policies/ Windows Settings/ Security Settings/ Windows Firewall with Advanced Security/ Outbound Rules	a. Right-click Inbound Rules. b. Left-click New Rule. c. Add predefined BranchCache rules.
BranchCache Hosted Cache Clietnt (HTTP-Out)
BranchCache Hosted Cache Server (HTTP-Out)
BranchCache Peer Discovery (WSD-Out)

Optional: BranchCache for WSUS and IIS Servers

BranchCache also accelerates content for web servers and BITS application servers. Simply install the BranchCache feature and ensure the service is running. No other configuration steps are necessary.

Evaluate

User PowerShell and Performance monitor to ensure BranchCache works:

http://www.stevenjordan.net/2013/03/2012-branchcache-troubleshooting.html

That's It!

References:

http://social.technet.microsoft.com/wiki/contents/articles/14309.branchcache-frequently-asked-questions.aspx

http://technet.microsoft.com/en-us/library/hh848420.aspx

http://technet.microsoft.com/en-us/library/jj572970.aspx

http://technet.microsoft.com/en-us/library/dd637785(v=ws.10).aspx

http://technet.microsoft.com/en-us/library/ff710438(v=ws.10).aspx

http://technet.microsoft.com/en-us/library/dd637785(v=ws.10).aspx

https://ammarhasayen.com/2013/10/11/branchcache-course-109-where-files-are-stored/

https://2pintsoftware.com/branchcache-teeny-weeny-files/