First, the essential ideas
- Storm control
- Storm control suppresses specified traffic categories when their measured rate crosses a threshold. It does not identify whether a sender is an authorized router.
- Rising and falling threshold
- The rising threshold starts suppression; a lower falling threshold permits recovery after traffic subsides. The gap reduces repeated switching between states near one value.
- Broadcast and multicast
- Broadcast targets all devices in an Ethernet broadcast domain. Multicast targets a group. IPv6 uses multicast for discovery rather than IPv4-style broadcast.
- RA and RS
- An IPv6 Router Advertisement (RA) conveys router and prefix information. A Router Solicitation (RS) asks routers to advertise. Both are ICMPv6 messages, not DHCPv4.
- RA guard
- RA guard examines advertisements at a Layer 2 boundary and permits or blocks them according to policy. A host-facing role rejects router advertisements arriving from that port.
- SLAAC and lifetime
- Stateless Address Autoconfiguration lets a host form IPv6 addresses from suitable advertised information. Advertised lifetimes mean old addresses or routes may remain after new RAs stop.
- Ingress and platform support
- Ingress means traffic entering a particular interface. Hardware and software determine which packets a feature can inspect and how thresholds are enforced.
Two packets can both be undesirable for different reasons: one contributes to excessive traffic, while another falsely announces a router. A low-rate unwanted advertisement can evade a volume-only design. Conversely, a legitimate device can generate too much traffic without violating its role.
See the idea
Volume is not authority
Storm control limits a traffic rate; RA guard limits which ports may advertise an IPv6 router.
Measure the rate
Choose a traffic category and units. A configured threshold is not proof of measured suppression.
What this model leaves out: This is a control comparison, not a measured traffic graph. Threshold effectiveness and advanced packet handling remain untested.
Full visual explanation and references
Three comparison records show rate thresholds, a host role that rejects RAs and a router role that permits legitimate RAs.
This is a control comparison, not a measured traffic graph. Threshold effectiveness and advanced packet handling remain untested.
- Measure the rate
Choose a traffic category and units. A configured threshold is not proof of measured suppression.
www.cisco.com - Protect the host edge
The host-role policy rejects router advertisements arriving from that port; it does not cap all traffic volume.
www.cisco.com - Preserve the real router
Attach the router role to the verified router port. Retest fresh advertisements after any template change.
www.cisco.com
One idea at a time
Start with something familiar.
Separate two questions on your worksheet: Is the rate acceptable, and is this port allowed to send router advertisements? Write the expected router port before entering a policy name; a name does not automatically discover the device attached to it.
Why learn this?
Overly low thresholds can discard useful traffic, while incorrect RA roles can hide the real gateway. Restoring connectivity by removing all protection leaves the design question unanswered.
An everyday comparison
A building can have both a limit on how many deliveries enter per minute and a rule naming who may issue official notices. These are different checks even though both operate near the entrance.
What happens in a network
Storm control resembles the delivery-rate limit; RA guard resembles the notice-authority rule. A small number of unauthorized notices can matter even when total volume is low.
Where the comparison stopsNetwork policies inspect supported packet fields and port roles, not human intent. Platform limits and topology determine whether packets actually cross the enforcement point.
Follow one worked example
- Record the correct advertisement source.
The host solicits an RA and records the router's link-local source and advertised prefix. This baseline does not depend on a previously cached default route.
Why: The safe fault later changes advertisement reception, which may not immediately remove existing host configuration.
- Install two different kinds of control.
The host port receives an illustrative broadcast storm threshold and a host RA role. The actual router port receives a router RA role.
Why: Broadcast limits do not authorize IPv6 multicast advertisements; each control has its own scope.
- Correct the attachment, not the test.
Temporarily putting the host policy on the router port blocks legitimate advertisements. Restore the router role and repeat the same solicitation.
Why: A narrow attachment repair preserves the host-facing protection and provides a controlled comparison.
Your first small task
On paper, compare a quiet unauthorized RA with a high-rate broadcast stream. Choose the appropriate control for each, then explain why a one-percent broadcast limit is not evidence that unauthorized IPv6 RAs are blocked.
Show a hint
Classify the packet's purpose and destination type before choosing the control.
Check the expected result
RA guard addresses the role violation; storm control addresses the rate. IPv6 advertisements are not Ethernet broadcast traffic.
Pause and explain it in your own words
Why might a host keep an IPv6 address after the router's new RAs are blocked?
Show a hint
Consider the lifetimes of information already received rather than assuming every control message is required continuously.
Show the explanation
Previously learned addresses and routes can remain valid until their lifetimes expire. Therefore an existing address or a successful local ping does not prove fresh advertisements pass. Use a new solicitation and inspect the response.
Short answer
What should you understand today?
Storm control asks how much of a traffic class enters a port; RA guard asks whether an IPv6 router advertisement is allowed to arrive there. Configure them for different purposes. Choose storm thresholds from measured traffic and assign RA roles from the actual topology, then verify fresh advertisements rather than relying only on an old address.
Before you begin
Learning targets
- Review IPv6 prefixes, link-local addresses, SLAAC and Layer 2 access ports.
- Use dedicated Catalyst 9200 IOS XE 17.12, ISR4321 IOS XE 17.9 and Ubuntu 22.04 hardware.
- Install the ndisc6 package on the host before isolation; do not attach these lab links to production.
- Distinguish volume-based suppression from advertisement policy.
- Read rising/falling thresholds without treating example values as production recommendations.
- Configure host-facing and router-facing RA guard roles deliberately.
- Observe a fresh RA baseline, introduce one role error, restore it and retest.
Words you will meet
Open a word when you need its meaning. You do not need to memorize the whole list before reading.
Storm control
Storm control suppresses specified traffic categories when their measured rate crosses a threshold. It does not identify whether a sender is an authorized router.
Rising and falling threshold
The rising threshold starts suppression; a lower falling threshold permits recovery after traffic subsides. The gap reduces repeated switching between states near one value.
Broadcast and multicast
Broadcast targets all devices in an Ethernet broadcast domain. Multicast targets a group. IPv6 uses multicast for discovery rather than IPv4-style broadcast.
RA and RS
An IPv6 Router Advertisement (RA) conveys router and prefix information. A Router Solicitation (RS) asks routers to advertise. Both are ICMPv6 messages, not DHCPv4.
RA guard
RA guard examines advertisements at a Layer 2 boundary and permits or blocks them according to policy. A host-facing role rejects router advertisements arriving from that port.
SLAAC and lifetime
Stateless Address Autoconfiguration lets a host form IPv6 addresses from suitable advertised information. Advertised lifetimes mean old addresses or routes may remain after new RAs stop.
Ingress and platform support
Ingress means traffic entering a particular interface. Hardware and software determine which packets a feature can inspect and how thresholds are enforced.
Rate suppression needs a traffic baseline
Storm control monitors a selected traffic class and compares it with a configured threshold. The platform supports percentage, bits-per-second and packets-per-second forms. Percentages depend on interface bandwidth, and hardware enforcement can be approximate. A rising value of 1.00 and falling value of 0.50 means a one-percent start and half-percent recovery point in our illustration, not one packet per second. These are teaching values, not universal safe settings.
- Do not generate a flood to make this beginner lab appear complete.
- Configured thresholds and measured suppression are separate claims.
Traffic categories are not interchangeable
Broadcast, multicast and unicast controls operate on different traffic classes. Suppression of multicast can affect legitimate routing and discovery traffic as well as unwanted traffic. The exact exceptions and hardware behavior must come from the selected platform guide. Our lab configures broadcast only on the single-host port; it does not infer that this protects every IPv6 control message. A threshold of zero is not a harmless starting value.
- Choose the traffic category deliberately and inspect its installed value.
- Avoid assuming every device implements identical unicast or multicast accounting.
RA guard follows the ingress role
RA guard is deployed where advertisements traverse a controlled Layer 2 device. The simplest policy differentiates host-facing input, where router advertisements should not originate, from a legitimate router-facing input. Cisco's selected guide calls for explicit router roles on router-facing ports when host roles are used. This is not the same feature as DHCP snooping or IPv4 ARP inspection. It does not authenticate every IPv6 packet.
- Port-role correctness is part of the security policy.
- A downstream shared segment that bypasses the guard is outside this enforcement boundary.
Test new information, not only cached state
Hosts can retain previously advertised addresses, prefixes and default routers for their respective lifetimes. Removing new RAs does not necessarily make an existing local ping fail immediately. This lab therefore uses rdisc6 to send a bounded solicitation and report received advertisements, rather than flushing every host address or waiting for arbitrary timers. Record the actual router source and prefix before and after the policy change.
- Use the same interface and solicitation command in every comparison.
- A local echo reply tests a different behavior from receiving a new RA.
Implementation limits are part of honest security
IETF guidance documents why implementations must inspect IPv6 header chains adequately and handle problematic fragmentation safely. A single ordinary RA test does not prove resistance to every evasion technique. Follow the supported software and hardware guidance, patching process and authorized test plan; this lesson provides no crafted evasion traffic. Nor does it claim that the GNS3 built-in switch implements Catalyst RA guard or hardware policers.
- Do not claim universal rogue-router prevention from one successful test.
- Separate policy configuration, ordinary traffic observation and specialized security validation.
Track the new blueprint scope explicitly
Storm control and RA guard extend beyond the specifically listed v1.1 5.7 controls, so this chapter is supporting extension for that version. They are named within announced v2.0 4.7. Day 51 supplies the companion port-security, DHCP-snooping and DAI instruction. v1.1 is current through 2 February 2027; v2.0 starts on 3 February. This mapping does not convert unperformed hardware tests into completed practical evidence.
- Keep configuration coverage and observed competence separate.
- Do not relabel extension material as a named current-version objective.
Real-world walkthrough
A quiet IPv6 failure after an access template change
In a fictional lab change, a standard host-port template is applied to the port connected to the real IPv6 router. There is no traffic storm and old client addresses remain visible, yet newly connected hosts cannot receive router advertisements. An operator who checks only existing ping results might miss the role error.
- Trace which switch port actually receives R1's advertisements and compare it with the template's intended host role.
- Preserve a fresh solicitation result and the current policy attachments before changing configuration.
- Check whether the incident concerns rates, router-role authorization or both; do not lower storm thresholds without evidence.
- Restore the router role on that one port while keeping the host role on the endpoint-facing port.
- Repeat the identical solicitation and record the router source and prefix, with load and evasion tests explicitly excluded.
Guided GNS3 lab
Inspect thresholds and repair one RA role assignment
Configure broadcast storm control and RA guard on dedicated hardware, observe legitimate advertisements and repair a role mismatch. The exercise avoids floods; neither hardware runtime nor measured suppression is claimed here.
Addressing plan
| Device | Interface | Address | Purpose |
|---|---|---|---|
| R1 | GigabitEthernet0/0/0 | 2001:db8:52::1/64; link-local automatically formed | Advertise the isolated prefix and router information. |
| Client | enp1s0 | IPv6 link-local; SLAAC in 2001:db8:52::/64 | Observe actual address and RA source; no fixed suffix assumed. |
| SW1 | Gi1/0/1-2 | Layer 2 access VLAN 52 | Enforce distinct ingress roles; no SVI required. |
Set up the lab
- Start from backed-up dedicated equipment, not Day 51's active policy state. Only the two named ports are in scope.
- Use direct USB/serial consoles with documented settings, usually 9600 8N1 and no flow control. Verify show version and port labels.
- Enable ordinary host IPv6 reception on Client's dedicated NIC; verify forwarding is off and the lab NIC accepts RAs. No DHCPv6 server is needed.
- Install rdisc6 before isolation. Paper alternative: evaluate policy roles and threshold math; this does not prove hardware enforcement.
- The threshold is illustrative. No flood generator, multicast suppression, shutdown action or remote management path is part of this exercise.
Prepare the isolated switching segment
Open SW1's direct USB or serial console in your terminal application before typing; confirm its hostname. Confirm fresh unused ports and the release, then put both links in VLAN 52. Keep management on the direct console.
enable
configure terminal
vlan 52
exit
interface range GigabitEthernet1/0/1 - 2
switchport mode access
switchport access vlan 52
no shutdown
endWhat each command means
enable- Enter privileged EXEC on this authorized lab device; stop if access is not authorized.
configure terminal- Enter global configuration from privileged EXEC; changes affect the active configuration.
vlan 52- Create the isolated IPv6 exercise VLAN.
exit- Return from VLAN mode to global configuration.
interface range GigabitEthernet1/0/1 - 2- Select exactly the router and host lab ports.
switchport mode access- Use explicit untagged access links.
switchport access vlan 52- Place the two links in the same Layer 2 domain.
no shutdown- Enable the selected lab interfaces.
end- Return to privileged EXEC without saving or undoing the accepted changes.
- What you should see
- Expect the two connected ports in VLAN 52 and eventually forwarding.
- Why this step matters
- A known Layer 2 path is required before a missing advertisement can be attributed to RA guard.
Configure the legitimate IPv6 router
Open R1's direct USB or serial console in your terminal application before typing; confirm its hostname. Enable IPv6 routing and address only the mapped lab interface. Do not suppress its advertisements or configure a default route toward an external network.
enable
configure terminal
ipv6 unicast-routing
interface GigabitEthernet0/0/0
ipv6 address 2001:db8:52::1/64
no shutdown
end
show ipv6 interface GigabitEthernet0/0/0What each command means
enable- Enter privileged EXEC on this authorized lab device; stop if access is not authorized.
configure terminal- Enter global configuration from privileged EXEC; changes affect the active configuration.
ipv6 unicast-routing- Enable IPv6 router forwarding and normal router advertisement behavior.
interface GigabitEthernet0/0/0- Select the interface cabled to SW1 Gi1/0/1.
ipv6 address 2001:db8:52::1/64- Assign the documentation prefix on the isolated segment.
no shutdown- Enable the dedicated router interface.
end- Return to privileged EXEC without saving or undoing the accepted changes.
show ipv6 interface GigabitEthernet0/0/0- Record the actual link-local source and advertisement settings.
- What you should see
- Expect the interface to advertise its /64 with a link-local router source.
- Why this step matters
- The legitimate origin and prefix must be known before testing which policy allows its messages.
Record a fresh advertisement baseline
Open Client's local terminal console before typing. Verify enp1s0 is the isolated NIC. The bounded solicitation should report an advertisement from R1; do not infer success from a previously present address alone.
ip -6 address show dev enp1s0
sudo rdisc6 -1 enp1s0
ip -6 route show dev enp1s0What each command means
ip -6 address show dev enp1s0- Record current link-local and any autoconfigured address.
sudo rdisc6 -1 enp1s0- Solicit router advertisements on the named NIC and stop after the first response.
ip -6 route show dev enp1s0- Record routes learned on this interface without assuming they immediately expire later.
- What you should see
- Expect R1's advertisement with 2001:db8:52::/64; record actual output and stop if absent.
- Why this step matters
- A fresh solicitation tests the control message that the later role fault is intended to block.
Configure the illustrative broadcast limit
Open SW1's direct USB or serial console in your terminal application before typing; confirm its hostname. Apply only a broadcast threshold on the host port. Do not generate excess traffic or select a shutdown action. Read back the values and record that suppression is unmeasured.
configure terminal
interface GigabitEthernet1/0/2
storm-control broadcast level 1.00 0.50
end
show storm-control GigabitEthernet1/0/2 broadcastWhat each command means
configure terminal- Enter global configuration from privileged EXEC; changes affect the active configuration.
interface GigabitEthernet1/0/2- Select the single-host ingress port.
storm-control broadcast level 1.00 0.50- Set illustrative one-percent rising and half-percent falling thresholds.
end- Return to privileged EXEC without saving or undoing the accepted changes.
show storm-control GigabitEthernet1/0/2 broadcast- Inspect the configured broadcast thresholds and current state.
- What you should see
- Expect the configured percentages to be visible; no drop or performance result is predicted.
- Why this step matters
- Reading a configured limit is useful but cannot establish its behavior under real traffic load.
Create explicit host and router RA roles
Open SW1's direct USB or serial console in your terminal application before typing; confirm its hostname. Define both policies before attaching them. These policies are separate from DHCP snooping and the storm-control command.
configure terminal
ipv6 nd raguard policy EDGE52
device-role host
exit
ipv6 nd raguard policy ROUTER52
device-role router
end
show ipv6 nd raguard policy EDGE52
show ipv6 nd raguard policy ROUTER52What each command means
configure terminal- Enter global configuration from privileged EXEC; changes affect the active configuration.
ipv6 nd raguard policy EDGE52- Create the policy intended for the Client-facing port.
device-role host- Declare that advertisements must not originate from this attached host role.
exit- Return to global configuration for the other policy.
ipv6 nd raguard policy ROUTER52- Create the policy for the legitimate router connection.
device-role router- Declare the connected device to be an authorized router role.
end- Return to privileged EXEC without saving or undoing the accepted changes.
show ipv6 nd raguard policy EDGE52- Read back the host policy definition.
show ipv6 nd raguard policy ROUTER52- Read back the router policy definition.
- What you should see
- Expect distinct host and router roles, with neither policy attached merely by being created.
- Why this step matters
- Definition and application are separate; a policy name alone does not protect any link.
Attach each role to its real ingress port
Open SW1's direct USB or serial console in your terminal application before typing; confirm its hostname. Attach the host policy to Gi1/0/2 and router policy to Gi1/0/1. Inspect both interface configurations so a swapped cable label cannot go unnoticed.
configure terminal
interface GigabitEthernet1/0/2
ipv6 nd raguard attach-policy EDGE52
interface GigabitEthernet1/0/1
ipv6 nd raguard attach-policy ROUTER52
end
show running-config interface GigabitEthernet1/0/1
show running-config interface GigabitEthernet1/0/2What each command means
configure terminal- Enter global configuration from privileged EXEC; changes affect the active configuration.
interface GigabitEthernet1/0/2- Select the Client-facing ingress port.
ipv6 nd raguard attach-policy EDGE52- Attach host-role RA protection at the client edge.
interface GigabitEthernet1/0/1- Select the R1-facing ingress port.
ipv6 nd raguard attach-policy ROUTER52- Attach the explicit router role to the legitimate RA source path.
end- Return to privileged EXEC without saving or undoing the accepted changes.
show running-config interface GigabitEthernet1/0/1- Check the router-facing attachment.
show running-config interface GigabitEthernet1/0/2- Check host policy and storm threshold together.
- What you should see
- Expect correct roles on both actual cables, not just in the policy definitions.
- Why this step matters
- Misattachment changes which device is allowed to advertise without changing the policy text.
Verify the protected advertisement path
Open Client's local terminal console before typing. Repeat the same bounded solicitation after attaching the two policies. Keep the source router and prefix unchanged.
sudo rdisc6 -1 enp1s0What each command means
sudo rdisc6 -1 enp1s0- Verify fresh advertisements still arrive with the intended roles installed.
- What you should see
- Expect the same legitimate router and prefix as the unfiltered baseline.
- Why this step matters
- The role policy should preserve intended control traffic while placing a boundary on the host port.
Introduce a bounded router-role mistake
Open SW1's direct USB or serial console in your terminal application before typing; confirm its hostname. In this disconnected lab only, detach ROUTER52 from the router-facing port and attach EDGE52 there. Leave the real Client port and the storm threshold unchanged.
configure terminal
interface GigabitEthernet1/0/1
no ipv6 nd raguard attach-policy ROUTER52
ipv6 nd raguard attach-policy EDGE52
endWhat each command means
configure terminal- Enter global configuration from privileged EXEC; changes affect the active configuration.
interface GigabitEthernet1/0/1- Select only the legitimate router ingress.
no ipv6 nd raguard attach-policy ROUTER52- Remove the correct role attachment from that one port.
ipv6 nd raguard attach-policy EDGE52- Deliberately misclassify the router connection as host-facing.
end- Return to privileged EXEC without saving or undoing the accepted changes.
- What you should see
- Expect the router-facing interface now references the host role.
- Why this step matters
- This creates an ordinary configuration fault without generating rogue advertisements or traffic overload.
Observe blocked fresh advertisements
Open Client's local terminal console before typing. Repeat the original solicitation and allow its bounded retries to finish. Existing addresses or routes may remain valid; do not delete them simply to force a dramatic failure.
sudo rdisc6 -1 enp1s0
ip -6 address show dev enp1s0What each command means
sudo rdisc6 -1 enp1s0- Solicit fresh router information during the host-role misattachment.
ip -6 address show dev enp1s0- Record that previously learned addressing may still exist.
- What you should see
- Expect no fresh RA response through the misclassified router port, even if old addressing remains.
- Why this step matters
- This separates information reception from cached configuration and avoids a false instant-outage claim.
Restore the router attachment
Open SW1's direct USB or serial console in your terminal application before typing; confirm its hostname. Remove only the wrong role from Gi1/0/1 and restore ROUTER52. Leave EDGE52 on the real host port and retain the illustrative storm threshold.
configure terminal
interface GigabitEthernet1/0/1
no ipv6 nd raguard attach-policy EDGE52
ipv6 nd raguard attach-policy ROUTER52
end
show running-config interface GigabitEthernet1/0/1What each command means
configure terminal- Enter global configuration from privileged EXEC; changes affect the active configuration.
interface GigabitEthernet1/0/1- Select the same router-facing port affected by the experiment.
no ipv6 nd raguard attach-policy EDGE52- Remove the deliberate wrong host-role attachment.
ipv6 nd raguard attach-policy ROUTER52- Restore the known correct router role.
end- Return to privileged EXEC without saving or undoing the accepted changes.
show running-config interface GigabitEthernet1/0/1- Verify the final router-facing attachment.
- What you should see
- Expect the protected baseline restored without broad trusted-port bypasses.
- Why this step matters
- A narrow inverse repairs the mistake while preserving the intended edge protection.
Retest and document unmeasured behavior
Open Client's local terminal console before typing. Repeat the same solicitation and record the actual response. Preserve all three observations, then leave the dedicated lab isolated or disconnect its data cables.
sudo rdisc6 -1 enp1s0
ip -6 route show dev enp1s0What each command means
sudo rdisc6 -1 enp1s0- Verify the legitimate advertisement returns after the attachment repair.
ip -6 route show dev enp1s0- Record the final route state without claiming Internet reachability.
- What you should see
- Expect the original router and prefix to appear again; hardware execution is still unmeasured in this authored lesson.
- Why this step matters
- Close with the actual control-message test, and label load, evasion and production compatibility as separate untested questions.
Verify
- Require a fresh RA response before adding any guard policy.
- Read back the broadcast threshold and its units without claiming measured suppression.
- Confirm host and router policy definitions plus exact interface attachments.
- Compare fresh solicitations before fault, during fault and after the exact role restoration.
- Record that existing addresses can persist and that no flooding or evasion tests were run.
Troubleshoot
- If no baseline RA appears, check interface state, VLAN forwarding, R1 advertisement settings and host IPv6 prerequisites before touching guard policy.
- If new RAs disappear only after policy attachment, verify role and cable mapping on both ports.
- If ordinary traffic is unexpectedly suppressed, inspect traffic category and units; never lower a threshold blindly to diagnose a different protocol fault.
- If the platform rejects a command, use the declared supported hardware or label the activity as paper analysis, not an emulator success.
GNS3 does not provide Cisco images. A license or entitlement must permit the image in the selected environment; do not share or redistribute image files. Cisco Modeling Labs is an official alternative. Its supplied Cisco reference images are licensed for use within CML, not automatically for export to GNS3. An unlicensed learner must use the explicitly labeled paper alternative, not report simulated Cisco execution.
- Restore ROUTER52 to Gi1/0/1 and retain EDGE52 on Gi1/0/2; repeat the solicitation before stopping.
- Keep the threshold labeled illustrative and do not transfer it into a production template without a measured baseline.
- Disconnect the two dedicated data links after recording final state; use pre-lab backups for an independently approved full teardown.
Practice set
Answer before you reveal
01What does level 1.00 0.50 mean in this command?
These are percentages, not packets per second. Hardware measurement and enforcement can differ from simple arithmetic.
02Why does a broadcast threshold not authorize IPv6 routers?
IPv6 discovery uses multicast and role-sensitive control messages. A low-rate unwanted RA needs a different safeguard.
03Why define a router role as well as a host role?
Applying a host template everywhere can suppress the legitimate gateway. Follow the documented platform role requirements.
04Can an IPv6 address remain after fresh RAs stop?
A retained address does not prove the current advertisement path works. Test fresh information reception.
05Does this lab prove evasion resistance?
Extension-header parsing and fragmentation behavior require platform-specific validation beyond this bounded beginner exercise.
06What is the current-version mapping?
Do not silently expand the specifically listed v1.1 5.7 controls or claim all v2.0 security is covered by this lesson.
Knowledge check
Quiz: prove the reasoning
Keep these
Technical takeaways
- Volume protection and router-role protection solve different problems.
- Threshold units and platform behavior matter as much as the configured number.
- Attach host and router policies according to verified physical roles.
- Fresh advertisements and cached IPv6 state are different observations.
- Ordinary RA tests do not establish resistance to every implementation edge case.
- No flood or hardware performance claim is needed to teach a safe configuration workflow.