Packet Pushers - Priority Queue

Romana is an open-source project that tackles network and security issues for cloud-native applications.

Romana’s goal is to address these issues with the simplest possible solutions using technologies we’re all familiar with–no overlays required.

According to its Web site, Romana “automates the creation of isolated Cloud Native Networks and secures applications with a distributed firewall that applies access control policies consistently across all endpoints and services, wherever they run.”

Joining us on Priority Queue to talk about the project is Chris Marino. Chris is part of a team behind Romana, and the founder and CEO of Pani Networks. We’ll explore just what the Romana project is about, drill into its major components, and look at its integration with OpenStack and Kubernetes.

We’ll also play Devil’s advocate to look at limitations with the project. To get more details about Romana, check out the project’s blog.

Show Notes:

Section 1 – Are Cloud Native Networks Really That Complex?

* What do we mean when we say “cloud native network”?

* Not just private cloud, also public cloud

* The emerging container problem

* A common solution in this space is an overlay using VXLAN with an SDN controller.

* What does VXLAN do for us?

* How does the SDN controller fit in?

* So let’s do a multi-tenant packet walk

* How hard is it to troubleshoot this sort of architecture?

Section 2 – Introducing The Romana Project

* In a nutshell, what is the Romana project?

* Let’s discuss the IP scheme used

* 32 bits

* Break them up how you need

* By default, broken on the octet boundary

* Network, tenants, hosts, networks, endpoints

* Okay, so let’s talk through each of the components

* Route manager

* IPAM

* Service insertion

* Is there a Romana API?

* Explain how Romana integrates with OpenStack

* Explain how Romana integrates with Kubernetes

Section 3 – Devil’s Advocate

* I find your lack of scale disturbing

* I want to use IPv6 addressing instead of IPv4. When?

* vMotion. I really, really want that…

* Native IP with no encap makes me nervous. Why shouldn’t it?

* How do I explain Romana multi-tenancy to a security auditor?

* There is zero chance I’m going to use static routes. Will Romana integrate with my BGP or OSPF?

* How is Romana itself secured so that it’s not provisioning IPs for undesirable endpoints or hosts?

The brave new world of networking services is automated, elastic, and chained.

That is to say, if you need to push traffic through a bunch of virtual middleboxes, you’re going to automate the creation of those middleboxes. Eventually, the days of standing up hardware services and plumbing them oh-so-carefully will be gone, because the world won’t wait for you to get it done. Automation is your answer.

And when you need to create more of them to support additional volume, the services will grow dynamically – more instances stood up and torn down as needed, depending on load.

And if you have a bunch of network services an application must pass through, you’ll set up traffic patterns in a service chain so that traffic flows through the virtual network services they need to without you having to rely on physical plumbing and clever routing.

All of this happens today in the worlds of OpenStack, containers, NFV, and microservices. In other words, this isn’t the “unicorn networking no one uses” that some of you complain about. This is real stuff.

To discuss microservice orchestration for networking is our sponsor, Sonus Networks. Bryan Hill, Vice President, Platform Engineering, joins us from Sonus to explore what microservices mean and how they are linked together in a cloud architecture.

We’ll also get into details about the orchestration mechanisms within OpenStack, discuss an OpenStack reference model, talk about how virtual network functions (VNFs) and microservices relate, and review several use cases.

Link:

ETSI OpenStack Reference Model (PDF)

Here on the Priority Queue, we’re soaring over the campus, buoyed aloft by 2.4 and 5 gigahertz radio waves carrying us to the land of Aruba Networks’ wireless certifications.

Aruba offers a plethora of certifications, and now that Aruba is part of Hewlett Packard Enterprise, those certs become part of the wider HPE certification ecosystem.

Kimberly Graves is here to chat with us about the Aruba Networks certification ladder. She’ll discuss why to certify on Aruba gear, what you’ll learn, and offer training and testing insights. Kimberly is a wireless network engineer and security consultant, and is currently a senior course and exam developer at Aruba. You can follow her on Twitter at @kimberlyagraves.

Show Notes:

Section 1 – Why Certify On Aruba Gear?

* Will I learn wireless fundamentals?

* Are there a lot Aruba installations out there that need certified people?

* Will my Aruba certs help me operate non-Aruba wireless networks?

Section 2 – Certification Levels And Tracks

* What are the main levels of certification (associate, professional, expert, etc.)?

* What are the major certification tracks?

* Which tracks are seeing the most growth or demand from the industry?

Section 3 – Training, Testing And Costs

* Will I be able to get certified without hands-on training? If not, how can I fix that?

* I’m a self-paced learner. What resources are available to me?

* Books

* Training

* Community

* Is there a recommended minimum spec for a home lab?

* I like to go to class. What are my options?

* Online

* Brick & mortar

* How are tests administered?

* Lower-level exams

* Expert exams

* Between training and testing, how much is this all going to cost?

If SDN is about automation and orchestration to configure the network, then the unasked (and unanswered question) is how do we test it? And how do we automate the testing?

Recently, Matt Oswalt announced ToDD (Testing On Demand: Distributed), an open source tool for validating network changes.

As Matt notes on his GitHub page, if you want to define the success of change, “…the only way to do that is to put your network through the same paces that the real-world does, and get detailed information back on how that test performed.”

Matt joins us to talk about test-driven automation, and to share details about the ToDD project. Also joining the conversation is Chris Young, a networking professional who’s worked with a preview of ToDD.

Links:

The Power of Test-Driven Network Automation – Keeping It Classless

Network Programmability and Automation by Jason Edelman; Scott S. Lowe; Matt Oswalt

An Introduction To ToDD – Youtube

Matt Oswalt’s Github page

kontrolissues.net – Chris Young’s Blog

Show Notes:

Part 1: Test-Driven Network Automation

* What does success look like?

* Automation without verification says to me that speed is more important than consistency and predictability – and that’s just not the case in the real world.

Part 2: ToDD

* Concepts

* Agents – runs the tests

* Groups – defines which agents run the tests

* Testruns – defines the tests

* Testlets – standardizes the tests

* Post-Test Analytics

* InfluxDB

* Graphana

Part 3: Future of ToDD and TDNA

* Maturation of ToDD itself

* Vendor platforms

* Maturation of rest of pipeline

* Automated baselines (machine learning?)

* We need to get better about not doing manual, bespoke things to our networks, including verification of changes. Automation without verification is pointless (and dangerous)

P4 is a language for programming the forwarding plane of packet-processing devices such as switches right down to the chip level, allowing network operators to customize how a device processes packets.

The goal of P4 is to enhance the flexibility of a network architecture and enable changes without having to wait for chip manufacturers or software developers to incorporate new features or protocol support.

P4 is an open-source project under the Apache 2.0 license. The code is maintained by the P4 consortium, which was started by Nick McKeown at Stanford University and Jennifer Rexford at Princeton University.

Our guest today to drill into the weeds about P4 is Professor McKeown. He’s been involved in several advances in networking technology over the last two decades. In particular, Nick has been a key driver of Software Defined Networking, and was a co-founder of Nicira Networks, which became VMware NSX. He is a full professor in Computer Science at Stanford University.

Links:

P4.org

Let’s get started (A blog from Jennifer Rexford and Nick McKeown introducing P4)

P4: Programming Protocol-Independent Packet Processors (Whitepaper)

Programming Protocol-Independent Packet Processors (Slide presentation by Jennifer Rexford)

This episode of Priority Queue, sponsored by Aruba, a Hewlett Packard Enterprise company, explores the ongoing evolution of the digital workplace.

As wireless networking has become both reliable and preferred by users, the next step is to fully utilize this network.

The explosion of mobile and IoT devices are transforming the way we communicate and consume services. Mobility changes the very nature of our work environments, where collaborative open spaces and non-routine schedules are becoming the norm.

Ozer Dondurmacioglu, Product Marketing Lead at Aruba, joins the Packet Pushers to talk about  how Aruba is helping IT networking teams can get ready for the digital workplace with the announcement of new products and solutions, including Aruba ClearPass for secure remote access.

This podcast was recorded at the Aruba Atmosphere Conference in 2016.

Links:

Policy management with Aruba ClearPass

Unified wired and wireless network infrastructure from Aruba

Network management with Aruba AirWave

Mobile engagement with Aruba Meridian

Wi-Fi analytics with Aruba ALE

Welcome to the Packet Pushers Priority Queue. On today’s show we’re going to talk about BGP flowspec, an RFC that can be used for DoS mitigation.

But before we dive in, let’s level set on BGP, the border gateway protocol. BGP is the routing protocol that glues the Internet together. Big, huge companies and service providers use complex BGP policies to govern traffic flowing across their networks. BGP lets you perform some clever routing tricks that you can’t really do with an interior gateway routing protocol like OSPF or EIGRP.

And all of that is, more or less, true. To quote RFC 4271, “The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems.  This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability, from which routing loops may be pruned and, at the AS level, some policy decisions may be enforced.”

Okay. So RFC 4271 tells us that BGP is, primarily for telling BGP speakers what networks are reachable via what autonomous systems. And if you dig a little deeper, you find that information is learned via the exchange of NLRIs – network layer reachability information messages.

Now, here’s the big deal with BGP. An NLRI could contain any sort of information. An NLRI doesn’t have to contain an IP prefix with reachability information. You know, a route. For instance, RFC 4684 defines NLRIs that contain route-target information. RFC 4760 talks about NLRIs for multi-protocol BGP. RFC 7432 defines NLRIs for EVPN.

Once you realize this, BGP becomes more than just a routing protocol. BGP can be used to share all sorts of information between BGP speakers to influence their forwarding decisions.

The topic of our conversation today is RFC 5575, BGP flowspec. BGP flowspec defines a specific BGP NLRI defining a flow. What do BGP speakers do with this flow information?

Our guest today is Justin Ryburn, who’s going to talk us through BGP flowspec and how it can be used to mitigate DoS and DDoS attacks.

Justin is a Consulting Engineer with Juniper Networks. He’s been with Juniper for about 9 years in both pre-sales and post-sales Engineering roles, and has about 20 years experience in networking with a primary focus on service providers and carriers.

Show Notes:

Section 1 – Setting Up The problem: DoS Attacks

* Briefly, what’s a DoS attack?

* High Level – Denial of Service attack is any attack that denies (blocks) the legitimate use of a resource.

* There is also a term DDoS. The extra D stands for distributed and it refers to the type of attack with a widely distributed source.

* What are the chief ways DoS attacks are defended against (and their issues)?

* Manual call – help me, I’m being attacked!

* D/RTBH – victim announces RTBH

* S/RTBH – victim calls for help, NOC initiates RTBH + uRPF

* The big deal? Every flow dies in the blackhole in destination-based filtering. A lack of granularity that kills useful traffic along with the DoS traffic. Even source-based with uRPF is not a perfect answer, although it’s better that destination-based.

* It is better in the sense that it does not “complete the attack” like you mentioned with destination-based filtering. However, it is impractical for a truly distributed attack as the source can be hundreds or thousands of hosts.

Section 2 – Introducing BGP Flowspec For DoS Mitigation

* What is BGP flowspec?

This episode of Priority Queue, sponsored by Aruba, a Hewlett Packard Enterprise company, talks about location services. Location services are being deployed in shopping centers, stadiums, hospitals, and other public areas. They tap into wireless networks to enable people to get location-related information and services on their mobile devices.

Traditional WLAN infrastructure is necessary for location services, but another key element is the Bluetooth Low Energy (BLE) protocol, which allows low-volume data transmissions over brief bursts instead of a continuous transmission.

BLE has given rise to beacons – tiny Bluetooth devices that broadcasts a small amount of data at regular intervals. These beacons are so small that they can run on coin-sized batteries for 2 years.

Placing beacons around a physical buildings allows smartphones to know where they are by hearing the BLE messages. By combining this with an app to fetch data based on the beacon and some programming, you can create location services.

People can use their phones to find the shop they want in a large shopping mall, or get alerts that the person they want to meet is drinking coffee in the next room. Companies have new ways to generate revenue with push notifications to users.

Julia Farina, Head of Product Marketing for Mobile Engagement at Aruba, sat down with Greg and Ethan at the Atmosphere 2016 conference to talk about location services and how the Aruba product line supports and enables these services.

They discuss how BLE integrates with Aruba’s wireless infrastructure, examine use cases for location services, and dive into the Meridian platform for building location features into mobile applications.

On today's Priority Queue show, sponsored by Aruba, we get a detailed update on the integration roadmap between Aruba and HPE Networking product lines.

Network monitoring has been in the doldrums for decades. The best protocols for network visibility that our industry has produced are SNMP, ping, and syslog. We use SNMP for metrics and ping to test availability, and syslog is an entire data source for device information. All of these have limitations.

However, over the last few years, software defined networking has seen new ways of getting information from our devices, and new tools and techniques are emerging to help network operators get better data and make more sense out of it.

Today we have a couple of folks to talk about the state of network monitoring and analytics. We’ll discuss why things like SNMP aren’t enough, how analytics and telemetry differ from traditional monitoring, what data sources are available, and how we can put that data to good use.

Our guests are Avi Freedman, Founder and CEO at Kentik, and Bill Beckett, Founder and CSO at Saisei.

Show Notes:

A. Define Analytics & Telemetry Compared To Network Monitoring

* I’ve got SNMP, why isn’t that enough?

* Flexible data sources

* What kind of data? Routing? Counters? Control-plane ‘deep’ counters like Q depth? Detailed config data (like LACP hash params+functions)?

* How often? Streaming or pull? What about streaming?

* Self-defined data formats

* Network-centric or application-centric instead of device-centric or “hop by hop” performance

B. Implementation Factors

* OpenConfig/NetCONF/YANG

* sFlow/NetFlow/IPFIX

* DPI

* Other data sources?

* Streaming bus?

* REST APIs

C. Data Wrangling

* Data platforms – one or many?

* Streaming data buses to feed multiple tools?

* How to interoperate?

* How to use for multiple purposes (BI, ops, security, performance)?

D. Use Cases

* Debugging/root cause?  How to use the data for that?

* Alerting and prediction over the data?

* Security?

* Performance?

* Other?

E. Visualization & Presentation

* Viable UI design

* UX flow and presentation

* Onboarding

* Business – linking performance to dollars, reducing asset values

Links:

PQ Show 46 – Saisei & Network Performance Enforcement – Packet Pushers

PQ Show 71: Kentik & Real-Time Network Visibility (Sponsored) – Packet Pushers

What is Juniper-Grafana? – GitHub