Day Two Cloud 129: Practical Advice On Optimizing Cloud Costs
Optimizing cloud costs means more than looking at your bill and hunting down unused instances. It's about understanding the full lifecycle of cloud workloads, dealing with management that wants predictable spending even as your actual usage varies, and setting up repeatable processes. Guests Fred Chagnon and Jeremy Roberts, both at Info-Tech Research Group, offer practical advice for optimizing your cloud spending.Catch 2022: Networking Ice Bucket Challenge
At the start of this exciting new year of 2022, I figured this might be a good time to introduce a new challenge:
Using Netsim-Tools, build the most complicated virtual network topology that still allows host A to ping host B
Anything goes — and if you have to extend the tooling to make things work, even better. Varying latency and occasional packet loss are acceptable, but there needs to be at least 1 ping reply being delivered to A.
For example, how about multi-vendor EVPN-VXLAN over SRv6 with MACsec encryption and Traffic Engineering?
Happy 2022 networking everyone! 🎆
Feedback: Recursive BGP Next Hop Resolution
The Recursive BGP Next Hops: an RFC 4271 Quirk blog post generated tons of feedback (thanks a million to everyone writing a comment on my blog or LinkedIn).
Starting with Robert Razsuk who managed to track down the original email that triggered the (maybe dubious) text in RFC 4271:
The text in section 5.1.3 was not really targeting to prohibit load balancing. Keep in mind that it is FIB layer which constructs actual forwarding paths.
The text has been suggested by Tom Petch in discussion about BGP advertising valid paths or even paths it actually installs in the RIB/FIB. The entire section 5.1.3 is about rules when advertising paths by BGP.
Feedback: Recursive BGP Next Hop Resolution
The Recursive BGP Next Hops: an RFC 4271 Quirk blog post generated tons of feedback (thanks a million to everyone writing a comment on my blog or LinkedIn).
Starting with Robert Razsuk who managed to track down the original email that triggered the (maybe dubious) text in RFC 4271:
The text in section 5.1.3 was not really targeting to prohibit load balancing. Keep in mind that it is FIB layer which constructs actual forwarding paths.
The text has been suggested by Tom Petch in discussion about BGP advertising valid paths or even paths it actually installs in the RIB/FIB. The entire section 5.1.3 is about rules when advertising paths by BGP.
Cisco SDA and Security Part IV – micro-segmentation in SDA continued (some more)
In this post, we will look at how to leverage SXP tunnels in ISE to achieve a specific use case.
Cisco SDA and Security Part III – micro-segmentation in SDA continued
In this post, we look at how SGACLs are pushed to NADs, with clear packet captures and packet walks. We also see how SGTs are added to the VXLAN header.
Cisco SDA and Security Part II – micro-segmentation in SDA
In this post, we look at microsegmentation in Cisco’s SD-Access fabric, using SGTs.
Cisco SDA and Security Part I – macro segmentation in SDA
In this post, we will look at macro segmentation in Cisco’s SD-Access.
I Can Hardly Contain(erize) Myself!
Happy New Year! Last year I wrote a series of blogs under the “Infrastructure as Software” banner exploring how to build a Django three-tiered application from pyATS that parsed network state data. Now that I’ve built a working Django application locally the challenge is to make it available to others. README After I had built […]
The post I Can Hardly Contain(erize) Myself! appeared first on Packet Pushers.
Why cloud native requires a holistic approach to security and observability
Like any great technology, the interest in and adoption of Kubernetes (an excellent way to orchestrate your workloads, by the way) took off as cloud native and containerization grew in popularity. With that came a lot of confusion. Everyone was using Kubernetes to move their workloads, but as they went through their journey to deployment, they weren’t thinking about security until they got to production. While this might seem like the intuitive thing to do, it doesn’t work in Kubernetes.
With Kubernetes, you can’t wait until the end when you’re ready to move workloads to production; you need to think about security early on. If security is not thought through in a system like Kubernetes, workloads are left vulnerable and you will not end up with a solution that is effective.
Why is this? What makes cloud native so different? Let’s take a look at some of the differences to understand why they warrant a more holistic approach to security and observability for cloud-native applications, whether in Kubernetes or another environment.
Cloud native: Origins, key differences, and challenges
What we’re used to (if we remove cloud native from the equation) is having a client-server architecture, where servers are running Continue reading
Aws Advanced Networking — Enhanced Networking — 3— Intel 82599 VF
The first two posts covered SRIOV/ ENA settings and use-cases, the next one in the series is about using Intel 82599 Virtual Functions adapter.
Post 1: https://r2079.wordpress.com/2021/12/28/enhanced-networking-1-sriov-aws/
Post 2: https://r2079.wordpress.com/2022/01/08/enhanced-networking-2-verifying-ena/
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sriov-networking.html
Instance Types: Select from the following supported instance types: C3, C4, D2, I2, M4 (excluding m4.16xlarge), and R3.
How can we verify:
At instance Level:
aws ec2 describe-instance-attribute --instance-id i-xx --attribute sriovNetSupport
[cloudshell-user@ip-10-0-119-152 ~]$ aws ec2 describe-instance-attribute --instance-id i-xx --attribute sriovNetSupport
{
"InstanceId": "i-xx",
"SriovNetSupport": {
"Value": "simple" -> Simple indicates its enabled, if not enabled its empty
}
}At an AMI Level
aws ec2 describe-images --image-id ami-07d8796a2b0f8d29c --query "Images[].EnaSupport"
[cloudshell-user@ip-10-0-119-152 ~]$ aws ec2 describe-images --image-id ami-07d8796a2b0f8d29c --query "Images[].SriovNetSupport"
[
"simple"
]At an Interface Level
ubuntu@ip-172-31-25-23:~$ ethtool -i ens3
driver: ixgbevf
version: 4.1.0-k
firmware-version:
expansion-rom-version:
bus-info: 0000:00:03.0
supports-statistics: yes
supports-test: yes
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: yes
ubuntu@ip-172-31-25-23:~$Latest Ubuntu HVM and Amazon Linux AMI have drivers for Enhanced Networking, IXGBEVF module and required modules for sriovNetSupport.
There is also the best practices Github guide for ENA Linux best practices and operating system optimisation.
https://github.com/amzn/amzn-drivers/blob/master/kernel/linux/ena/ENA_Linux_Best_Practices.rst
Heavy Networking 612: Cloud-Native Kubernetes Networking For CSPs (Sponsored)
Heavy Networking explores big ideas around service provider and cloud provider network services in 2022, both how they collide and are complementary. Our sponsor is Juniper Networks. We also get an update on Juniper’s Contrail product, a software-defined networking platform that now includes native integration with Kubernetes.
The post Heavy Networking 612: Cloud-Native Kubernetes Networking For CSPs (Sponsored) appeared first on Packet Pushers.
Heavy Networking 612: Cloud-Native Kubernetes Networking For CSPs (Sponsored)
Heavy Networking explores big ideas around service provider and cloud provider network services in 2022, both how they collide and are complementary. Our sponsor is Juniper Networks. We also get an update on Juniper’s Contrail product, a software-defined networking platform that now includes native integration with Kubernetes.IP Addressing through 2021s
Time for another annual roundup from the world of IP addresses. Let's see what has changed in the past 12 months in addressing the Internet and look at how IP address allocation information can inform us of the changing nature of the network itself.2021 IT Blog Awards finalist!
I was surprised but very honoured to learn that my blog was selected as a finalist in the IT Blog Awards. I started this blog to help with my learning during a personal research project and to contribute to the open-source networking community as best I could. I never imagined that someone else might consider it for an honour such as this!
If you have gotten value from reading this blog, please go to the IT Blog Awards voting page and vote for the “Open Source Routing and Network Simulation” blog. Thank you so much!
Former R&D Engineer Wins Round 2 of Project Jengo, and Cloudflare Wins at the Patent Office
The classic children’s fairy tale The Three Billy Goats Gruff tells the story of three goats trying to cross a bridge to a field of yummy grass, despite the monstrous troll that lives underneath the bridge and threatens to eat them. To beat the troll, the goats played on his greed and proceeded across the bridge in order from smallest to largest – and holding the troll at bay each time with promises of a larger meal if he waited for the larger goat to follow. In the end, the troll passed on attacking the smaller goats and was left to do battle with the largest goat who was able to defeat the troll, toss him off the bridge, and watch him float downstream. The goats were then able to enjoy the yummy grass, troll-free. In our fight against Sable Networks (patent troll), we plan on being that third goat, and our recent wins suggest we might be on track to do just that.
$10,000 to our second round of Project Jengo winner!
We started Project Jengo 2 last year as a prior art search contest, so we could enlist your help in the battle against Sable Networks. We committed Continue reading
Just Out: netsim-tools Release 1.1
New Year break was probably my busiest time (programming-wise) in years. Jeroen van Bemmel continued generating great ideas (and writing code and device configuration templates), and I found myself saying, “why not, let’s do the right thing!” more often than I expected. In parallel, Stefano Sasso fixed configuration templates for Junos, Mikrotik Router OS, and VyOS, and we were good to go.
To give you an idea of how fast we were moving: issue #84 was created on December 22nd, Sunday’s pull request that pushed release 1.1 into the master branch was #135 (GitHub numbers everything you do sequentially).