vpn.center/

My criticism of Cisco's Firepower product is fairly well-published. However, to their credit Cisco seems to be finally steering the product in the right direction with the continued development of their Firepower Device Management  alternative for on-box management, allowing customers to abandon the dismal FMC. With the breakaway from a centralized controller though, users now need to revert to managing individual resources on their appliance(s) such as firewall policies, configuration backups, etc. This guide shows one elegant way to maintain configuration backups of a fleet of FDM appliances using a simple, flexible Ansible playbook.

This process shows you step by step how to run the tried and tested ASA appliance on a Firepower 2100 series chassis out of the box. Note that no special hardware (SSD, etc) is needed on the Firepower 2100 series devices to support this configuration. A quick housekeeping aside: To anyone who reads this article and believes that one is giving up security by replacing FTD with ASA, I strongly contend that you're probably wrong about that. Also, if from reading this it sounds as though I'm being harsh toward Cisco and their Firepower product team's top-level decision making, it's only because it actually is that terrible. </sarcastic rant> On that note, let's get started! Concepts and Key Terms Cisco's Firepower isn't actually a product in and of itself but a suite of products and subcomponents. For those uninitiated with the breakdown, it's important to understand what those components are for this procedure. FXOS  (Firepower eXte

This is a write up on best practice networking basics for Google Cloud Platform with what I've learned over the last year while working on a large company migration to the cloud from AWS. I hope that it comes in handy for anyone new to designing networking in and to Google Cloud, or those who may just be generally interested in the details of the networking architecture stitching their projects together. Overview The Google Cloud Platform (the AWS-like division of the larger "Google Cloud", hereon referred to as just 'GCP'') organizational resource layout is generally like this: Created cloud resources live in a VPC, which are part of a project, which are organized in folders or subfolders. The flow is... Create a folder for each BU or department in your organization. From there, create a project for nearly everything else. This includes creating a dedicated project for the shared VPC to exist in. Nearly every different use case pretty much get

image credit: dpdk.org, linux foundation Here's a write up on some of the dirty details that I've learned over the last year or so while building an NFV (network function virtualization) platform with the goal of virtualizing edge devices at scale. If you've ever wondered how to get usable, scalable performance out of virtualized networking drivers and appliances in production then hopefully you'll find this useful. While deploying specialized, purpose built network hardware might still make sense to many organizations who require a certain level of scale and performance (read: layer 2-3), I'd like to explore for a moment the possibilities which stem from the proliferation of x86-based cloud platforms, namely: virtual network appliances and their capability to eliminate the rapidly less-sexy sound of network appliances being unwieldy racked & stacked in your edge cabs. What must system owners consider before making a transition to virtual appliances for

Like many of us in the networking field, my earliest career dream was to join the coveted CCIE (Cisco Certified Internetwork Expert) club. In fact one of the most time-consuming things that I've ever done was invest myself into building and working through my home lab rack over, and over...and over again to eventually go and pass this one-of-a-kind exam to earn my place and certificate number. That hard work turned out to be great fun, and in reminiscing about my trips to San Jose to sit for hours in Cisco's infamous 'Building C', it even had a romantic quality. These days though I must admit that I've become rather disenchanted with the program. Please don't misunderstand me; I certainly still respect it and those who are part of its iconic history, but with the explosion of vendor competition in the networking world and with so many new technologies and architectures to absorb (cloud platforms, network virtualization, programming, automation and so on

I've noticed quite a lot of confusion in the networking realm over the last few years, even by experienced networking professionals, as to what exactly SD-WAN is and for what use cases one may consider using it for. Well, here's my take on hopefully clearing some things up. First things first... How SD-WAN compares to traditional MPLS L3VPN They're both managed VPN services, it's mostly a difference of who's performing the encapsulation and doing the management. SD-WAN offers true CE-to-CE flow encryption, whereas MPLS isn't encrypted at all and performs encap/decap on the upstream PE routers for each site. SD-WAN needs this encryption since it relies on the Internet to be it's backbone, where MPLS is contained in a service provider's VRF. Bottom line: Carriers are maddeningly slow and expensive, and the SD-WAN market wouldn't have been created at all if it weren't to give a giant middle finger to that. SD-WAN technology isn&

It's quite common to hear of companies these days planning to migrate some or all of their infrastructure into third-party cloud providers such as AWS. However, for some organizations it still makes good sense to build physical, on-premises data centers to either augment that cloud workload presence or supplement it entirely. Today I'm going to pretend I'm working for one of those companies and come up with a network design to build out, just to get the juices flowing. Be forewarned: brief this article is not, but I have glossed over a few details here and there for some brevity. Really, I wanted to illustrate some of the decisions that go into the process for those unaccustomed or otherwise curious. The Challenge Let's say a startup has hired me to design a data center network for their existing co-lo space that will be used to host all of their services. All that I've been given so far are four 42RU, dual-power cabinets in the datacenter cage, and