Telstra Tests Network Slicing Today to Prep for 5G Tomorrow
Managing a lot of different slices is no easy task.
Managing a lot of different slices is no easy task.
Juniper's Telemetry Interface leverages its own silicon.
The server race is really afoot now that IBM has finally gotten off the starting blocks with its first Power9 system, based on its “Nimbus” variant of that processor and turbocharged with the latest “Volta” Tesla GPU accelerators from Nvidia and EDR InfiniBand networks from Mellanox Technologies.
The machine launched today, known variously as by the code-name “Witherspoon” or “Newell,” is the building block of the CORAL systems being deployed by the US Department of Energy – “Summit” at Oak Ridge National Laboratory and “Sierra” at Lawrence Livermore National Laboratory. But more importantly, the Witherspoon system represents a new …
Power9 To The People was written by Timothy Prickett Morgan at The Next Platform.
It combines technology from Intel and Hyper.

This blog post focuses on getting Red Hat Ansible Tower to use SAML as quick as possible. We will use the free OneLogin SAML provider service. Users with an existing SAML service may still find this blog post useful; especially the last section with some troublehooting tips.
Getting Ansible Tower to interoperate with OneLogin SAML requires both systems to have values from each other. This blog post is separated into three sections: the interdependent fields of the two systems, a detailed walkthrough of configuring OneLogin and Ansible Tower with both interdependent and per-system fields and values, and the troubleshooting of potential misconfigurations and corresponding error messages in Ansible Tower.
Defined in Ansible Tower, needed by OneLogin:
Defined in OneLogin, needed by Ansible Tower:
Ansible Tower and OneLogin Definitions
| Ansible Tower |
OneLogin |
|---|---|
| SAML ASSERTION CONSUMER SERVICE (ACS) URL |
ACS (Consumer) URL |
| SAML SERVICE PROVIDER ENTITY ID |
Audience |
| SAML ENABLED IDENTITY PROVIDERS (python dictionary where entity_id is the “magic” key) |
Issuer URL |
| SAML ENABLED IDENTITY PROVIDERS (python dictionary where url is the “magic” key) |
SAML 2.0 Endpoint (HTTP) |
| SAML ENABLED IDENTITY Continue reading |
With VXLAN design, the easiest thing to overlook is how communication occurs between subnets. I think many times, network engineers take for granted that our traffic will flow in a VXLAN environment. And it’s also easy to get confused when trying to figure out traffic routing path between your overlay and underlay.
As I work with customers in designing VXLAN infrastructures, one of the first questions I always ask is: “Where do you expect the gateway of the servers?”
This always leads to one of three designs, which I will outline over the next two posts. Before we start, know that all these designs leverage BGP EVPN. Ethernet Virtual Private Networks (EVPN) are an address family within BGP that are used to exchange VXLAN related information. This blog won’t go into detail about EVPN, but we have previous blogs to help fill in the gap.
With that said, let’s get started with the first VXLAN design example.
The first case is the simplest environment, and that is the gateway on an internet edge service. In this case, the VXLAN acts as a strict L2 overlay, and the L3 routed BGP underlay is hidden from the end hosts and servers.

The world doesn’t need another public cloud.
Pivotal Container Service, developed with VMware and Google, is initially available.

ZTP stands for Zero Touch Provisioning. And, as a quick google search will quickly reveal, many other things as well.
Back to our ZTP. ZTP is the process by which new network switches can be configured without much human involvement. Notice that I said “much” and not “any”. ZTP is not it’s not truly zero because something (someone!) needs to put the first components of the network together in order for the rest of the network to be built in a ZTP fashion.
Where provisioning many switches could have quite a while through ZTP processes it’s down to a matter of minutes. Switches can also be updated automatically with any need for physical intervention.
The beauty of ZTP is the continued march towards more and more robust automation solutions. Delightfully, once folks aren’t mired in the repetitive manual work they can move onto tasks that bring innovation to businesses and, more importantly, make jobs more enjoyable. We also can’t ignore the fact that it renders moot a lot of the specialized skills that traditionally defined the role of a network engineer. Continue reading
When deploying IPv6, one of the fundamental questions the network engineer needs to ask is: DHCPv6, or SLAAC? As the argument between these two has reached almost political dimensions, perhaps a quick look at the positive and negative attributes of each solution are. Originally, the idea was that IPv6 addresses would be created using stateless configuration (SLAAC). The network parts of the address would be obtained by listening for a Router Advertisement (RA), and the host part would be built using a local (presumably unique) physical (MAC) address. In this way, a host can be connected to the network, and come up and run, without any manual configuration. Of course, there is still the problem of DNS—how should a host discover which server it should contact to resolve domain names? To resolve this part, the DHCPv6 protocol would be used. So in IPv6 configuration, as initially conceived, the information obtained from RA would be combined with DNS information from DHCPv6 to fully configure an IPv6 host when it is attached to the network.
There are several problems with this scheme, as you might expect. The most obvious is that most network operators do not want to deploy two protocols to Continue reading
Barefoot leverages its Tofino programmable switch and the P4 language.
AT&T wants white box routers; VMware swoops on VeloCloud; Cisco Ericsson partnership wavers.

Introducing NSX-T 2.1 with Pivotal Integration Application architectures are evolving. That shouldn’t be news to anyone. Today, emerging app architectures that leverage container-based workloads and microservices are becoming mainstream, moving from science projects in development labs to enterprise production deployments at scale. The benefits are clear. Developers and the application lifecycle, become faster, more productive,... Read more →
Application architectures are evolving. That shouldn’t be news to anyone. Today, emerging app architectures that leverage container-based workloads and microservices are becoming mainstream, moving from science projects in development labs to enterprise production deployments at scale. The benefits are clear. Developers and the application lifecycle, become faster, more productive, more agile, and more responsive to the needs of the business.
Today we’re announcing NSX-T 2.1, which will enable advanced networking and security across these emerging app architectures, just as it does for traditional 3-tier apps. More specifically, NSX-T 2.1 will serve as the networking and security platform for the recently announced VMware Pivotal Container Service (PKS), a Kubernetes solution jointly developed by VMware and Pivotal in collaboration with Google. NSX-T 2.1 will also introduce integration with the latest 2.0 release of Pivotal Cloud Foundry (PCF), serving as the networking and security engine behind PCF. In these environments, NSX-T will provide Layer 3 container networking and advanced networking services such as load balancing, micro-segmentation, and more.
For development teams, these integrations mean that they will be able operate quickly and consume infrastructure as code. Meanwhile, their workflows will remain the same — fast and efficient — because NSX-T will integrate tightly with these application platforms, connecting directly into the Continue reading