Rust Notes: Arrays
An array is a sequence of values, of the same type. A tuple is defined with square brackets []. Array Considerations Arrays live on the stack by default and have a fixed size. Traits are only implemented on an array with a size of 32 or less. Arrays with a size greater than 32 lose...continue reading
Rust Notes: Tuples
A tuple is a sequence of values, which can be of different types. A tuple is defined with circle brackets (). Tuple Considerations The number of elements in a tuple is known as its arity. Traits are only implemented on a tuple with an arity of 12 or less. Tuples with an arity...continue reading
Rust Notes: Chars
A char in Rust represents a single unicode scalar value. A char is defined as a single character within single quotes eg: ('a'). Char Considerations A char is not the same as a single str character. Strings DO NOT use chars internally. A char is always 4-bytes in length. continue reading
Rust Notes: If Conditionals
The if conditional block in Rust behaves similarly to other languages. In Rust, if blocks act as an expression and the resulting branch can be assigned to a variable. The resulting expression of an if branch can be assigned to a variable with the let keyword. If...continue reading
All is fair in and #NANOG Hackathons — refurbishing NAPALM drivers to build a multi-vendor…
All is fair in 💔 and #NANOG Hackathons — refurbishing NAPALM 🔥 drivers to build a multi-vendor #gNMI plug-in 🔌
We’re in Austin, Texas this week where the 84th North American Network Operators Group (NANOG) convention is taking place. Preceding that, during the Super Bowl ⅬⅤⅠ weekend (in which another blue team is about to win big), there is a Hackathon in which the teams are challenged to prepare for the networking equivalent of an epic halftime show.
Yours truly figures it would be a good idea to use this opportunity to kick-off the creation of a multi-vendor NAPALM driver. Most (if not all) NAPALM drivers to date are single vendor, see for example the Nokia SR OS NAPALM driver and the SR Linux variant. However, there is significant overlap in functionality and logic, and so I’d like to see if there is a possibility to “share the burden” by collaborating on some of the more basic (and — quite frankly — boring) parts of the drivers.
My (rough) plan is to clone the best current NAPALM driver code base — eos has been suggested — remove whatever logic it uses to talk to its vendor specific device APIs, and replace that with pyGNMI. To demonstrate this Continue reading
Worth Reading: Crazy about VMware SD-WAN
Have to work with VMware SD-WAN (the entity formerly known as VeloCloud)? You might find interesting tidbits in Crazy about VMware SD-WAN by Alexander Marhold.
Worth Reading: Crazy about VMware SD-WAN
Have to work with VMware SD-WAN (the entity formerly known as VeloCloud)? You might find interesting tidbits in Crazy about VMware SD-WAN by Alexander Marhold.
Who Wants to Be Supported Forever?
I saw an interesting thread today on Reddit talking about using networking equipment past the End of Life. It’s a fun read that talks about why someone would want to do something like this and how you might find yourself in some trouble depending on your company policies and such. But I wanted to touch on something that I think we skip over when we get here. What does the life of the equipment really mean?
It’s a Kind of Magic
As someone that uses equipment of all kinds, the lifetime of that equipment means something different for me than it does for vendors. When I think of how long something lasts I think of it in terms of how long I can use it until it is unable to be repaired any further. A great example of this is a car. All of my life I have driven older used cars that I continue to fix over and over until they have a very high mileage or my needs change and I must buy something different.
My vehicles don’t have a warranty or any kind of support, necessarily. If I need something fixed I either fix it myself or Continue reading
Heavy Networking 617: Go Vs. Python For Network Engineers
Today's Heavy Networking makes the case for why network engineers should consider using the Go language instead for their automation needs. Guest Darren Parkinson makes a strong argument for adding Go to your tool kit.
The post Heavy Networking 617: Go Vs. Python For Network Engineers appeared first on Packet Pushers.
Heavy Networking 617: Go Vs. Python For Network Engineers
Today's Heavy Networking makes the case for why network engineers should consider using the Go language instead for their automation needs. Guest Darren Parkinson makes a strong argument for adding Go to your tool kit.Win the Data Center Race with On-Premises Cloud
Embracing the cloud data center model for on-premises operations eliminates the need for compromise and provides the flexibility to scale as business requirements change.Video: Network Layer Addressing
After a brief excursion into the ancient data link layer addressing ideas (that you can still find in numerous systems today) and LAN addressing it’s time to focus on network-layer addressing, starting with “can we design protocols without network-layer addresses” (unfortunately, YES) and “should a network-layer address be tied to a node or to an interface” (as always, it depends).
For more details, watch the Network Layer Addressing video (part of How Networks Really Work webinar).
You need Free ipSpace.net Subscription to watch the video, and the Standard ipSpace.net Subscription to register for upcoming live sessions.
Video: Network Layer Addressing
After a brief excursion into the ancient data link layer addressing ideas (that you can still find in numerous systems today) and LAN addressing it’s time to focus on network-layer addressing, starting with “can we design protocols without network-layer addresses” (unfortunately, YES) and “should a network-layer address be tied to a node or to an interface” (as always, it depends).
For more details, watch the Network Layer Addressing video (part of How Networks Really Work webinar).
You need Free ipSpace.net Subscription to watch the video, and the Standard ipSpace.net Subscription to register for upcoming live sessions.
DNS4EU
The last few decades have not been a story of unqualified success for European technology enterprises. The European industrial giants of the old telephone world have found it to be extraordinarily difficult to translate their former dominant positions in the telco world into the Internet world. To be brutally frank, none of the current generation of major players in the digital environment are European. The concern is that if today’s technology world equates to the previous world of far-flung colonial empires then relative national wealth and prosperity appear to be linked to the ability to master, or preferably dominate, critical aspects of the sector. And in this respect Europe appears to have been left behind.Cloudflare acquires Vectrix to expand Zero Trust SaaS security
We are excited to share that Vectrix has been acquired by Cloudflare!
Vectrix helps IT and security teams detect security issues across their SaaS applications. We look at both data and users in SaaS apps to alert teams to issues ranging from unauthorized user access and file exposure to misconfigurations and shadow IT.
We built Vectrix to solve a problem that terrified us as security engineers ourselves: how do we know if the SaaS apps we use have the right controls in place? Is our company data protected? SaaS tools make it easy to work with data and collaborate across organizations of any size, but that also makes them vulnerable.
The growing SaaS security problem
The past two years have accelerated SaaS adoption much faster than any of us could have imagined and without much input on how to secure this new business stack.
Google Workspace for collaboration. Microsoft Teams for communication. Workday for HR. Salesforce for customer relationship management. The list goes on.
With this new reliance on SaaS, IT and security teams are faced with a new set of problems like files and folders being made public on the Internet, external users joining private chat channels, or an Continue reading
Adding a CASB to Cloudflare Zero Trust
Earlier today, Cloudflare announced that we have acquired Vectrix, a cloud-access security broker (CASB) company focused on solving the problem of control and visibility in the SaaS applications and public cloud providers that your team uses.
We are excited to welcome the Vectrix team and their technology to the Cloudflare Zero Trust product group. We don’t believe a CASB should be a point solution. Instead, the features of a CASB should be one component of a comprehensive Zero Trust deployment. Each piece of technology, CASB included, should work better together than they would as a standalone product.
We know that this migration is a journey for most customers. That’s true for our own team at Cloudflare, too. We’ve built our own Zero Trust platform to solve problems for customers at any stage of that journey.
Start by defending the resources you control
Several years ago, we protected the internal resources that Cloudflare employees needed by creating a private network with hardware appliances. We deployed applications in a data center and made them available to this network. Users inside the San Francisco office connected to a secure Wi-Fi network that placed them on the network.
For everyone else, we punched a Continue reading
HS016 Team Structure for Technology Teams
Discussing what might drives team structure in Enterprise IT.
The post HS016 Team Structure for Technology Teams appeared first on Packet Pushers.
