Arista EOS Spanning-Tree PortFast and BPDU Guard Setup

Connecting an end host, IP phone or server to an Arista EOS switch without changing the spanning-tree behavior can cost you 30 seconds of forwarding delay every time the link bounces - and if someone plugs a rogue switch into an access port, it can even hijack the root bridge of your whole VLAN. This article walks through the two EOS mechanisms that fix both problems: spanning-tree portfast (called edge-port in EOS) for instant forwarding on host ports, and BPDU Guard to shut down any port that receives an unexpected BPDU. All commands shown are copy-paste ready for EOS 4.x.

Why PortFast (Edge Port) and BPDU Guard Matter

PortFast is a Cisco term; in Arista EOS the equivalent configuration is spanning-tree portfast on the interface, and EOS refers to such ports as edge ports. An edge port skips the listening/learning states and moves straight to forwarding, which matters for devices such as IP phones, printers and NAS boxes that must not wait for STP convergence. BPDU Guard (spanning-tree bpduguard enable) is the enforcement half: if a BPDU arrives on a port that should only face an end device, EOS disables the port and logs the event, preventing an unauthorized switch from altering the spanning-tree topology.

The two features are almost always discussed together because they are two halves of one decision: portfast removes the waiting time that protects the topology, and BPDU Guard puts the protection back where it belongs - at the edge of the network, on the port that should never see a BPDU.

EOS Port Types: Edge, Network and Normal

Arista's model is more explicit than most vendors', and understanding the three port types is what makes the rest of the configuration obvious.

Two consequences follow. First, spanning-tree portfast network on an uplink is not "portfast for switches" - it changes the port's role in Bridge Assurance, and applying it to a port that faces a host or a device that does not speak the expected BPDU pattern will leave the port discarding traffic. Second, auto-edge (spanning-tree portfast auto) is a good fit for panel ports nobody has documented, because detection is based on the absence of BPDUs rather than on someone having written a portfast line into the config.

Configuring PortFast on an Arista EOS Access Port

Enter interface configuration mode and enable portfast together with the access VLAN assignment:

switch(config)# interface Ethernet1
switch(config-if-Et1)# switchport mode access
switch(config-if-Et1)# switchport access vlan 10
switch(config-if-Et1)# spanning-tree portfast
switch(config-if-Et1)# no shutdown

Keep the order habit: mode, VLAN, portfast, then bring the port up. If the port is already up when you enable portfast, the change takes effect immediately and the port goes straight to forwarding - which is exactly the point, and also why you should never apply it to a port you have not confirmed is host-facing. Verify the peer before you touch the config, not after the loop.

Enabling BPDU Guard per Interface

BPDU Guard is configured separately and is normally combined with portfast on user-facing ports:

switch(config)# interface Ethernet1
switch(config-if-Et1)# spanning-tree portfast
switch(config-if-Et1)# spanning-tree bpduguard enable

There is an important asymmetry in how EOS treats the per-interface and global forms of BPDU Guard:

• Per-interface (spanning-tree bpduguard enable): the port is disabled when it receives a BPDU regardless of its operational portfast state. This is the form to use on a specific port you want protected no matter what.
• Global (spanning-tree edge-port bpduguard default): BPDU Guard applies only to ports that are operationally in the portfast state. Ports that are not edge ports are unaffected.

That distinction matters when a port stops being an edge port at runtime - a portfast port that later receives a BPDU sets its operating state to non-portfast while keeping the portfast configuration, and under the global form the port is no longer a BPDU Guard candidate at that moment.

Global Defaults: edge-port bpduguard default

For campus leaf switches, Arista recommends enabling BPDU Guard by default on every portfast (edge) port so you never forget it on a new interface:

switch(config)# spanning-tree edge-port bpduguard default

Inter-switch trunks remain unaffected because they are not edge ports. The Nutanix/Arista validated layer-2 campus configuration and Arista Community validated designs use exactly this pattern on leaf switches, often combined with spanning-tree portfast network on uplinks when Bridge Assurance is desired. BPDU Guard is disabled on all ports by default, so this one line is the difference between a design that enforces the edge and one that trusts every cable that ever gets plugged in.

What Actually Happens When a BPDU Arrives

Walk through it in the exact order EOS evaluates the events, because the two protections react differently:

1. BPDU received on an edge port
      |
      +-- portfast state ...... the port's OPERATING state becomes non-portfast
      |                         (the portfast CONFIGURATION is unchanged)
      |
      +-- bpduguard ........... the port is DISABLED
                                - blocked ports recover on their own
                                - disabled ports require manual intervention

A disabled port is not a blocked port: it does not re-converge by itself, and it stays down until someone removes the offending cable and re-enables the interface - unless you have configured errdisable recovery. That is deliberate. The point of BPDU Guard is to make an accidental loop or an unauthorized switch a visible, attended event.

Recovering a Disabled Port: errdisable recovery

If your environment cannot justify a truck roll for every BPDU Guard event (test labs, kiosk ports, conference rooms), EOS can re-enable the port automatically after a timer:

switch(config)# errdisable recovery cause bpduguard
switch(config)# errdisable recovery interval 300

switch# show errdisable recovery
switch# show errdisable detect

Set the interval deliberately. A port that flaps back to life every 300 seconds while the offending device is still connected will receive another BPDU, get disabled again, and produce a log pattern that looks like flapping rather than a security event. If you enable recovery, make sure the log from the first event reaches your monitoring system - it is the only reliable evidence that someone plugged the wrong thing into the wrong port.

Root Guard, Loop Guard and Bridge Assurance

BPDU Guard protects the edge. Three related EOS features protect the rest of the topology, and they are configured with their own commands:

Root guard belongs on the ports you would never allow to be the root: distribution-facing ports on an access switch, for example. Loop guard belongs on blocked and root ports of point-to-point links. Bridge Assurance is the switch-to-switch counterpart of BPDU Guard and, unlike the other two, it requires both ends of the link to be configured consistently - enable it in one direction only and the port discards.

Verifying PortFast and BPDU Guard

Check the operational state of the interface and the running configuration:

switch# show spanning-tree interface Ethernet1
switch# show spanning-tree interface Ethernet1 detail
switch# show running-config interfaces Ethernet1
switch# show logging | include bpduguard

If a rogue device sends a BPDU, the port is moved to a disabled (errdisabled-like) state and an event similar to BPDU Guard disables interface appears in the log. Re-enable the port only after removing the offending device.

A Complete Access-Port Template

Combining everything above, this is the pattern that works for a documented campus access port - one line per concern, so a reviewer can see exactly which protection is where:

switch(config)# interface Ethernet12
switch(config-if-Et12)# description Access - office 12-04
switch(config-if-Et12)# switchport mode access
switch(config-if-Et12)# switchport access vlan 30
switch(config-if-Et12)# spanning-tree portfast
switch(config-if-Et12)# spanning-tree bpduguard enable
switch(config-if-Et12)# no shutdown

! global policy for every present and future edge port
switch(config)# spanning-tree edge-port bpduguard default
switch(config)# errdisable recovery cause bpduguard
switch(config)# errdisable recovery interval 300

Two habits make this template safe to roll out at scale. First, apply the description with the portfast lines so the intent is documented next to the configuration. Second, keep the per-interface spanning-tree bpduguard enable even when the global default is on: the per-interface form is the one that protects the port regardless of its operational portfast state, and it survives a port that starts receiving BPDUs.

Common Mistakes

1. Portfast on a switch-to-switch link without BPDU Guard. This is the configuration that creates the loop BPDU Guard exists to prevent. If both ends are switches, use spanning-tree portfast network and Bridge Assurance instead - or nothing at all.
2. Expecting a disabled port to recover on its own. Blocked ports converge; BPDU-Guard-disabled ports need errdisable recovery cause bpduguard or a human.
3. Confusing portfast configuration with portfast operating state. A portfast port that receives a BPDU goes to non-portfast operating state while the config stays as written - the running config will look correct while the operational state says otherwise. Always check show spanning-tree interface, not the config.
4. Applying root guard where you actually want loop guard. They solve different failures: root guard prevents a port becoming root, loop guard prevents a blocked port from erroneously forwarding.
5. Enabling Bridge Assurance on one side only. It requires a network port with a point-to-point link type on both ends; a one-sided configuration discards traffic.

Related Guides on This Site

If you are hardening access ports, see our Cisco PortFast, BPDU Guard and Root Guard explained, the spanning tree root bridge election and design rules, the Arista EOS trunk and inter-VLAN routing run book, and the RSTP vs MSTP comparison to decide which spanning-tree mode fits your topology.

原文链接：https://www.cisconetsolutions.com/arista-eos-configuration-cheat-sheet/