Files
ferrix/docs/examples/transit.textpb
T
Rayhaan JaufeerallyandClaude Opus 5.5 72444c2706 Control communities: session groups, prepends, and only ours to give
Control communities could say which peers a route goes to, by AS. Now
they can also name sessions by group, and ask for prepends:

  L:11:P .. L:13:P   our AS once to three times more towards AS P
                     (P 0: towards every peer in another AS)
  L:20:G / L:21:G    not to / only to the sessions of group G
  L:31:G .. L:33:G   our AS once to three times more towards group G

A group is a number given to sessions in the configuration (`groups` of
a peer): those at one exchange, or those over one link. The same network
at two exchanges is one AS but two sessions, which is what steering
inbound traffic between exchanges needs. Of several prepends that apply
the most counts, on top of the session's own as_path_prepend. Functions
2 to 9, as the documentation already promised, and 100 and up stay
informational; 10 to 99 are kept for actions to come.

They are acted on where a route leaves our AS, and taken off there; our
informational communities are not. To a peer in our own AS a route goes
with them, unchanged, so that a mark put on at one router is acted on at
another. Before, they were acted on and taken off on internal sessions
too, so a route marked "to nobody" did not even reach our own routers.

And they are ours to give: the communities of our own AS (L:n, L:n:m,
and 0:n where control communities are on) are taken off every route
from a peer in another AS as it comes in, before import marks are put
on. A peer at an exchange could otherwise decide where its routes go
from us, and set our informational marks. A customer that is to steer
its own routes is given import.accept_control_communities. An UPDATE
without any of ours is still taken as it came, without being written
out again.

This changes what a customer that set control communities gets: it now
needs accept_control_communities. The transit example and the interop
lab say so; the lab also has FRR, as a customer, ask for a prepend
towards BIRD's group, and BIRD, as a provider, have its "not to" taken
off.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-05 16:12:05 +02:00

74 lines
2.3 KiB
Protocol Buffer Text Format

# Transit network with two providers and one customer. Customer routes are
# advertised to all neighbors. Provider routes are advertised to the
# customer only. The BGP roles of the neighbors enforce this.
router_id: "198.51.100.1"
local_asn: 64500
# Advertise learned routes to all neighbors, as BGP roles permit.
export { learned_routes: true }
# Customers can restrict the advertisement of their routes with the large
# communities 64500:0:P (not to AS P), 64500:1:P (only to AS P), and
# 64500:0:0 (to no neighbor), or the standard communities 0:P, 64500:P, and
# 0:64500, and prepend 64500 towards AS P with 64500:11:P to 64500:13:P.
# Ferrix removes the communities of AS 64500 from the routes of other
# neighbors, such as the providers below.
control_communities: true
peers {
name: "transit-a"
endpoint { address: "203.0.113.0" }
remote_asn: 64496
role: PROVIDER
import {
max_prefixes: 1500000
add_large_communities: "64500:2:100"
}
}
peers {
name: "transit-b"
endpoint { address: "203.0.113.2" }
remote_asn: 64497
role: PROVIDER
import {
max_prefixes: 1500000
add_large_communities: "64500:2:200"
}
# Prepend to make the path through transit-b less preferred. This
# statement replaces the top-level export statement for this neighbor.
export { learned_routes: true as_path_prepend: 2 }
}
# Customer with a four-octet AS number. The prefix and origin AS lists
# restrict its routes to its registered address space. Local preference
# 200 makes its routes preferred over the same prefixes from providers.
# The customer may set control communities; the informational communities
# 64500:2:* are removed, so that it cannot set those.
peers {
name: "customer-65536"
endpoint { address: "203.0.113.5" }
remote_asn: 65536
role: CUSTOMER
require_role: true
import {
max_prefixes: 50
prefixes { prefix: "192.0.2.0/24" }
prefixes { prefix: "2001:db8:a00::/40" max_length: 48 }
origin_asns: 65536
accept_control_communities: true
remove_communities: "64500:2:*"
add_large_communities: "64500:2:300"
local_pref: 200
}
}
originate { prefix: "198.51.100.0/24" }
originate { prefix: "2001:db8:100::/40" }
rpki { caches { address: "::1" port: 3323 } }
kernel {}
http_endpoint { address: "127.0.0.1" port: 8080 }