I always love to read the practical advice by Andrew Lerner. Here’s another gem that matches what Brad Hedlund, Dinesh Dutt and myself (plus numerous others) have been saying for ages:
One specific recommendation we make in the research is to “Build a rightsized physical infrastructure by using a leaf/spine design with fixed-form factor switches and 25/100G capable interfaces (that are reverse-compatible with 10G).”
There’s a slight gotcha in that advice: it trades implicit complexity of chassis switches with explicit complexity of fixed-form switches.
Read more ...
An integration with Cisco Tetration will combine platform telemetry with machine learning algorithms to improve threat detection.
The open source tool allows for the building of a container image without providing privileged root access.
Ciena stands to be a winner because it competes with ZTE. Infinera and Nokia might benefit as well.

In previous blog post we discussed how we use the TPROXY iptables module to power Cloudflare Spectrum. With TPROXY we solved a major technical issue on the server side, and we thought we might find another use for it on the client side of our product.

This is Addressograph. Source Wikipedia
When building an application level proxy, the first consideration is always about retaining real client source IP addresses. Some protocols make it easy, e.g. HTTP has a defined X-Forwarded-For header[1], but there isn't a similar thing for generic TCP tunnels.
Others have faced this problem before us, and have devised three general solutions:

For certain applications it may be okay to ignore the real client IP address. For example, sometimes the client needs to identify itself with a username and password anyway, so the source IP doesn't really matter. In general, it's not a good practice because...
A second method was developed by Akamai: the client IP is saved inside a custom option in the TCP header in the SYN packet. Early implementations of this method weren't conforming to any standards, e.g. using option field 28 Continue reading
In a previous post, I covered how to integrate NSX-T with VMware Identity Manager (vIDM) to achieve remote user authentication and role-based access control (RBAC) for users registered with a corporate Active Directory (AD) http://blogs.vmware.com/networkvirtualization/2017/11/remote-user-auth…-rbac-with-nsx-t.html/
On this post, I’m showing how add two-factor authentication (2FA) for NSX-T administrators/operators on top of that existing integration. Two-factor authentication is a mechanism that checks username and password as usual, but adds an additional security control before users are authenticated. It is a particular deployment of a more generic approach known as Multi-Factor Authentication (MFA).
Throughout this post, I’m providing step-by-step guidance on how to use VMware Verify as that second authentication. I will also highlight what would be different if using third party mechanisms. At the end of the post, you will find a demo showing how to do the configuration and how users authenticate once 2FA is enabled.
What is VMware Verify? Let me quote what my colleague Vikas Jain wrote on this post: “VMware Verify uses modern mobile push tokens, where users get a push notification on their mobile device that they can simply accept or deny. When the user’s device does not have cellular reception, Continue reading
War and the battlefield themes dominated the opening keynotes at the annual RSA Conference 2018, just a day after a joint U.S. and U.K. alert warned that Russians are targeting American and British organizations’ network infrastructure devices, such as routers.
The new platform allows the company to get into the application space and diversify operations away from the increasingly competitive infrastructure space around OpenStack and Kubernetes.
Anyone who has worked with OSPF for any length of time has at least heard of areas—but perhaps before diving into Topology Transparent Zones (TTZs), a short review is in order.

In this diagram, routers A and B are in area 0, routers C and D are Area Border Routers (ABRs), and routers E, F, G, H, and K are all in area 1. The ABRs, C and D, do not advertise the existence of E, F, G, H, or K to the routers in area 0, nor the links to or between any of those routers. Any reachable destinations in area 1 are advertised using a em>summary LSA, or a type 3 LSA, towards A and B. From the perspective of A and B, 100::/64 and 101::/64 would be advertised by C and D as directly connected destinations, using the cost from C and D to each of these two destinations, based on a summary LSA.
What if you wanted to place H and K in their own area, with G as an ABR, behind the existing area 1? You cannot do this in OSPF using any form of a standard flooding domain, or area. There is no way Continue reading
Cisco, itself, recently issued a warning about its Smart Install client, saying it was vulnerable to cyber attacks by nation-state actors.
Cisco expects the ratio of IT people to devices to increase from 1 to 1,000 to 1 to 100,000 in just a couple of years.
The company claims its platform is the only one that can run both Swarm and Kubernetes in the same cluster.

WiFi isn’t fit for use in Location Services