The evolution of switches

The evolution of switches: #cissp insight

Did you know that switches were already introduced in the 19th century? Voice switches, also known as circuit switches, were the backbone of communication networks. Invented in the late 19th century, these switches established a dedicated circuit between two points for the duration of a call. While effective, this method was resource-intensive, limiting the number of simultaneous calls that could be handled. Early switches required also significant human intervention for line establishment, posing security and reliability challenges. In the next sections, we will deep dive into the most important elements of switches and the security concerns we have today. 

Fig.1 The transition from voice switching to packet switching

When did it all start?

The 1970s and 1980s marked the beginning of a new era with the introduction of packet switching, a concept which initially began with the invention of ARPANET, the predecessor of the modern internet. Unlike circuit switching, packet switching sends data in smaller packets through various routes before reassembling at the destination. This approach optimizes network efficiency and resource utilization. 

Our office museum has a telephone switchboard, which you can see at the following picture:

Fig.2 Office museum telephone switchboard

Why packet switching?

1. Improvement of efficiency: Packet switching allows multiple communications to share the same network bandwidth, significantly enhancing network efficiency compared to the dedicated paths of voice switching. If you were to compare it to a transition that is happening today, it would be the switch over from dark fiber to MPLS and later on to SD-WAN. 
2. Scalability: As the demand for data services grew, packet-switched networks proved to be highly scalable, accommodating more users and diverse data types without the need for expansion of the underlying infrastructure. 
3. Cost Optimization: The shared network approach of packet switching reduces operational costs. It eliminates the need for dedicated circuits for each communication, lowering both capital and maintenance expenses. This is also similar to the transition to SD-WAN. 
4. Additional capabilities: The switchover meant that the traditional circuits would also open up for other kinds of traffic than voice, which is basically what happened in the next few years.
5. Resilience and Flexibility: Together with opening for other kinds of traffic, new capabilities were also introduces, like the ability of packet-switched networks to reroute data through multiple pathways, which enhances network resilience against failures and congestion.

What has changed?

Since then a lot of things have changed. Today we have an unthinkable transmission speed, from a few bps to gigabit or terabitps speeds. The initial packet switches didn't have any modern protocols supported, like MPLS, QoS etc. Their main purpose was to do basic data routing. Today we can see switches that also do dynamic routing, switching, have firewall capabilities and even VPN or IDS features. With the recent developments of AI we expect more machine learning and predictive analytics functionality, as well as possibility to automate troubleshooting and optimize networks. It will also help with securing that these systems are configured in alignment with the organization security policies. 

What are some of the most common attacks against switches?

As this is a CISSP focused post, it's normal to discuss the security aspect. Historically the focus was in external threats to the company, but now we need to implement zero-trust principles as internal threats are equally important.

Fig 3. Switch Security

 Some of the security concerns we face today are:

1. MAC flooding, which basically is going to fill the MAC address table of the switch, causing it to become a hub and broadcasting packets to all ports. A hacker could sit on one of the ports and mirror the traffic to his PC. 
2. ARP poisoning. In this case, the hacker would send a fake ARP response over a local area network to behave as if they were one of the legitimate hosts. Years ago I experimented with an old rooted android phone. By using an app to poison ARP, I was able to hijack sessions and change all pictures on all websites that my colleagues visited at the office. Fun times...
3. VLAN hopping. The hacker would add some extra VLAN tag to the packet, so that when the actual vlan tag was removed, the switch would see this hacker tag and send the traffic to a different VLAN than the original one. 
4. STP manipulation. Knowing how Spanning Tree does the root bridge election, the hacker would install a switch in the network and make it the root bridge, which would then send all traffic through it. This can be a devastating attack and can happen also due to a mistake. I've experienced shortage on multiple cities many years ago, because some misconfigured switch was connected by some end customer to the ISP network. Then the traffic for all those cities would tend to go through this single location and get black holed. This would come handy to a potential attacker, as all traffic would go through their switch, and they would have the possibility to perform Man in the Middle attacks. 
5. DoS and Vulnerabilities. The attacker could either overload the switch with traffic, or exploit some vulnerability. Vulnerabilities have more and more focus nowadays, considering the increasing threat landscape.

How do we mitigate them?

There are several mechanisms we can use to protect our switches. Here come some of the most important ones:

1. Port Security. This is one of the first things that should be implemented in a modern network. Unauthorized devices should be prevented to connect to a network and the amount of MAC addresses learned through the ports should be limited, to avoid MAC flooding. 
2. Dynamic ARP inspection. To prevent poisoning of ARP and the possibility to hijack sessions like explained on point 2 above, ARP packets should be inspected, and the invalid ones should be blocked.
3. Secure VLANs. There are several things to consider, but default and native VLANs should not be used, and access lists should be implemented to isolate traffic between networks. 
4. STP Root Guard and BPDU Guard. These mechanisms would prevent an unknown switch from connecting to our network and making devastating changes, like the ones explained on point 4 above.
5. Regular updates. The only way to protect from vulnerabilities is to keep the software updated and reduce our exposure. Back in the old days, it was normal to brag about how many years a Cisco device had been on for. This is no longer an option today, and in the best case it should be mentioned as something to avoid. We still face gaps in this area when we analyze customer networks. The best option would be to implement switches that can be updated automatically. 
6. Network Segmentation. The network should be divided to smaller subsets, like VLAN's and private VLANs. Furthermore, the traffic between these subsets should be limited by access lists. Ideally, the network should filter by TCP/UDP port and IP. 

There are many more mechanisms that can be implemented to increase security, which we will not address on this post, but having most of what is mentioned here in place is a good first step towards securing the internal domain. 

Conclusion

The modern day switches come from an invention that started back in the 19th century. Since then a lot has happened, which testifies the human effort and desire to improve. It also reflects an adaptation to the growing demands of a digitally connected world, offering improved efficiency, scalability, and expansion of communication capabilities. The introduction of AI is going to push further into the simplification and increase of capabilities towards a more digitized world, as well as simplify the secure implementation of them in accordance to the company policies. It will also pose new security risks, which we need to address. It's important to implement security with zero trust principles and take extra steps to secure the internal domain. 

References

(ISC)2 CISSP Certified Information Systems Security Professional Official Study Guide: CISSP Domain 4: Communication and Network Security

General MS Best Practices - Cisco Meraki

Image courtesy: DALL-E

Read More

Meraki Source NAT and IP aliases

Meraki Source NAT and IP Aliases Features: An Overview

This post provides a look into Meraki's NAT for inter-vlan traffic. There have been some rumors in the forums discussing this feature, but since it's still a hidden/beta feature, there is no documentation available, which is why I decided to write about it. 

What is Source NAT? (Beta)

In simple terms, Source NAT is a mechanism that modifies the source IP address of traffic as it moves between domains, whether it's between LAN and WAN, VLANs or VPN sites. This is particularly beneficial in environments where there's a need to mask the original source or destination IP address of a device in one domain when communicating with devices in a different domain.

What is IP Alias? (Beta)

I like the fact that Meraki has decided to call this IP Aliases, as it's basically destination NAT combined with Proxy ARP. Our traffic would be destined to an IP within our current VLAN, which is not in use, and the Meraki firewall will translate the destination to an IP in another VLAN. The MX will respond to ARP requests as if the IP was assigned to it (Proxy ARP). 

Activating the Features

Since they're beta features, both inter-VLAN Source NAT and IP Alias aren't immediately accessible. To enable them, you need to:

1. Contact Meraki Support.
2. Express interest in the beta feature and explain the specific scenario you are willing to solve. 
3. Wait for it to be activated on your dashboard.

Remember, beta features are still under testing, so ensure you have proper backups and testing procedures before implementing them in production environments.

Configuring Source NAT and IP Alias on Meraki

Once the features are activated, the configuration is quite straightforward:

1. Navigate to the Meraki Dashboard: Log in and choose the network you want to configure.
2. Go to the Security & SD-WAN -> Addressing & VLANs and choose the specific VLAN, in our previous example we would choose the red VLAN. 
3. Hit Next on the first 2 screens related to generic VLAN config and IPv4 config, and you will reach the section on figure 2. 
4. Enable Source NAT traffic and pick the Source NAT VLAN. 
5. You have the possibility to enable IP aliases, which requires a source and destination IP. Even though it's called source, it's actually the destination as seen from the host that initiated the traffic. The Destination IP is the IP in the target VLAN we aim to direct traffic towards.
6. Save and Test: After configuring, save the changes and start testing to ensure that the NAT is functioning as expected.

Here comes an example configuration:

Fig.1 Source NAT and IP aliases configuration

Use cases

The most traditional use of Source NAT is when translating our private IP's to a single public IP, in order for us to be able to reach the internet. Another scenario would be in translating our traffic as it goes through a VPN, to avoid duplicate IP's between the 2 parties, or just to comply with the addressing schemes. A less traditional use would be to translate the source traffic between 2 networks in our environment. It's this last scenario that we are interested in.

Let's consider 2 VLAN's in our domain, where one is using the MX as gateway, while the other one is using a third party firewall, according to the following diagram. The Meraki MX has the blue and the red VLANs directly attached. Traffic going from the blue VLAN towards a device in the red VLAN, would reach the destination without issues, however return traffic would be sent to the third party firewall, instead of the MX, since the gateway for the blue VLAN is pointing to that one. The third party firewall would have the job to return the traffic back to us. For this to work, we would need a static route with destination the blue VLAN using the MX as next hop. Let's suppose that we don't control this firewall, so we can't configure the static route. 

 

Fig 1. Traffic with and without Source NAT on the MX

In this case we could use Source NAT. We would translate the source of the traffic to be the MX IP on the red VLAN. When traffic would reach the devices on the red VLAN, it would think that we reside within the same VLAN, so it would send the traffic back to the MX, instead of it's gateway, the third party firewall. Now let's discuss how we do this on an MX firewall. 

IP Aliases on the other hand are used to hide the destination of the traffic. Instead of sending traffic directly to the destination, we would send it to a local IP within our own VLAN. Our MX would use proxy ARP to respond to the initiator of the traffic, as if this IP was assigned to a local interface. The MX would then translate this further to the destination VLAN/IP. You can see a simplified illustration in the Fig.2 below. 

Fig 2. Traffic sent to the IP alias on the Blue VLAN

What are the benefits?

In most cases, you would want to avoid using Source NAT or IP aliases in the internal domain, since it will hide some of the traffic as seen from the source or the destination. This might pose some security concerns, as logs might not record the original IPs. We might not be able to track the actual source and destination, which might as well be an internal threat. It could still be used in some scenarios though:

Privacy and Security: In environments where device anonymity is crucial, such as in labs or testing facilities, masking the original IP can add another layer of security. This would provide privacy as well as security by obscurity to some extent. 

Network Migrations: When migrating from a firewall configured with source NAT between VLANs, we might want to do a one to one replacement and introduce changes in a later moment. In this case, it can be handy to have all features supported. 

Conclusion

MX firewalls are great for edge use, but they are not widely used in the internal domain for internal segmentation purposes. By introducing more features similar to the ones supported on ASA, Secure Firewall and other third party firewalls, we will see MX eventually become an Internal Segmentation Firewall.  While these features are still in beta, the results seem promising. While source NAT and IP aliases might not be a great idea for most scenarios, it can still be used to provide security by obscurity or to ease migrations from firewalls that already support these features.

References

Port Forwarding and NAT Rules on the MX - Cisco Meraki

Read More

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