24 Route-Maps for BGP

Route-maps are the primary tool for applying policy in BGP. They work like an if-then construct: a match clause defines a condition, and a set clause defines what to do with the routes that match. In BGP, route-maps are the glue that connects filtering (which routes) with attribute manipulation (what to do with them).

Structure

A route-map is a named list of statements, each with a sequence number and a permit or deny action:

route-map NAME permit|deny SEQ
  match <criteria>
  set <action>

• Statements are evaluated top-down by sequence number; the first match wins, like an ACL.
• match defines the condition. A statement can have multiple match clauses.
• set defines the modification applied when a route matches.
• A statement with no match clause matches everything (like permit any), often used as a final catch-all.
• There is an implicit deny at the end: any route not matched by an explicit permit is dropped.

The two-layer permit/deny logic

The word permit/deny appears twice with different meanings, which is the most misunderstood part:

• The permit/deny inside the referenced ACL or prefix-list answers: does the route match this statement? (selection)
• The permit/deny on the route-map statement answers: what to do with a matched route? (action)

Interaction:

ACL / prefix-list result	Effect on the route-map statement
permit	The route matches this statement → the route-map’s permit/deny action applies
deny	The route does not match this statement → skip to the next statement

A deny in the prefix-list does not filter the route; it only means “no match here, move on.” The route can still be permitted later by a catch-all. Filtering only happens when a route reaches a route-map statement whose action is deny, or hits the implicit deny.

Use in BGP

Route-maps are attached per-neighbor and per-direction (inbound or outbound). Their set clauses manipulate the attributes that drive best-path selection:

• set weight
• set local-preference
• set metric (MED)
• set as-path prepend
• set community

Their match side commonly references the filtering tools studied separately: match ip address prefix-list ... and match as-path .... This is why route-maps tie filtering and attributes together.

Direction: in vs out

• in controls what enters the router (routes learned/accepted from a neighbor).
• out controls what leaves the router (routes advertised to a neighbor).

Which attribute is applied in which direction depends on intent: for example, Local Preference and Weight are typically set inbound (they affect your own decisions from what you learn), while AS-PATH prepend and MED are typically set outbound (they influence how others send traffic toward you).

Self-check

Q1 — How are route-map statements evaluated?

A) All at once, in parallel
B) Top-down by sequence number, first match wins, with an implicit deny at the end
C) Bottom-up, last match wins
D) Randomly

Respuesta

B is correct. Statements are processed top-down by sequence; the first match wins, and anything not matched by an explicit permit hits the implicit deny.

• A) False — evaluation is ordered, not parallel.
• C) False — it is top-down, first match wins.
• D) False — the order is deterministic.

Q2 — In the two-layer logic, what does a deny in the referenced prefix-list mean?

A) The route is immediately filtered and dropped
B) The route does not match this statement, so evaluation moves to the next statement
C) The route-map’s set clauses are applied
D) The session is reset

Respuesta

B is correct. A prefix-list deny means “no match here, move on.” It does not filter; the route can still be permitted by a later catch-all.

• A) False — filtering only happens at a route-map deny action or the implicit deny.
• C) False — set clauses apply only on a match with a permit action.
• D) False — it has nothing to do with session resets.

Q3 — In BGP, how are route-maps attached?

A) Globally to the whole BGP process only
B) Per-neighbor and per-direction (in or out)
C) Only to the routing table
D) Only to eBGP peers

Respuesta

B is correct. BGP route-maps are applied per-neighbor and per-direction, letting you set inbound or outbound policy for each peer.

• A) False — they are applied per neighbor and direction, not just globally.
• C) False — they attach to neighbors, not directly to the routing table.
• D) False — they work for both eBGP and iBGP neighbors.

Q4 — Which set clause would you use to influence inbound traffic by lengthening the path advertised outward?

A) set local-preference
B) set weight
C) set as-path prepend
D) set origin

Respuesta

C is correct. set as-path prepend lengthens the AS-PATH advertised outbound so a path looks less preferred, steering inbound traffic to another entry.

• A) False — Local Preference influences the AS-wide outbound decision.
• B) False — Weight is a local outbound preference on one router.
• D) False — set origin changes the Origin code, not path length.