Same routing intent different route-map semantics

Introduction to Policy Intent Translation

Overview of FRR and Vendor NOS Policy Languages

Free Range Routing (FRR) implements a policy language derived from the Cisco IOS route‑map model, extended with FRR‑specific constructs such as route-map, prefix-list, community-list, and as-path access-list.

Vendor Network Operating Systems (NOS) each expose their own policy language:

• Cisco IOS‑XR – hierarchical route-policy with prefix-set, community-set, as-path-set, etc.
• Juniper Junos – policy-options containing policy-statement, prefix-list, community, and as-path.
• Arista EOS – mirrors the Cisco IOS route‑map syntax, adding a few EOS‑specific match/set clauses while supporting the same list types as FRR.

Importance of Equivalent Policy Intent Translation

In multi‑vendor fabrics operators must express the same routing intent—e.g., “accept only prefixes from AS 65000 with community 65000:100 and set local‑pref 200”—across FRR and each vendor NOS. Semantic drift between the languages can cause silent mis‑filters, unintended route acceptance, or incorrect attribute manipulation, leading to black‑holes, sub‑optimal paths, or policy violations. A rigorous translation framework ensures that the control‑plane state installed in each router’s RIB/FIB reflects the operator’s original intent, enabling predictable forwarding behavior and simplifying audits.

Policy Language Comparison

FRR Policy Language

Syntax and Structure

FRR policy language revolves around three primitive object types and the route-map construct:

A route-map term may contain multiple match clauses (all must be true) and multiple set clauses (all are applied). If no match is present, the term matches everything. The implicit default action at the end of a route‑map is deny.

Example Policy Configurations

! FRR: accept only 10.0.0.0/8 prefixes with community 65000:100, set local-pref 200
ip prefix-list PFX-10 seq 5 permit 10.0.0.0/8
ip community-list STD-COMM seq 5 permit 65000:100
route-map RM-ACCEPT-IN permit 10
  match ip address prefix-list PFX-10
  match community STD-COMM
  set local-preference 200
route-map RM-ACCEPT-IN deny 20   ! explicit deny for clarity

Applied to a BGP neighbor:

router bgp 65001
  neighbor 192.0.2.2 route-map RM-ACCEPT-IN in

Cisco IOS‑XR Policy Language

IOS‑XR uses a hierarchical, declarative model:

• Sets – prefix-set, community-set, as-path-set, rd-set, etc.
• Policy statements – defined under route-policy <NAME> with if … then … elseif … else … end-policy.
• Matching – uses in operator against a set; supports ge, le for prefix length.
• Actions – pass, drop, set local-preference, set metric, set next-hop, set weight, add community, delete community, etc.

Syntax example

prefix-set PFX-10
  10.0.0.0/8 eq 8
end-set

community-set STD-COMM
  65000:100
end-set

route-policy RM-ACCEPT-IN
  if destination in PFX-10 and community matches-any STD-COMM then
    set local-preference 200
    pass
  else
    drop
  endif
end-policy

Applied:

router bgp 65001
  neighbor 192.0.2.2 address-family ipv4 unicast
    route-policy RM-ACCEPT-IN in

Juniper Junos Policy Language

Junos uses policy-options:

• Prefix lists – prefix-list <NAME> { <PREFIX>/<LEN>; }
• Community lists – community <NAME> members [ <COMMUNITY> ];
• AS‑path regex – defined as as-path <NAME> ".*".
• Policy statements – policy-statement <NAME> { term <TERM> { from { …; } then { …; } } }
• Implicit default – reject if no term matches.

Syntax example

prefix-list PFX-10 {
    10.0.0.0/8 exact;
}
community STD-COMM {
    members 65000:100;
}
policy-statement RM-ACCEPT-IN {
    term ACCEPT {
        from {
            prefix-list PFX-10;
            community [ STD-COMM ];
        }
        then {
            local-preference 200;
            accept;
        }
    }
    term REJECT {
        then reject;
    }
}

Applied:

protocols {
    bgp {
        group EXT {
            neighbor 192.0.2.2 {
                import RM-ACCEPT-IN;
            }
        }
    }
}

Arista EOS Policy Language

EOS closely follows the IOS route‑map model, supporting the same list types and adding a few EOS‑specific match/set clauses (e.g., match ipv6 address, set weight). The syntax is identical to FRR for the core constructs.

Syntax example

ip prefix-list PFX-10 seq 5 permit 10.0.0.0/8
ip community-list STD-COMM seq 5 permit 65000:100
route-map RM-ACCEPT-IN permit 10
  match ip address prefix-list PFX-10
  match community STD-COMM
  set local-preference 200
route-map RM-ACCEPT-IN deny 20

Applied:

router bgp 65001
  neighbor 192.0.2.2 route-map RM-ACCEPT-IN in

Semantic Mismatches and Their Impact

Route Filtering Mismatches

Prefix Matching

Impact – A FRR prefix‑list using ge 24 le 30 translates directly to IOS‑XR ge 24 le 30 inside a prefix-set. However, if an operator mistakenly omits ge/le and relies on the implicit exact match, the resulting filter will be stricter than intended, potentially dropping legitimate longer prefixes.

Community Matching

Impact – The biggest divergence is the OR vs AND semantics. FRR/EOS match community requires all listed communities to be present (AND). IOS‑XR’s community matches-any is OR unless matches-every is used. Junos also uses AND. Translating a FRR term that lists multiple communities without adjusting the operator can unintentionally broaden the match (OR) or narrow it (AND) depending on target.

AS Path Matching

Impact – Generally consistent, but operators must be aware that some vendors (e.g., older IOS releases) treat the ^ anchor differently when the AS_PATH contains confederation segments; however, modern releases align. The primary risk is using a regex that inadvertently matches more than intended due to missing anchors.

Action Mismatches

Route Acceptance and Rejection

Impact – Direct mapping is straightforward; however, forgetting to add an explicit deny/drop/reject term can lead to unintended acceptance because the implicit default varies (FRR/EOS: deny; IOS‑XR: drop; Junos: reject). In practice, all three result in the route not being installed, but the reason code differs in BGP notifications (e.g., notify with Cease/Administrative shutdown vs Cease/Peer deconfigured). For troubleshooting, the distinction matters only when examining logs.

Route Modification

Impact – The semantics of additive vs set are identical across platforms. However, FRR/EOS allow multiple set community clauses in a term; the last one wins unless additive is used. IOS‑XR’s set community is also last‑wins unless additive. Junos uses community add (additive) and community set (replace). Mis‑interpreting additive vs replace can lead to unintended community stripping.

Route Redistribution

Impact – While the high‑level concept is the same, the attachment point differs: FRR/EOS apply a route-map directly under the redistribution command; IOS‑XR references a route-policy; Junos uses an export policy within the protocol configuration. Mis‑mapping the policy