Arista EOS Route Maps and Prefix Lists Configuration

Route maps decide everything that routing protocols do not do by default: which routes are redistributed, which are accepted from a neighbour, and how attributes are rewritten along the way. On Arista EOS the syntax is IOS-like with a few differences that trip people up, especially around implicit deny, sequence ordering and the way prefix lists combine with route maps. This guide covers building both objects, wiring them into BGP, and verifying that the policy is doing what you intended.

Prefix Lists: The Matching Primitive

A prefix list is an ordered set of entries that permit or deny prefixes, optionally with a length range. The ge and le keywords specify the range of prefix lengths that match, which is how a single entry can cover all the more-specifics of a summary.

switch(config)# ip prefix-list PL_CUST_A seq 10 permit 203.0.113.0/24
switch(config)# ip prefix-list PL_CUST_A seq 20 permit 198.51.100.0/24 ge 25 le 28
switch(config)# ip prefix-list PL_CUST_A seq 100 deny 0.0.0.0/0 le 32
switch# show ip prefix-list PL_CUST_A

That third entry implements the explicit deny that people often forget. A prefix list has an implicit deny at the end, and being explicit about it makes the intent visible to the next engineer and makes the hit counts meaningful.

Route Maps: Ordered Rules

A route map is a list of sequences, each with an action of permit or deny, one or more match statements and one or more set statements. Evaluation stops at the first sequence that matches all of its match conditions.

switch(config)# route-map RM_CUST_A_IN permit 10
switch(config-route-map-RM_CUST_A_IN)# match ip address prefix-list PL_CUST_A
switch(config-route-map-RM_CUST_A_IN)# set local-preference 200
switch(config-route-map-RM_CUST_A_IN)# exit

switch(config)# route-map RM_CUST_A_IN deny 20
switch(config-route-map-RM_CUST_A_IN)# exit

Sequence 20 with a bare deny makes the policy explicit: everything that is not in the prefix list is rejected. Without it the route map falls through to its own implicit deny, which is functionally similar but produces much less useful debugging output.

Matching on More Than Address

switch(config)# ip community-list standard CL_NO_EXPORT permit no-export
switch(config)# ip as-path access-list 10 permit ^65001(_65001)*$
switch(config)# route-map RM_IN permit 10
switch(config-route-map-RM_IN)# match community CL_NO_EXPORT
switch(config-route-map-RM_IN)# match as-path 10
switch(config-route-map-RM_IN)# match metric 0
switch(config-route-map-RM_IN)# match interface Ethernet1

Multiple match statements within a single sequence are ANDed - all of them must be true. To OR two conditions, use two sequences with the same action, because evaluation stops at the first match and only that sequence's set clauses apply.

Setting Attributes

switch(config-route-map-RM_OUT)# set local-preference 150
switch(config-route-map-RM_OUT)# set metric 100
switch(config-route-map-RM_OUT)# set community 65001:100 additive
switch(config-route-map-RM_OUT)# set as-path prepend 65001 65001
switch(config-route-map-RM_OUT)# set ip next-hop 192.0.2.1
switch(config-route-map-RM_OUT)# set tag 42

additive on the community set is important: without it the set clause replaces every community on the route, which silently strips tags your own policy relies on further down the network. The same applies to prepending - it is for inbound traffic engineering and is easy to over-apply.

Wiring Into BGP

switch(config)# router bgp 65001
switch(config-router-bgp)# neighbor 192.0.2.2 remote-as 65002
switch(config-router-bgp)# neighbor 192.0.2.2 route-map RM_CUST_A_IN in
switch(config-router-bgp)# neighbor 192.0.2.2 route-map RM_OUT out
switch(config-router-bgp)# redistribute connected route-map RM_REDIST
switch(config-router-bgp)# exit

Direction matters and is easy to invert: an inbound route map filters what you accept from the neighbour, an outbound route map filters what you advertise to them. Testing in the wrong direction produces an empty table and a lot of wasted time.

Verification

switch# show route-map
switch# show route-map RM_CUST_A_IN
switch# show ip prefix-list PL_CUST_A
switch# show ip bgp neighbors 192.0.2.2
switch# show ip bgp neighbors 192.0.2.2 advertised-routes
switch# show ip bgp neighbors 192.0.2.2 routes
switch# show ip bgp 203.0.113.0/24

Compare advertised-routes against routes to see the effect of an outbound policy, and to see the effect of an inbound policy compare received counts against what appears in the BGP table. If a route is missing entirely, check the order of the sequences: a deny sequence with a broad match placed above a permit sequence will silently win. For the ACL side of packet filtering on EOS, see EOS ACL configuration with counters, and for the peer-level configuration, EOS BGP peers and peer groups.

原文链接：https://www.arista.com/en/um-eos/eos-acls-and-route-maps