loop

Pre-Alpha. This page describes behavior that may change.

Route loop detection ingress filter per RFC 4271 Section 9 and RFC 4456 Section 8. Silently discards incoming UPDATE messages that indicate a routing loop.

Category

Core.

Configuration

Loop detection always runs on every received UPDATE with sensible defaults (AS-loop rejects on first match, cluster-id equals router-id). No configuration is needed to get RFC-compliant behaviour.

To tune it — for example to allow your own ASN to appear in AS_PATH a few times (AS-confederation members), or to use a cluster-id different from the router-id — define a loop-detection filter instance under bgp/policy:

bgp {
    policy {
        loop-detection no-self-as {
            allow-own-as 0;
            cluster-id   10.0.0.254;
        }
    }
}

The instance name is auto-populated at the front of every peer's import filter chain and can be suppressed on a specific peer with inactive:<name> or the CLI editor deactivate verb. See route filters for the chain mechanics and the loop-detection filter type reference for the leaves.

Behaviour

The filter walks the path attributes of each incoming UPDATE once and performs three checks:

1. AS loop (all sessions, RFC 4271 S9): if the local ASN appears in the AS_PATH attribute (AS_SEQUENCE or AS_SET segments) more than allow-own-as times, the route is rejected. allow-own-as defaults to 0 (reject on the first occurrence).
2. Originator-ID loop (iBGP only, RFC 4456 S8): if the ORIGINATOR_ID attribute matches the local Router ID, the route is rejected.
3. Cluster-list loop (iBGP only, RFC 4456 S8): if the cluster ID (from loop-detection/cluster-id or session/cluster-id, defaulting to the router-id) appears in the CLUSTER_LIST attribute, the route is rejected.

The filter operates directly on the wire-format UPDATE payload with zero-copy attribute iteration. Rejected routes are logged at debug level and silently dropped before reaching the decision process.

session/cluster-id and loop-detection/cluster-id are kept in sync automatically (RFC 4456 egress and ingress must use the same value), so setting either one at any level propagates to the other.

Interactions

• Runs as a protocol-stage ingress filter inside the BGP reactor. It is part of the filter chain that every received UPDATE passes through before route selection.
• Exposed to config as the built-in loop-detection filter type under bgp/policy. See route filters.
• No dependencies on other plugins. The filter is self-contained and stateless.
• Works with 2-byte and 4-byte ASN encodings depending on the peer's capability negotiation.

Source

main/internal/component/bgp/reactor/filter/

See also

• bgp
• Plugin index