community filters

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

Ze supports tagging and stripping BGP communities on ingress and egress through the bgp-filter-community plugin. The feature has two parts: named community definitions under bgp { community { } }, and per-direction filter rules under filter { ingress/egress { community { } } } that reference those names. Filter rules can be applied at the BGP global, group, or peer level, and the ze:cumulative extension means values from all levels are accumulated rather than replaced.

Named community definitions

Communities are defined once under the bgp { community { } } block and referenced by name in filter rules. Three types are supported:

bgp {
    community {
        standard customer-routes {
            value [ 65000:100 65000:200 ];
        }

        large ixp-local {
            value [ 65000:0:1 65000:0:2 ];
        }

        extended rt-import {
            value [ route-target:65000:1 ];
        }
    }
}

List	Key	Value format	Description
standard <name>	name	ASN:value	RFC 1997 standard communities.
large <name>	name	GA:LD1:LD2	RFC 8092 large communities.
extended <name>	name	type-specific	RFC 4360 extended communities.

Each named set is a leaf-list of string values. You can define as many named sets as needed.

Standard community values accept either the numeric ASN:value form or a well-known name. All names in the IANA BGP Well-Known Communities registry are recognized, including no-export, no-advertise, no-export-subconfed, nopeer / no-peer, graceful-shutdown (gshut), accept-own, accept-own-nexthop, route-filter-v4 / route-filter-v6 and their translated variants, llgr-stale, no-llgr, standby-pe, and blackhole (RFC 7999). Both kebab-case (no-export) and underscore (no_export) spellings are accepted, and these names round-trip on output.

Filter rules

Filter rules live under filter { ingress { community { } } } and filter { egress { community { } } }. Each direction has two leaf-lists:

Path	Type	Description
filter/ingress/community/tag	leaf-list (string)	Named communities to add to routes received from this peer.
filter/ingress/community/strip	leaf-list (string)	Named communities to remove from routes received from this peer.
filter/egress/community/tag	leaf-list (string)	Named communities to add to routes sent to this peer.
filter/egress/community/strip	leaf-list (string)	Named communities to remove from routes sent to this peer.

The values are the names of community sets defined in bgp { community { } }.

YANG structure

The YANG module ze-filter-community augments the BGP configuration at four levels:

// Named community definitions
augment "/bgp:bgp" {
    container community {
        list standard { key "name"; leaf name { type string; } leaf-list value { type string; } }
        list large    { key "name"; leaf name { type string; } leaf-list value { type string; } }
        list extended { key "name"; leaf name { type string; } leaf-list value { type string; } }
    }
}

// Filter config grouping (reused at all levels)
grouping community-filter-config {
    container filter {
        container ingress {
            container community {
                leaf-list tag   { type string; ze:cumulative; }
                leaf-list strip { type string; ze:cumulative; }
            }
        }
        container egress {
            container community {
                leaf-list tag   { type string; ze:cumulative; }
                leaf-list strip { type string; ze:cumulative; }
            }
        }
    }
}

// Applied at four levels:
augment "/bgp:bgp"                      { uses community-filter-config; }  // global
augment "/bgp:bgp/bgp:group"            { uses community-filter-config; }  // group
augment "/bgp:bgp/bgp:group/bgp:peer"   { uses community-filter-config; }  // peer inside group
augment "/bgp:bgp/bgp:peer"             { uses community-filter-config; }  // standalone peer

Cumulative behavior (ze:cumulative)

All four tag and strip leaf-lists are marked ze:cumulative. This means that values from the BGP global level, the group level, and the peer level are accumulated (appended together) rather than the most-specific level replacing the others.

For example, if the global config tags customer-routes and a group also tags ixp-local, a peer in that group gets both customer-routes and ixp-local tagged on its routes. This is different from standard YANG leaf-list behavior, where the peer-level value would replace the group-level value.

The accumulation order is: bgp (global) + group + peer. All three levels contribute.

How the filter applies at different levels

The community-filter-config grouping is augmented at four points in the config hierarchy:

Level	Config path	Scope
BGP global	bgp { filter { ... } }	Default for all peers.
Group	bgp { group <name> { filter { ... } } }	All peers in this group.
Group/peer	bgp { group <name> { peer <name> { filter { ... } } } }	One peer inside a group.
Standalone peer	bgp { peer <name> { filter { ... } } }	One peer outside any group.

Because of ze:cumulative, rules at broader levels are not overridden -- they stack. A peer inside a group inherits the global tags, the group tags, and its own tags.

Example: IXP route server community filtering

A common IXP deployment: tag customer routes with a local community on ingress, and strip internal communities before sending routes to IXP route servers on egress.

bgp {
    community {
        standard customer-origin {
            value [ 65000:100 ];
        }
        standard internal-ops {
            value [ 65000:999 65000:998 ];
        }
        large ixp-peer-id {
            value [ 65000:0:42 ];
        }
    }

    // Global default: strip internal communities on egress
    filter {
        egress {
            community {
                strip [ internal-ops ];
            }
        }
    }

    group customers {
        // Tag all customer routes on ingress
        filter {
            ingress {
                community {
                    tag [ customer-origin ];
                }
            }
        }

        peer customer-a {
            connection { remote { ip 10.0.0.1; } local { ip 10.0.0.2; } }
            session    { asn { local 65000; remote 65001; } }
        }

        peer customer-b {
            connection { remote { ip 10.0.0.3; } local { ip 10.0.0.4; } }
            session    { asn { local 65000; remote 65002; } }
        }
    }

    group ixp-rs {
        // Tag routes sent to route servers with the IXP peer identifier
        filter {
            egress {
                community {
                    tag [ ixp-peer-id ];
                }
            }
        }

        peer rs1 {
            connection { remote { ip 10.100.0.1; } local { ip 10.100.0.2; } }
            session    { asn { local 65000; remote 65500; } }
        }
    }
}

In this configuration:

• Routes from customer-a and customer-b are tagged with customer-origin (65000:100) on ingress (group-level rule).
• Routes sent to rs1 are tagged with ixp-peer-id (65000:0:42) on egress (group-level rule) and have internal-ops (65000:999, 65000:998) stripped on egress (global-level rule). Both rules apply because of ze:cumulative.
• Routes sent to any peer have internal-ops stripped on egress (global-level rule).

See also

• BGP policies for the broader policy framework.
• BGP peers for peer and group configuration.
• Plugin: bgp-filter-community for the plugin internals.
• Overview for the surrounding config model.