Latest Cisco, PMP, AWS, CompTIA, Microsoft Materials on SALE Get Now Get Now

IPv6 RA Guard: Every Port Filtered, and the Rogue Router Still Wins

Infrastructure Security and Services ｜ Configuration ｜ Intermediate ｜ 23 min read

A router advertisement is a small message with unusual authority. It tells every host on the segment who the default router is, which prefixes exist, whether to configure addresses automatically or ask a server, how far packets may travel and which name servers to use. Nothing authenticates it, and a host that receives one from a device with no business sending it will believe every word.

Filtering those messages at the access port is the highest-value control on an IPv6 segment, and it is genuinely simple to deploy. What is not simple is the boundary: the filter protects hosts from devices on other ports, and the accidental rogue router in a real enterprise is usually sitting on the same unmanaged switch as the hosts it affects, where no port-based filter can see it at all.

This article covers what an advertisement actually tells a host and why each field matters, how to build a policy field by field rather than accepting the defaults, how to prove in a lab that it works, how the filter is evaded and what closes the gap, and what it does not protect — including the awkward tail after a rogue advertisement has already been believed. It is written for the lab rather than for the written exam, and sits alongside the rest of the CCIE Enterprise Infrastructure lab certification track.

Blog ClaimThis filter on a port does not protect the hosts behind that port from one another, and the accidental rogue router in an enterprise almost always lives exactly there — on the unmanaged switch under somebody's desk, on the wrong side of the only control you deployed.
Each field in the advertisement has a policy control that checks it, except the router lifetime — which is why a rogue advertisement that was believed once continues to be believed after the rogue is removed.

What Does an Advertisement Tell a Host?

What is in the message?

Six things that change host behaviour. The source address, which becomes a default router. A lifetime, saying how long to keep treating it as one. One or more prefixes, each with a flag saying whether to build an address from it. Two flags saying whether to also ask an address server. A hop count for the host to use on outgoing packets. And a preference, which decides the winner when more than one router advertises. A rogue can set every one of these, and each produces a different and separately diagnosable failure.

A Deeper Dive into the Fields

The source address and the lifetime

The source becomes an entry in the host's default router list, and the lifetime says for how long. A lifetime of zero means "I am not a router" and is how a router gracefully withdraws. Any non-zero value keeps the host using it until it expires or is refreshed.

There is no policy field that constrains the lifetime, and that omission has a consequence covered at the end of this article: an advertisement that was accepted before the filter was applied continues to be believed for its full lifetime afterwards, with the rogue gone and nothing to withdraw it.

The prefix and its autonomous flag

A prefix option with the autonomous flag set tells a host to build a global address from that prefix. That is how a rogue gives hosts addresses in a range it controls, which combined with being the default router is a complete interception.

The flag can also be cleared, which advertises the prefix as on-link without offering address configuration. A rogue can use that to tell hosts that a prefix is reachable locally when it is not, which produces resolution attempts that go nowhere and traffic that is black-holed rather than intercepted.

The two configuration flags

One says addresses should come from a server rather than from autoconfiguration; the other says other settings should come from a server. Together they determine whether hosts will attempt a server exchange at all.

Setting them where the network does not use a server produces hosts that wait for a response that never comes, which delays their connectivity without breaking it. Clearing them where the network does use a server produces hosts that never ask, which is the more damaging direction. Both are worth constraining in policy because both are silent.

The hop count

A value telling hosts what hop count to place on outgoing packets. Set low enough, traffic reaches the first router and no further, which produces a network where local communication works and everything remote fails.

That symptom looks like a routing problem and is not, which makes it worth knowing about. Constraining a minimum in policy rejects an advertisement carrying an unreasonably low value, and it costs nothing because no legitimate advertisement carries one.

! Tighten the router so a rogue has less room and a shorter tail
R1(config)# interface GigabitEthernet0/1
R1(config-if)# ipv6 nd ra interval 60
R1(config-if)# ipv6 nd ra lifetime 180
R1(config-if)# ipv6 nd prefix 2001:DB8:10::/64 2592000 604800
!
! A router that must never be a default router for this segment
R2(config)# interface GigabitEthernet0/2
R2(config-if)# ipv6 nd ra lifetime 0

The preference

Three levels, with the middle one as the default. A host presented with two routers uses the one with the higher preference. So a rogue that advertises the highest level wins against a legitimate router that left the field at its default, without needing to suppress the legitimate advertisement at all.

This is the cheapest possible attack and the easiest to block: a policy that rejects any advertisement claiming a preference above what the real routers use removes it entirely. It is also worth setting the real routers explicitly rather than leaving them at the default, so that the policy has something definite to permit.

! What a legitimate advertisement looks like on the wire
R1# show ipv6 interface GigabitEthernet0/1 | section ND
  ND DAD is enabled, number of DAD attempts: 1
  ND reachable time is 30000 milliseconds
  ND advertised reachable time is 0 milliseconds
  ND advertised retransmit interval is 0 milliseconds
  ND router advertisements are sent every 200 seconds
  ND router advertisements live for 1800 seconds
  ND advertised default router preference is Medium
!
! Set the preference explicitly so the policy can permit it
R1(config)# interface GigabitEthernet0/1
R1(config-if)# ipv6 nd router-preference high
Field a rogue sets Effect on hosts Looks like
Source, with a lifetime It becomes the default router Total interception or black hole
Prefix with autonomous flag Hosts build addresses in its range Wrong source addresses everywhere
Managed config flag set Hosts wait for a server that is absent Slow connectivity on startup
Low hop count Traffic dies after the first router Local works, remote fails
Preference high Beats the legitimate router Intermittent, depends on timing
Set the real routers explicitlyA policy that permits a preference up to a stated level needs the legitimate routers to state theirs. Leaving them at the default and configuring a maximum in policy works, and configuring both explicitly means the intended value is written down in two places rather than assumed in one.
Sub claimEvery field in the advertisement has a policy control except the lifetime, which is why a rogue that was believed once keeps being believed long after it has been disconnected.

How Is the Policy Built, Field by Field?

What are the two shapes?

A policy for ports where no router should exist, which declares the port role as a host and discards every advertisement without further examination. And a policy for ports where a router legitimately sits, which accepts advertisements and then checks them — the source address against a list, the advertised prefixes against a list, the configuration flags against expected values, the hop count against a minimum and the preference against a maximum. The first is one line; the second is where the thought goes.

A Deeper Dive into the Policy

The client-facing policy

One statement. A port declared as facing hosts discards advertisements arriving on it, and no further clause is needed or evaluated. This covers the overwhelming majority of ports in an access layer and carries no risk beyond applying it to the wrong port.

! Client ports: nothing to think about
Sw1(config)# ipv6 nd raguard policy RA-HOST
Sw1(config-nd-raguard)# device-role host
!
Sw1(config)# interface range GigabitEthernet1/0/1 - 48
Sw1(config-if-range)# ipv6 nd raguard attach-policy RA-HOST

The router-facing policy, clause by clause

Accepting advertisements is the starting point, and every clause after that narrows what is accepted. The source list names the addresses the real routers use, which are link-local addresses and therefore stable and known. The prefix list names the prefixes that may be advertised, which catches a legitimate router that has been misconfigured as well as a hostile one on a trusted port.

The flag clauses state what the configuration flags must be, which is a direct expression of whether this network uses an address server. The hop count minimum and preference maximum reject values outside what the design uses. Together they turn a port that accepts advertisements into a port that accepts this network's advertisements.

! Router-facing: accept, then check everything
Sw1(config)# ipv6 access-list RA-SOURCES
Sw1(config-ipv6-acl)# permit ipv6 host FE80::1 any
Sw1(config-ipv6-acl)# permit ipv6 host FE80::2 any
!
Sw1(config)# ipv6 prefix-list RA-PREFIXES permit 2001:DB8:10::/64
Sw1(config)# ipv6 prefix-list RA-PREFIXES permit 2001:DB8:20::/64
!
Sw1(config)# ipv6 nd raguard policy RA-ROUTER
Sw1(config-nd-raguard)# device-role router
Sw1(config-nd-raguard)# trusted-port
Sw1(config-nd-raguard)# match ipv6 access-list RA-SOURCES
Sw1(config-nd-raguard)# match ra prefix-list RA-PREFIXES
Sw1(config-nd-raguard)# managed-config-flag off
Sw1(config-nd-raguard)# other-config-flag off
Sw1(config-nd-raguard)# hop-limit minimum 64
Sw1(config-nd-raguard)# router-preference maximum high

Where to attach it

Per port or per VLAN. Per VLAN is less typing and applies to every port carrying that VLAN — including the uplink, which is exactly the port that must not receive the client policy. Port attachment takes precedence, so an explicit router policy on the uplink overrides the VLAN attachment correctly.

The rule is to apply both in the same change, never in sequence. A VLAN attachment applied first, with the uplink override to follow, produces a window in which every host on the switch loses its default router.

! VLAN-wide, with the uplink overridden in the SAME change
Sw1(config)# vlan configuration 10,20,30
Sw1(config-vlan-config)# ipv6 nd raguard attach-policy RA-HOST
!
Sw1(config)# interface TenGigabitEthernet1/0/1
Sw1(config-if)# ipv6 nd raguard attach-policy RA-ROUTER
!
! Confirm which policy landed on which target
Sw1# show ipv6 nd raguard policy RA-HOST
Sw1# show ipv6 nd raguard policy RA-ROUTER
Pitfall: every host loses its gateway the instant a VLAN policy is attached Symptom: attaching the client policy at the VLAN level causes every device on the switch to lose IPv6 connectivity within seconds, while IPv4 continues normally. Cause: the VLAN attachment covers every port carrying that VLAN, and the uplink carries it. The legitimate router's advertisements arrive over the uplink and are discarded by a policy written for client ports. Confirm: the drop counters increment on the uplink interface rather than on client ports. Fix: attach the router-role policy to the uplink at the port level in the same configuration change, since port attachment takes precedence over VLAN attachment.

The trusted-port clause, which is narrower than it sounds

Declaring a port trusted relaxes some checks, and it does not disable the match clauses that are also configured. A trusted port with a source list still enforces the source list. That combination is the useful one: trust the port enough to accept advertisements, and still require them to come from the right place and say the right things.

A trusted port with no match clauses accepts anything, which is appropriate only where the far side is a device entirely under your control and reached over a link nothing else can join.

Policies for ports that might be either

Some ports genuinely change role — a port that serves a user today and a lab router next month. The temptation is a permissive policy that covers both, which means the port is permanently a router port.

The better answer is a deliberate change when the role changes. It is a two-line configuration and it keeps the default posture strict, where the permissive compromise makes one port a permanent hole that nobody revisits.

What the defaults do if you configure nothing

A policy with no role stated behaves permissively, which is the opposite of useful. Every policy should state the role explicitly, even where the intended behaviour matches whatever the default happens to be, because the default is a property of the software version and the explicit statement is not.

Sub claimThe client-facing policy is one line and the router-facing one is where the design lives, because that is the only port where an advertisement is accepted and therefore the only port where what it says can be checked.

How Do You Prove It Works?

What does a test look like?

Generate an advertisement from a device on a client port and confirm two things: that no host on the segment picked up a new default router, and that the switch's counters recorded a drop on that specific port. Then repeat from the uplink side to confirm the legitimate router is still being accepted. A test that only checks the first half proves the rogue failed and not that the filter is why.

A Deeper Dive into Testing

Generating a test advertisement

Any host that can be made to act as a router will do. A Linux machine running an advertisement daemon is the controlled way; enabling connection sharing on a laptop is the realistic way, because it reproduces the accident rather than the attack. Both are valid and the second is closer to what will actually happen.

The test device goes on a client port, with the policy already applied, and a monitoring host goes on another client port in the same VLAN. The monitoring host is where the result is observed.

What to observe on the host

The default router list before and after. With the filter working, it contains only the legitimate router throughout. Without it, the rogue appears within seconds and frequently displaces the real one.

The address list is the second check. A rogue advertising a prefix with the autonomous flag causes the host to build an address from it, so a new global address appearing in an unexpected range is direct evidence the advertisement was accepted.

! On the monitoring host, before and after the test
! Linux:
ip -6 route show default
ip -6 addr show dev eth0
!
! Windows:
netsh interface ipv6 show route
netsh interface ipv6 show address
!
! Neither should change during the test

What to observe on the switch

The drop counter, per port. A working filter increments it on the port the rogue is connected to, and on no other. That second part matters: a counter incrementing on the uplink as well means the policy has been applied somewhere it should not be, and the test has found a second problem.

! Drops, per VLAN and per interface
Sw1# show device-tracking counters vlan 10
Received messages on vlan 10 :
Protocol      Protocol message
NDP           RA[12] NS[1840] NA[1791]
!
Dropped messages on vlan 10 :
Protocol      Protocol message
NDP           RA_GUARD[12]
!
Sw1# show device-tracking counters interface GigabitEthernet1/0/12
!
! And which policy is actually on that port
Sw1# show ipv6 nd raguard policy RA-HOST | section Target

Testing the field checks separately

The role check is easy to verify. The match clauses need a different test: an advertisement from the legitimate source that carries a prefix not on the list, or a preference above the maximum, sent from the router-facing port.

That is harder to arrange and it is the test that catches a policy where a clause was typed but references an empty list, or where a prefix list permits more than intended. Doing it once, in a lab, against the exact policy that will be deployed, is worth the effort because these clauses fail open rather than closed.

Pitfall: a match clause references a list that does not exist Symptom: the policy is applied, the role check works, and advertisements that should be rejected by a source or prefix clause are accepted. Nothing in the configuration looks wrong and no error was reported when the policy was written. Cause: the clause names a list that was never created or was created empty, and an absent list does not cause the clause to reject everything — the check simply does not constrain anything. Confirm: display the named list; it returns nothing or does not exist. Fix: create the lists before referencing them, and verify each clause with a deliberately non-conforming advertisement rather than by reading the policy.

A lab topology that exercises everything

One switch, one router on a trusted port, two hosts on client ports, and a fourth client port for the rogue. That is enough to test the role check, the source clause, the prefix clause and the preference clause, and to observe the effect on a real host rather than on a counter.

Adding a small unmanaged switch on one of the client ports, with the rogue and a host both behind it, demonstrates the limitation covered later — and demonstrating it is more persuasive than describing it when explaining to a colleague why the control is not sufficient on its own.

What to record

The counters before and after, the host's router list before and after, and the exact policy text used. That record is what makes the test repeatable after a software upgrade, which is when the behaviour of these features most often changes.

Re-running it after each major upgrade takes half an hour and catches regressions in a feature whose failure is entirely silent. Reading this once is not the same as being able to do it under time pressure, which is what repetition against realistic CCIE lab practice scenarios is for.

Test From Expected on the host Expected on the switch
Role check A client port No change at all Drop counter on that port
Legitimate router The uplink Router present as normal No drops on the uplink
Source clause Router port, wrong source No change Drop counter on the uplink
Prefix clause Router port, wrong prefix No new address Drop counter on the uplink
Preference clause Router port, preference too high No change Drop counter on the uplink
Sub claimA test that confirms the rogue had no effect proves nothing about the filter, because a host may simply have preferred the real router — only the drop counter on the specific port establishes that the filter is what stopped it.

How Is It Evaded, and What Closes the Gap?

What are the techniques?

Two structural ones and two configuration ones. Fragmenting the advertisement so that the message type is not in the first fragment, which defeats a filter that inspects only what it can see immediately. Prepending a long chain of extension headers so the parser gives up before reaching the type. Advertising the highest preference to beat a legitimate router rather than suppressing it. And sending from a port the policy trusts, which is a configuration failure rather than an evasion.

A Deeper Dive into Evasion

Fragmentation

A message split across fragments puts its type field in the first one and its content in later ones, or with sufficient effort puts the recognisable part somewhere a simple filter does not look. A filter that classifies on the first fragment alone can be persuaded to let the rest through.

The clean answer is that neighbour discovery messages have no legitimate reason to be fragmented. Current standards require hosts to discard fragmented neighbour discovery outright, and switches can be configured to discard them at the port. Both should be in place: the host requirement covers hosts that implement it, and the switch check covers the ones that do not.

Extension header chains

A long chain of headers between the address header and the message itself forces a parser to walk further than it may be willing to. Where the parser cannot determine the message type within its budget, it must decide what to do with a packet it could not classify.

Discarding it is the right answer for an access port, and it is expressible as an access list clause matching packets whose transport could not be determined. Nothing legitimate on a client port looks like that.

! Discard what cannot be classified, and fragmented ND
Sw1(config)# ipv6 access-list RA-HARDEN
Sw1(config-ipv6-acl)# deny ipv6 any any undetermined-transport
Sw1(config-ipv6-acl)# deny ipv6 any any fragments
Sw1(config-ipv6-acl)# permit ipv6 any any
!
Sw1(config)# interface range GigabitEthernet1/0/1 - 48
Sw1(config-if-range)# ipv6 traffic-filter RA-HARDEN in

Preference, which is not really evasion

Advertising the highest preference does not bypass the filter at all — it wins against the legitimate router on any port where advertisements are accepted. So it matters only on trusted ports, and it is closed by the preference maximum clause.

It is included here because it is the technique that works when someone has been careless with trust, which is more common than a genuine evasion attempt. A lab port trusted years ago and never untrusted is the usual vector.

The trusted port that should not be

Not an evasion of the filter but a gap in it. Ports become trusted for good reasons and stay trusted after those reasons end: a temporary router for a project, a port used to test something, a template applied to a range that turned out to include more ports than intended.

An audit listing every port with a router-role policy, compared against the ports that actually have routers behind them, finds these. It is one command per switch and the difference is the finding.

! Which ports accept advertisements at all?
Sw1# show ipv6 nd raguard policy RA-ROUTER | section Target
Target               Type  Policy               Feature        Target range
Te1/0/1              PORT  RA-ROUTER            RA guard       vlan all
Gi1/0/40             PORT  RA-ROUTER            RA guard       vlan all
!
! That second one - is there still a router behind it?
Sw1# show interface GigabitEthernet1/0/40 | include description|line protocol
Sw1# show device-tracking database interface GigabitEthernet1/0/40
Pitfall: a lab port trusted two years ago is still trusted Symptom: a rogue advertisement is accepted despite the filter being deployed across the access layer, and the counters show no drop anywhere. The policy appears correct on every port that was checked. Cause: one port carries a router-role policy applied for a temporary purpose and never removed. Advertisements arriving there are accepted by design. Confirm: list every target of the router-role policy and compare against the ports that genuinely have routers behind them. Fix: return the port to the client-role policy, and make the comparison a scheduled audit rather than an incident response.

What the host can do for itself

Modern operating systems can be configured to ignore advertisements entirely, which is appropriate on a server with static addressing and inappropriate on a client. Where a critical host must not be redirected, that setting is a useful second layer and it does not depend on the switch at all.

It is worth knowing about for exactly the case this article ends on: a host behind an unmanaged switch, where no port-based filter can help and the host's own configuration is the only available control.

Sub claimFragmentation and header chains are evasions of the filter's parser rather than of its policy, which is why the countermeasure is a traffic filter discarding what cannot be classified rather than a change to the policy itself.

What Does It Not Protect, and What Happens Afterwards?

Where are the limits?

Three. Hosts sharing a port with the rogue — anything behind an unmanaged switch or a virtualised host — are on the same side of the control and see the advertisement directly. A rogue on a trusted port is permitted by design. And once an advertisement has been believed, the filter cannot unsay it: the host keeps the rogue as a default router until the lifetime it was given expires, which can be many minutes after the rogue has been unplugged.

A Deeper Dive into the Limits

Everything behind one port shares one policy

A port applies its policy to traffic crossing it. Two devices connected to the same unmanaged switch under a desk communicate without their traffic crossing that port at all, so an advertisement from one reaches the other with the filter never involved.

This is not a defect, it is what a port-based control means, and it is the reason this control alone is not sufficient. It matters more than it sounds because the accidental rogue router — a laptop with connection sharing, a small consumer router someone brought in — is very likely to be on exactly such a switch, alongside the hosts it will affect.

What to do about it

Three partial answers, none complete. Reduce the number of unmanaged switches, which is an estate discipline question rather than a configuration one. Configure critical hosts to ignore advertisements, which works where the host is a server with static addressing. And detect rather than prevent: monitor for advertisements from unexpected sources and investigate, accepting that the control will be after the fact.

Being honest about this in a design document is better than claiming coverage the control does not have. A filter deployed on every access port is a substantial improvement and it is not a guarantee.

Virtualised hosts, which are the same problem

A hypervisor presents several machines on one physical port, and traffic between them never leaves the host. A virtual machine that is misconfigured as a router affects its neighbours on the same host with no switch involvement.

The answer there is the hypervisor's own switching configuration, which usually has an equivalent control. It is a different team's responsibility in most organisations, which is exactly why it is missed — the network team deploys the filter, the virtualisation team is not asked, and the gap sits between them.

The tail after a rogue has been believed

A host that accepted an advertisement holds the router for the lifetime it was given. Removing the rogue from the network does not withdraw it, because withdrawal requires the rogue to send a further advertisement with a zero lifetime and it is no longer there to send one.

So an incident has a tail: the rogue is found and unplugged, and hosts continue to use it as a gateway for the remainder of the lifetime. Depending on what was advertised that can be a long time. The practical remedies are to restart the affected hosts' interfaces, or to have the legitimate router send advertisements more frequently so that hosts refresh their view sooner.

Pitfall: hosts keep failing after the rogue device has been removed Symptom: the offending device is identified and disconnected, and affected hosts continue to have no connectivity for a further period with no obvious cause. Newly connected hosts are fine. Cause: a default router entry persists for the lifetime the advertisement specified. Removing the device does not withdraw the entry, because withdrawal would require it to send an advertisement with a zero lifetime. Confirm: the affected host still lists the rogue's address as a default router, with a decreasing lifetime. Fix: restart the affected interfaces, or accept the wait — and shorten the legitimate router's advertisement interval so that future incidents have a shorter tail.

Detection as a complement

Where prevention cannot reach, detection can. The switch's drop counters tell you the filter acted; a monitoring system watching for advertisements from unexpected sources tells you one appeared somewhere the filter could not act.

On a network with many unmanaged switches this is the more valuable signal, because it is the only visibility into the population the filter does not cover. It also identifies which ports have unmanaged switches behind them, which is useful in its own right.

! Detection: drops mean the filter acted. Watch the trend.
Sw1# show device-tracking counters vlan 10 | include RA
!
! Which ports have more than one device behind them?
! Those are the unmanaged switches the filter cannot reach past.
Sw1# show device-tracking database | count Gi1/0/
Sw1# show mac address-table count interface GigabitEthernet1/0/12
!
! Host-side, for a server that must never be redirected
!   Linux:   sysctl -w net.ipv6.conf.eth0.accept_ra=0
!   Windows: netsh interface ipv6 set interface "Ethernet" routerdiscovery=disabled

What to deploy alongside

The address server filter, which closes the equivalent gap for address assignment. Neighbour message inspection and source enforcement, once the binding table is established, which stop a device claiming an address rather than claiming to be a router. And the traffic filter discarding unclassifiable and fragmented traffic, which closes the evasions.

The advertisement filter is the first of these and the highest value, and it is the first rather than the only one.

Blueprint framing

The CCIE Enterprise Infrastructure v1.1 blueprint covers IPv6 first hop security within its infrastructure security domain. The advertisement filter is the part most likely to be examined directly — what the port role does, which fields a policy can check, and why the control is per port rather than per host.

Limit Why Partial answer
Hosts behind an unmanaged switch Traffic never crosses the port Estate discipline, host configuration
Virtual machines on one host Traffic never leaves the hypervisor The hypervisor's own control
A rogue on a trusted port Permitted by design Match clauses, and a trust audit
After a rogue was believed Lifetime cannot be withdrawn Restart interfaces, shorter intervals
Fragmented or unclassifiable messages The parser cannot reach the type A traffic filter discarding both
Shorten the legitimate router's intervalIt costs a little multicast traffic and it shortens the tail of every future incident, because hosts refresh their view of the segment more often. It is the only setting that improves recovery time after a rogue has already been believed.
Sub claimThe filter cannot withdraw what it failed to prevent, so the recovery time after an incident is set entirely by the lifetime the rogue advertised and by how often the legitimate router refreshes.

Conclusion

A router advertisement carries six things that change host behaviour, and a policy can check five of them. The source, the prefixes, the two configuration flags, the hop count and the preference all have clauses. The lifetime does not, and that single omission is why an incident has a tail: a host that believed a rogue keeps believing it after the rogue is gone, because withdrawal would require the rogue to say so.

The policy itself is two shapes. Ports facing hosts get one line and discard everything. Ports facing routers accept advertisements and then check them, and that is where the design lives — a source list of the real routers' link-local addresses, a prefix list of what may be advertised, explicit values for the configuration flags, and a preference maximum that stops the cheapest attack available. Deploy the VLAN attachment and the uplink override in the same change, because the gap between them is a switch with no gateway.

And be honest about the boundary. This is a port-based control, so everything behind a port shares one policy: two devices on the same unmanaged switch talk to each other without the filter ever being consulted, and that is precisely where the accidental rogue router lives. Deploying it on every access port is a large improvement and it is not coverage. What fills the gap is not more configuration on the switch — it is fewer unmanaged switches, host-side settings on the machines that matter, and monitoring that tells you an advertisement appeared somewhere the filter could not reach. More CCIE Enterprise Infrastructure material — labs, protocol breakdowns and study guides — is collected on the SPOTO CCIE site.

Reference Notes

  1. RFC 4861 specifies the router advertisement message, including the router lifetime, the current hop limit, the managed and other configuration flags, and the prefix information option.
  2. RFC 4861 states that a router lifetime of zero indicates the sender is not a default router, and that a host retains a default router entry until its lifetime expires.
  3. RFC 4861 defines the autonomous flag in the prefix information option, which indicates that a host may use the prefix for stateless address autoconfiguration.
  4. RFC 4191 defines default router preferences carried in router advertisements, with high, medium and low values, medium being the default.
  5. RFC 6104 describes the rogue router advertisement problem, including both deliberate attacks and accidental cases such as host connection sharing.
  6. RFC 6105 defines router advertisement guard, in which a switch discards router advertisements received on ports where no router is expected, and describes stateless and stateful modes.
  7. RFC 6105 describes the criteria a filter may apply to an accepted advertisement, including the source address, the advertised prefixes and the router preference.
  8. RFC 7113 describes evasion of router advertisement guard using IPv6 fragmentation and long extension header chains, and recommends discarding packets whose upper-layer protocol cannot be determined.
  9. RFC 6980 states that nodes must discard fragmented neighbour discovery messages, since there is no legitimate need to fragment them.
  10. Cisco documentation describes the router advertisement guard policy, including the device role, trusted port, source access list, prefix list, configuration flag, hop limit and router preference clauses.
  11. Cisco documentation states that a policy attached to an interface takes precedence over a policy attached to the VLAN carried on that interface.
  12. The CCIE Enterprise Infrastructure v1.1 unified exam topics include IPv6 first hop security within the infrastructure security domain.