• BGP Peering – Configuration Best Practices – Security and Manageability

 
 
Print Friendly, PDF & Email

 

 

 

BGP Peering – Configuration Best Practices

– – – – – – – – – – – – – – – –

Security and Manageability

 

 

 

1) Introduction

This article provides suggestions of BGP peering configuration, with general best practices and some particular considerations for manageability and security.

 

 

2) Arista EOS Security – General

 

It is recommended to approach security not only specifically for BGP but to englobe other aspects of security for Arista EOS. More global security topics are covered in other articles, listed below. The present article focuses solely on BGP peering.

 

Securing EOS CLI: 

https://eos.arista.com/securing-eos-cli/

 

Restricting access to the switch/router:

https://eos.arista.com/restricting-access-to-the-switch/

 

Arista EOS hardening guide:

https://eos.arista.com/arista-eos-hardening-guide/

 

The RFC 7454 provides guidance on BGP Operations and Security, you will find some useful vendor-agnostic guidance.

https://tools.ietf.org/html/rfc7454

Some of these concepts are well and understood, but RFC7454 represent a robust source of information.

The present article presents similar ideas, but with a focus on Arista EOS specifically, with CLI examples.

 

 

3) BGP Security – overview

Different facets of BGP need to be involved for protection and filtering invalid parameters:

 

BGP protocol TTL

Restrict to drop invalid peers request from beyond the domain you trust.

Feature details: https://eos.arista.com/eos-4-17-1f/gtsm-for-bgp/

 

BGP connections to the control-plane

Arista EOS provides two mechanisms to protect the control-plane:

a) Control-plane ACL filters traffic

b) Control-plane policing (CoPP) restrict the amount of packet per second (pps) allowed to reach the CPU, per class of traffic (control-plane traffic), and also provide guaranteed bandwidth per class.

Both the ACL and the policy can be tuned to suit the needs; in particular to narrow the allowed traffic to trusted sources.

 

AS-Path filtering

Since direct BGP peers and routers behind them may be able to modify the prefix ASNs (AS-path replacement), the AS-path ASNs alone are not enough criteria for trusting prefixes. You should rely on the IP prefixes too.

 

Prefix filtering

Common prefix-list filtering, enhanced by the ability to load prefix-lists from a file, either by URL (HTTP/HTTPS/SCP) or local flash.

 

BGP protocol peer ASN

It seems obvious, but since there are features that allow to peer automatically with neighbour whose ASN was implicitly derived (automatically), without explicitly dictating the ASN (feature: “bgp listen …” ), then higher security would require specifying the ASNs. The “bgp listen …” feature is not suitable for BGP router peering, it is used for simpler operations but that is only appropriate within a very trusted environment.

 

4) BGP security with Prefix filtering

Guidance on prefix-list for Arista EOS

Commonly used, prefix-list filtering provides granular control, more than AS-Path alone can do.

This method is enhanced in Arista EOS by the ability to load prefix-lists from a file, either by URL (HTTP/HTTPS/SCP) or local flash.

Syntax: 

[ip | ipv6] prefix-list <PL_NAME> source <local or remote location>

 

Example:

!
ip prefix-list PL_BOGONS source https://some.address.com/bogons_full_v4
ipv6 prefix-list PL_BOGONS_v6 source https://some.address.com/bogons_full_v6
!

 

This is particularly useful for dynamic files or very large files (Full Bogons black list) as it keeps the running-configuration clean and minimalistic, the configuration will only be populated with that single “prefix-list <name> source” line that refers to the file. The content of the file itself is not included in the running-configuration, for clarity.

Note that you would likely need to include such prefix-list in a route-map (because default routes cannot be part of the file).

 

Route-map hierarchy can help

As a side note, the route-maps support hierarchical structure, so it is possible to have very flexible and organised filtering policy.

Sub-route-maps are detailed here:

https://eos.arista.com/eos-4-17-0f/bgp-policy-config-enhancements/

 

Bogons lists

Team-Cymru is a trusted source for listing bogons prefixes (https://www.team-cymru.org), but you may use your own trusted reference.

Example of simple bogons list:

https://www.team-cymru.org/Services/Bogons/bogon-bn-agg.txt

 

Bogons lists to use on Arista EOS

Example of bogons list converted as prefix-list ready to use on Arista EOS:

https://github.com/alexisdacquay/arista-eos-templates/tree/master/bogons

This provide a neat way to manage very large filtering, and ease reflecting its dynamic nature (easy refresh methods)

The below section describes the content you can find at:

https://github.com/alexisdacquay/arista-eos-templates/tree/master/bogons

First, note that any converted bogons list is a snapshot, it might is not necessarily up to date.

The different files you can find there are as follows.

 

[short] source-seed.txt 

Location: https://github.com/alexisdacquay/arista-eos-templates/blob/master/bogons/prefix-list/short/source-seed.txt

Format: prefix-list file format (not EOS configuration)

Description: File containing the prefix-list entries in file format. Note that you cannot copy/paste that content into EOS CLI or via API, as there is not prefix-list denomination. This format is only to be used in a file retrieved as a source by a prefix-list .

IPv4 example of file format:

permit 0.0.0.0/8 le 32
permit 10.0.0.0/8 le 32
permit 100.64.0.0/10 le 32
[...]

 

IPv6 example of file format:

permit ::/8 le 128
permit 100::/8 le 128
permit 200::/7 le 128
[...]

 

 

[short] standalone.cfg

Location: https://github.com/alexisdacquay/arista-eos-templates/blob/master/bogons/prefix-list/short/standalone.cfg

Format: EOS configuration

Description: This is the classic standalone and complete prefix-list configuration that can be pasted in CLI or pushed by API, it would fully appear in the “show run” output. This format cannot be used as file format for a prefix-list “source“.

IPv4 Example:

!
ip prefix-list PL_BOGONS_v4 seq 10 deny 0.0.0.0/8 le 32
ip prefix-list PL_BOGONS_v4 seq 20 deny 10.0.0.0/8 le 32
ip prefix-list PL_BOGONS_v4 seq 30 deny 100.64.0.0/10 le 32
[...]
!

For IPv6 there is no “short and simple” list, please use the full bogons list. But for completeness, here is an extract from what an IPv6 prefix-list would look like:

 

!
ipv6 prefix-list PL_BOGONS_v6 seq 10 deny ::/8 le 128
ipv6 prefix-list PL_BOGONS_v6 seq 20 deny 100::/8 le 128
ipv6 prefix-list PL_BOGONS_v6 seq 30 deny 200::/7 le 128
[...]
!

 

[full] seed_ipv4.txt, seed_ipv6.txt

Location: 

For IPv4:

https://raw.githubusercontent.com/alexisdacquay/arista-eos-templates/master/bogons/prefix-list/full/seed_ipv4.txt

For IPv6:

https://raw.githubusercontent.com/alexisdacquay/arista-eos-templates/master/bogons/prefix-list/full/seed_ipv6.txt

In case the files become unavailable for some reasons, you may navigate through the directories from the root folder:

https://github.com/alexisdacquay/arista-eos-templates/tree/master/bogons/

Format: prefix-list file format (not EOS configuration)

Description: Bogons full (unallocated + alien) entries in file format for the prefix-list. Below are the full paths for each seed file, to be called by “prefix-list source

 

In the below you will notice that the prefix-list that use a source file is called in a route-map, not on BGP peers directly.

This is because although you would need a trailing 0.0.0.0/0 or ::/0 after a long list of denied prefixes, when using a file source then the file format prefix entries cannot have a 0.0.0.0/0 or ::/0. You can have many thousands of prefixes (I tested >100k), any prefixes you want except the default route.

This is by design, as a safeguard to avoid big mistakes and complicated overlapping checks. If you need to allow “everything else” than it is easier (neater) to create a relevant follow-up route-map entry that does such permit. Make it a standalone route-map entry that make it stand out, rather than having the default route swamped in a long prefix-list within thousands of deny entries. A “route-map permit” with no specific match would default to match all (usual behaviour). You do not need to match a prefix-list permitting 0.0.0.0/0. The route-map can then be applied to BGP neighbour or BGP network statements. 

Below is an example of such route-map denying IPv4 and IPv6 bogons and then permitting everything else legitimate.

 

!
ip prefix-list PL_BOGONS_V4 source https://raw.githubusercontent.com/alexisdacquay/arista-eos-templates/master/bogons/prefix-list/full/seed_ipv4.txt
ipv6 prefix-list PL_BOGONS_V6 source https://raw.githubusercontent.com/alexisdacquay/arista-eos-templates/master/bogons/prefix-list/full/seed_ipv6.txt
!
route-map RM_IN deny 10
match ip address prefix-list PL_BOGONS_V4
!
route-map RM_IN deny 50
match ipv6 address prefix-list PL_BOGONS_V6
!
route-map RM_IN permit 1000
description Default permit. File format prefix entries cannot have trailing 0.0.0.0/0 or ::/0
!

 

For short prefix-lists you may feel comfortable enough configuring them fully in the configuration, without using prefix-list source and a file. For example, the basic bogons list is fairly simple and does not justify employing the source file.

Reasons for preferring static and standalone prefix-lists without ‘source’ file.

a) it does not overloads the configuration file

b) it is static

 

Example of a complete prefix-list for IPv4 bogons:

 

!
ip prefix-list PL_BOGONS_v4 seq 10 deny 0.0.0.0/8 le 32
ip prefix-list PL_BOGONS_v4 seq 20 deny 10.0.0.0/8 le 32
ip prefix-list PL_BOGONS_v4 seq 30 deny 100.64.0.0/10 le 32
ip prefix-list PL_BOGONS_v4 seq 40 deny 127.0.0.0/8 le 32
ip prefix-list PL_BOGONS_v4 seq 50 deny 169.254.0.0/16 le 32
ip prefix-list PL_BOGONS_v4 seq 60 deny 172.16.0.0/12 le 32
ip prefix-list PL_BOGONS_v4 seq 70 deny 192.0.0.0/24 le 32
ip prefix-list PL_BOGONS_v4 seq 80 deny 192.0.2.0/24 le 32
ip prefix-list PL_BOGONS_v4 seq 90 deny 192.168.0.0/16 le 32
ip prefix-list PL_BOGONS_v4 seq 100 deny 198.18.0.0/15 le 32
ip prefix-list PL_BOGONS_v4 seq 110 deny 198.51.100.0/24 le 32
ip prefix-list PL_BOGONS_v4 seq 120 deny 203.0.113.0/24 le 32
ip prefix-list PL_BOGONS_v4 seq 130 deny 224.0.0.0/3 le 32
ip prefix-list PL_BOGONS_v4 seq 1000 permit 0.0.0.0/0 le 32
!

 

One advantage of the prefix-list source method is that the source file can be updated relatively frequently and it is easy to reflect these file changes into EOS by refreshing the prefix-list; which is effectively doing a fresh lookup to the file and applies it again.

 

When using the source file method, it is recommended to refresh the prefix-list at least at boot-up time, but since your Arista device may not need to be rebooted for a very long time, your risk to have outdated entries. Make sure you refresh the prefix-list to reflect updates made in the source file. For example, the Full Bogons public lists may be updated at least daily.

It is not recommended to “leave and forget” it, for best security (not allowing invalid prefixes) and legitimate connectivity (not blocking newly valid prefixes), you must revisit this regularly or refresh the prefix-list regularly.

Please consider updating the prefix-list with the below methods:

a) manually with the EOS commands :

!
refresh ip prefix-list
!

You may run this in a controlled manner during change window.  Note that by refreshing a prefix-list there can be temporary short disruption while the data-plane’s hardware table(s) is  being reprogrammed.

 

b) schedule automatic daily refresh with the “schedule” feature, or at least with a fresh lookup upon a boot-up with the “event-handler“.

Here is a description of these two complementary features:

event-handler: Upon a trigger, take an action. The trigger can be a boot-up, a config change, a syslog message, count thresholds, etc

schedule : At regular interval, take an action. You can set to repeat an action every hour for example, or every day at 3AM.

 

As mentioned once before, but worthy to emphasise: It is not recommended to “leave and forget” it.

 

Example of refresh at boot-up:

 

!
event-handler REFRESH-PREFIX-LIST
   trigger on-boot
   action bash Cli -p 15 -c "refresh ip prefix-list"
   delay 120
   timeout 120
   asynchronous
!

 

Example of a refresh configured at regular interval (daily at 03:00) with the ‘schedule‘ feature:

!
schedule schedule-refresh-prefix-list at 03:00:00 interval 1440 timeout 1 max-log-files 10 command refresh ip prefix-list
!

 

 

5) BGP connections to the control-plane

 

This section describes how to restrict access to the Arista EOS control-plane, in particular for BGP connections, using the control-plane access-list. For hardening the BGP control-plane you can restrict the source IP addresses to only the trusted peer IP addresses.

Use this article as reference: https://eos.arista.com/restricting-access-to-the-switch/

 

Summary of the instructions to amend the control-plane ACL:

5.a) copy your current default control-plane ACL to a new ACL.

5.b) tune the new ACL to restrict BGP (and other protocols)

5.c) configure EOS to use that new ACL. You can always fall back to the read-only default ACL if you need.

 

These three steps are detailed further below.

 

5.a) Copy the default control-plane ACL

The default control-plane ACL might vary between EOS version as features are added and might require new entries in that default ACL. Therefore, when copying that default ACL make sure you take a fresh look at the default ACL in your current EOS version, not a legacy ACL copy from a past EOS version.

You can check your default control-plane ACL with the commands:

 

 

!
show ip access-list default-control-plane-acl
show ip6 access-list default-control-plane-acl
!

 

 

Below is an example of the read-only default control-plane ACL for IPv4. The IPv6 one look similar because the IPv6 addresses as specified as any/any by default. Note that some entries in this might be different than what you have in your own EOS because it includes recent features (e.g. multihop-bfd, micro-bfd, etc), hence the previous mention of taking a copy of your running ACL.

 

ip access-list default-control-plane-acl

statistics per-entry
10 permit icmp any any
20 permit ip any any tracked
30 permit udp any any eq bfd ttl eq 255
40 permit udp any any eq bfd-echo ttl eq 254
50 permit udp any any eq multihop-bfd
60 permit udp any any eq micro-bfd
70 permit ospf any any
80 permit tcp any any eq ssh telnet www snmp bgp https msdp ldp
90 permit udp any any eq bootps bootpc snmp rip ntp ldp
100 permit tcp any any eq mlag ttl eq 255
110 permit udp any any eq mlag ttl eq 255
120 permit vrrp any any
130 permit ahp any any
140 permit pim any any
150 permit igmp any any
160 permit tcp any any range 5900 5910
170 permit tcp any any range 50000 50100
180 permit udp any any range 51000 51100
190 permit tcp any any eq 3333
200 permit tcp any any eq nat ttl eq 255
210 permit tcp any eq bgp any
220 permit rsvp any any

 

5.b) Tune the new ACL to restrict BGP (and other protocols)

Copy the default ACL, make the adequate modifications and  paste it into a new ACL (for example name “my-control-plane-acl-01”) 

In the below ACL, ‘bgp‘ was removed as a destination TCP port in line 80, and it was instead added to a new line 1000 for a more restrictive statement. Whilst the line 210 already existed for bgp as source TCP port, it not restrictive enough in term of IP addresses, so new entries are added in the 10xx range.

Summary:

a) remove all mentions of BGP

b) creates more specific entries for BGP.

 

Note that only ingress traffic is filtered, so in this control-plane ACL you only need to match the traffic destined to the local Arista device, not the traffic going out to the remote peers.

To reflect this BGP traffic direction, in the later control-plane ACL example, the new rules 1000 and 1010 have:

– source IP: <TRUSTED_PEERS>

– destination: <MY_IP>

 

Obviously, you should have serious interest in hardening EOS not only for BGP but also many other protocols such as SSH, HTTPS, telnet (inactive by default), etc. The current document focuses on BGP.

 

ip access-list my-control-plane-acl-01
statistics per-entry
10 permit icmp any any
20 permit ip any any tracked
30 permit udp any any eq bfd ttl eq 255
40 permit udp any any eq bfd-echo ttl eq 254
50 permit udp any any eq multihop-bfd
60 permit udp any any eq micro-bfd
70 permit ospf any any
80 permit tcp any any eq ssh telnet www snmp https msdp ldp
90 permit udp any any eq bootps bootpc snmp rip ntp ldp
100 permit tcp any any eq mlag ttl eq 255
110 permit udp any any eq mlag ttl eq 255
120 permit vrrp any any
130 permit ahp any any
140 permit pim any any
150 permit igmp any any
160 permit tcp any any range 5900 5910
170 permit tcp any any range 50000 50100
180 permit udp any any range 51000 51100
190 permit tcp any any eq 3333
200 permit tcp any any eq nat ttl eq 255
220 permit rsvp any any
! New:
1000 permit tcp <TRUSTED_PEERS> <MY_IP> bgp
1010 permit tcp <TRUSTED_PEERS> eq bgp <MY_IP>
! Tracking, to identify dropped TCP traffic
2000 deny tcp any any eq bgp log
2010 deny tcp any eq bgp any log
exit

 

Note: The ACL config is created once you exit the ACL configuration mode.

arista(config-acl-my-control-plane-acl-01)#show active
                      <-- No config yet, the change is pending
arista(config-acl-my-control-plane-acl-01)#show diff
--- 
+++ 
@@ -0,0 +1,5 @@
+ip Access List my-control-plane-acl-01
+        10 permit icmp any any
+        20 permit ip any any tracked
+        30 permit udp any any eq bfd ttl eq 255
[...]
arista(config-acl-my-control-plane-acl-01)#exit <-- creates the ACL
arista(config)#show ip access-lists my-control-plane-acl-01 
IP Access List my-control-plane-acl-01
        statistics per-entry
        10 permit icmp any any
        20 permit ip any any tracked
        30 permit udp any any eq bfd ttl eq 255
[...]

 

The procedure for IPv6 would be extremely similar.

 

5.c) Apply the new control-plane ACL

Under the configuration mode “control-plane” you can change the ACL and QoS policy that protect the control-plane. Below is the configuration to apply the newly created custom ACL.

!
config
control-plane
! Apply the new ACL:
ip access-group my-control-plane-acl-01-v4 in
ipv6 access-group my-control-plane-acl-01-v6 in
exit
!

 

Note the “in” direction; the traffic is filtered ingress, for inbound traffic only.

 

You should verify that the ACL has taken effect for control-plane filtering, by looking up for match counters.

In the below example, successful trusted connections are matching the permit rule and are accounted for “[match 4 packets, 0:00:02 ago]

The undesired traffic matches against the deny rules “[match 3 packets, 0:00:00 ago]“.

 

arista#show ip access-lists

[...]
IP Access List my-control-plane-acl-01
statistics per-entry
[...]
1000 permit tcp host 10.0.0.3 host 10.0.0.2 eq bgp [match 4 packets, 0:00:02 ago]
1010 permit tcp host 10.0.0.3 eq bgp host 10.0.0.2
[...]
2000 deny tcp any any eq bgp log [match 3 packets, 0:00:00 ago]
2010 deny tcp any eq bgp any log

 

The ACL “deny” entries with “log” show records in the log for the blocked TCP connection(s):

arista#show log
Nov 15 17:41:01 s7152 Acl: %ACL-6-IPACCESS: list my-control-pla denied tcp 10.0.0.3(35229) -> 10.0.0.2(179)
Nov 15 17:41:02 s7152 Acl: %ACL-6-IPACCESS: list my-control-pla denied tcp 10.0.0.3(35229) -> 10.0.0.2(179)
Nov 15 17:41:04 s7152 Acl: %ACL-6-IPACCESS: list my-control-pla denied tcp 10.0.0.3(35229) -> 10.0.0.2(179)

 

 

6) Maximum accepted routes

In case of malicious or erroneous advertisement of very large amount of prefixes, your Arista router might get its resources under stress. In extreme cases it can saturate these resources, preventing legitimate prefixes from being learnt, hence causing outages.

There are several sorts of resources to consider:

– Control-plane: RAM, drives the amount of entries in the routing table (RIB)

– Control-plane: CPU, drives the amount of peers, frequency of changes, convergence speed

– Data-plane: hardware table(s) entries, dictates how many different prefixes can be written. Note that in ECMP cases, a single prefix with different next-hops would consume a single entry in a prefix hardware table. The multiple next-hops would be located in a different hardware table.

You should preserve your resources and legitimate prefixes by setting a limit to the amount of prefixes you accept from BGP neighbour. The limit may be:

– informational only; an alert is triggered upon exceeding the threshold

– acted upon; once the threshold is reached then the BGP peer is forced to IDLE until the BGP connection is reset.

 

There are 2 different features relating to the maximum routes in a BGP peering:

maximum-routes: only warns; this is active by default (warning set to 12000)

    ! Exceeding this max will generate a Syslog warning (but no action taken)
! There is a default threshold for all peers set to 12000
neighbor <PEER_IP> maximum-routes <WARNING_THRESHOLD>
!

 

maximum-accepted-routes: can warn at a first threshold and then shut the peer at the 2nd threshold.

Upon exceeding the max-accepted-routes threshold the neighbor relationship will be teared down as a protection mechanism, the peering will be in BGP IDLE state until a clear is triggered (clear ip bgp …). Since the condition is considered extreme and it is not possible to identify which prefixes from the “fraudulent” peer are valid or not, the whole peer is disabled, no prefixes from that peer will remain valid.


! If you want further protection (rather than just warning), then the following
! command, upon exceeding the max_accepted will permanently shut the peer into
! IDLE state until a "clear ip bgp ..." command is entered.
neighbor <PEER_IP> maximum-accepted-routes <SHUTTING_THRESHOLD> warning-limit <WARNING_THRESHOLD>

!

 

 

7) BGP authentication

You should authenticate all the BGP neighbors with the command “neighbor password” and the MD5 method.

Syntax:

neighbor NEIGHBOR_ID password [ENCRYPT_LEVEL] key_text

Where “[ENCRYPT_LEVEL]” should be “7” to use the MD5 method, but you can omit  “[ENCRYPT_LEVEL]” entirely as “7” will  be used by default. Clear text password (level “0“) is not recommended.

 

Example with MD5 (default):

arista(config-router-bgp)#neighbor 123.1.1.1 password Just_1test
arista(config-router-bgp)#show active
router bgp 100
   neighbor 123.1.1.1 password 7 q0JQDtL7EMzioobkjG4BiA==

 

8) Improved Visibility

Several methods are available to you, exposing BGP information.

– BMP – BGP Monitoring Protocol

– Arista EOS streaming and telemetry

– SNMP MIBs

 

8.1) BMP – BGP Monitoring Protocol

BMP allows a monitoring station to connect to a router and collect all of the BGP announcements received from the router’s BGP peers.

https://eos.arista.com/eos-4-20-1f/bgp-monitoring-protocol/

 

8.2) Streaming

Arista EOS natively supports streaming, where updates are trigger-based – no polling, so no missed information.

To aggregate, correlate, run analytics, and present the information, you may use Arista CVP (Cloud Vision Portal) or an aggregator of your choice. The streaming format uses open standards.

In the below example, you can receive continuous information about BGP changes, look back at any point in time across multiple devices. Reminder: this is trigger-based (no polling), therefore 100% accurate. There is no loss of granularity.

 

 

 

8.3) SNMP

The Arista EOS MIBs are detailed at the below link.

https://www.arista.com/en/support/product-documentation/arista-snmp-mibs

 

The BGP-related MIBs are:

– ARISTA-BGP4V2-MIB

– ARISTA-BGP4V2-TC-MIB

– BGP4-MIB

 

Some other MIBs are not specific to BGP, but useful nevertheless in BGP peering context:

– RFC 4292 IP-FORWARD-MIB

– ARISTA-NEXTHOP-GROUP-MIB

– ARISTA-HARDWARE-UTILIZATION-MIB (https://eos.arista.com/eos-4-18-1f/snmp-mib-support-for-show-hardware-capacity/)

 

 

9) BGP Convergence – BFD

If two BGP neighbors do not have a direct physical connection then you would benefit from BFD to quickly detect failures in the path. This is recommended even though the two routers might appear as directly connected, if there is some transport equipment in the way, because such devices might not propagate correctly the link state changes.

 

BFD: https://eos.arista.com/eos-4-17-0f/bfd-enchancements/

Multi-hop BFD: https://eos.arista.com/eos-4-20-1f/multihop-bfd/

 

 

10) Additional Filtering

Depending on your use case, there are additional typical filtering you may want to implement.

– remove-private-as

– block prefixes of certain length

– block default routes

 

10.1) Private ASN

By default the private ASNs in a path are preserved. To remove these:

neighbor NEIGHBOR_ID remove-private-as

There are various tunings for this command, so you should look at the details in the manual (for example here: https://www.arista.com/en/um-eos/eos-section-31-4-bgp-commands#ww1117427 )

 

10.1) Prefix length

To prevent advertising or receiving prefixes that are too granular, match the generic prefixes with a prefix-list:

!
ip prefix-list <PREFIX_LIST_V4> permit 0.0.0.0/0 le 24
!
ipv6 prefix-list <PREFIX_LIST_V6>
permit ::/0 le 48
!

The syntax “0.0.0.0/0” means “any prefix” (technically: “any bits”) while “le <length>” indicates “less or equal”, meaning that the accepted (permit) prefix length would be 24, 23 or smaller.

No longer prefix would be accepted. For example, /25, /26, etc would be denied.

 

10.1) Default route

Ensure you only advertise or receive specific/explicit routes by matching and denying the default route in a prefix-list.

!
ip prefix-list <PREFIX_LIST> deny 0.0.0.0/0
ipv6 prefix-list <PREFIX_LIST_V6>
deny ::/0
!

 

A) Annex – Full BGP configuration

This section provides and example with templates for BGP and the relevant security settings.

 

!
event-handler REFRESH-PREFIX-LIST
trigger on-boot
action bash Cli -p 15 -c "refresh ip prefix-list"
delay 120
timeout 120
asynchronous
!
schedule schedule-refresh-prefix-list at 03:00:00 interval 1440 timeout 1 max-log-files 10 command refresh ip prefix-list
!
ip prefix-list PL_BOGONS_V4 source https://raw.githubusercontent.com/alexisdacquay/arista-eos-templates/master/bogons/prefix-list/full/seed_ipv4.txt
ipv6 prefix-list PL_BOGONS_V6 source https://raw.githubusercontent.com/alexisdacquay/arista-eos-templates/master/bogons/prefix-list/full/seed_ipv6.txt
!
route-map RM_IN deny 10
match ip address prefix-list PL_BOGONS_V4
!
route-map RM_IN deny 50
match ipv6 address prefix-list PL_BOGONS_V6
!
route-map RM_IN permit 1000
description Default permit (everything else). The file-format prefix entries cannot have trailing 0.0.0.0/0 or ::/0
!
ip prefix-list PL_OUT description Legitimate prefixes to advertise
ip prefix-list PL_OUT seq 10 permit <MY_PREFIX>/<MY_SUBNETMASK>
ip prefix-list PL_OUT seq 1000 deny 0.0.0.0/0 le 32
!
!
router bgp <ASN>
!
bgp graceful-restart
!
! Some defaults (for information only):
!graceful-restart stalepath-time 300
!graceful-restart restart-time 300
!bgp log-neighbor-changes
!
neighbor <PEER_IP> remote-as <PEER_ASN>
neighbor <PEER_IP> description <PEER_DESCRIPTION>
!
! Prevents spoofing or DoS to BGP from remote sources
neighbor <PEER_IP> ttl maximum-hops <MAX_HOPS>
!
! Set peer authentication by password (MD5 hash)
neighbor <PEER_IP> password <PASSWORD>
!
! If you want to load prefixes by URL mode, since it does not accept trailing
! 0/0, then you must use route-map. See the presented example above.
! If instead the filtering is simple then you may use prefix-list instead.
neighbor <PEER_IP> route-map RM_IN in
!
! You may use a prefix-list to announce only your prefixes. Note: IPv4 only here. For IPv6 you must use a route-map
neighbor <PEER_IP> prefix-list PL_OUT out
!
! This is a default, and recommended:
!neighbor <PEER_IP> soft-reconfiguration inbound
!
! Exceeding this max will generate a Syslog warning (but no action taken)
! There is a default threshold for all peers set to 12000
neighbor <PEER_IP> maximum-routes <WARNING_THRESHOLD>
!
! If you want further protection (rather than just warning), then the following
! command, uponn exceeding the max_accepted will permanently shut the peer into
! IDLE state until a "clear ip bgp ..." command is entered.
! neighbor <PEER_IP> maximum-accepted-routes <SHUTTING_THRESHOLD> warning-limit <WARNING_THRESHOLD>
!
! Benefit from ECMP Load-balancing (default is "maximum-paths 1" )
maximum-paths 16
!
! To improve BGP convergence for BGP peers that are not on a directl physical
! connection, you may want to use BFD (including multi-hop BFD support)
! https://eos.arista.com/eos-4-17-0f/bfd-enchancements/
! https://eos.arista.com/eos-4-20-1f/multihop-bfd/
!
! You would advertise summaries by use of BGP aggregate or static routes
! that match the network statement prefix.
network <SUBNET> <NET_SUBNETMASK>
!
! If using static route to populate your routing table with summaries, you may
! want to bring dynamic considerations. One optino is BFD tracking for static
! routes: https://eos.arista.com/eos-4-20-1f/bfd-for-static-routes/
! Another option is log tracking, reacting to events for populating or removing
! the static route, if desired:
! https://eos.arista.com/ip-static-route-with-health-check/
ip route 185.10.160.0/24 Null0
ipv6 route 2a03:65c0::/24 Null0
!
ip access-list my-control-plane-acl-01
statistics per-entry
10 permit icmp any any
20 permit ip any any tracked
30 permit udp any any eq bfd ttl eq 255
40 permit udp any any eq bfd-echo ttl eq 254
50 permit udp any any eq multihop-bfd
60 permit udp any any eq micro-bfd
70 permit ospf any any
80 permit tcp any any eq ssh telnet www snmp https msdp ldp
90 permit udp any any eq bootps bootpc snmp rip ntp ldp
100 permit tcp any any eq mlag ttl eq 255
110 permit udp any any eq mlag ttl eq 255
120 permit vrrp any any
130 permit ahp any any
140 permit pim any any
150 permit igmp any any
160 permit tcp any any range 5900 5910
170 permit tcp any any range 50000 50100
180 permit udp any any range 51000 51100
190 permit tcp any any eq 3333
200 permit tcp any any eq nat ttl eq 255
220 permit rsvp any any
! New:
1010 permit tcp <TRUSTED_PEERS> <MY_IP> bgp
1000 permit tcp <TRUSTED_PEERS> eq bgp <MY_IP>
! Tracking, to identify dropped TCP traffic
2000 deny tcp any any eq bgp log [match 3 packets, 0:00:00 ago]
2010 deny tcp any eq bgp any log
exit
!
control-plane
ip access-group my-control-plane-acl-01 in
ipv6 access-group my-control-plane-acl-01-v6 in
exit
!

 

 

B) References

 

http://www.team-cymru.com/bogon-reference.html

https://tools.ietf.org/html/rfc7454

 

 

 

 

Follow

Get every new post on this blog delivered to your Inbox.

Join other followers: