Meraki NAT Exceptions and Inbound Firewall

This blog post focuses on 2 Meraki MX beta features, NAT Exceptions and Inbound Firewall. We will explain how to enable and configure them in your environment. The purpose is to provide extra means for you as a network or security technician to achieve smooth transition from other Cisco or third party firewalls to full-stack Meraki. 

Nat Exceptions (Beta)

Nat Exception or "No-NAT" is a feature designed for situations where you want certain traffic to bypass Network Address Translation on an MX security appliance. This is particularly useful when you have traffic that needs to maintain the original source IP address for proper routing or functionality, such as in a site-to-site VPN or MPLS topology. The NAT Exception allows specific internal IPs to send traffic without undergoing NAT, preserving the original source IP address. NAT is applied by default for traffic from LAN to WAN on an MX, but is disabled for traffic routed on the LAN side of the firewall (e.g. MPLS) or for Auto-VPN traffic.

Prerequisite

Meraki support needs to be contacted via phone to enable this feature. 

Configuration

After Meraki support has enabled the feature on your network, you can configure it by following these steps. Check Figure 1 for more details. 

• Navigate to Security & SD-WAN > Addressing and VLANs.
• At the bottom of the page you will find NAT Exceptions
• Choose the uplink where you want to disable NAT
• Choose if you want to Override NAT per VLAN, in case you have several VLANs
• Override the NAT Config per VLAN if it has to be different based on the uplink

Fig 1. Example of Nat Exception configuration

Note

Remember that exempting NAT will affect all traffic going out through the specific uplink, which could potentially disrupt internet traffic for all your internal networks. 

Inbound Firewall (Beta)

The Inbound Firewall feature provides extra flexibility for your Meraki MX security appliance. This feature allows you to specify which inbound connections from the WAN to the LAN are permitted. The default behavior in an MX WAN is to allow returning LAN traffic (established) and any traffic which has been forwarded via NAT rules. The rest is blocked by default. Inbound Firewall rules are particularly useful when you want to limit the incoming traffic to specific IP addresses and/or ports, providing a higher level of granularity for your specific needs. 

Prerequisite

Same as with NAT Exceptions, Meraki support needs to be contacted via phone to enable the feature. 

Configuration

Navigate to Security & SD-WAN > Firewall. 

Two new sections for Layer 3 Inbound Rules and Inbound cellular failover rules have been added to the configuration. 

The configuration is pretty straight forward. 

• Policy: Allow or Deny
• Description: Provide a description of the rule.
• Protocol: TCP/UDP/ICMPv4/v6 or Any
• Source IP/Network
• Source Port
• Destination IP/Network
• Destination Port

Fig 2. Example of Inbound Firewall configuration

A few notes

The rules are limited to inbound traffic from WAN/Cellular in their respective sections. This can not be used for traffic between vlans or routed on the inner side of the firewall. In that case, outbound rules must be used. 

After enabling Inbound Firewall, all inbound traffic through the WAN/Cellular is allowed by default, so it's crucial to implement layer 3 firewall rules immediately to prevent potential security breaches. Warnings appear on both the Inbound Firewall and Security Appliance sections. 

Warning: Cisco Meraki Support has enabled the use of custom layer 3 inbound firewall rules which defaults to "allow all" behavior unless configured otherwise. Settings previously designated under "Security appliance services" should be configured as explicit firewall rules (e.g. adding a rule to block TCP over port 80 to restrict access to the local status page). We recommend that you configure layer 3 inbound rules to whitelist authorized network routes and append a "deny all" rule to avoid exposing Meraki host services.

Security Appliance Services: Normally, these fields control what services are available from remote IPs, e.g., ICMP ping, web (local status & configuration), and SNMP. However, because Cisco Meraki Support has enabled the use of custom layer 3 inbound firewall rules on this network, remote access to security appliance services will be restricted according to the layer 3 inbound rules configured above.

Use Cases

Depending on your current scenario and problem you are trying to solve, it can be handy to have some extra enterprise features like NAT Exception and Inbound Firewall in a Meraki MX. While the MX appliance running in Routed(NAT) mode is often associated with edge or WAN-side functionality (including acting as an Internet gateway, providing VPN functionality, and serving as a firewall), it can also be effectively used within the LAN for purposes like network segmentation. It can enforce security policies and control access between different VLANs or network segments, effectively acting as an internal firewall. This combined with IDS/IPS, Advanced Malware Protection and URL filtering will block the attacks very close to the source. 

Is this supported?

Since these are beta features, there is some risk for them to be unstable. The NAT Exceptions appeared already back in the beta version 15.4, so it has been there for a while.Several scenarios have been tested in my lab environment and no unexpected results have been encountered. Meraki supports by default the most recent Beta releases of their software as well as older versions with best effort.

Conclusions

While the Nat Exceptions and Inbound Firewall features offer greater flexibility and control, they can potentially expose your internal resources or disrupt your services if not configured properly. Always plan and assess your network needs carefully, considering both functionality and security when you decide. 

References

General MX Best Practices

MX and MS Basic Recommended Layer 3 Topology - Cisco Meraki

Read More

Meraki Security Baseline

Network security is an essential aspect of any organization, and with the increasing threat of cyber-attacks, it is imperative to ensure that the firewall security features are enabled and functioning correctly. However, manually checking the security status of firewalls can be a time-consuming task, especially when dealing with multiple firewalls across multiple organizations. This is a challenge that most Managed Service Providers like ourselves face. The purpose of this blog post is to start building a security baseline, which can help standardize and audit security configurations on customers based on the MX Security Best Practice Design document published by Cisco Meraki. In this post, we will go over the steps to accomplish this using Python.

Overview of the Script

The script uses the Meraki REST API to check the security settings of MX firewalls in a list of  organizations. The script reads the API keys and org IDs from a file, and then retrieves the list of networks for the selected organization. It filters the list to find the MX firewalls and then retrieves the license edition, anti-malware, intrusion prevention and IP spoofing protection settings for each firewall. The results are displayed in a table format, showing the organization name, network name, license edition, anti-malware status, intrusion prevention status and spoof protection status. 

Prerequisites

• A Meraki Dashboard account with API access enabled
• Python 3.x installed
• The 'requests' and 'prettytable' libraries installed
• A file containing the API keys and organization IDs of the Meraki organizations to be checked

The Code

The code consists of the following steps:

1. Import the necessary libraries, including the 'requests' library for making API calls and the 'prettytable' library for generating a table to display the results.
2. Read the file containing the API keys and organization IDs of the Meraki organizations to be checked.
3. Use the Meraki APIs to retrieve the list of networks in each organization.
4. Filter the networks to find Meraki MX firewalls.
5. For each firewall, make API calls to obtain the license edition, anti-malware, intrusion prevention, and spoof protection settings.
6. Format the results as a table, with the organization name, network name, license edition, anti-malware status, intrusion prevention status, and spoof protection status as columns.
7. Print the table.

The end result will look like this:

Fig.1 Table with list of controls

Here comes the full script, which is also published on GitHub: Meraki-Security-Baseline. Comments under each section should give you an idea on what each part of the code is doing. 

import requests
from prettytable import PrettyTable
table= PrettyTable()

# API endpoint for organizations
org_url = 'https://api.meraki.com/api/v1/organizations'

# API endpoint for firewalls
fw_url = 'https://api.meraki.com/api/v1/networks/{}/appliance/'

# Read the file containing the API keys and org IDs
with open("C:/MerakiAutomation/api_keys_org_ids.txt", "r") as f:
    lines = f.readlines()
    print(lines)

# Create a table header
table.field_names = ["Organization", "Network", "License Edition", "Anti-Malware", "Intrusion Prevention", "Spoof Protection"]
table.align["Organization"] = "l"
table.align["Network"] = "l"
table.align["License Edition"] = "l"
table.align["Anti-Malware"] = "l"
table.align["Intrusion Prevention"] = "l"
table.align["Spoof Protection"] = "l"

# Loop through each line in the file
for line in lines:
    api_key, org_id = line.strip().split(",")

    # Get list of networks for the selected organization
    networks_url = f"https://api.meraki.com/api/v1/organizations/{org_id}/networks"
    response = requests.get(networks_url, headers={'X-Cisco-Meraki-API-Key': api_key})
    networks = response.json()

    # Filter the networks to find MX firewalls
    mx_firewalls = [network for network in networks if network['productTypes'][0] == 'appliance']

    # Loop through the firewall list
    for firewall in mx_firewalls:

         # Get the organization name
        org_response = requests.get(f"{org_url}/{org_id}", headers={'X-Cisco-Meraki-API-Key': api_key})
        org = org_response.json()
        org_name = org['name']

        
        # Network Name
        network_name = firewall['name']

        # Get the current license version for the MX
        licenses_response = requests.get(f"{org_url}/{org_id}/licensing/coterm/licenses/", headers={'X-Cisco-Meraki-API-Key': api_key}).json()
        license_edition = "Enterprise"
        for item in licenses_response:
            counts = item.get('counts')
            for count in counts:
                if count.get('model').startswith('MX'):
                    editions = item.get('editions')
                    for edition in editions:
                        if 'Advanced Security' in edition.get('edition'):
                            license_edition = 'Advanced Security'
                        break

        # Get anti-malware settings
        fw_url_antimalware = (fw_url + "security//malware")
        firewall_settings = requests.get(fw_url_antimalware.format(firewall['id']), headers={'X-Cisco-Meraki-API-Key': api_key}).json()
        anti_malware_enabled = firewall_settings['mode']

        # Get intrusion prevention settings
        fw_url_intrusion = (fw_url + "security//intrusion")
        firewall_settings = requests.get(fw_url_intrusion.format(firewall['id']), headers={'X-Cisco-Meraki-API-Key': api_key}).json()
        if 'mode' in firewall_settings:
            intrusion_prevention_enabled = firewall_settings['mode']
        else:
            intrusion_prevention_enabled = "Not Supported"
    
        # Get Ip Spoof Protection settings
        fw_url_spoof = (fw_url + "firewall//settings")
        firewall_settings = requests.get(fw_url_spoof.format(firewall['id']), headers={'X-Cisco-Meraki-API-Key': api_key}).json()
        spoof_protection_enabled = firewall_settings['spoofingProtection']['ipSourceGuard']['mode']
        
        # Add rows to the table
        table.add_row([org_name, network_name, license_edition, anti_malware_enabled, intrusion_prevention_enabled, spoof_protection_enabled ])

# Print the results
print (table)

Future work

Please note that this script is the first version of our Meraki baseline security checks, which will be expanded in the future. I plan to include additional controls from Cisco Meraki's Best Practice Design for MX Security. 

Conclusion

In conclusion, the script provides a quick and easy way to check the security configuration and license of all the MX firewalls in different organizations, saving time and reducing the chances of security configuration issues going unnoticed. As a best practice, it is recommended to run this script on a regular basis to ensure that the firewall security configurations remain consistent and secure.

References

Introduction - Meraki-Dashboard-API-v1-Documentation - Document - Cisco DevNet

Best Practice Design - MX Security and SD-WAN - Cisco Meraki

prettytable · PyPI

Read More

My Own Path to CCIE: Maximizing Chances of Success and Enjoying the Benefits

    The CCIE Enterprise Infrastructure certification is without any doubt one of the most highly desired certifications in the field of networking. It's a testament to one's knowledge, experience, and expertise in the field of enterprise networking. In this blog post, I'll be sharing a few thoughts on my experience with CCIE and the advantages that come with this certification.

Fig.1 The CCIE kit

The path to success

    I started this journey back in 2015 in Albania with CCIE R&S, but due to the job profile and some potential contacts with service providers, decided to switch to SP after passing the written exam of R&S. I took the exam in Brussels on 15 May 2015 and failed. Back then, the exam had a single module lasting 8 hours with a 30 minutes break for lunch. I believe my failure is mostly related to speed, as I ran out of time before I could go through all the questions. After that, I learned a few tricks, which I used during the Enterprise Infrastructure:

• Practice speed. Not only you should have a deep understanding of the technologies, best practices and methodologies, but you should also show that you can implement them quickly without mistakes.
• Attack the problems from different angles. Don't limit yourself to finding a single solution for each problem. Many questions in the exam are quite restrictive in what you are allowed to do. You might need to find a different solution to comply the restrictions.
• Notepad is your friend. A lot of tasks back then were repetitive, and this is also relevant today. It can help you avoid mistakes and save time. Every second you spare on the exam is going to count when the clock ticks at the end of the exam.

    With this experience I had back in 2015, and a few changes in my private life over the years, it took me quite some time to get back on track. But then on summer 2021 I couldn't wait anymore. Parenting was getting easier, my team was covering my back at work and my wife my absence at home. I booked my CCIE Enterprise Infrastructure exam for 20 July 2022 in a mobile lab in Copenhagen.

    The next few months a lot of my free time was dedicated to reading, practicing and watching videos. To ensure that I was well-prepared, I took a couple of weeks off before the exam date, during which I focused exclusively on studying and preparing for the exam.

    Finally, the big day arrived, and I confidently drove towards the mobile lab in Copenhagen, ready to take on the challenge of the CCIE Enterprise Infrastructure exam. I arrived at the mobile lab in Copenhagen about an hour earlier than the scheduled exam time. I decided to take a walk around the nearby harbor to take some fresh air, clear my mind and calm my nerves. Then I went towards the exam hall. The rest of the day was a mix of excitement, stress, depression, happiness and finally accomplishment. The day after, this mail arrived:

Fig. 2 The confirmation mail

    I was so excited about the end result, that I didn't read the email I received from Cisco Training carefully, and forgot to confirm my information on my profile, which delayed the delivery of the certification kit by about 3 months.  

What are some of the advantages you get from the certification?

    CCIE Enterprise Infrastructure certification not only certifies an individual's expertise in the field of enterprise networking, but it also provides numerous benefits and opportunities. Here are some of the most important ones: 

• Increased knowledge and skills: The certification requires extensive study and a lot of hands-on work. This leads naturally towards a deeper understanding of the technologies and best practices.
• Networking Opportunities: It opens doors towards the community, both via social platforms, but also through events organized by Cisco. You get the chance to share what you learn with others, but also develop yourself though the knowledge you ingest from them.
• Professional Growth: Being part of such an exclusive community and meeting with so many professional people is going to help in the process of developing your own career. 

Is it still worth it, even though it's a 30-year-old certification?

    I had the opportunity to join an event "CCIE in an SDN World" last week, where there was some discussion about developments of CCIE and the impact that automation and SDN is having on the network engineers nowadays and if we are all going to be replaced by AI/ML. Since I've been through the certification process recently, here are my takes:

• CCIE evolves: The field of networking is constantly evolving, and CCIE certified professionals are equipped to adapt to new technologies and stay ahead of the curve. We are in a process of upgrading and evolving our own skills together with the exam.
• Industry Demand: Despite advancements in automation and AI, the demand for skilled network engineers remains high. Even though platforms like ChatGPT are having a large success in adaptation in different fields, you still need to interact with them. If you don't have the knowledge and the skills, how would you instruct the AI platform?
• Are we that evolved? I still use CLI myself daily, even though I'm learning more and more automation and programmability. Don't you?

Conclusion 

    Obtaining a CCIE Enterprise Infrastructure certification is still a valuable and relevant accomplishment in today's ever-evolving world of networking. It requires extensive preparation, which leads to increased knowledge and skills in the field. Not only does it offer opportunities for professional growth, but it also opens doors for networking and community building. Despite advancements in automation and AI, the demand for skilled network engineers remains high, and CCIE certified professionals are equipped to adapt and stay ahead of the curve. So, the journey may be challenging, but the reward of obtaining the CCIE Enterprise Infrastructure certification is worth it. 

Bonus question: Do you know the first 3 CCIE numbers?

Fig. 3 The first 3 CCIE's (Credit: Jeff McLaughlin)

#1024 - The lab

#1025 - The lab creator: Stuart Biggs

#1026 - Terrance Slattery 

Read More

Azure Security - Overview based on AZ-500

    This post is a review of Azure Security, based on the training provided during the Security Cloud Week for Partners, with focus on the AZ-500 track. I've spent a lot of time on testing different security features based on the labs provided. My initial plan was to subscribe to the SC-100 track, but the lack of labs on that track made me change direction towards AZ-500. 

What does AZ-500 cover?

    The exam covers all aspects of cloud-based security in Microsoft Azure, including protection of identity, access, data, applications and networks. The rich amount of security features is tied closely to the MITRE ATT&CK® framework, which basically describes all the techniques used by modern day security threats. This is a more detailed version of the Cyber Kill Chain developed by Lockheed Martin. The purpose is to master all aspects of Azure security in order to offer protection from all the different steps and techniques used by an attacker. You can learn more about the mapping between Azure Security and MITRE framework on this article. 

Identity and Access (30-35%)

    The first thing you have to master is identity and access protection. This part has a lot of focus on Azure AD and hybrid identity protection. You have to master things like conditional access, Multi-Factor Authentication, access reviews etc. Once you have mastered all the security related features, you might wonder which ones you should activate for your organization. Microsoft has provided a document describing the security best practices which might come handy. You can find it here.

Implement Platform Protection (15-20%)

    The platform consists of infrastructure and network resources running on Azure. The purpose here is to harden the infrastructure as much as possible, so that we are better protected when the actual attack happens. Topics to master include implementation of security on the perimeter, network, hosts and containers. I've had some challenges with Containers security especially, due to my limited experience with containers, so I expect to put more focus on that part in the near future. If you are implementing platform protection in your environment, you might want to consider best practice articles provided by Microsoft like these: network security, container security.

Secure your data and applications (25-30%)

    Here you will learn a lot about Azure Key Vault, storage, applications and SQL security. The purpose is to protect access to applications, and secure data on rest or in transit. The exam focuses particularly on the Azure Key Vault and overall secret and keys protection. Once you have mastered all the topics you can read what is considered best practice in terms of securing data and applications on these articles: SQL, Key Vault, Applications

 Manage Security Operations (25-30%)

    Now once you have found out how to protect identity, access, platform, data and applications, you need some way to operate all this security posture you have built. Azure has 3 main tools to simplify operations, basically Azure Monitor, MS Defender for Cloud and Sentinel. AZ-500 helps you with exploring all the features available, but within a limited scope. Sentinel as an example requires much more focus than what is given on the exam. I've found some best practice article on Sentinel here.

Implementation considerations

  One way to implement security is to master all the aspects of the platform provided by Azure and follow their best practice documents. Depending on the specific task or project, you might need to have more focus on specific aspects, but as long as you use their recommendations and best practice documents, you should be good. Operations itself is simplified by all the tools and benchmarks that are already built into the platform. 

  Another approach most companies use to streamline their security is by implementing standard controls, like NIST, CIS etc. Azure has a lot of these regulatory compliance controls built into the Defender for Cloud. You could though make your own decisions and start with the standard itself. If you decide to implement CIS, it can be helpful to use the security guideline built by Microsoft in collaboration with them. You can find it here. It contains all the steps necessary for auditing and implementing the technical CIS controls. 

Conclusion

  Security in Azure and Microsoft generally might be a bit overwhelming due to the large amount of tools, dashboards, manuals. Microsoft is working constantly on simplifying the baseline configurations and consolidating the dashboards, but it's still a work in progress. I've found that attending trainings regularly, reading their best practice documentation and testing as many features as you can is pretty helpful in regard to building the knowledge needed to manage most aspects of security. 

Read More

BGP Filtering Techniques

 

This article describes 3 different techniques to filter inbound BGP routes.

    Let's consider a scenario where we have 2 different companies. The first company has its own DC running OSPF internally with everything in area 0, its own ASN and BGP peering to ISP A. The second company has another DC, which is also running OSPF internally in area 0, with a different ASN and BGP peering to ISP A. 

Fig.1 Topology

    The first company acquires the second one, and we face the challenge to connect the 2 DC environments to each other. As part of the design, we decide to establish direct fiber between the companies. Once this is in place, we would like to have all traffic between the DC's to use this link, instead of going through ISP A. However we notice that the routes from the 80.80.0.0/16 address space learned through BGP and redistributed into OSPF take precedence over the OSPF learned routes. 

    In order to resolve this issue, we need to have some mechanisms in place that prevents routes announced from DC1 to ISP A via eBGP to be learned via BGP and injected back into OSPF in the DC2 and vice versa. You can find the lab file at the end of this post. 

Method 1:  The traditional way of doing it

    The first option is probably also the most obvious. We filter the inbound BGP routes with a prefix-list and a route-map. Let's check how routing towards the public IPv4 subnets looks like in the DC's first. 

R1-DC01# show ip route 80.80.200.0
Routing entry for 80.80.200.0/24
  Known via "ospf 1", distance 110, metric 1
  Tag 65100, type extern 2, forward metric 20
  Last update from 10.100.12.2 on Ethernet0/0, 00:03:57 ago
  Routing Descriptor Blocks:
  * 10.100.12.2, from 10.100.100.2, 00:03:57 ago, via Ethernet0/0
      Route metric is 1, traffic share count is 1
      Route tag 65100

R2-DC01# show ip route 80.80.200.0
Routing entry for 80.80.200.0/24
  Known via "bgp 65001", distance 20, metric 0
  Tag 65100, type external
  Redistributing via ospf 1
  Advertised by ospf 1 subnets
  Last update from 100.100.23.3 00:04:42 ago
  Routing Descriptor Blocks:
  * 100.100.23.3, from 100.100.23.3, 00:04:42 ago
      Route metric is 0, traffic share count is 1
      AS Hops 2
      Route tag 65100

R5-DC02#show ip route 80.80.100.0
Routing entry for 80.80.100.0/24
  Known via "bgp 65002", distance 20, metric 0
  Tag 65100, type external
  Last update from 100.100.45.4 00:10:10 ago
  Routing Descriptor Blocks:
  * 100.100.45.4, from 100.100.45.4, 00:10:10 ago
      Route metric is 0, traffic share count is 1
      AS Hops 2
      Route tag 65100

R6-DC02#show ip route 80.80.100.0
Routing entry for 80.80.100.0/24
  Known via "ospf 1", distance 110, metric 1
  Tag 65100, type extern 2, forward metric 20
  Last update from 10.200.56.5 on Ethernet0/0, 00:00:17 ago
  Routing Descriptor Blocks:
  * 10.200.56.5, from 10.200.200.5, 00:00:17 ago, via Ethernet0/0
      Route metric is 1, traffic share count is 1
      Route tag 65100

    So, we have 2 problems. Edge routers R2 and R5 are injecting the BGP route due to the lower administrative distance of BGP, while the core routers R1 and R6 are injecting it because the metric for the redistributed route from BGP to OSPF is "1", unless if specified manually. We implement the following prefix list and route map on R2 and R5 and apply it to the peering towards R3 and R4 in the inbound direction. 

R2-DC01#
ip prefix-list INTERNAL seq 10 permit 80.80.0.0/16 ge 24
route-map FILTER-IN deny 10
 match ip address prefix-list INTERNAL
route-map FILTER-IN permit 20

router bgp 65001
 bgp log-neighbor-changes
 neighbor 100.100.23.3 remote-as 65100
 address-family ipv4
  network 80.80.100.0 mask 255.255.255.0
  neighbor 100.100.23.3 activate
  neighbor 100.100.23.3 route-map FILTER-IN in


R5-DC02#
ip prefix-list INTERNAL seq 10 permit 80.80.0.0/16 ge 24
route-map FILTER-IN deny 10
 match ip address prefix-list INTERNAL
route-map FILTER-IN permit 20

router bgp 65002
 neighbor 100.100.45.4 remote-as 65100
 address-family ipv4
  network 80.80.200.0 mask 255.255.255.0
  neighbor 100.100.45.4 activate
  neighbor 100.100.45.4 route-map FILTER-IN in

Now let's have a look at the routing table, just to be sure. 

R1-DC01#show ip route 80.80.200.0
Routing entry for 80.80.200.0/24
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 10
  Last update from 10.100.200.6 on Ethernet0/1, 00:05:04 ago
  Routing Descriptor Blocks:
  * 10.100.200.6, from 10.200.200.6, 00:05:04 ago, via Ethernet0/1
      Route metric is 20, traffic share count is 1

R2-DC01#show ip route  80.80.200.0
Routing entry for 80.80.200.0/24
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 20
  Last update from 10.100.12.1 on Ethernet0/0, 00:05:45 ago
  Routing Descriptor Blocks:
  * 10.100.12.1, from 10.200.200.6, 00:05:45 ago, via Ethernet0/0
      Route metric is 20, traffic share count is 1

R5-DC02#show ip route 80.80.100.0
Routing entry for 80.80.100.0/24
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 20
  Last update from 10.200.56.6 on Ethernet0/0, 00:08:54 ago
  Routing Descriptor Blocks:
  * 10.200.56.6, from 10.100.100.1, 00:08:54 ago, via Ethernet0/0
      Route metric is 20, traffic share count is 1

R6-DC02#show ip route 80.80.100.0
Routing entry for 80.80.100.0/24
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 10
  Last update from 10.100.200.1 on Ethernet0/1, 00:09:50 ago
  Routing Descriptor Blocks:
  * 10.100.200.1, from 10.100.100.1, 00:09:50 ago, via Ethernet0/1
      Route metric is 20, traffic share count is 1

    As you can see from the routing tables, we are now using the direct link between the DC's, just as we wanted it. This solution comes though with the challenge of keeping the prefix-list updated. Easy, right? Until when you spend hours trying to find and update some prefix-list or ACL somewhere in the network. 

Method 2:  The well known attribute

    Even though the first method solves the design requirement, we have the challenge of keeping the prefix-list updated. Since we have 1 AS for each DC, we could do the filtration based on the BGP well known attribute ASN. Instead of building a route-map, we just need to create an as-path filter and apply it directly to the peer with a filter list. Let's make it happen. 

Here is how the configuration looks like:

R2-DC01#
ip as-path access-list 1 deny ^65002$
ip as-path access-list 1 permit .*

router bgp 65001
 address-family ipv4
  neighbor 100.100.23.3 filter-list 1 in
 exit-address-family

R5-DC02#
ip as-path access-list 1 deny ^65001$
ip as-path access-list 1 permit .*

router bgp 65002
 address-family ipv4
  neighbor 100.100.45.4 filter-list 1 in

    The end result is the same. The routes containing AS 65002 in the as-path are filtered inbound on R2 and the ones containing AS 65001 are filtered inbound in R5. The final routing table looks exactly the same as the final one on method 1. This method is widely adapted, but we just need to keep in mind that it will filter any routes containing the respective AS on the path. 

 

Method 3: Some magic?

    Well let's say that managment doesn't like route-maps, acl's or filter lists, and they want the whole config to be done within the BGP process. Typical manager, right?  Just find a solution and fix it.

    However, we can use a magic trick, local-as, which makes us appear as if we were members of another AS than the actual one. We will implement the changes on DC2. This is very handy in cases of acquisitions, where we don't want to change our original peering agreements. 

    After the local-as configuration is applied, both the real ASN and the local-as are added to the AS path. In our case, routes transiting ISP A, would have both AS 65001 and 65002 when they reach DC1. The BGP loop prevention mechanism would then drop advertisements inbound on DC01, since the local ASN is part of the AS_Path in a route received through eBGP. Let's have a look at the configuration that is necessary to make this happen. 

First, let's look at the advertisements on R2 and R5:

R2-DC01#show ip bgp 80.80.200.0
BGP routing table entry for 80.80.200.0/24, version 13
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  65100 65002
    100.100.23.3 from 100.100.23.3 (100.100.100.3)
      Origin IGP, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0

R5-DC02#show ip bgp 80.80.100.0
BGP routing table entry for 80.80.100.0/24, version 22
Paths: (1 available, best #1, table default)
  Not advertised to any peer
  Refresh Epoch 1
  65100 65001
    100.100.45.4 from 100.100.45.4 (100.100.100.4)
      Origin IGP, localpref 100, valid, external, best
      rx pathid: 0, tx pathid: 0x0

    So in this case we see only the ASN of ISP A and the one from the other DC. In order to implement the solution, we need to change the BGP process id on R5, and configure the local-as for the peering towards R4. 

The final config on R5 looks like this:

R5-DC02#show run | se router bgp
router bgp 65001
 bgp log-neighbor-changes
 neighbor 100.100.45.4 remote-as 65100
 neighbor 100.100.45.4 local-as 65002
 !
 address-family ipv4
  neighbor 100.100.45.4 activate
 exit-address-family

    In order to verify the presence of both AS65001 and 65002 on the route advertised from R5, we can use the ISP routers R3 or R4. We can also check that the routes for the 80.80.x.x are no longer pointing towards ISP A on R2 and R5. 

R3-ISP# show ip bgp 80.80.200.0
BGP routing table entry for 80.80.200.0/24, version 17
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     10
  Refresh Epoch 1
  65002 65001
    100.100.34.4 from 100.100.34.4 (100.100.100.4)
      Origin IGP, metric 20, localpref 100, valid, internal, best

R2-DC01#show ip route 80.80.200.0
Routing entry for 80.80.200.0/24
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 20
  Last update from 10.100.12.1 on Ethernet0/0, 00:11:02 ago
  Routing Descriptor Blocks:
  * 10.100.12.1, from 10.200.200.6, 00:11:02 ago, via Ethernet0/0
      Route metric is 20, traffic share count is 1

R5-DC02#show ip route 80.80.100.0
Routing entry for 80.80.100.0/24
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 20
  Last update from 10.200.56.6 on Ethernet0/0, 00:10:07 ago
  Routing Descriptor Blocks:
  * 10.200.56.6, from 10.100.100.1, 00:10:07 ago, via Ethernet0/0
      Route metric is 20, traffic share count is 1

Conclusion

    We looked at 3 different ways to filter inbound eBGP advertisements and routes, route-maps and prefix-lists, as-path acl and filter-lists, and the magic trick with local-as. All three methods have their ups and downs, but the end result is the same in our specific scenario. 

References

Configuring the BGP Local-AS Feature - Cisco

Cisco Content Hub - BGP 4 Prefix Filter and Inbound Route Maps

Lab

EVE-NG Community lab based on iOL L3 images

Read More