NetKubeLab ไทย

Spanning Tree — the protocol that fixes a problem Ethernet created

Why one redundant cable can take down a whole network, how Radia Perlman solved it in 1985, what is in the 35-byte BPDU, and every step of the development from 802.1D to what replaced it

The Ethernet article left one fact standing without saying how dangerous it is.

An Ethernet frame has no age field.

An IP packet has a TTL. Every router that forwards it subtracts one, and at zero the packet is discarded. That is why traceroute works, and why a packet that gets lost on the internet always dies by itself.

An Ethernet frame has nothing of the kind. No field to decrement, no condition under which a switch decides to drop a frame because it has been travelling long enough.

This page is about what had to be built because that field does not exist.

The problem — one frame is enough

One broadcast frame circulating in both directions around a ring of three switches, because nothing in the Ethernet header can be decremented

The MAC address article explained that a switch does two things — it remembers which MAC is on which port, and if it does not know where the destination is, it sends the frame out every port except the one it arrived on. A broadcast always goes out every port, with no exception.

Combine those two with cables wired in a ring, and have one machine send a broadcast. One frame.

Switch B forwards it to A and C. A forwards to C. C forwards to A and back to B. And around again, in both directions at once. The frame count grows every lap, and nothing stops it.

This is not "the network got slower". This is the network dying. Within seconds the switch CPUs are full, the cables are full, and every machine on that ring is busy reading the same frame over and over.

There is a second effect that makes it harder to diagnose — the same frame enters each switch on a different port each lap, so the MAC table overwrites itself continuously. The switch is not only flooding the network, it has also forgotten where everything is.

If you have never looked at this, start here

The Mac reading this page already has a bridge that supports STP.

$ ifconfig bridge0
bridge0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST>
    Configuration:
        id 0:0:0:0:0:0 priority 0 hellotime 0 fwddelay 0
        maxage 0 holdcnt 0 proto stp maxaddr 100 timeout 1200
        root id 0:0:0:0:0:0 priority 0 ifcost 0 port 0
    member: en1 flags=3<LEARNING,DISCOVER>

What to notice is the row of zeroes — hellotime 0 fwddelay 0 maxage 0 — and the member flags, which say only LEARNING,DISCOVER with no mention of STP.

This bridge is not running STP, which man ifconfig states plainly: -stp is the default for every interface added to a bridge. The proto stp field says which protocol it would use if enabled; it does not say it is enabled.

On a real switch the command that answers everything is show spanning-tree, which is used throughout this page.

STP does not remove loops, it blocks ports

The physical topology is still a triangle, but the usable topology is a tree, because one cable is forbidden to forward

This is where the misunderstanding is most common, and it has to be straight before anything else.

STP does not make the loop in the cabling go away. Every cable is still plugged in. What it does is pick some ports and forbid them to forward, until the graph that remains has no cycle.

The name comes straight from graph theory — a tree that spans every vertex. A tree connects everything without a cycle, which is exactly what is wanted.

And here is the cost that cannot be avoided: cable you paid for and installed is forbidden to carry traffic. In a network where each switch has two uplinks for resilience, half the bandwidth you bought sits idle at all times. That is the price of safety, and it is the motivation behind everything developed since.

1985 — the problem Radia Perlman was handed

Radia Perlman was working at Digital Equipment Corporation, and was handed the problem of how to let bridges be wired into any topology at all and still work correctly.

The result is the paper An Algorithm for Distributed Computation of a Spanning Tree in an Extended LAN, published in Proceedings of the ninth symposium on Data communications, 1985, pages 44 to 53.

What makes the problem hard is not finding a spanning tree — algorithms for that long predate it. The difficulty is finding one in a distributed way: nobody sees the whole picture, nobody knows how many switches there are, and every one of them has to arrive at the same answer.

What she wrote is still running in every switch on earth today. IEEE turned it into the standard 802.1D in 1990.

The paper also carries something the field remembers it for — Perlman wrote a poem, Algorhyme, to go with it.

The design thinking — why it came out looking like this

This section is worth more to somebody who will go and build something of their own than any field-level detail.

It has to work with no configuration at all

Bridges then were sold to people with no network team. If a protocol has to be configured before it is safe, it will not be safe in most places. So every value has a default that works immediately, and the defaults were chosen to be safe first rather than fast first.

There is no centre, so a centre has to be created

Everything starts out equal, but computing a tree requires a root. The solution is that every bridge claims to be the root, and concedes when it hears a "better" one. Better means a smaller number — a criterion each one can evaluate alone, without asking anybody.

Information has to be able to expire on its own

A cable that breaks does not send a signal saying it broke. A bridge can only learn of it by not hearing anything any more. So every piece of information has an age, and if nothing new arrives to renew it, the old one dies.

This is the root of all the slowness discussed below. Being sure the silence is real means waiting longer than a single lost message.

When unsure, take the side that does not forward

A port that has just come up does not forward immediately. It waits, listens, and only then forwards. Because the two ways of being wrong are not equal — being wrong and not forwarding costs a few seconds, being wrong and forwarding takes down the whole network.

The mechanism — three rules, and that is all

The three-step election: one root bridge per network, one root port per switch, one designated port per cable, and everything left over is blocked

The entire protocol comes down to three rules.

One, elect one root bridge for the network. The lowest bridge ID wins.

Two, every non-root switch picks one root port. The port whose total cost to the root is lowest.

Three, every cable picks one designated port. The end that is closer to the root.

Any port with no role at all is blocked. There is no rule four. These three guarantee by themselves that what remains is a tree.

The bridge ID is 8 bytes, and its meaning has changed

  priority   2 bytes
  MAC        6 bytes
             -------
             8 bytes

The default priority is 32768, and it may be set from 0 to 61440 in steps of 4096 only.

That 4096 is not arbitrary. 802.1t re-divided those two bytes into a 4-bit priority and a 12-bit system ID extension. The lower 12 bits hold a VLAN number or an instance number, which gives every instance a distinct bridge ID without needing a separate MAC.

  4 bits priority  x  4096 = the step size you see
  12 bits ext      -> 0 to 4095, the VLAN number

What you see on a real screen is odd-looking numbers like 32778, which read straight off once you know where they come from.

  32778 = 32768 + 10      priority 32768 on VLAN 10
  24586 = 24576 + 10      priority 24576 on VLAN 10 (24576 = 6 x 4096)

Path cost is the part that had to be rewritten twice

The first 802.1D derived cost from the formula 1000 divided by the speed in Mbps.

   10 Mbps  ->  1000/10   = 100
  100 Mbps  ->  1000/100  = 10
    1 Gbps  ->  1000/1000 = 1
   10 Gbps  ->  1000/10000 = 0.1

The last line is where the formula breaks. Cost is an integer, a value below 1 has nowhere to live, and rounding it to 1 makes it indistinguishable from gigabit.

So 802.1D-1998 dropped the formula and used a table instead: 10 Mbps is 100, 100 Mbps is 19, 1 Gbps is 4. The odd-looking 19 was chosen to keep the gaps between speed tiers usable; it comes from no formula.

And that still was not enough, because 802.1D-1998 limits path cost to a 16-bit unsigned integer, 65535. As speeds rose the range became too narrow, so 802.1t used the full 32 bits the BPDU already had, with a new table.

   10 Mbps  ->  2,000,000
  100 Mbps  ->    200,000
    1 Gbps  ->     20,000
   10 Gbps  ->      2,000

And these are recommended values, not requirements. RFC 4188, the bridge MIB, says plainly that 802.1D-1998 only recommends the default be in inverse proportion to the speed of the attached LAN.

Check against reality and the difference shows at once. The Linux kernel, in net/bridge/br_if.c, gives gigabit 5, not 4.

  SPEED_10000  -> 2
  SPEED_5000   -> 3
  SPEED_2500   -> 4
  SPEED_1000   -> 5
  SPEED_100    -> 19
  SPEED_10     -> 100

The reason reads off the table itself. If gigabit were 4 as the standard says, there would be no number left for 2.5G. Linux moved gigabit down a step to make room for speeds that arrived later.

The lesson generalises past STP — when two devices from different vendors compute cost differently, the tree you get is not the tree you designed. Do not read only the standard; read what the equipment in front of you reports.

Reading every field of a BPDU

The 35-byte Configuration BPDU drawn to scale, split into a 5-byte header, 20 bytes of identity and distance, and 10 bytes of timers

The message bridges exchange is called a BPDU. It is sent to the destination MAC 01:80:c2:00:00:00 with LLC SAP 0x42 as both source and destination.

That address was chosen deliberately. It sits in the range a bridge must not forward, so an STP message always travels exactly one hop, talking only to immediate neighbours. The protocol whose job is preventing loops is one that cannot itself circulate.

A Configuration BPDU has twelve fields totalling exactly 35 bytes.

  off  field                  len  meaning
   0   Protocol Identifier     2   always 0x0000
   2   Protocol Version        1   0 in 802.1D
   3   BPDU Type               1   0x00 config, 0x80 TCN
   4   Flags                   1   bit 0 = TC, bit 7 = TC ack
   5   Root Identifier         8   who everyone calls root
  13   Root Path Cost          4   sender's own cost to root
  17   Bridge Identifier       8   who sent this frame
  25   Port Identifier         2   which port sent it
  27   Message Age             2   grows on every hop
  29   Max Age                 2   root's value, everyone obeys
  31   Hello Time              2   root's value, everyone obeys
  33   Forward Delay           2   root's value, everyone obeys
                              ---
                               35

That number is checkable in real source. In the Linux kernel's net/bridge/br_stp_bpdu.c the buffer is declared unsigned char buf[35] and sent with br_send_bpdu(p, buf, 35), while the TCN BPDU uses buf[4] and is sent with length 4.

Three fields are worth reading past their names.

Message Age is the field that stands in for the TTL an Ethernet frame does not have. It is the only field here that an intermediate bridge increments before forwarding. Once it exceeds Max Age, that information is discarded. Note that Ethernet did not get a hop counter back — the protocol built its own, for use only on its own messages.

The last three timer fields belong to the root, not to the sender. Setting max age on one switch and seeing nothing change is normal: if it is not the root, the value is overwritten by the root's on every BPDU that arrives. What you set matters only if that switch becomes the root.

All four are 16-bit numbers in units of one 256th of a second. The same source shows it as #define STP_HZ 256, meaning 20 seconds is transmitted as 5120, and the largest value the field can hold is 65535 divided by 256, about 256 seconds.

Five states, and fifty seconds

A timeline comparing 802.1D, where a port passes through 20 seconds of blocking, 15 of listening and 15 of learning for a total of 50, against 802.1w, measured in milliseconds

A port in 802.1D has five states, and three of them are waiting.

  disabled     off, doing nothing at all
  blocking     receives BPDUs only, no data, learns nothing
  listening    now in the tree computation, still no learning, no data
  learning     learning MACs now, still not forwarding
  forwarding   carrying data normally

The three timer defaults are hello 2 seconds, max age 20, forward delay 15. Checkable from man ifconfig on this very machine, which also gives the settable ranges.

  maxage      default 20   min 6   max 40
  fwddelay    default 15   min 4   max 30
  hellotime   default 2    min 1   max 2
  priority    default 32768   min 0   max 61440

The first three lines match the ranges RFC 4188 gives in hundredths of a second: 600 to 4000, 400 to 3000, and 100 to 1000.

But the hellotime line does not match. RFC 4188 gives 1 to 10 seconds; macOS allows only 1 to 2. This is why you read the man page of the machine you are sitting at rather than recalling the standard.

The time lost computes directly.

  max age expiry   20
  listening        15
  learning         15
                   --
                   50 seconds

Fifty seconds is the case where the cable that broke is not your own — the old information has to expire before counting starts. If it is your own cable, the electrical signal tells you immediately, no max age wait, leaving 15 plus 15, or 30 seconds.

Why so slow? Because a bridge cannot distinguish "silent because the cable broke" from "silent because one BPDU was lost". When the evidence is identical but the consequences are wildly different, the only safe move is to wait long enough to be sure.

Fifty seconds was acceptable in 1990. On a network carrying voice and video it is not. Everything developed after this is an attempt to reduce that number.

Every step of the development, in order

1990 · IEEE 802.1D

The first standard. Everything above is this edition: five states, three timers, one tree for the entire network.

1998 · 802.1D-1998 and 802.1t — the cost table

Covered under path cost above. In short the formula was replaced by a table, and then the table was widened from 16 bits to 32. 802.1t is also what re-divided the 2-byte priority into 4 bits and 12 bits, as used today.

Along the way · what vendors bolted on themselves

Before IEEE standardised anything about speed, Cisco shipped its own — PortFast let a port with a machine on it skip the waiting entirely; UplinkFast and BackboneFast sped up failover to a backup link.

These three matter historically because their ideas were pulled back into the standard afterwards. PortFast became the edge port in 802.1w, and immediate failover became the alternate port role. Development often travels this way: the product ships first, the standard follows.

PVST · PVST+ · Rapid PVST+ — a tree per VLAN

802.1D has one tree for the whole network, which means a blocked cable is blocked for every VLAN at once. There is no way to let one VLAN use the left path and another the right.

Cisco solved it by running a separate STP instance per VLAN, called PVST. PVST+ is the version that interoperates with standard equipment, and Rapid PVST+ is the same thing with 802.1w as the engine inside.

The benefit is real per-VLAN load distribution. The price is just as clear: one VLAN is one instance to compute and one more stream of BPDUs to send. More VLANs means more CPU, so every platform has its own ceiling — some cap at 256 instances, others around 510.

This is a vendor protocol, not an IEEE standard, and it is the reason 802.1s exists.

2001 · 802.1w RSTP — stop using timers as the main tool

The proposal and agreement exchange that lets a port forward immediately without waiting on a timer, because the far end blocks its own other ports before answering

IEEE describes 802.1w as a supplement to 802.1D-1998 providing rapid reconfiguration capability. It was later folded into 802.1D-2004 as one document.

Five states collapse to three, with the first three of the old set becoming a single state.

  802.1D                802.1w        in tree  learns MAC
  disabled     ------>  discarding    no       no
  blocking     ------>  discarding    no       no
  listening    ------>  discarding    yes      no
  learning     ------>  learning      yes      yes
  forwarding   ------>  forwarding    yes      yes

The collapse is not only about naming. It reflects that three old states did the same thing — not forwarding and not learning — differing only in why, which is information that belongs in the port's role rather than in its state.

And the roles are the real addition. 802.1w names things 802.1D had no word for.

  root         the port facing the root
  designated   the end that forwards on that cable
  alternate    an already-computed backup path to the root
  backup       a backup path to the same segment on the same cable

The difference is in already computed. In 802.1D a blocked port is a port with no special standing; when the root port dies, computation restarts. In 802.1w the backup is ranked in advance, so failover is a promotion rather than a recalculation.

The cleverest part is proposal and agreement. When a link between two switches comes up, the end nearer the root sends a proposal. The far end blocks all its own non-edge ports first, and only then answers with an agreement. On receiving it, the first end forwards immediately.

This is a complete change of principle. The old safety came from waiting long enough to believe there is no loop. The new safety comes from the other end having made it safe before answering. The answer is evidence, not a timeout.

It works only on a link directly between two devices, because there has to be exactly one party to answer. On a segment shared by several, RSTP falls back to the old timers.

2002 · 802.1s MSTP — many VLANs, few trees

Groups of VLANs mapped onto a small number of instances, each instance having its own root and blocking a different cable

IEEE states the scope of 802.1s as adding the facility for VLAN bridges to use multiple spanning trees, so traffic belonging to different VLANs can flow over potentially different paths.

The idea is to decouple the number of VLANs from the number of trees. PVST+ ties them together, one to one. MSTP lets any number of VLANs map onto the same instance — a thousand VLANs can use two instances if two paths are all you want.

The computation therefore scales with the number of paths wanted, not the number of VLANs that exist.

The price is a clear jump in conceptual complexity.

  • MSTI — one tree inside a region, the thing VLANs are mapped onto
  • IST — instance 0, always present, carries every VLAN not mapped anywhere, and represents the whole region when talking to the outside
  • CIST — the tree that ties regions and legacy equipment outside them together

And the condition people miss most often is the region. Two switches are in the same region only if all three of these match.

  1  region name
  2  revision number
  3  the VLAN-to-instance mapping table

The third is not compared by sending the whole table. A digest of it travels in the IST's BPDUs and is compared against the local value. That saves a great deal of space, at a cost worth knowing — when it does not match, you learn only that it does not match, not where.

A mismatch is not an error. It means those two switches are now different regions and see each other through the CIST as though they were legacy devices. The tree you designed simply does not form, and nothing says so.

2011 and 2012 · TRILL and SPB — trying to stop using a tree

TRILL is RFC 6325, from 2011, Standards Track, whose first author is the same Radia Perlman.

SPB is IEEE 802.1aq, approved on 29 March 2012. Its scope states that it specifies shortest path bridging of unicast and multicast frames.

Both have the same goal — stop blocking cables, and let every one of them carry traffic along genuinely shortest paths, by bringing the ideas of routing protocols down to this layer. TRILL also adds a hop count to its own header, closing the hole this page opened with.

Both saw real but limited deployment, and neither is what won.

What actually won

A network relying on STP alone with one uplink blocked, beside one where both uplinks forward at the same time

What replaced STP in real data centres is not a newer STP. It is a change of problem.

First, bundle the cables so the switch sees one link. Two uplinks to two switches are made to look like a single link as far as STP is concerned. With no loop visible, no port is blocked, and both cables carry traffic.

Second, stop doing layer two across switches at all. Route between switches instead, which means the TTL comes back, multiple paths work at once, and the protocol was designed for cyclic graphs from the start. The layer two that must still exist is encapsulated inside and driven by a control plane rather than learned from traffic.

RFC 7432, the 2015 EVPN standard, describes the limitations of the older approach across multihoming, redundancy, load balancing and multipathing, and states that EVPN enables load balancing to and from devices attached at multiple points at once.

But STP is still enabled in almost all of those networks. It is kept as a safety net for the day somebody miscables something, not as the mechanism that decides paths. It moved from architecture to emergency brake, a position it fills very well.

Where it lies to you

"A blocked port is a dead port." No. It still receives BPDUs, and it must, because ceasing to hear them is the only signal that the plan needs to change. A blocked port that also stopped receiving is a port the network can no longer see.

"If STP is running, a loop cannot happen." Not true. STP prevents loops it can see. What it cannot see is a link that carries traffic in only one direction — one end can transmit but not receive. The end that cannot receive concludes nobody is there and turns its port into a designated port, while the other end is transmitting all along. The result is a loop STP opened itself. Mechanisms like loop guard exist specifically for this.

"A converged tree is a good tree." Unrelated. STP guarantees only the absence of loops, not that paths are short or fast. If the root lands on a small switch in a meeting room, the whole building's traffic detours through it while every indicator reports normal.

"RSTP is always fast." Fast on a link directly between two switches. On a shared segment it returns to the old timers, and if a device that speaks only 802.1D is present, the port facing it falls back to 802.1D too.

"The missing half of the bandwidth is a bug." It is the design, and it was known from 1985. RFC 6325 states it plainly: spanning tree works by blocking ports, limiting the number of forwarding links, and therefore creates bottlenecks by concentrating traffic onto selected links.

Security — one frame is enough to take the network

STP has no authentication of any kind. No signature, no secret. Anybody who can send a BPDU gets a vote.

The most direct attack is to send a BPDU claiming priority 0. Since lower wins, every switch on the segment accepts the intruder as root at once and recomputes the entire tree to face it.

The effect has two layers. The first is that the network stops while the recomputation happens. The second is worse — traffic that used to go directly is rerouted through whatever is now the root.

The defence is not in the protocol; it is in what you configure on the port.

  • BPDU guard — a port with a user's machine on it should never receive a BPDU. If it does, shut the port down.
  • root guard — this port must not become the way to the root. If a better BPDU arrives, reject it. Use it in directions where you know the root does not belong.

Neither is on by default. Both are two lines that belong on every user-facing port.

Worked examples from real work

Case 1 — the whole building slows down within seconds

Not gradually. Fine one moment, and then everything at once.

How to read it. A simultaneous failure across a whole segment is the signature of a broadcast storm. Look at the counters before anything else.

switch# show interfaces Gi1/0/12 counters
  Port      InOctets    InUcastPkts InMcastPkts InBcastPkts
  Gi1/0/12  4127883904  14827       9204        18442117

Eighteen million broadcasts on one port while unicast is in the tens of thousands is a ratio that cannot occur on a healthy network.

Then ask what STP thinks.

switch# show spanning-tree vlan 10 detail | include from|changes
  Number of topology changes 2841 last change occurred 00:00:03 ago
        from GigabitEthernet1/0/12

Two thousand eight hundred changes, the last three seconds ago. The tree has never settled. Port 12 is where to look first.

Not yet proved. The counter accumulates since boot, and the port reported is the one that heard the change, not necessarily the one that caused it. Clear the counters, measure again, and walk upstream one device at a time.

Case 2 — everything reports normal, but it is inexplicably slow

No errors, no broken cable, but traffic between two servers in adjacent racks is slower than it should be.

How to read it. Ask where the root is.

switch# show spanning-tree vlan 10 root
                    Root  Hello Max Fwd
Vlan       Root ID   Cost  Time  Age Dly  Root Port
---------- --------- ----- ----- --- ---  ---------
VLAN0010   32778     19    2     20  15   Gi1/0/8
           0000.5e00.53c7

Two things here are wrong. Priority 32778 means the root is still on the default — nobody intended it to be root; it won because its MAC happened to be lower. And cost 19 is the hundred-megabit value, on a core that is gigabit throughout.

Together those read as: the root landed on a small switch attached by a hundred-megabit link, so the whole VLAN's traffic detours through it.

The fix is not to hunt for ports to disable. It is to set a priority on the core switches below the default, so the root sits where it was meant to.

Not yet proved. We can see the root is in the wrong place, but not when that switch was plugged in or by whom. Compare against when the symptom started before concluding.

Case 3 — plug in a cable and wait half a minute

A machine on a freshly connected port fails to get an address the first time, then succeeds by itself on a later attempt.

How to read it. Add the numbers: 15 plus 15 is 30 seconds, the time a port spends in listening and then learning before it may forward. A DHCP request sent during that window is not refused. It simply disappears.

switch# show spanning-tree interface Gi1/0/33 detail | include port
  Port 33 (GigabitEthernet1/0/33) of VLAN0010 is listening
  Port path cost 4, Port priority 128, Port Identifier 128.33

The word listening on a port with a computer on it is the whole answer. Such a port cannot create a loop, so there is no reason to wait. Declare it an edge port, or enable PortFast.

Not yet proved. We proved the port does wait; we did not prove that is the only cause. Set the edge port and measure again — if it still fails, the problem is elsewhere.

Case 4 — MSTP that refuses to be one region

MSTP is configured on both switches, but the trees are not splitting as designed.

How to read it. Compare all three things that decide a region.

switchA# show spanning-tree mst configuration
  Name      [campus]
  Revision  3     Instances configured 3
  Digest    0xAC36177F50283CD4B83821D8AB26DE62

switchB# show spanning-tree mst configuration
  Name      [campus]
  Revision  3     Instances configured 3
  Digest    0x3C60DA3E2B1F44C79E5A20B7C8114F0D

Name matches, revision matches, but the digests differ — so the VLAN-to-instance tables are not identical. These two are different regions and see each other through the CIST.

The digest tells you only that they differ, not where. You have to compare the tables line by line, and the usual culprit is a VLAN added later and mapped on only one of the two.

Not yet proved. Differing digests confirm the tables differ, but not which one is right. Go back to the design document for what was agreed, rather than copying one side over the other.

When STP is not enough — from the person who built it

The sharpest criticism does not come from outside. RFC 6325, from 2011, whose first author is Radia Perlman, names four limitations of IEEE 802.1 bridging.

One, wasted bandwidth. Spanning tree works by blocking ports, limiting the number of forwarding links, and therefore creates bottlenecks by concentrating traffic onto selected links.

Two, paths are not shortest paths. Forwarding is whatever path remains after spanning tree eliminates the redundant ones.

Three, there is no hop count. The Ethernet header contains no hop count or TTL field, which is dangerous when there are temporary loops, such as when spanning tree messages are lost.

Four, VLANs can partition when the spanning tree reconfigures.

The third is what this article opened with. In thirty years STP never fixed that problem; it managed around it. Everything that came after — TRILL, or the move to routing between switches — starts by getting a hop count back first.

References

Origin

  • Radia Perlman, An Algorithm for Distributed Computation of a Spanning Tree in an Extended LAN, Proceedings of the ninth symposium on Data communications (SIGCOMM '85), ACM, pages 44 to 53 dl.acm.org/doi/10.1145/319056.319004

Standards

What is on the machine

  • man ifconfig on macOS — the defaults and ranges for maxage, fwddelay, hellotime and priority, and the sentence stating -stp is the default
  • net/bridge/br_stp_bpdu.c in the Linux kernel — the buf[35] that confirms the BPDU size, and STP_HZ 256 that gives the timer field unit
  • net/bridge/br_if.c — the real path cost table, which gives gigabit 5, not 4
  • show spanning-tree and show spanning-tree mst configuration on a switch, the two commands that answer nearly every STP question

Related reading here

  • Ethernet — where the frame with no age field comes from
  • MAC address — how a switch works, and why a broadcast reaches everything on one wire
  • VLAN — what PVST+ and MSTP are trying to manage
  • Internet Protocol — the TTL that Ethernet does not have

อ่านหน้านี้เป็นภาษาไทย

← Back to the basics