Redistributing static into BGP — route-map filtering, seed metric, community tags

Redistributing static routes into BGP is the bridge from operator-configured routing to dynamic routing. A static route the operator writes by hand becomes a BGP route that is advertised to the upstream provider, to the downstream peer, or to the iBGP mesh.

On VyOS 1.5 LTS, redistribute static is one of the most common redistribution sources. It is also one of the most common sources of route leaks when configured without a filter. This lesson covers the production pattern, the community tag for downstream filtering, and the failure modes the operator will encounter.

The configuration

The canonical configuration:

configure
# 1. The static routes (the source)
set protocols static route 192.168.100.0/24 next-hop 198.51.100.1
set protocols static route 192.168.200.0/24 next-hop 198.51.100.1

# 2. The prefix-list enumerating the routes to redistribute
set policy prefix-list STATIC-TO-BGP rule 10 action permit
set policy prefix-list STATIC-TO-BGP rule 10 prefix 192.168.100.0/24

set policy prefix-list STATIC-TO-BGP rule 20 action permit
set policy prefix-list STATIC-TO-BGP rule 20 prefix 192.168.200.0/24

# The explicit catch-all deny. A prefix-list rule carries exactly one
# prefix and cannot be written as a bare action, so the deny-everything
# rule is spelled out as 0.0.0.0/0 with any length.
set policy prefix-list STATIC-TO-BGP rule 100 action deny
set policy prefix-list STATIC-TO-BGP rule 100 prefix 0.0.0.0/0
set policy prefix-list STATIC-TO-BGP rule 100 le 32

# 3. The route-map filtering and stamping
set policy route-map STATIC-TO-BGP rule 10 action permit
set policy route-map STATIC-TO-BGP rule 10 match ip address prefix-list STATIC-TO-BGP
set policy route-map STATIC-TO-BGP rule 10 set metric 100
set policy route-map STATIC-TO-BGP rule 10 set community 64512:100 additive

# 4. The redistribution statement, under the address family
set protocols bgp address-family ipv4-unicast redistribute static route-map STATIC-TO-BGP
commit
save

Two things about that last line are the migration. In VyOS 1.3 the statement was set protocols bgp <asn> redistribute static ..., with the ASN as a node name. VyOS 1.4 removed the ASN from the path — it now lives in set protocols bgp system-as <asn> — and moved redistribution under an address family, so IPv6 redistribution is set protocols bgp address-family ipv6-unicast redistribute static rather than a separate command family. A 1.3-era line is rejected at commit on a 1.5 router.

The pattern:

• The static route is the source (it was configured manually).
• The prefix-list enumerates which static routes are eligible for redistribution.
• The route-map filters by the prefix-list and stamps a metric and a community.
• The redistribution statement references the route-map.

flowchart LR
  S["Static routes\n192.168.100.0/24\n192.168.200.0/24"]
  PL["Prefix-list STATIC-TO-BGP\nallow: 192.168.100.0/24, 192.168.200.0/24\ndeny: everything else"]
  RM["Route-map STATIC-TO-BGP\nmatch: prefix-list\nset: metric 100\nset: community 64512:100 additive"]
  BGP["BGP Loc-RIB\n192.168.100.0/24 metric 100 origin incomplete\n192.168.200.0/24 metric 100 origin incomplete"]
  PEER["Peer 10.0.0.2\nadvertised-routes"]

  S --> PL
  PL -->|"prefix matches"| RM
  PL -->|"no match"| X["filtered"]
  RM -->|"action permit"| BGP
  BGP --> PEER

The route is filtered at the prefix-list stage (the implicit deny at the end of the prefix-list catches any static route not enumerated). The route-map applies the set clauses (metric, community). The route enters the BGP Loc-RIB and is advertised to peers.

The seed metric and MED

The seed metric on redistribute static becomes the BGP MED:

set protocols bgp address-family ipv4-unicast redistribute static metric 100

metric and route-map are the only two nodes the redistribution statement carries. If both are present the route-map’s set metric wins for the routes it matches, because the route-map runs on the route after the seed metric is applied — which makes the seed metric the value for anything the route-map permits without setting one.

On the originating router the redistributed route looks like this:

$ show ip bgp 192.168.100.0/24

BGP routing table entry for 192.168.100.0/24
Paths: (1 available, best #1, table default)
Local
  198.51.100.1 from 0.0.0.0 (10.255.0.1)
    Origin incomplete, metric 100, localpref 100, weight 32768, valid, sourced, best (First path received)
    Community: 64512:100

The three markers that say “this is a redistribution, not a received route”: the path reads Local, the origin is incomplete rather than IGP, and the weight is 32768. The metric 100 is the MED the peer will receive.

The default seed metric for redistribute static is 0, and a route carrying no MED at all is compared as 0 by default anyway — so either way the redistributed route lands at the bottom of the MED range unless the operator says otherwise. The operator who wants the redistributed route to be less-preferred than existing routes must set a higher metric explicitly.

The community tag

A community tag stamped on the redistributed route is the production pattern for downstream filtering:

set policy route-map STATIC-TO-BGP rule 10 set community 64512:100 additive

The downstream peer can then filter on this community:

# On the downstream peer: deny the redistributed static
set policy community-list FROM-R1-STATIC rule 10 action permit
set policy community-list FROM-R1-STATIC rule 10 community 64512:100

set policy route-map FROM-R1 rule 10 action deny
set policy route-map FROM-R1 rule 10 match community FROM-R1-STATIC

set protocols bgp neighbor 10.0.0.1 address-family ipv4-unicast route-map import FROM-R1

Note the attachment form: per-neighbour policy lives under the neighbour’s address family in 1.5, and the direction is import / export rather than a trailing in / out.

The community tag is the contract between the redistribution source and the downstream filter. The source stamps 64512:100; the downstream denies it. The contract is auditable: the source’s configuration shows the stamping; the downstream’s configuration shows the filter.

Without the community tag, the downstream filter must use prefix-lists or as-path access-lists. These are harder to audit: a prefix-list says ‘this prefix’ but not ‘this route came from the redistribution’. A community tag says both.

Distribute-list vs route-map

VyOS 1.5 LTS supports two filtering mechanisms for BGP redistribution:

• route-map — the production pattern. Filters by prefix-list, community, as-path; manipulates attributes (metric, community, origin).
• distribute-list — a simpler filter. References a prefix-list directly on the redistribution statement:

set protocols bgp 64512 redistribute static prefix-list STATIC-TO-BGP

The distribute-list is simpler but less expressive. It cannot stamp a community, set a metric per-prefix, or match on multiple criteria. It is appropriate for the simple case ‘redistribute these specific prefixes from static into BGP, with the default seed metric’.

The production pattern is the route-map. The distribute-list is the escape hatch when the route-map is overkill.

Operational commands

# The static routes (the source)
show ip route static

# The BGP view (after redistribution)
show ip bgp
show ip bgp 192.168.100.0/24

# What is being advertised to the peer
show ip bgp neighbors 10.0.0.2 advertised-routes

# The matching engine's view (FRR)
vtysh -c 'show route-map STATIC-TO-BGP'
vtysh -c 'show ip bgp community 64512:100'

The show ip bgp neighbors <peer> advertised-routes command is the canonical validation: it shows every route the BGP speaker is advertising to that peer. The operator who has just deployed a new redistribution should run this command and confirm the advertised routes match the intended prefix list.

Failure modes

Unfiltered redistribution leaks internal prefixes

The operator configures redistribute static without a route-map or prefix-list. Every static route is advertised into BGP. Internal prefixes (e.g. 10.0.0.0/8 used for the management network) leak to the upstream provider.

Diagnostic:

• show ip bgp neighbors <peer> advertised-routes shows internal prefixes.
• The upstream provider’s received-routes shows the same prefixes.

Fix: add a route-map with a prefix-list that enumerates only the prefixes the operator intends to advertise.

Static route is not redistributed

The operator has a static route 192.168.100.0/24 but it does not appear in the BGP Loc-RIB after redistribute static. Possible causes:

• The route-map filters the prefix. The prefix is not in the route-map’s prefix-list.
• The static route is not in the RIB. The static route’s next-hop is unreachable.
• The route-map has a set metric that conflicts with the route’s existing metric.

Diagnostic:

• show ip route 192.168.100.0/24 shows whether the route is in the kernel FIB.
• show policy route-map STATIC-TO-BGP shows the route-map configuration.
• vtysh -c 'show ip prefix-list STATIC-TO-BGP 192.168.100.0/24' shows whether the prefix-list permits the route.

Fix: address the specific cause (add the prefix to the prefix-list, fix the static route’s next-hop, etc.).

Downstream peer does not honour the community tag

The operator stamps 64512:100 on the redistributed route. The downstream peer has no filter for this community; the peer accepts the route. The operator expected the peer to deny the route.

Diagnostic:

• The peer’s BGP table has the route with community 64512:100.
• The peer is advertising the route to its peers.

Fix: coordinate with the downstream peer operator. The community tag is a contract; both sides must implement it.

Rollback

A redistribute static change is reversible through the standard VyOS mechanisms:

• rollback N and commit to revert to a previous configuration revision.
• delete protocols bgp <asn> redistribute static and commit to remove the redistribution.
• delete protocols bgp <asn> redistribute static route-map and commit to remove the route-map (the redistribution remains but is unfiltered).
• delete protocols bgp <asn> redistribute static metric and commit to remove the metric override (the seed metric reverts to 0).

Production discipline

Cross-course references

• XXV-VyOS-BGPAdvertise (vyos-xxv-03-bgp-redistribute-static) covers redistribute static in the BGP context.
• XXIX-VyOS-BGPCommunities covers the BGP communities used here for downstream filtering.
• XXXIV-VyOS-Redistribution (next lessons) covers the other redistribution sources: OSPF, connected, kernel.

Quiz