We Just Added a New Google Cloud Platform Course to Our Video Library

Last week we added another Google Cloud Platform Course to our video Library. You can find this course, Google Cloud Platform: Networking Fundamentals, on our All Access Pass streaming site and also at ine.com.

 

Why You Should Take This Course:

Google Cloud Platform enables developers to build, test and deploy applications on Googles highly-scalable, secure, and reliable infrastructure.

 

About the Course:

This course covers specifically Google Cloud Platform Networking services. We will review the features and functions of Google Cloud Platform Networking Services so that you will understand the GCP options available.

We will also dive into GCP Networking fundamentals such as Software Defined Networking, Load Balancing, Autoscaling and Virtual Private Clouds. As an added bonus, we will also dive into identity and access management from a networking security perspective.

This course is taught by Joseph Holbrook and is 3 hours and 51 minutes long.

 

What You’ll Learn:

After taking this class students will understand what GCP Cloud services will enable their organization around networking services. Whether you’re a developer or architect, this course will help you understand the basic capabilities and some of the useful advanced features of GCP networking services and features.

 

About Continue reading

Learning to Ask Questions

A lot of folks ask me about learning theory—they don’t have the time for it, or they don’t understand why they should. This video is in answer to that question.

Oil and Gas Industry Gets GPU, Deep Learning Injection

Although oil and gas software giant, Baker Hughes, is not in the business of high performance computing, the software it creates for the world’s leading oil and gas companies requires supercomputing capabilities for some use cases and increasingly, these systems can serve double-duty for emerging deep learning workloads.

The HPC requirements make sense for an industry awash in hundreds of petabytes each year in sensor and equipment data and many terabytes per day for seismic and discovery simulations and the deep learning angle is becoming the next best way of building meaning out of so many bytes.

In effort to …

Oil and Gas Industry Gets GPU, Deep Learning Injection was written by Nicole Hemsoth at The Next Platform.

For Many, Hyperconverged Is The Next Platform

There is a kind of dichotomy in the datacenter. The upstart hyperconverged storage makers will tell you that the server-storage half-bloods that they have created are inspired by the storage at Google or Facebook or Amazon Web Services, but this is not, strictly speaking, true.  Hyperscalers and cloud builders are creating completely disaggregated compute and storage, linked by vast Clos networks with incredible amounts of bandwidth. But enterprises, who operate on a much more modest scale, are increasingly adopting hyperconverged storage – which mixes compute and storage on the same virtualized clusters.

One camp is splitting up servers and storage, …

For Many, Hyperconverged Is The Next Platform was written by Timothy Prickett Morgan at The Next Platform.

Use YANG Data Models to Configure Network Device with Ansible

It took years after NETCONF RFCs were published before IETF standardized YANG. It took another half-decade before they could agree on how to enable or disable an interface, set interface description, or read interface counters. A few more years passed by, and finally some vendors implemented some of the IETF or OpenConfig YANG data models (with one notable exception).

Now that we have the standardized structure, it’s easy to build automated multi-vendor networks, right? Not so fast…

Read more ...

The problematic Wannacry North Korea attribution

Last month, the US government officially "attributed" the Wannacry ransomware worm to North Korea. This attribution has three flaws, which are a good lesson for attribution in general.

It was an accident

The most important fact about Wannacry is that it was an accident. We've had 30 years of experience with Internet worms teaching us that worms are always accidents. While launching worms may be intentional, their effects cannot be predicted. While they appear to have targets, like Slammer against South Korea, or Witty against the Pentagon, further analysis shows this was just a random effect that was impossible to predict ahead of time. Only in hindsight are these effects explainable.

We should hold those causing accidents accountable, too, but it's a different accountability. The U.S. has caused more civilian deaths in its War on Terror than the terrorists caused triggering that war. But we hold these to be morally different: the terrorists targeted the innocent, whereas the U.S. takes great pains to avoid civilian casualties. 

Since we are talking about blaming those responsible for accidents, we also must include the NSA in that mix. The NSA created, then allowed the release of, weaponized exploits. That's Continue reading

Understanding the Container Network Interface (CNI)


Container Network Interface (CNI) is a framework and an interface that abstracts away the network stack from the container runtime. This abstraction helps separate container management and networking thereby providing different players in the market, target the two problems independently. CNI is one of the two frameworks that make this abstraction possible, the other being the Container Network Model (CNM) that Docker implements as libNetwork. When Docker developed libNetwork (based on CNM) for docker container networking, CoreOS came up with a competing model for rkt (pronounced rocket) their container runtime. CNI being the network interface of choice for Kubernetes, the most popular container orchestration platform, it has gained popularity. CNI is now part of the CNCF consortium.

The CNI"nterface" is composed of two components - NetPlugin and the IPAM plugin. While NetPlugin is responsible for setting up network plumbing i.e. conduit between the container & the host, the IPAM plugin is responsible for IP address allocation. Since these two are designed to be pluggable, we can pick-and-choose plugins from different sources/vendors for each of them. CNI takes in a JSON configuration file from the container runtime or from an orchestrator like Kubernetes, that specifies the choice for each Continue reading

New Role, Same Goal

I recently gave a presentation at Network Field Day 17 wherein I announced that not only was I about to give probably the most compressed talk of my life (time constraints are unforgiving) but that I also was now working for Juniper. Until today, this was pretty much the most explanation I had time to give: I decided to accept a position with Juniper over the 2017 holiday, and I started last week.

New Role, Same Goal

I recently gave a presentation at Network Field Day 17 wherein I announced that not only was I about to give probably the most compressed talk of my life (time constraints are unforgiving) but that I also was now working for Juniper. Until today, this was pretty much the most explanation I had time to give:

I decided to accept a position with Juniper over the 2017 holiday, and I started last week. There were a few reasons for moving on from the StackStorm team, some of which are personal and have nothing to do with either day job. Despite the move, all of these things are still true:

  • StackStorm is and continues to be an awesome project. Regular updates are happening all the time, each full of tons of new features and fixes.
  • The StackStorm team and Extreme Networks as a whole are some of my favorite people ever. I will never forget everything I learned from them, and will try my best to stay in contact with all of them.
  • The concepts behind StackStorm, such as infrastructure-as-code, and autonomous response to events, are still top-of-mind for me. I still strongly believe that each of these concepts are Continue reading

New Role, Same Goal

I recently gave a presentation at Network Field Day 17 wherein I announced that not only was I about to give probably the most compressed talk of my life (time constraints are unforgiving) but that I also was now working for Juniper. Until today, this was pretty much the most explanation I had time to give:

I decided to accept a position with Juniper over the 2017 holiday, and I started last week. There were a few reasons for moving on from the StackStorm team, some of which are personal and have nothing to do with either day job. Despite the move, all of these things are still true:

  • StackStorm is and continues to be an awesome project. Regular updates are happening all the time, each full of tons of new features and fixes.
  • The StackStorm team and Extreme Networks as a whole are some of my favorite people ever. I will never forget everything I learned from them, and will try my best to stay in contact with all of them.
  • The concepts behind StackStorm, such as infrastructure-as-code, and autonomous response to events, are still top-of-mind for me. I still strongly believe that each of these concepts are Continue reading

BGP design options for EVPN in Data Center Fabrics

Ivan Pepelnjak described his views regarding BGP design options for EVPN-based Data Center Fabrics in this article. In comments to following blog post we briefly discussed sanity of eBGP underlay + iBGP overlay design option and come to conclusion that we disagree on this subject. In this blog post I try to summarize my thoughts about this design options.

Let’s start with the basics – what’s the idea behind underlay/overlay design? It’s quite simple – this is logical separation of duties of “underlying infrastructure” (providing simple IP transport in case of DC fabrics) and some “service” overlayed on top of it (be it L3VPN or EVPN or any hypervisor-based SDN solution). The key word in previous sentence – “separation”. In good design overlay and underlay should be as separate and independent from each other as possible. This provides a lot of benefits – most important of which is the ability to implement “smart edge – simple core” network design, where your core devices (= spines in DC fabric case) doesn’t need to understand all complex VPN-related protocols and hold customer-related state.

We use this design option for a long time – OSPF for underlay and iBGP for overlay is de-facto Continue reading

1 … 1,745 1,746 1,747 1,748 1,749 … 3,841