Protocols

GOOSE publish/subscribe: timing, VLANs, and what breaks first

2026-10-29 · 8 min read

GOOSE is the part of IEC 61850 that people trust with interlocking, so it is also the part where a two-millisecond surprise becomes an incident report. It is not a request/response protocol: publishers multicast, subscribers filter, and delivery is made reliable by repetition rather than acknowledgement. Understanding that one sentence explains most GOOSE behaviour on site.

How repetition works

A publisher sends a GOOSE message immediately when its data changes, then retransmits the same message at increasing intervals until either the data changes again or the maximum interval is reached, at which point it keeps sending at that steady rate as a heartbeat. Two counters accompany each message: a state number that increments on every real change, and a sequence number that increments on every retransmission of the same state.

A subscriber therefore has three things to watch: is this a new state, is this a duplicate, and has the publisher gone quiet. That third one is a timer, and it is the only mechanism by which a subscriber learns that the publisher died rather than that nothing changed.

Where GOOSE actually breaks

In order of how often we see it:

• The network, not the stack. GOOSE is layer-2 multicast. A switch that floods multicast to every port, or an unmanaged switch that drops under burst, produces symptoms the publisher cannot see and the subscriber reports as missing messages.
• VLAN and priority handling. GOOSE is normally carried in a dedicated VLAN with priority tagging. A publisher that tags correctly and a subscriber that strips tags incorrectly is a broken link that looks like a configuration detail until commissioning.
• Retransmission storms after a topology change. A network that briefly loses multicast makes every affected publisher look like it changed state, and the resulting burst is exactly when switches are least able to absorb it.
• Capture tools lying to you. A laptop capturing with a normal NIC drops messages under burst and shows a loss pattern that is in the capture path, not the network. Use a tap or a switch mirror port.
• Subscriber filtering by mistake. Filtering on APPID but not on the dataset reference, or vice versa, produces a subscriber that reacts to the wrong publisher — usually discovered during a test with two publishers on the same VLAN.

What to test, in the order that finds defects fastest

• Publish with no subscriber present. The publisher must keep publishing. A stack that stops when nobody listens is not implementing GOOSE.
• Subscribe to a publisher that restarts. The state number restarts; the subscriber must recover rather than latch.
• Pull the cable for longer than the heartbeat interval. The subscriber must report the loss, and the report must be distinguishable from a stale value.
• Two publishers of the same dataset on one VLAN. Confirm the subscriber separates them correctly.
• Burst the link to the point of loss. Then confirm that recovery does not itself produce a second storm.

Design rules that survive contact with a substation

None of these are protocol requirements; all of them are what distinguishes a demonstration from a product.

• Treat loss of a subscription as a first-class event in your device model, not as a silence.
• Publish from a dedicated thread or timer source, never from the same path that handles MMS traffic.
• Keep the publisher's dataset small. GOOSE messages are small by design; a dataset that approaches the frame size limit is a design smell.
• Do not route GOOSE. If a design requires crossing a router, the design is wrong.
• Log the counters (state changes, retransmissions, received duplicates, loss detections) and expose them; field debugging without counters is guesswork.

Questions that come up

Does GOOSE guarantee delivery?

No. It reduces the probability of missing a change to an acceptable level by repeating, and it gives the subscriber the information needed to detect that something was missed. Any design that assumes delivery is incomplete.

How fast can GOOSE be?

The retransmission scheme is designed for a few milliseconds on a dedicated network, and the achievable figure depends on the publisher's software path, the switch and the subscriber. Any vendor number should come with the network it was measured on.

Can SV and GOOSE share a network?

They can share a physical network if both are engineered for the combined load, but the safer default is separate VLANs with priority handling, because a sampling burst and an interlocking message have very different consequences when one is delayed.

Keep reading