Redistributing static routes into BGP — metric, route-map, and route leak

Redistributing static routes into BGP is the way to advertise prefixes that are not directly connected to the router. On VyOS 1.5 LTS / FRR 10.x, the configuration lives inside the address family it applies to: set protocols bgp address-family ipv4-unicast redistribute static [metric <m>] [route-map <name>]. The route-map is the safety belt — without it, every static route in the RIB becomes a BGP advertisement.

This lesson is the operator’s reference for static-to-BGP redistribution: how it works, what attributes the routes inherit, why the route-map is mandatory in production, and how the redistribution fails.

What the redistribution does

The BGP redistribute static statement tells FRR: “every static route in the RIB should be considered for redistribution into BGP”. FRR then:

1. Walks the RIB and finds every route with source static.
2. Filters the routes through the route-map (if configured).
3. The routes that pass the route-map are installed into the BGP Loc-RIB as locally originated routes.
4. The Loc-RIB entries participate in the BGP best-path algorithm.
5. Surviving best paths are filtered through outbound policy and advertised to peers.

flowchart LR
  STATIC["Static routes\n(RIB)"]
  RM{"Route-map\nfilter"}
  INSTALL["Install in Loc-RIB\n(origin: incomplete)"]
  BEST["Best-path algorithm"]
  POLICY["Outbound policy"]
  PEER["BGP peer"]

  STATIC --> RM
  RM -- "permit" --> INSTALL
  RM -- "deny" --> X["Drop"]
  INSTALL --> BEST
  BEST --> POLICY
  POLICY --> PEER

The default attributes:

• Origin — incomplete (?). FRR’s default for redistributed routes. The reason: the route’s source is not an IGP, so the origin is “unknown / partially-known”.
• Weight — 32768 (locally originated).
• AS-path — empty (the local AS is the originator).
• Next-hop — displayed as 0.0.0.0 in the local BGP table. That is not an address the peer will ever see: it is how FRR marks “this router originated the route”. On advertisement FRR substitutes a real local address — the egress interface address towards an eBGP peer, the session’s local address towards an iBGP peer.
• MED — 0 by default, or the metric specified in the redistribution configuration.

The VyOS configuration

configure
set protocols static route 192.0.2.0/24 next-hop 10.0.0.1
set protocols bgp system-as 64512
set protocols bgp address-family ipv4-unicast redistribute static
commit
save

This is the simplest form. The static route 192.0.2.0/24 is redistributed into BGP as-is.

The address family in that path is doing real work, not decorating it. redistribute is a property of one address family, so the statement above moves IPv4 static routes and nothing else. A router that also carries IPv6 statics needs a second statement, set protocols bgp address-family ipv6-unicast redistribute static, and the two are filtered independently — a route-map attached to the IPv4 family has no effect on the IPv6 one. The most common form of this mistake is a dual-stack router where the IPv4 redistribution is carefully filtered and the IPv6 redistribution was never configured at all, so half the estate is silently unadvertised.

With a metric:

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

The metric becomes the MED in the advertised BGP route. MED is used by the receiving peer (if the peer honours MED) to choose between multiple routes to the same prefix. Higher MED is less preferred in the standard best-path rule.

With a route-map (the production pattern):

set policy prefix-list BGP-INTERNAL-STATIC rule 10 action permit
set policy prefix-list BGP-INTERNAL-STATIC rule 10 prefix 192.0.2.0/24
set policy prefix-list BGP-INTERNAL-STATIC rule 20 action deny
set policy prefix-list BGP-INTERNAL-STATIC rule 20 prefix 0.0.0.0/0
set policy prefix-list BGP-INTERNAL-STATIC rule 20 le 32

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 BGP-INTERNAL-STATIC
set policy route-map STATIC-TO-BGP rule 10 set metric 50
set policy route-map STATIC-TO-BGP rule 10 set community 64512:300 additive

set protocols bgp address-family ipv4-unicast redistribute static route-map STATIC-TO-BGP

The route-map:

• Filters which static routes are redistributed (BGP-INTERNAL-STATIC allows only 192.0.2.0/24).
• Sets the metric on the redistributed route (metric 50).
• Stamps a community (64512:300) for downstream policy (additive adds to whatever is already on the route; for a fresh redistribution, this is equivalent to plain set community). The FRR command underneath is set community <AA:NN> additive; the VyOS leaf that renders it has been reshaped more than once across releases, so confirm the node with tab-completion before pasting this line into a router you cannot reach out of band.

Note rule 20 of the prefix-list. A VyOS prefix-list rule needs a prefix, so an action deny on its own does not commit — the explicit deny-all is 0.0.0.0/0 with le 32, which matches every IPv4 prefix of any length. It is also, strictly, redundant: FRR ends every prefix-list and every route-map with an implicit deny. Write it anyway, because a filter whose last line states its own default is a filter the next operator can read without knowing FRR’s conventions.

After commit, show ip bgp should show the static route as a locally originated entry with origin ? and the configured metric:

vyos@r1:~$ show ip bgp

BGP table version is 4, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 192.0.2.0/24     0.0.0.0                  0         32768 ?

Note the ? in the Path column (origin incomplete).

Why the route-map is mandatory in production

Without a route-map, redistribute static brings every static route in the RIB into BGP. This is the canonical route leak anti-pattern.

The scenario:

configure
set protocols static route 10.10.0.0/16 next-hop 192.168.1.1
set protocols static route 192.168.1.0/24 next-hop 10.0.0.5
set protocols bgp system-as 64512
set protocols bgp address-family ipv4-unicast redistribute static
set protocols bgp neighbor 10.0.0.2 remote-as 64513
commit

Both static routes are now in the BGP table. If the operator intended only 10.10.0.0/16 to be advertised to the eBGP peer (and 192.168.1.0/24 was an internal route-mgmt subnet), the 192.168.1.0/24 is leaked to the external peer.

The fix is always a route-map:

set policy prefix-list ADVERTISE-EXTERNAL-STATIC rule 10 action permit
set policy prefix-list ADVERTISE-EXTERNAL-STATIC rule 10 prefix 10.10.0.0/16
set policy prefix-list ADVERTISE-EXTERNAL-STATIC rule 20 action deny
set policy prefix-list ADVERTISE-EXTERNAL-STATIC rule 20 prefix 0.0.0.0/0
set policy prefix-list ADVERTISE-EXTERNAL-STATIC rule 20 le 32

set policy route-map STATIC-OUT rule 10 action permit
set policy route-map STATIC-OUT rule 10 match ip address prefix-list ADVERTISE-EXTERNAL-STATIC

set protocols bgp address-family ipv4-unicast redistribute static route-map STATIC-OUT

The prefix-list ADVERTISE-EXTERNAL-STATIC allows exactly 10.10.0.0/16 and denies the rest. The route-map’s rule 10 matches only what that list permits; 192.168.1.0/24 matches no rule, falls off the end of the route-map, and is dropped by the implicit deny. It stays in the RIB and never enters BGP.

Read the permit rule carefully rather than the deny rule. rule 10 prefix 10.10.0.0/16 with no ge or le matches that prefix at that length and nothing else — not 10.10.5.0/24, not 10.0.0.0/8. Adding le 32 to it, which operators do reflexively to “cover the subnets”, turns the allow-list into a permit for every more-specific inside 10.10.0.0/16. That is where allow-lists actually fail.

Metric and MED

The metric keyword sets the MED of the redistributed route:

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

MED is a hint to the receiving peer that “this is the cost of entering my AS at this router”. Lower MED is preferred.

In a multi-eBGP-peer setup (the operator has two upstream providers), MED can be used to make one provider preferred for traffic destined to the operator’s prefixes:

The metric on the redistribution cannot do this on its own. There is one redistribute static statement per address family, so it produces one MED for every peer — and VyOS runs a single BGP process per VRF, so there is no second instance to put a different value in. The metric is a property of the route in the Loc-RIB, not of any particular session.

Per-peer MED therefore belongs in outbound policy:

set policy route-map STATIC-OUT-A rule 10 action permit
set policy route-map STATIC-OUT-A rule 10 match ip address prefix-list ADVERTISE-EXTERNAL-STATIC
set policy route-map STATIC-OUT-A rule 10 set metric 10

set policy route-map STATIC-OUT-B rule 10 action permit
set policy route-map STATIC-OUT-B rule 10 match ip address prefix-list ADVERTISE-EXTERNAL-STATIC
set policy route-map STATIC-OUT-B rule 10 set metric 100

set protocols bgp neighbor 10.0.0.2 address-family ipv4-unicast route-map export STATIC-OUT-A
set protocols bgp neighbor 10.0.0.6 address-family ipv4-unicast route-map export STATIC-OUT-B

This pattern keeps the redistribution simple (redistribute static route-map STATIC-TO-BGP without a metric) and lets outbound policy apply per-peer.

Origin override

The default incomplete origin can be overridden with a route-map:

set policy route-map STATIC-AS-IGP rule 10 action permit
set policy route-map STATIC-AS-IGP rule 10 match ip address prefix-list ADVERTISE-EXTERNAL-STATIC
set policy route-map STATIC-AS-IGP rule 10 set origin igp

set protocols bgp address-family ipv4-unicast redistribute static route-map STATIC-AS-IGP

The set origin igp rewrites the origin to igp. The route is now preferred by peers that follow the RFC 4271 “lower-origin-wins” rule.

A common production reasoning: “the static routes I advertise represent my own prefixes, so the origin should be igp”. This is correct if the static routes are the operator’s owned prefixes. If the static routes are upstream provider prefixes (learned via static rather than via BGP), the origin should remain incomplete.

Validation

# 1. The static route is in the RIB
show ip route static

# 2. The route-map allows the prefix
show policy route-map STATIC-OUT

# 3. The route is in the BGP table with the right origin
show ip bgp 192.0.2.0/24
# Expected: *> 192.0.2.0/24 ... 0.0.0.0 ... 32768 ?

# 4. The route is advertised to the peer
show ip bgp neighbors 10.0.0.2 advertised-routes

The ? in the Path column is the signature of a redistributed static route. If the operator expects i and sees ?, the origin override (route-map set origin igp) is missing.

vyos@r1:~$ show ip bgp neighbors 10.0.0.2 advertised-routes

BGP table version is 4, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, R Removed

   Network          Next Hop            Metric LocPrf Weight Path
*> 192.0.2.0/24     10.0.0.1                50         32768 ?

Total number of prefixes 1

Note that the next-hop on the wire is 10.0.0.1 — R1’s own address on the link to that peer — even though the Loc-RIB entry displayed 0.0.0.0. The same substitution happens for an iBGP peer, using the local address of that session rather than the link address. 0.0.0.0 is a display convention for “originated here”, not a value that is ever advertised.

Failure modes

Static route is not advertised

show ip bgp 192.0.2.0/24 returns nothing. Diagnostic path:

1. Is the static route in the RIB? show ip route static. If the static route is absent, BGP has nothing to redistribute. Common cause: the operator removed the static route, or the next-hop is unreachable.
2. Does the route-map allow the prefix? show policy route-map STATIC-OUT. Walk the route-map rules; confirm that the prefix matches a permit rule. A common mistake: rule 10 permits a prefix-list that does not contain the static route, so the prefix reaches the end of the route-map and is dropped by FRR’s implicit deny — with or without an explicit catch-all rule below it.
3. Is the prefix in the BGP Loc-RIB? show ip bgp 192.0.2.0/24. If absent, the route-map rejected the prefix or the static route is not in the RIB.
4. Is outbound policy blocking? show ip bgp neighbors <peer> advertised-routes. If the prefix is in the BGP table but not advertised, the outbound route-map or prefix-list on the peer session is denying it.

Static route is leaked to a peer

The operator added a static route for testing; the route-map does not filter it; the peer receives the prefix. The fix:

• Add the prefix to the deny-list (a deny rule at the top of the route-map).
• Remove the static route after testing.
• Audit all peers for the leaked prefix and request withdrawal.

Origin is ? instead of i

The operator expected origin igp but the BGP table shows origin incomplete. The route-map did not include set origin igp. Fix the route-map and recommit.

The peer cannot resolve the next-hop

0.0.0.0 in the local table is not this failure. A route this router originated is advertised with a real local address in the NEXT_HOP, and no configuration is needed to make that happen — if the peer sees 0.0.0.0, look at what is between you and the peer, not at the redistribution.

The next-hop problem that is real appears one hop further on. An iBGP peer that receives an eBGP-learned route keeps the external next-hop, because iBGP does not rewrite it. If that address is not in the receiving router’s IGP, the route is marked inaccessible and never becomes best. The fix is applied on the router that re-advertises into iBGP:

set protocols bgp neighbor 10.0.0.2 address-family ipv4-unicast nexthop-self

nexthop-self rewrites the NEXT_HOP to this router’s own session address before advertising to that peer, so the peer resolves it through the IGP path it already has. It is per-neighbour and per-address-family, and it is a no-op for the locally redistributed statics in this lesson — those already carry a resolvable next-hop. Configure it on the border router for the routes it relays, not as a reflex.

Rollback

# Remove the redistribution entirely
delete protocols bgp address-family ipv4-unicast redistribute static
commit

# Remove the metric but keep the redistribution
delete protocols bgp address-family ipv4-unicast redistribute static metric
commit

# Remove the route-map (warning: this re-introduces the leak risk)
delete protocols bgp address-family ipv4-unicast redistribute static route-map
commit

Deleting a leaf takes the node, not the value: delete ... redistribute static route-map removes the filter and leaves the redistribution running unfiltered, which is the leak this lesson is about. If the intent is to stop advertising, delete redistribute static itself.

The rollback for a leaked route is to remove the route-map filter and remove the offending static route. The peer will receive a withdrawal on the next UPDATE cycle.

A tested rollback plan is mandatory for production:

• Know the prefix-list that filters the redistribution.
• Know which static routes are expected to be advertised.
• Know which peer sessions will receive withdrawals if the redistribution is removed.

Production discipline

Cross-course references

• Part XXV-01 (XXV-VyOS-BGPAdvertise / network statement) is the alternative for explicit per-prefix origination.
• Part XXV-04 (XXV-VyOS-BGPAdvertise / redistribute OSPF) covers redistribution from a dynamic IGP, which has different attribute defaults.
• Part XXVI (XXVI-VyOS-BGPAttributes) covers the ORIGIN attribute that this lesson overrides via route-map.
• Part XXXIII (XXXIII-VyOS-RoutePolicy) covers the route-map primitives used here.
• Part XXXIV (XXXIV-VyOS-RouteRedistribution) covers redistribution in general — the loops, the feedback, the tagging, and the administrative-distance traps.

Quiz