4 - BGP Roles QCM - Noah Van Horenbeke - TFE

QCM Presentation

This quiz accompanies the BGP Roles lab and serves as a comprehension check before diving into the debugging. The goal is not to memorize FRR syntax, but to clearly understand why BGP Roles exist when operators already know how to write export route-map rules and configure per-neighbor local-preference values.

References:

Paste this command into your terminal:

The password to connect is

Please answer to all the questions. Internal error {} has not a valid extension. {} is too heavy.

Question 1: Main distinction

Your lab partner argues: "We already filter exports with route-maps and set local-preference per neighbor type. BGP Roles are just syntactic sugar for the same thing."

What is the single most important capability that BGP Roles (RFC 9234) give you that a pure local-pref + route-map setup cannot provide?

A misconfiguration (e.g. one side says Provider, the other says Peer) prevents the session from coming up at all.

Roles replace the need to run BGP entirely on customer-facing links by encoding the policy directly in the IP header.

Roles compress multiple route-map statements into a single configuration line, but the runtime behaviour is identical to a correctly-written route-map.

Roles allow you to assign a higher weight to customer routes than to peer or provider routes during the BGP best-path selection.

Question 2: OTC usage

Consider this FRR snippet on r5 for neighbor r6 (which is r5's provider):

router bgp 65005
neighbor fc00:56::6 remote-as 65006
neighbor fc00:56::6 local-role customer
!
address-family ipv6 unicast
    neighbor fc00:56::6 route-map RM-IN in
    neighbor fc00:56::6 route-map RM-OUT out
!
route-map RM-IN permit 10
    set local-preference 50
!
route-map RM-OUT permit 10

The RM-OUT route-map is permit 10 with no filtering. Does this configuration risk leaking provider routes back to r6 (i.e. back to the provider)?

Yes — RFC 9234 only affects the BGP OPEN message; it has no effect on UPDATE messages or route propagation.

No — because local-role customer is configured, any route received from r6 is automatically tagged with the OTC attribute (AS 65006). The OTC egress check then blocks r5 from re-advertising those routes back to r6 (or to any other peer/provider), regardless of what RM-OUT permits.

Yes — RM-OUT is wide-open, so routes learned from r6 will be re-advertised to r6, causing a leak.

No — but only because local-preference 50 is low, so the routes won't win best-path and therefore won't be advertised.

Question 3: Diagnosis

You run show bgp ipv6 summary on r3 and the session to r4 is stuck in Active / Idle, flapping. You run show bgp neighbor fc00:34::4 json and see "localRole": "peer". On r4, the equivalent command shows "localRole": "provider". What is happening?

The roles are fine but the local-preference values disagree, which prevents convergence.

Each side rejects the OPEN with a Role Mismatch Notification, so the session never establishes.

The session is fine; roles are informational only. The flapping is caused by something else (probably IPv6 reachability).

The roles form a valid pair (Peer on one side, Provider on the other is allowed by RFC 9234), so the session will eventually stabilize.

Question 4: Local-Pref and Export Policy

A student writes: "In the Gao-Rexford model, customer routes have local-preference 200, peer routes 100, provider routes 50. So if I configure those local-pref values correctly on r5, I don't need BGP Roles — the policy is already enforced." What is wrong with this reasoning?

Local-pref is reset to 100 at every AS boundary, so the student's values would never take effect.

Nothing is wrong. Local-pref fully replaces BGP Roles in modern FRR deployments.

Local-pref controls which route r5 selects as best for its own forwarding. It does not control which routes r5 re-advertises to other neighbours.

Local-pref values above 100 are not allowed for eBGP sessions, so the configuration wouldn't apply.

Question 5: Diagnostic commands

On r5, you want to verify which routes are actually being advertised to the peer at fc00:25::2. Which command is correct, and what extra thing should you then cross-check to make sure BGP Roles are doing their job?

show ip route bgp — then check the kernel FIB for the neighbor's prefixes.

show running-config — the advertised routes are whatever appears in the route-map.

show bgp ipv6 neighbors fc00:25::2 advertised-routes — then run show bgp neighbor fc00:25::2 json and confirm localRole and remoteRole form a valid pair (e.g. both Peer)

show bgp ipv6 unicast — then check that all routes have the OTC attribute set and confirm best-path are correctly selected.

Author(s)	Noah Van Horenbeke
Deadline	No deadline
Submission limit	No limitation

Information

Sign in

4 - BGP Roles QCM

QCM Presentation

Question 1: Main distinction

Question 2: OTC usage

Question 3: Diagnosis

Question 4: Local-Pref and Export Policy

Question 5: Diagnostic commands

Information

Sign in

4 - BGP Roles QCM Collapse context

QCM Presentation

Question 1: Main distinction

Question 2: OTC usage

Question 3: Diagnosis

Question 4: Local-Pref and Export Policy

Question 5: Diagnostic commands

4 - BGP Roles QCM