We often put together experiments that measure hardware performance to improve our understanding and provide insights to our hardware partners. We recently wanted to know more about Hyper-Threading and Turbo Boost. The last time we assessed these two technologies was when we were still deploying the Intel Xeons (Skylake/Purley), but beginning with our Gen X servers we switched over to the AMD EPYC (Zen 2/Rome). This blog is about our latest attempt at quantifying the performance impact of Hyper-Threading and Turbo Boost on our AMD-based servers running our software stack.
Intel briefly introduced Hyper-Threading with NetBurst (Northwood) back in 2002, then reintroduced Hyper-Threading six years later with Nehalem along with Turbo Boost. AMD presented their own implementation of these technologies with Zen in 2017, but AMD’s version of Turbo Boost actually dates back to AMD K10 (Thuban), in 2010, when it used to be called Turbo Core. Since Zen, Hyper-Threading and Turbo Boost are known as simultaneous multithreading (SMT) and Core Performance Boost (CPB), respectively. The underlying implementation of Hyper-Threading and Turbo Boost differs between the two vendors, but the high-level concept remains the same.
Hyper-Threading or simultaneous multithreading creates a second hardware thread within a processor’s core, also known Continue reading
In the Graceful Restart 101 blog post, I promised to discuss the ugly parts of this concept in a follow-up post. It turns out we’ll need more than one; today, we’ll focus on other control plane protocols in an access network scenario.
Imagine an access router with multiple uplinks serving a bunch of non-redundantly-connected customers:
A few weeks ago, I asked my manager, Chris Bareford, if he would approve the purchase of a licence to use the https://www.shodan.io open intelligence platform. I was both vague and detailed enough to justify the purchase, something about gathering threat intelligence as far as I can recall. My request was approved, and I am now in possession of the Shodan freelancer API entitlement. This is useful to me in automating certain intelligence and discovery tasks.
This blog, however, is NOT about the Shodan freelancer API.
Part of my job is to help enable cyber readiness for both my internal colleagues and my customers and prospective customers, and as part of this remit I publish a weekly threat landscape report, which is essentially a collection of things I have found to be interesting (and/or concerning) during the previous week from a cyber-security perspective. One element of this report covers what I would consider to be largely opportunistic attacks (or probes), and so I summarize an anonymized set of the past week’s common vulnerabilities & exposures (CVE) that VMware customers have had. When collating this type of information on a regular basis, what you notice is that, in addition Continue reading
“Facebook can't be down, can it?”, we thought, for a second.
Today at 15:51 UTC, we opened an internal incident entitled "Facebook DNS lookup returning SERVFAIL" because we were worried that something was wrong with our DNS resolver 1.1.1.1. But as we were about to post on our public status page we realized something else more serious was going on.
Social media quickly burst into flames, reporting what our engineers rapidly confirmed too. Facebook and its affiliated services WhatsApp and Instagram were, in fact, all down. Their DNS names stopped resolving, and their infrastructure IPs were unreachable. It was as if someone had "pulled the cables" from their data centers all at once and disconnected them from the Internet.
This wasn't a DNS issue itself, but failing DNS was the first symptom we'd seen of a larger Facebook outage.
How's that even possible?
Facebook has now published a blog post giving some details of what happened internally. Externally, we saw the BGP and DNS problems outlined in this post but the problem actually began with a configuration change that affected the entire internal backbone. That cascaded into Facebook and other properties disappearing and Continue reading
Hello my friend,
For quite a while we were silent (literally, the last post was month ago), as we were busy with extremely busy with completion of an important customer engagement. It was successfully completed and we are back on track with writing new interesting and useful (we hope so :-)) materials for you! And today we talk about our favourite topic – automation. To be precise, automation of Nokia SR OS devices with a new Python library called pySROS created by Nokia folks.
1
2
3
4
5 No part of this blogpost could be reproduced, stored in a
retrieval system, or transmitted in any form or by any
means, electronic, mechanical or photocopying, recording,
or otherwise, for commercial purposes without the
prior permission of the author.
If you have ever been in a situation, when there are much more work than hours in a day, then you know how important is to be able to do the job quickly and accurately. It is even better, if such job is done not by yourself, but rather by someone else or something else. This is exactly, where the automation of network and Continue reading
This week's Network Break talks about a new data center chassis from Juniper, why Akamai spent $600 million to buy security company Guardicore, what happened to Zoom's big acquisition of a contact center company, and more tech news.
The post Network Break 353: New Juniper Chassis Tops 400G; Akamai Spends Big Money On Microsegmentation appeared first on Packet Pushers.
This chapter explains the VPC Control-Plane operation when two EC2 instances within the same subnet initiate TCP session between themself. In our example, EC2 instances are launched in two different physical servers. Both instances have an Elastic Network Interface (ENI) card. The left-hand side EC2’s ENI has MAC/IP addresses cafe:0001:0001/10.10.1.11 and the right-hand side EC2’s ENI has MAC/IP addresses beef:0001:0001/10.10.1.22. Each physical server hosting EC2 instances has a Nitro Card for VPC [NC4VPC]. It is responsible for routing, data packets encapsulation/decapsulation, and Traffic limiting. In addition, Security Groups (SGs) are implemented in hardware on the Nitro card for VPC. AWS Control-Plane relies on the Mapping Service system decoupled from the network devices. It means that switches are unaware of Overlay Networks having no state information related to VPC’s, Subnets, EC2 Instances, or any other Overlay Network components. From the Control-Plane perspective, physical network switches participate in the Underlay Network routing process by advertising the reachability information of physical hosts, Mapping Service, and so on. From the Data-Plane point of view, they forwards packet based on the outer IP header.
Starting an EC2 instance triggers the Control-Plane process on a host. Figure 2-1 illustrates that Host-1 and Host-2 store information of their local EC2 instances into the Mapping cache. Then they register these instances into Mapping Service. You can consider the registration process as a routing update. We need to inform the Mapping Service about the EC2 instance’s a) MAC/IP addresses bind to ENI, b) Virtual Network Identifier (=VPC), c) the physical host IP, d) and the encapsulation mode (VPC tunnel header). If you are familiar with Locator/Id Separation Protocol LISP, you may notice that its Control-Plane process follows the same principles. The main difference is that switches in LISP-enabled networks have state information related to virtual/bare-metal servers running in a virtual network.
Figure 2-1: VPC Control-Plane Operation: Mapping Register.
Today on the Tech Bytes podcast we look at a global SD-WAN deployment for manufacturing company IMMI, which makes vehicle safety products, including products for school buses and military vehicles. Our guest is Tom Braden, VP of Enterprise Technology at IMMI, and our sponsor is HPE Aruba.
The post Tech Bytes: Global Manufacturer Taps Aruba EdgeConnect For SD-WAN, WAN Optimization appeared first on Packet Pushers.
Zero Trust rules by default block attempts to reach a resource. To obtain access, users need to prove they should be allowed to connect using signals like their identity, their device health, and other factors.
However, some workflows need a second opinion. Starting today, you can add new policies in Cloudflare Access that grant temporary access to specific users based on approvals for a set of predefined administrators. You can decide that some applications need second-party approval in addition to other Zero Trust signals. We’re excited to give your team another layer of Zero Trust control for any application — whether it’s a popular SaaS tool or you host it yourself.
Configuring appropriate user access is a challenge. Most companies start granting employee-specific application access based on username or email. This requires manual provisioning and deprovisioning when an employee joins or leaves.
When this becomes unwieldy, security teams generally use identity provider groups to set access levels by employee role. Which allows better provisioning and deprovisioning, but again starts to get clunky when application access requirements do not conform around roles. If a specific support rep needs access, then they need to be added to an existing Continue reading