Archive

Category Archives for "Networking"

The problem of unpredictable interface order in multi-network Docker containers

Whether we like it or not, the era of DevOps is upon us, fellow network engineers, and with it come opportunities to approach and solve common networking problems in new, innovative ways. One such problem is automated network change validation and testing in virtual environments, something I’ve already written about a few years ago. The biggest problem with my original approach was that I had to create a custom REST API SDK to work with a network simulation environment (UnetLab) that was never designed to be interacted with in a programmatic way. On the other hand, technologies like Docker have been very interesting since they were built around the idea of non-interactive lifecycle management and came with all API batteries already included. However, Docker was never intended to be used for network simulations and its support for multiple network interfaces is… somewhat problematic.

Problem demonstration

The easiest way to understand the problem is to see it. Let’s start with a blank Docker host and create a few networks:

docker network create net1
docker network create net2
docker network create net3

Now let’s see what prefixes have been allocated to those networks:

docker network inspect -f "{{range .IPAM.Config }}{{.Subnet}}{{end}}"  Continue reading

ChatOps – more Ops?

In the recent years we observed several movements inside of Corporate IT – DevOps and NetOps are two big ones in my experience. Probably there are more. While the definition of those is constantly changing depending on who you talk to and what time of day. Recently I came across a new term – ChatOps. […]

Link Propagation 108

Welcome to Link Propagation, a Packet Pushers newsletter. Link Propagation is included in your free membership. Each week we scour the InterWebs to find the most relevant practitioner blog posts, tech news, and product announcements. We drink from the fire hose so you can sip from a coffee cup. A note from Greg Why Link […]

Show 379: Grappling With Promise Theory

Mark Burgess, who developed the principles of Promise Theory as a way to model distributed systems, joins the Packet Pushers to explore how his ideas connect to networking and information systems. The post Show 379: Grappling With Promise Theory appeared first on Packet Pushers.

Weekend Reads 030218:

It’s been said that software is “eating the world.” More and more, critical systems that were once controlled mechanically, or by people, are coming to depend on code. This was perhaps never clearer than in the summer of 2015, when on a single day, United Airlines grounded its fleet because of a problem with its departure-management system; trading was suspended on the New York Stock Exchange after an upgrade; the front page of The Wall Street Journal’s website crashed; and Seattle’s 911 system went down again, this time because a different router failed. The simultaneous failure of so many software systems smelled at first of a coordinated cyberattack. Almost more frightening was the realization, late in the day, that it was just a coincidence. —James Somers @The Atlantic

The charges, and the confirmation that the Russians had used social media in an attempt to influence the 2016 election, is likely to fuel the call for government regulation of Twitter, Facebook and other social media outlets. When tweets and posts can hurt democracy, America should do something, right? Wrong. —Paul Levinson @Connecting

As we start to connect durable goods such as cars, medical devices, and electricity meters to the Internet, Continue reading

NSX Layer 2 VPN: Deploying for datacentre migrations

In my previous post, NSX Layer 2 VPN: Migrating workloads between Datacentres, I described the process and theory behind using an NSX Layer 2 VPN (L2VPN) to migrate workloads from a soon-to-be-retired VLAN backed datacentre, to an NSX Managed logical switch backed datacentre. In this post I will take you through the deployment of the L2VPN in my lab environment, following these high-level steps:

  • Prepare the NSX Managed Site
  • Deploy the Layer 2 VPN Server
  • Prepare the Standalone Site
  • Deploy the Layer 2 VPN Client
  • Validate the Layer 2 VPN connectivity

Current lab environment

The Lab environment I am using currently reflects the diagram below, with two VMs deployed onto VLAN 20 within my “remote” site (my remote site is actually just a separate cluster from my “NSX Managed Site”, which is my workload cluster). In my NSX Managed site I have a Provider Logical Router (PLR) and Distributed Logical Router (DLR) configured.

Current lab layout

Current lab layout

Configure the NSX Managed Site

To prepare the NSX Managed Site the L2VPN-Server needs to be connected to a “trunk” interface, which allows multiple VLAN or Logical Switches to be configured as sub-interfaces, rather than having an interface in each VLAN/Logical Switch.

The Continue reading

Enterprise Network on GNS3 – Part 7 – DMZ

This is the last article from the series of the articles discussing configuration of the enterprise network. The article explains the configuration of Demilitarized Zone (DMZ). Our DMZ consists of three devices - ASAv-DMZ-I, a multilayer switch vIOS-DMZ-I and Serv-DMZ-I. All the devices in DMZ are run by Qemu hypervisor. The ASAv_DMZ-I device is Cisco Adaptive Security Appliance Software version 9.6.1 and it has assigned 2048 MB RAM by GNS3. The device vIOS-DMZ-I is Cisco vIOS-L2 version 15.2 and it has assigned 512 MB RAM by GNS3. And finally, the device Serv-DMZ-I is Linux Ubuntu 16.04.3 LTS with 1024 MB RAM assigned by GNS3. The server Serv-DMZ-I provides DNS, NTP, Syslog services for devices in DMZ and a public web service for all hosts in the Internet.

Picture 1 - Demilitarized Zone - DMZ

All devices located in DMZ have their IP addresses assigned from the subnet 195.1.1.128/25. The subnet 195.1.1.128/27 is further divided with /30 mask, creating 8 subnets suitable for point-to-point link configuration . Servers located in DMZ are assigned to different VLANs. Currently, there is only server Serv-DMZ-I deployed in DMZ and configured with the IP addresses Continue reading

Enterprise Network on GNS3 – Part 7 – DMZ

This is the last article from the series of the articles discussing configuration of the enterprise network. The article explains the configuration of Demilitarized Zone (DMZ). Our DMZ consists of three devices - ASAv-DMZ-I, a multilayer switch vIOS-DMZ-I and Serv-DMZ-I. All the devices in DMZ are run by Qemu hypervisor. The ASAv_DMZ-I device is Cisco Adaptive Security Appliance Software version 9.6.1 and it has assigned 2048 MB RAM by GNS3. The device vIOS-DMZ-I is Cisco vIOS-L2 version 15.2 and it has assigned 512 MB RAM by GNS3. And finally, the device Serv-DMZ-I is Linux Ubuntu 16.04.3 LTS with 1024 MB RAM assigned by GNS3. The server Serv-DMZ-I provides DNS, NTP, Syslog services for devices in DMZ and a public web service for all hosts in the Internet.

Picture 1 - Demilitarized Zone - DMZ

All devices located in DMZ have their IP addresses assigned from the subnet 195.1.1.128/25. The subnet 195.1.1.128/27 is further divided with /30 mask, creating 8 subnets suitable for point-to-point link configuration . Servers located in DMZ are assigned to different VLANs. Currently, there is only server Serv-DMZ-I deployed in DMZ and configured with the IP addresses Continue reading

1 … 1,353 1,354 1,355 1,356 1,357 … 3,349