BGP Filtering Best Practices: Techniques and Guidelines for Using AS-Path Filters, Distribute-Lists, Prefix-Filters, and More.

Greetings, fellow networking enthusiasts! Today we’re going to dive into the exciting world of Border Gateway Protocol (BGP) security and the magic of BGP filtering. As you may already know, BGP is the routing protocol that helps guide data packets through the vast and complex network that makes up the internet. It’s like a GPS system for the internet!

But, like with any road trip, there’s always the risk of taking a detour through a sketchy neighborhood. In the internet world, these sketchy neighborhoods can be represented by malicious actors who want to hijack or redirect traffic for their own gain. That’s where BGP filtering comes in to save the day!

BGP filtering is like having a security guard at the door of your network, only allowing trusted routes and filtering out any unwanted ones. And just like with a good security guard, it’s important to have solid BGP filtering best practices in place to ensure maximum security. Over the past decade, BGP security has evolved significantly, moving beyond manual CLI configurations to embrace automation, Infrastructure as Code, and advanced validation techniques.

So sit back, grab your favorite caffeinated beverage, and let’s dive into the wonderful world of BGP filtering, its foundational techniques, and its role in maximizing BGP security with modern approaches as we head towards 2025!

BGP Filtering Techniques – AS-Path Filters

Definition and purpose

AS-Path Filters can be like the secret agents of the BGP filtering world! They use the AS-path list to selectively filter routes, choosing only the most trustworthy data packets to let into your network.

When it comes to incoming routes, AS-Path filters work like a secret door at a VIP party. Only the permitted routes are allowed in and added to the local BGP table, while the denied routes are silently dropped, like a party crasher trying to sneak in.

For outgoing routes, AS-Path filters are like a trusty messenger. The permitted routes are transmitted to the neighbor, while the denied routes are never sent, like a message that’s too sensitive to send to just anyone.

How to create and apply AS-Path filters

Modern network operating systems like Cisco IOS XE (e.g., 17.9 Denali), Juniper Junos (e.g., 23.4R1 LTS), and Arista EOS (e.g., 4.32.0F) all support AS-Path filters using regular expressions. While manual configuration is still possible, automation is now the preferred method for managing these rules at scale.

Here’s an example using Cisco IOS XE CLI:

ip as-path access-list AS_FILTER_IN permit ^123_456$
! This permits routes originating from AS 123 and passing through AS 456
!
ip as-path access-list AS_FILTER_OUT permit ^$
! This permits only routes originating in the local AS (empty AS-path) for advertising
!
router bgp 65001
! specify the local AS number (e.g., a private AS or your registered public AS)
!
neighbor 192.0.2.1 remote-as 65002
neighbor 192.0.2.1 filter-list AS_FILTER_IN in
! apply the AS-Path filter to incoming routes from the BGP neighbor
neighbor 192.0.2.1 filter-list AS_FILTER_OUT out
! apply the AS-Path filter to outgoing routes to the BGP neighbor

And to verify your AS-Path filter configuration:

show ip bgp neighbor 192.0.2.1 received-routes
! display the received routes from the specified BGP neighbor
!
show ip bgp neighbors 192.0.2.1 filters
! display the applied filters on the specified BGP neighbor

BGP Filtering Best Practices for using AS-Path filters

BGP Filtering Best Practices for using AS-Path filters are more critical than ever:

• Regularly review and update your AS-Path filters to ensure maximum security. Leverage automation platforms (like Ansible Automation Platform or Nornir) and Infrastructure as Code (IaC) principles to manage these updates consistently and audibly.
• Use different filters for different types of data packets or peers, just like having different VIP lists for different areas of your party. Consider peer-specific filters for granular control.
• Test your filters rigorously in a lab environment (or a staging network) before applying them in a production environment. Automated testing frameworks are crucial here.
• Document your AS-Path filter configuration thoroughly for future reference. Integrate this documentation directly into your IaC solution, making the code the source of truth.
• For critical Internet-facing peers, implement explicit allow-lists for expected AS-paths and a default deny, rather than attempting to deny known bad AS-paths.

BGP Filtering using AS-Path Access-List to prevent being used as transit BGP AS

One of the most important things to do with BGP in a dual-homing network is to stop our BGP AS number from being used as a transit AS between two service providers. Although there are several methods to perform them, for example, using BGP communities, etc. One easy approach is to use BGP filtering to achieve this design.

• Suppose our AS is 300, and we don’t want BGP AS 200 to use our AS as a transit AS. We are able to accomplish this through the use of an “IP as-path access-list” and by matching the as-path and then filtering it to the desired neighbor by BGP “filter-list”. Below is an example –
• The syntax of AS-PATH access-list (Cisco IOS XE):

 RTC(conf)#ip as-path access-list 13 permit ^$

 Right here ^ matches the beginning of the string.

Right here, $ matches the end of the string. The `^$` regex literally means “an empty AS path,” which implies the prefix originated in the local AS.

• The syntax of the BGP filter-list:

router bgp 300

neighbor 198.51.100.1 filter-list 13 out

By doing this, we are only advertising network prefixes originating in our local AS, which is AS300, to our neighbors (e.g., AS100 and AS200, if 198.51.100.1 is a peer in one of those). The result of this filter list will be that AS 200 will not be able to use AS 300 to reach AS 100. This is achieved by using filtering primarily based on AS-PATH data. Because the AS-PATH of a prefix is not added when the prefix leaves the AS, prefixes that have originated inside the AS could have an empty AS-PATH.

This may be simply matched with a regular expression that specifies that the end of the as-path string comes instantly after the beginning of the as-path string and is denoted as `^$`.

You can use the below command to check the configuration:-

R1#show ip bgp neighbors [ip address of EBGP Neighbor] advertised-routes

BGP Filtering Techniques – Distribute-Lists

Definition and purpose:

Distribute-lists, my friend, are like bouncers at a popular nightclub. They control who gets in and who doesn’t. In BGP, distribute-lists act as filters for incoming or outgoing routes. They help you control which routes are advertised or accepted from a neighboring router. With distribute-lists, you can be in charge of what routes enter or exit your network, giving you the power to control your network’s traffic flow. While still present in many network OS, distribute-lists are often superseded by more granular `route-maps` or `policy-statements` which offer greater flexibility and readability.

How to create and apply Distribute-lists:

Creating a distribute-list is quite simple. You can do it with just a few lines of configuration. Here’s an Example of creating a distribute-list in Cisco IOS XE:

Router(config)# ip access-list standard BGP_OUT_FILTER
Router(config-std-nacl)# permit 11.11.11.0 0.0.0.255
Router(config-std-nacl)# deny any

Once you’ve created the distribute-list, you can apply it to a BGP neighbor by using the following configuration:

Router(config)# router bgp 100
Router(config-router)# neighbor 1.1.1.1 remote-as 200
Router(config-router)# neighbor 1.1.1.1 distribute-list BGP_OUT_FILTER out

With this configuration, all outgoing routes to the 1.1.1.1 neighbor will be checked against the distribute-list before being advertised. For incoming routes, substitute `out` with `in`.

BGP Filtering Best Practices for using distribute-lists:

Here are a few tips:

• Always keep your distribute-lists up-to-date and relevant. This helps prevent unwanted routes from entering your network. Regularly audit them using automation.
• Extended access lists should be used instead of standard access lists when more granular matching (e.g., source/destination IP, protocol) is needed, or for precise prefix length matching, as standard ACLs have a fundamental flaw: they cannot exactly match the length of a network mask, allowing more than the intended length. For BGP, prefix-lists are generally preferred over ACLs.
• Use a combination of distribute-lists (or more likely, route-maps/policy-statements) and prefix-lists for a more comprehensive filtering approach. This can help prevent potential routing loops and other issues.
• Use the “show ip bgp” command to verify your distribute-lists and ensure they’re working as intended. In automated environments, this verification can be part of a CI/CD pipeline.
• Regularly monitor your BGP sessions and routes to catch any potential issues early on. Leverage network observability tools for real-time insights.

BGP Filtering Techniques – Prefix-Lists

Definition and purpose:

Prefix-filters, my friend, are like sieves in a kitchen. They sort out the unwanted bits and keep only what you want. In BGP, prefix-filters act as filters for incoming or outgoing routes based on the prefixes of the routes. They help you control which routes are advertised or accepted from a neighboring router based on the prefix of the route. With prefix-filters, you can be in charge of what routes enter or exit your network, giving you the power to control your network’s traffic flow. Prefix-lists are generally considered more robust and efficient than standard access-lists for BGP route filtering due to their explicit prefix length matching capabilities.

How to create and apply prefix-filters:

Creating a prefix-filter is a snap. You can do it with just a few lines of configuration.

Here’s an example of creating a prefix-filter in Cisco IOS XE:

Router(config)# ip prefix-list MY_PREFIX_FILTER seq 5 permit 11.11.11.0/24
Router(config)# ip prefix-list MY_PREFIX_FILTER seq 10 permit 10.0.0.0/8 le 24
Router(config)# ip prefix-list MY_PREFIX_FILTER seq 20 deny 0.0.0.0/0 le 32

The `le` (less than or equal) and `ge` (greater than or equal) keywords are powerful for matching ranges of prefix lengths. `0.0.0.0/0 le 32` effectively denies all prefixes.

Once you’ve created the prefix-filter, you can apply it to a BGP neighbor by using the following configuration:

Router(config)# router bgp 100
Router(config-router)# neighbor 1.1.1.1 remote-as 200
Router(config-router)# neighbor 1.1.1.1 prefix-list MY_PREFIX_FILTER in

With this configuration, all incoming routes from the 1.1.1.1 neighbor will be checked against the prefix-filter before being accepted into the BGP table.

BGP Filtering Best Practices for using prefix-filters:

Here are a few tips:

• Always keep your prefix-filters up-to-date and relevant. This helps prevent unwanted routes from entering your network. Leverage RIR data (like ARIN, RIPE, APNIC) and PeeringDB for accurate prefix information.
• Use a combination of prefix-lists with route-maps or policy-statements for a more comprehensive and flexible filtering approach. This can help prevent potential routing loops and other issues.
• Implement ingress filtering (uRPF) where appropriate to help prevent spoofed source addresses.
• Use the “show ip bgp” command to verify your prefix-filters and ensure they’re working as intended. Modern automation tools can parse this output for validation.
• Regularly monitor your BGP sessions and routes, coupled with network observability platforms, to catch any potential issues early on.
• Consider generating prefix-lists automatically from a source of truth (e.g., a Network Source of Truth like Nautobot) to reduce human error and ensure consistency.

BGP Filtering in the Age of Automation: Modern Approaches for 2025

The landscape of network management has shifted dramatically. Manual CLI configurations are giving way to programmatic approaches, leveraging Infrastructure as Code (IaC) and network automation tools. This not only increases efficiency but significantly enhances the accuracy and security of BGP filtering.

Modern BGP Filtering Tools & Frameworks

To manage BGP filtering at scale, especially in multi-vendor environments, network engineers increasingly rely on powerful automation tools.

• Python (3.12+) and Libraries: Python continues to be the lingua franca of network automation. Ensure you’re using Python 3.12 or newer for optimal performance and security.
  • Netmiko (4.3.0+): A multi-vendor SSH library that simplifies sending CLI commands and parsing output. It’s excellent for basic configuration tasks and data retrieval.
  • Scrapli (2024.1.1+): A highly performant, asynchronous network interaction library that supports SSH, Telnet (deprecated for production!), NETCONF, and gNMI. Scrapli is often preferred for its speed and modern API.
  • Paramiko (3.4.1+): A low-level SSHv2 protocol implementation for Python, often used by other libraries but can be used directly for custom SSH interactions. Ensure you are using SSHv2 for all connections.
  • Nornir (3.x): A pluggable automation framework built on Python. Nornir orchestrates tasks across multiple devices, making it ideal for managing large-scale BGP configurations and applying filtering rules consistently.
• Ansible Automation Platform (2.4+) / Ansible Core (2.17+): Ansible remains a top choice for configuration management.
  • Use Ansible Automation Platform 2.4 or newer, which includes features like Event-Driven Ansible (for reactive filtering based on events), Execution Environments (for consistent and isolated automation runs), and certified content collections.
  • Always use Fully Qualified Collection Names (FQCNs) in your playbooks (e.g., `cisco.ios.ios_config` instead of `ios_config`) for clarity and compatibility.
• NETCONF/RESTCONF/gNMI: For more programmatic and model-driven interactions, these protocols are becoming standard.
  • NETCONF (RFC 6241 – version 1.1): A robust protocol for configuring network devices, often leveraging YANG data models.
  • RESTCONF: A RESTful API that works over HTTP(S) and also uses YANG data models, offering a simpler alternative to NETCONF for some use cases.
  • gNMI (gRPC Network Management Interface): A Google-developed protocol primarily used for high-frequency telemetry streaming and configuration, favored by modern cloud and service provider networks.

Infrastructure as Code & GitOps for BGP Filtering

Treating your network configuration as code, stored in a version control system like Git, is a fundamental shift for robust BGP filtering.

• Version Control (Git): All BGP filtering policies (prefix-lists, AS-path filters, route-maps) should be defined in text files and stored in Git. This provides a complete audit trail of who changed what, when, and why.
• CI/CD Pipelines: Implement Continuous Integration/Continuous Deployment pipelines.
  • Validation: Before deploying, automatically validate filter syntax, logical correctness, and impact (e.g., using a network simulator or a “dry run” with the device).
  • Deployment: Once validated, the changes are automatically pushed to devices using automation tools.
• GitOps: This methodology extends IaC by using Git as the single source of truth for declarative infrastructure. Changes to Git automatically trigger deployments and synchronization, minimizing human error and providing a clear rollback mechanism.

Advanced BGP Security: RPKI and BGPsec

Beyond basic filtering, the industry has developed advanced mechanisms to enhance BGP security, specifically targeting the origin validation and path validation of routes.

Resource Public Key Infrastructure (RPKI)

RPKI provides a way to verify the authenticity of announcements for IP address space and Autonomous Systems.

• Origin Validation: RPKI allows an Internet routing registry to digitally sign records called Route Origin Authorizations (ROAs). A ROA states which AS is authorized to originate a specific prefix.
• Implementation: Routers use a BGP Route Origin Validation (ROV) process to compare received BGP announcements against a local RPKI cache (maintained by RPKI Validators). This allows routes to be classified as VALID, INVALID, or UNKNOWN.
• Filtering with RPKI: Networks can then configure their BGP policies to prefer VALID routes, demote UNKNOWN routes, and discard INVALID routes, significantly reducing the risk of accidental or malicious route hijacks.

BGPsec

BGPsec is a security extension to BGP that provides cryptographic proof that an AS path is legitimate.

• Path Validation: Unlike RPKI which validates the *origin* of a route, BGPsec aims to validate the *entire path* that a BGP advertisement has traversed. Each AS along the path cryptographically signs the update before passing it on.
• Challenges: BGPsec requires significant computational overhead and widespread adoption to be fully effective, making its deployment slower than RPKI. However, it represents the future of truly secure BGP path validation.

BGP Filtering & Network Observability / AI-Powered NetOps

Simply applying filters isn’t enough; you need to know if they’re working as intended and if new threats are emerging.

• Real-time Monitoring & Telemetry: Shift from polling-based monitoring to streaming telemetry (e.g., using gNMI or NETCONF subscriptions) for immediate insights into BGP session states, route changes, and filter hits.
• Network Observability Platforms: Tools like Suzieq, Kentik, or open-source solutions allow you to collect, analyze, and visualize rich network data. This helps you:
  • Verify filter effectiveness in real-time.
  • Detect BGP anomalies, such as unexpected route withdrawals, new prefix announcements, or AS-path changes that bypass existing filters.
  • Understand the impact of filtering changes before and after deployment.
• AI/ML in NetOps: Artificial Intelligence and Machine Learning are increasingly applied to network operations:
  • Anomaly Detection: AI/ML algorithms can identify unusual BGP routing patterns (e.g., potential route hijacks or leaks) that might slip past static filters.
  • Predictive Analysis: Forecast potential BGP issues based on historical data.
  • Automated Remediation: In advanced stages, AI-driven systems could potentially trigger automated BGP filter updates or reconfigurations in response to detected threats (Event-Driven Automation).
  • Cisco DNA Center 2.3.5+, for instance, integrates AI/ML capabilities for network assurance and operations, which can extend to BGP health monitoring and anomaly detection.

Best Practices for BGP Filtering – Planning And Design

Aha! You’re now ready to take your BGP filtering to the next level! We’ll start with planning and design, the cornerstone of a successful BGP filtering implementation. Here’s what you need to keep in mind.

Defining BGP filtering requirements and goals:

Before you start, it’s important to know what you’re aiming for. Ask yourself, what kind of traffic do you want to allow or block in your network? This will help you determine the BGP filtering requirements and goals. It’s like deciding what kind of pizza you want to order before you pick up the phone – you want to make sure you get what you want! Consider also the role of your AS (stub, transit), peering agreements, and RPKI policy.

Identifying potential risks and threats:

Once you know what you want, it’s time to look for potential risks and threats. What kind of malicious traffic could your network be exposed to? Who do you need to protect your network from? It’s like looking out for the boogie man before you go to bed. You want to make sure you’re protected! This includes common BGP issues like route leaks, hijacks, and invalid origin AS.

Evaluating BGP filtering options:

Finally, it’s time to evaluate the different BGP filtering options available. What techniques and tools will best suit your needs? Which ones are the most secure and effective? It’s like trying on different outfits before you go out on a date. You want to make sure you look and feel your best! This evaluation should now heavily weigh automation platforms, IaC, RPKI integration, and modern telemetry capabilities.

So, that’s the planning and design stage done and dusted. Now it’s time to move on to the next step: implementation and deployment!

Best Practices for BGP Filtering – Implementation and deployment

Awesome, you’ve made it to the implementation and deployment stage! This is where the rubber meets the road, so let’s make sure we do it right.

Testing BGP filtering rules in a lab environment:

Before you deploy BGP filtering rules in a production environment, it’s important to test them in a lab environment first. This allows you to fine-tune the rules and make sure they’re working as expected. It’s like a dress rehearsal before a big performance. You want to make sure everything is perfect before you hit the stage! Leverage network emulation (e.g., EVE-NG, GNS3) or virtualized network functions to simulate your production environment. Automated testing scripts should be a core part of this process.

Monitoring BGP sessions and routes:

Once you’ve deployed the BGP filtering rules, it’s important to monitor the BGP sessions and routes to make sure everything is working as expected. You want to make sure your network is secure and that the filtering rules are having the desired effect. It’s like keeping an eye on your pizza in the oven to make sure it doesn’t burn! Integrate this monitoring with your network observability platform to detect anomalies quickly.

Documenting BGP filtering rules and policies:

Finally, it’s important to document the BGP filtering rules and policies so that others can understand what you’ve done and why. This makes it easier for others to maintain and update the filtering rules in the future. It’s like writing down a recipe for a delicious dish so that others can follow it and make it again. With IaC, your version-controlled code in Git becomes the primary documentation, supplemented by diagrams and explanations in a centralized knowledge base.

And that’s it! You’re now ready to deploy BGP filtering in your network. Just remember to stay vigilant and keep monitoring your BGP sessions and routes. The internet is a big and ever-changing place, so it’s important to keep your BGP filtering up-to-date.

Best Practices for BGP Filtering – Maintenance and updates

So let’s talk about maintenance and updates of your BGP filtering rules. This is an important aspect of BGP security that often gets overlooked, but it’s crucial to keep your network secure.

Regularly reviewing and updating BGP filtering rules

First, you should regularly review and update your BGP filtering rules. This will help you keep up with changes in your network, peering relationships, and global routing table dynamics, ensuring that your filtering rules are still effective in protecting against potential threats. Think of it like brushing your teeth – it’s a simple task that you should do regularly to keep things in check. Automation can help automate policy generation from a single source of truth, making reviews simpler and faster.

Testing BGP filtering rules after updates

Next, after you’ve made any updates to your filtering rules, it’s important to test them. This is like taking a sip of water after brushing your teeth – you want to make sure everything is working as it should. Testing your filtering rules in a lab environment before deploying them to your live network will help you avoid any unexpected issues and ensure that your network remains secure. Automated pre-checks and post-checks (e.g., using Netmiko/Scrapli to collect `show` commands and parse them) are vital for this.

Documenting changes and updates

Finally, it’s essential to document any changes and updates to your filtering rules. This is like writing down what you did at the dentist – you want to make sure you have a record of what you did in case you need to refer back to it later. Documenting changes and updates to your filtering rules will also help you keep track of what’s changed over time and ensure that everyone involved in managing your network is on the same page. With GitOps, this documentation is inherently part of your version control history.

Conclusion

Once you’ve set up your AS-Path filters, distribute-lists, and prefix-list filters, be sure to test them out in a safe environment before rolling them out live. It’s best practice to keep BGP traffic isolated from your general internal network traffic. Remember that less is more! Going overboard with overly complex filtering could potentially block legitimate routes from reaching the gateway. The goal is precise filtering, not over-filtering.

However, “less is more” for the *complexity* of individual filters, not the *breadth* of your security strategy. A modern BGP filtering strategy for 2025 demands a multi-pronged approach: foundational filters, integrated RPKI origin validation, and a robust automation pipeline built on Python 3.12+, Nornir/Scrapli, Ansible Automation Platform 2.4+, and GitOps principles. Complement this with real-time network observability and AI-powered anomaly detection to proactively secure your routing.

Hopefully, this post covered a little bit of everything. There’s a lot to consider when it comes to BGP, but don’t let that intimidate you. Every network has its own set of requirements, and there isn’t one solution that will work for everyone (at least not yet). By implementing some security best practices and using a combination of filters, advanced validation, and modern automation on your networks, you should be well on your way to filtering out the bad routes and keeping your data safe and sound!