I’m getting ready for Mobility Field Day 8 later this week and there’s been a lot of effort making sure we’re ready to go. That means I’ve spent lots of time thinking about event planning instead of writing. So I wanted to share some quick thoughts with you ahead of this week as well as WLPC Europe next week.

• I remain convinced than half of the objections that are raised by oversight organizations when it comes to adopting new technology come from the fact they got caught flat-footed and weren’t ready for it to be popular. Whether it’s the Wi-Fi 6E safety issue or the report earlier this year from the FAA about 5G and airports it just seems like organizations spend less time doing actual investigation and more time writing press releases about how they are ready to figure it all out yet.
• I also remain cautiously optimistic that the new Apple devices rumored to be coming out later this year, namely the iPad Pro and MacBook Pro with M2 chips, will have Wi-Fi 6E support. Yes, the iPhone didn’t. It’s also a smaller device with less room to add new hardware. The iPad and MacBook have historically gotten new chips before the smaller mobile device does. If I’m wrong then I guess we’ll get to see if 6E is enough of a factor to get people to ditch their Apple device for a Google or Samsung one.
• As we rely more and more on software to expand the capabilities of our hardware I think we’re going to see more and more companies working toward the model of hardware-as-a-service. As in you lease the equipment from them for a monthly payment and, in return, you get to have a base level of features that can be expanded in higher “tiers” of service. Expect some more on this idea in the near future with the launch of solutions like Nile.

---

Tom’s Take

Make sure you tune in for Mobility Field Day 8 and don’t forget to tell us what you think! Maybe by next year we’ll have lots of Wi-Fi 7 content to discuss.

netlab release 1.3 introduced support for VXLAN transport with static ingress replication and EVPN control plane. Last week we replaced a VLAN trunk with VXLAN transport, now we’ll replace static ingress replication with EVPN control plane.

<figure><figcaption>

Lab topology

</figcaption> </figure>

Bruce Davie makes an excellent point in his QUIC Is Not a TCP Replacement article – QUIC not a next-generation TCP, it’s a reliable RPC transport protocol.

What Bruce forgot to mention is that we had a production-grade RPC transport protocol for years – SCTP (Stream Control Transmission Protocol) – but it had two shortcomings:

• It wasn’t invented by the right people;
• It used a different IP protocol number and thus upset every ossified middlebox in the Internet. QUIC hides on top of UDP (because adding extra headers makes at least as much sense as junk DNA).

Jeroen Van Bemmel created another interesting netlab topology: EVPN/VXLAN between SR Linux fabric and FRR on Linux hosts based on his work implementing VRFs, VXLAN, and EVPN on FRR in netlab release 1.3.1.

Bonus point: he also described how to do multi-vendor interoperability testing with netlab.

If only he wouldn’t be publishing his articles on a platform that’s almost as user-data-craving as Google.

I was lucky enough to have been invited to attend Network Field Day 29 this past September in San Jose, CA. This event brings independent thought leaders together with a number of IT product vendors to share information and opinions. We saw presentations from a pretty full range of vendors — from the chips to observability. It was a great event and worth a few hours to check out the videos. Thanks to Gestalt IT for getting me involved.

Nokia was among the list of high-end companies we saw. No, they don’t make phones any more (though they do market their name to products), but they are still in the full-power, throw-packets-as-fast-as-you-can markets for hyperscalers and such. If you’re old like I am, you might remember Nokia as the hardware that Checkpoint ran on for a while. My brain has done its best to filter memories of those devices, but, luckily, the Nokia team is doing some much better things these days.

SR Linux was one of the focuses and the big hitter for me. This is a modernization of the SR OS that was introduced 20 years or so ago, and gets us into a “world of streaming telemetry.” It’s natively model-driven, making it easier to push this telemetry to the various registered agent. Telemetry is great for those that care, but I was actually more interested in the way the OS is architected.

SR Linux is made up of some number of application running on a base system. These applications are things like BGP and OSPF and SSH, but, because of the model-driven architecture, they each have their own configurations and state. When the application is installed, it publishes itself to the system API and runs independently of the other applications. If updates are needed, only that specific application is updated, and the others aren’t affected.

These smaller, iterative domains are a huge change from the monolithic systems we’re used to in the network. If you wanted to add, say, some syslog functionality to a monolithic OS, you would need to get the vendor to write some code, compile it, and ship you a new image to install. You have the same process if you needed to update that terrible code they just wrote. Being modular as it is, that same code update in SR Linux only updates the logging module; there’s no need to install a new image and reboot during a window. Any day where you can limit the blast radius of a change is a good day.

Because the applications publish themselves to the system, they can all be managed through the OS and its API. Once you have a central API, all sorts of doors open up for you. Now we can integrate config updates and application upgrades in our CI/CD pipelines, which means hands are off the keyboard! You don’t want to wake up at 3am to make an update, and I don’t want you, a human, making any changes at 3am. It’s not because I’m a nice guy, either. I don’t want you to call me at 4:15am when you copied the wrong config in and have taken large chunks of the network down in your sleep. Seriously, automation is a good thing.

You now have an OS that runs applications modularly and has an API you can use. What else can you do with it? Well, you can write your own applications to install on the device. Or you can write a web app that streams telemetry from the devices. Check out their NetOps Development Kit for more info on that stuff.

Let’s think bigger, though. With the Digital Sandbox feature in the Fabric Services System (FSS), you can actually have a working copy of your SR Linux network running as a digital twin. That is, you can have a copy of your network running in containers somewhere that is exactly (for definitions of the word) like production. The idea of a digital twin has been around for as long as I have, but I’ve rarely seen it used properly. Way back, you had to buy 2 of everything and manually keep it in sync, which lasted about 45 seconds before you lost focus on it and had other stuff to do. There are modeling products out there today (see Forward Networks or IP Fabric), but those are mathematical models and are an estimation. They are very good estimations but are estimations nonetheless. With Digital Sandbox, though, a copy of your SR Linux devices and applications — the same ones you have running in production — runs on containers and everything is kept in sync with the actual production network through FSS. You can actually sync the physical state of the network as well. If an interface is down in production, that interface will be down on the twin.

Let me clarify the container thing a bit. Nokia has published a Docker container that you can run yourself. This is the same code that is used on your production devices and the same code used in the Digital Sandbox. It’s all the same, so changes on your laptop should look like changes on your digital twin and your production network. Great stuff.

The Network Field Day 29 page has the videos for Nokia and the other presenters for you to watch. Definitely worth your time.

Send any sawmill videos questions my way.

This is a very short post, as a complement to my previous post about PyATS, Genie, and RobotFramework. How can we see the debug logs of RobotFramework? I’m doing a lot of testing with RobotFramework and Genie right now. And I had a little trouble getting the right level of debugging to fix my mistakes. Here is a short and efficient way to generate a log file with RobotFramework: Just add the options -L trace and –b your_debug_file.log to have everything you need. For example: robot -d ./output -L trace…

The post RobotFramework Debug Logs appeared first on AboutNetworks.net.

Kubernetes services are like networking standards: there are so many to choose from. In his brief introduction to Kubernetes service types, Stuart Charlton listed six of them, and I’m positive there are more. That’s what you get when you’re trying to reinvent every network load balancing method known to mankind ;)

How should we engage with evolution and innovation in the Internet’s name space? How can we evolve this name environment if we avoid fragmentation and stay within the confines of the incumbent name system? Are all that we are permitted to vary when we try to innovate in the name space are the values of the labels used within DNS names? This was never a satisfactory answer, and many actors have experimented with various forms of alternative name systems running over the Internet for many years. These efforts inevitably result in a fragmented name space. Is there a better way to respond to these conflicting pressures?

While ranting about Linux data plane configuration, I mentioned an interesting solution: Cumulus Linux Network Command Line Utility (NCLU), an attempt to make Linux networking more palatable to more traditional networking engineers.

NCLU is a simple wrapper around ifupdown2 and frr packages. You can execute net add and net del commands to set or remove configuration parameters¹, and NCLU translates those commands into changes to corresponding configuration files.

In the final post in this privacy series, Russ White looks at privacy information that can be gleaned from DNS queries, and outlines essential steps in developing your breach plan. Don't have a breach plan? Here's your opportunity to start one.

The post Privacy And Networking Part 7: DNS Queries And Having A Breach Plan appeared first on Packet Pushers.

In the previous MLAG Deep Dive blog posts we discussed the innards of a standalone MLAG cluster. Now let’s see what happens when we connect such a cluster to a VXLAN fabric – we’ll use our standard MLAG topology and add a VXLAN transport underlay to it with another switch connected to the other end of the underlay network.

<figure><figcaption>

MLAG cluster connected to a VXLAN fabric

</figcaption> </figure>

Continuing with examples of installing a service mesh, this video walks through deploying the Consul mesh. Host Michael Levan brings his background in system administration, software development, and DevOps to this video series. He has Kubernetes experience as both a developer and infrastructure engineer. He’s also a consultant and Pluralsight author, and host of the […]

The post Service Mesh and Ingress In Kubernetes: Lesson 6 – Consul Service Mesh And App Installation – Video appeared first on Packet Pushers.

Jordi left an interesting comment to my EVPN/VXLAN or Bridged Data Center Fabrics blog post discussing the viability of using VXLAN and EVPN in times when the equipment lead times can exceed 12 months. Here it is:

---

Interesting article Ivan. Another major problem I see for EPVN, is the incompatibility between vendors, even though it is an open standard. With today’s crazy switch delivery times, we want a multi-vendor solution like BGP or LACP, but EVPN (due to vendors) isn’t ready for a multi-vendor production network fabric.

I spent the last week at the Philmont Leadership Challenge in beautiful Cimarron, NM. I had the chance to learn a bit more about servant leadership and work on my outdoor skills a little. I also had some time to reflect on an interesting question posed to me by one of the members of my crew.

He asked me, “You seem wise. How did you get so wise?” This caught me flat-flooted for a moment because I’d never really considered myself to be a very wise person. Experienced perhaps but not wise like Yoda or Gandalf. So I answered him as I thought more about it.

Intelligence is knowing what to do. Wisdom is knowing what not to do.

The more I thought about that quote the more I realized the importance of the distinction.

Basic Botany

There’s another saying that people tweeted back at me when I shared the above quote. It’s used in the context of describing Intelligence and Wisdom for Dungeons and Dragons roleplaying:

Intelligence is knowing that a tomato is a fruit. Wisdom is not putting tomatoes in a fruit salad.

It’s silly and funny but it gets right to the point and is a different version of my other observation. Intelligence is all about the acquisition of knowledge. Think about your certification journey. You spend all your time learning the correct commands for displaying routing tables or how to debug a device and figure out what’s going on. You memorize arguments so you can pass the exam without the use of the question mark.

Intelligence is focused on making sure you have all the knowledge you can ever use. Whether it’s an arcane spell book or Routing TCP/IP Volume 1 you’re working with the kinds of information that you need to ingest in order to get things done. Think of it like a kind of race to amass a fortune in facts.

However, as pointed out above, intelligence is often lacking in the application of that knowledge. Assembling a storehouse full of facts doesn’t do much to help you when it comes to applying that knowledge to produce outcomes. You can be a very intelligent person and still not know what to do with it. You may have heard someone say that a person is “book smart” or is lacking is “common sense”. These are both ways to say that someone is intelligent by maybe not wise.

Applied Science

If intelligence is all about acquisition of knowledge then wisdom is focused on application. Just because you know what commands are used to debug a router doesn’t mean you need to use them all the time. There are apocryphal stories of freshly minted CCIEs walking in to the data center for an ISP and entering debug ip packet detail on the CLI only to watch the switch completely exhaust itself and crash in the middle of the day. The command was correct for what they wanted to accomplish. What was missing was the applied knowledge that a busy switch wouldn’t be able to handle the additional processing load of that much data being streamed to the console.

Wisdom isn’t gained from reading a book. It’s gained from applying knowledge to situations. No application of that knowledge is going to be perfect every time. You’re going to make mistakes. You’re going to do things that cause problems. You’re going to need to fix mistakes and learn as you go. Along the way you’re going to find a lot of things that don’t work for a given situation. That’s where wisdom is gained. You’re not failing. You’re learning what doesn’t work so you don’t apply it incorrectly.

A perfect example of this came just a couple of days ago. The power in my office was out which meant the Internet was down for everyone. A major crisis for sure! I knew I needed to figure out what was going on so I started the troubleshooting process. I knew how electricity worked and what needed to be checked. Along the way I kept working and trying to figure out where the problem was. The wisdom I gained along the way from working with series circuits and receptacles helped me narrow things down to one wall socket that had become worn out and needed to be replaced. More wisdom told me to make sure the power was turned off before I started working on the replacement.

I succeeded not because I knew what to do as much as knowing what not to do when applying the knowledge. I didn’t have to check plugs I knew weren’t working. I knew things could be on different circuits. I knew I didn’t have to mess with working sockets either. All the knowledge of resistance and current would only serve me correctly if I knew where to put it and how to work around the issues I saw in the application of that knowledge.

Not every piece of wisdom comes from unexpected outcomes. It’s often just as important to do something that works and see the result so you can remember it for the next time. The wisdom comes in knowing how to apply that knowledge and why it only works in certain situations. If you’ve every worked with someone that troubleshoots really complex problems with statements like “I tried this crazy thing once and it worked” you know exactly how this can be done.

---

Tom’s Take

Intelligence has always been my strong point. I read a lot and retain knowledge. I’m at home when I’m recalling trivia or absorbing new facts. However I’ve always worried that I wasn’t very wise. I make simple mistakes and often forget how to use the information I have on hand. However, when I shared the quote above I finally realized that all those mistakes were just me learning how to apply the knowledge I’d gained over time. Wisdom isn’t a passage in a book. It’s not a fact. It’s about knowing when to use it and when not to use it. It’s about learning in a different way that matters just as much as all the libraries in the world.

netlab release 1.3 introduced support for VXLAN transport with static ingress replication. Time to check how easy it is to replace a VLAN trunk with VXLAN transport. We’ll use the lab topology from the VLAN trunking example, replace the VLAN trunk between S1 and S2 with an IP underlay network, and transport Ethernet frames across that network with VXLAN.

<figure><figcaption>

Lab topology

</figcaption> </figure>

One of the discussion topics at the recent ICANN 75 meeting was an old favourite of mine, namely the topic of Internet Fragmentation. Here, I’d like to explore this topic in a little more detail and look behinds the kneejerk response of declaiming fragmentation as bad under any and all circumstances. Perhaps there are more subtleties in this topic than simple judgements of good or bad.

Charity Majors published another masterpiece: The Hierarchy Is Bullshit (And Bad For Business).

I doubt that anyone who would need this particular bit of advice would read or follow it, but (as they say) hope springs eternal.

One of the overused buzzwords of the cloudy days is the Cloud-Native Environment. What should that mean and why could that be better than what we’ve been doing decades ago? Matthias Luft and Florian Barth tried to answer that question in the Introduction to Cloud Computing webinar.

Here’s an interesting question randomly appearing in my Twitter feed:

If you had a greenfield network, would you choose SR-MPLS, or SRv6? And why?

TL&DR: SR-MPLS, assuming you’re building a network providing end-to-end connectivity between hardware edge devices.

Now for the why part of the question:

I spent a rainy day implementing VLANs, VRFs, and VXLAN on Cumulus Linux VX and came to “appreciate” the beauties of Linux networking configuration.

TL&DR: It sucks

There are two major ways of configuring data plane constructs (interfaces, port channels, VLANs, VRFs) on Linux:

A startup called Veego is pitching an end user experience service to Internet Service Providers (ISPs) to help providers offer better tech support to customers. The question is, are ISPs interested in customer service?

The post Startup Veego Targets ISP Customer Service With An End User Experience Package  appeared first on Packet Pushers.

An attendee in the Building Next-Generation Data Center online course sent me an interesting dilemma:

Some customers don’t like EVPN because of complexity (it is required knowledge BGP, symmetric/asymmetric IRB, ARP suppression, VRF, RT/RD, etc). They agree, that EVPN gives more stability and broadcast traffic optimization, but still, it will not save DC from broadcast storms, because protections methods are the same for both solutions (minimize L2 segments, storm-control).

We’ll deal with the unnecessary EVPN-induced complexity some other time, today let’s start with a few intro-level details.

In this video, host Michael Levan walks through the basics of installing the Istio service mesh and deploying a simple application. Host Michael Levan brings his background in system administration, software development, and DevOps to this video series. He has Kubernetes experience as both a developer and infrastructure engineer. He’s also a consultant and Pluralsight […]

The post Service Mesh and Ingress In Kubernetes: Lesson 5 – Service Mesh Install And App Deployment With Istio – Video appeared first on Packet Pushers.

netlab release 1.3.1 contains major additions to FRR and Cumulus Linux, and new BGP features:

• VXLAN, VLANs, VRFs, and EVPN implemented on FRR and Cumulus Linux
• BGP local-as implemented in the BGP configuration module and supported on Arista EOS, Cisco IOS, Dell OS10, FRR, and Nokia SR Linux.
• Configurable BGP transport sessions
• Configurable default BGP address families supported on Arista EOS, Cisco IOS, Cumulus Linux, FRR, and Nokia SR Linux.

Here are some of the other goodies included in this release:

Most people carry a spare tire in their car. It’s there in case you get a flat and need to change the tire before you can be on your way again. In my old VAR job I drove a lot away from home and to the middle of nowhere so I didn’t want to rely on roadside assistance. Instead I just grabbed the extra tire out of the back if I needed it and went on my way. However, the process wasn’t entirely hitless. Even the pit crew for a racing team needs time to change tires. I could probably get it done in 20 minutes with appropriate cursing but those were 20 minutes that I wasn’t doing anything else beyond fixing a tire.

Spare tires are redundant. You have an extra thing to replace something that isn’t working. IT operations teams are familiar with redundant systems. Maybe you have a cold spare on the shelf for a switch that might go down. You might have a cold or warm data center location for a disaster. You could even have redundant devices in your enterprise to help you get back in to your equipment if something causes it to go offline. Well, I say that you do. If you’re Meta/Facebook you didn’t have them this time last year.

Don’t mistake redundancy for resilience though. Like the tire analogy above you’re not going to be able to fix a flat while you’re driving. Yes, I’ve seen the crazy video online of people doing that but aside from stunt driving you’re going to have to take some downtime from your travel to fix the tire. Likewise, a redundant setup that includes cold spares or out-of-band devices that are connected directly to your network could incur downtime if they go offline and lock you out of your management system. Facebook probably thought their out-of-band control system worked just fine. Until it didn’t.

The Right Gear for Resilience

At Networking Field Day 29 last week we were fortunate to see Opengear present again for the second time. I’m familiar with them from all the way back at Networking Field Day 2 in 2011 so their journey through the changes of networking over the past decade has been great to see. They make out-of-band devices and they make them well. They’re one of the companies that immediately spring to mind when you think about solutions for getting access to devices outside the normal network access method.

As a VAR there were times that I needed to make calls to locations in order to reboot devices or get console access to fix an issue. Whether it was driving 3 hours to press F1 to clear a failed power supply message or racing across town to restore phone service after locking myself out of an SSH session there are numerous reasons why having actual physical access to the console is important. Until we perfect quantum teleportation we’re going to have to solve that problem with technology. Here’s a video from the Networking Field Day session that highlights some of the challenges and solutions that Opengear has available:

<iframe allowfullscreen="true" class="youtube-player" height="329" sandbox="allow-scripts allow-same-origin allow-popups allow-presentation" src="https://www.youtube.com/embed/DC_xUWvTMgc?version=3&amp;rel=1&amp;showsearch=0&amp;showinfo=1&amp;iv_load_policy=1&amp;fs=1&amp;hl=en&amp;autohide=2&amp;wmode=transparent" style="border:0;" width="584"></iframe>

Ryan Hogg brings up a great argument here for redundancy versus resiliency. Are you managing your devices in-band? Or do you have a dedicated management network? And what’s your backup for that dedicated network if something goes offline? VLAN separation isn’t good enough. In the event of a failure mode, such as a bridging loop or another attack that takes a switch offline you won’t be able to access the management network if you can’t sent packets through it. If the tire goes flat you’re stopped until it’s fixed.

Opengear solves this problem in a number of ways. The first is of course providing a secondary access method to your network. Opengear console devices have a cellular backup function that can allow you to access them in the event of an outage, either from the internal network or from the Internet going down. I can think of a couple of times in my career where I would have loved to have been able to connect to a cellular interface to undo a change that just happened that had unintended consequences. Sometimes reload in 5 doesn’t quite do the job. Having a reliable way to connect to your core equipment makes life easy for network operating systems that don’t keep from making mistakes.

However, as mentioned, redundancy is not resiliency. It’s not enough for us to have access to fix the problem while everything is down and the world is on fire. We may be able to get back in and fix the issue without needing to drive to the site but the users in that location are still down while we’re working. SD-WAN devices have offered us diverse connectivity options for a number of years now. If the main broadband line goes down just fail back to the cellular connection for critical traffic until it comes back up. Easy to do now that we have the proper equipment to create circuit diversity.

As outlined in the video above, Opengear has the same capability as well. If you don’t have a fancy SD-WAN edge device you can still configure Opengear console devices to act as a secondary egress point. It’s as simple as configuring the network with an IP SLA to track the state of the WAN link and installing the cellular route in the routing table if that link goes down. Once configured your users can get out on the backup link while you’re coming in to fix whatever caused the issue. If it’s the ISP having the issue you can log a ticket and confirm things are working on-site without having to jump in a car to see what your users see.

Resilience Really Matters

One of the things that Opengear has always impressed me with is their litany of use cases for their devices. I can already think of a ton of ways that I could implement something like this for customers that need monitoring and resilient connectivity options. Remote offices are an obvious choice but so too are locations with terrible connectivity options.

If you are working in a location with spotty connectivity you can easily deploy an Opengear device to keep an eye on the network and/or servers as well as providing an extra way for the site to get back online in the event of an issue. If the WAN circuit goes down you can just hop over to the cellular link until you get it fixed. Opengear will tell you something happened and you can log into the Lighthouse central management system to go there and collect data. If configured correctly your users may not even realize they’re offline! We’re almost at the point of changing the tire while we’re driving.

---

Tom’s Take

I am often asked if I miss working on networking equipment since I rarely touch it these days. As soon as I’m compelled to answer that question I remember all the times I had to drive somewhere to fix an issue. Wasted time can never be recovered. Resources cost money whether it’s money for a device or time spent going to fix one. I look at the capabilities that a company like Opengear has today and I wish I had those fifteen years ago and could deploy them to places I know needed them. In my former line of work redundant things were hard to come by. Resilient options were much more appealing because they offered more than just a back plan in case of failure. You need to pick resiliency every time because otherwise you’re going to be losing time replacing that tire when you could be rolling along fixing it instead.

---

Disclaimer

Opengear was a presenter at Networking Field Day 29 on September 7, 2022. I am an employee of Tech Field Day, which is the company that managed the event. This blog post represents my own personal thoughts about the presentation and is not the opinion of Tech Field Day. Opengear did not provide compensation for this post or ask for editorial approval. This post is my perspective alone.

The last video in the 2-hour-long Network Addressing part of How Networks Really Work discusses Network Address Translation.

After watching it, you might want to spend some extra quality time (with a bit of soap opera vibe) enjoying the recent ‌Dual ISP deployment operational issues and uncertainties thread on the v6ops mailing list with a “surprising” result: NPTv6 or NAT66 is the least horrible way to do it.

Juniper Apstra has introduced Freeform, a new way to consume Apstra's data center automation platform without being tied to stringent reference architectures. While Freeform expands the network topologies and protocols Apstra can work with, it comes with its own tradeoffs.

The post Juniper Apstra Freeform Supports New Topologies, Protocols For Data Center Automation–With Caveats appeared first on Packet Pushers.

I keep hearing numerous variations of the following argument from people believing in the unlimited powers of multi-cloud¹ (deploying your workloads in multiple public cloud providers):

We don’t install all our servers in the same DC. But would you trust one Cloud Server Provider with all your applications? That’s why you should use multi-cloud.

I’ve been hearing similar arguments for at least 30 years, including:

Video four in this series provides a hands-n view of deploying NGINX Ingress running on AKS. Michael Levan brings his background in system administration, software development, and DevOps to this video series. He has Kubernetes experience as both a developer and infrastructure engineer. He’s also a consultant and Pluralsight author, and host of the “Kubernetes […]

The post Service Mesh And Ingress In Kubernetes: Lesson 4 – Ingress With Nginx Ingress – Video appeared first on Packet Pushers.

Early bridges implemented a single bridging domain across all ports. Within a few years, we got multiple bridging domains within a single device (including bridging implementation in Cisco IOS). The capability to have multiple bridging domains stretched across several devices was still missing… until the modern-day Pandora opened the VLAN box and forever swamped us in the complexities of large-scale bridging.

One of my readers preparing for public cloud deployment sent me an interesting observation:

I pushed to use infrastructure-as-code as we move to Azure, but I’m receiving a lot of pushback due to most of the involved parties not having any experience with code. Management is scared to use any kind of “homegrown” tools that only a few would understand. I feel like I’m stuck deploying and managing the environment manually.

It looks like a bad case of suboptimal terminology for this particular audience. For whatever reason, some infrastructure engineers prefer to stay as far away from programming as possible¹, and infrastructure-as-code sounds like programming to them.

Sometimes a painfully troublesome networking problem can have a complicated and brain-twisting root cause, one which you dread having to explain to peers and managers. However, sometimes the root cause is dead simple and makes you feel silly for how long it took you to find it. Today, I had one of the latter and […]

The post Linux Bonding, LLDP, and MAC Flapping appeared first on Packet Pushers.

In the last blog post in the VLANs and VRFs in netlab series, I described how we can combine VLANs and VRFs and create a VRF Lite solution with stretched VLANs. Wonder how hard would it be to create a routed multi-hop VRF Lite topology? It’s trivial.

<figure><figcaption>

Routed VRF Lite lab topology

</figcaption> </figure>

Andrea Dainese released an interesting tool that performs automated network discovery, pushes the discovered data into NetBox, and then uses netbox-topology-views plugin to create network topology diagrams.

Definitely worth exploring!

A fresh-faced network engineer learns the hard way about the need to prepare for swapping out a switch during an overnight maintenance window.

The post Maintenance Window Gone Wrong appeared first on Packet Pushers.

I woke up at 5am this morning to order a new iPhone. I did this because I wanted the new camera upgrades along with some other nice-to-haves. Why did I get an iPhone and not a new Samsung? Why didn’t I look at any of the other phones on the market? It’s because I am a loyal Apple customer at this point. Does that mean I think the iPhone is perfect? Far from it! But I will choose it in spite of the flaws because I know it has room to be better.

That whole story is repeated time and again in technology. People find themselves drawn to particular companies or brands. They pick a new phone or computer or car based on their familiarity with the way they work or the design choices that are made. But does that mean they have to be loyal to that company no matter what?

Agree to Disagree

One of the things that I feel is absolutely paramount to being a trusted advisor in the technology space is the ability to be critical of a product or brand. If you look at a lot of the ambassador or influencer program agreements you’ll see language nestled toward the bottom of the legalese. That language usually states you are not allowed to criticize the brand for their decisions or talk about them in a disparaging way. In theory the idea is important because it prevents people from signing up for the program and then using the platform to harshly and unfairly criticize the company.

However, the dark side of those agreements usually outweigh the benefits. The first issue is that companies will wield the power to silence you to great effect. The worst offenders will have you removed from the program and potentially even sue you. Samsung almost stranded bloggers 10 years ago because of some brand issues. At the time it seemed crazy that a brand would do that. Today it doesn’t seem quite so far-fetched.

The second issue is that those agreements are written in such a way as to be able to cause issues for you even if you didn’t realize you were doing something you weren’t supposed to be doing. Think about celebrities that have tweeted about a new Android phone and the tweet has metadata that says sent with Twitter for iPhone. How about companies that get very upset when you discuss companies that they see as competitors. Even if you don’t see them as competitors or don’t see the issue with it you may find yourself running afoul of the brand when they get mad about you posting a pic of their product next to the supposed competition.

In my career I’ve worked at a value-added reseller (VAR) where I found myself bound by certain agreements to talk positively about brands. I’ve also found myself on the wrong side of the table when that brand went into a bidding process with another VAR and then tried to tell me I could say bad things about them in the process because I was also their partner. The situation was difficult because I was selling against a partner that went with another company but I also needed to do the work to do the bid. Hamstringing me by claiming I had to play by some kind of weird rules ultimately made me very frustrated.

Blind Faith

Do companies really want ambassadors that only say positive things about the brand? Do they want people to regurgitate the marketing points with everyone and never discuss the downsides of the product? Would you trust someone that only ever had glowing things to say about something you were trying to buy?

The reality of our world today is that the way that people discuss products like this influences what we think about them. If the person doing the discussion never has a negative thing to say about a company then it creates issues with how they are perceived. It can create issues for a supposedly neutral or unbiased source if they only ever say positive things, especially if it later comes out they weren’t allowed to say something negative for fear they’d get silenced or sued.

Think about those that never say anything negative toward a brand or product. You probably know them by a familiar epithet: fanboys. Whether it’s Apple or Tesla or Android or Ford there are many people out there that aren’t just bound by agreement to always speak positively about something. They will go out of their way to attack those that speak ill of their favorite product. If you’ve every had an interaction with a fan online that left you shaking your head because you can’t understand why they don’t see the issues you know how difficult that conversation can be.

As a company, you want people discussing the challenges your product could potentially face. You want an honest opinion that it doesn’t fit in a particular vertical, for example. Imagine how upset a customer would be if they bought your product based on a review from a biased influencer only to find that it didn’t fit your need because the influencer couldn’t say anything negative. Would that customer be happy with your product? Would the community trust that influencer in the future?

---

Tom’s Take

Honesty isn’t negativity. You can be critical of something you enjoy and not insinuate you’re trying to destroy it. I’ll be the first person to point out the shortcomings of a product or company. I’ll be fair but honest. I’ll point out where the improvements need to be made. One of the joys of my day job at Tech Field Day is that I have the freedom to say what I want in my private life and not worry about my work agreements getting me in trouble as has happened with some in the past. I’ll always tell you straight up how I feel. That’s how you protect your brand. Not with glowing reviews but with honest discussion.

A couple of months ago, in July 2022, I wrote about our work in measuring the level of use of QUIC in the Internet. Getting this measurement “right” has been an interesting exercise, and it’s been a learning experience that I’d like to relate here. We’ll start from the end of the previous article and carry on from there.

The entire set of issues of network neutrality, interconnection and settlements, termination monopolies, cost allocation and infrastructure investment economics is back with us again. This time it’s not under the banner of “Network Neutrality,” but under a more directly confronting title of “Sender Pays”. The principle is much the same: network providers want to charge both their customers and the content providers to carry content to users.

Broadcom has announced a new ASIC in the Trident family that can monitor flows in real time to identify anomalies that may indicate DDoS attacks, port scans, data exfiltration, and other threats, but has yet to announce security partners to take advantage of this capability.

The post New Trident 4C ASIC Includes Real-Time Threat Analysis Option appeared first on Packet Pushers.

This video provides a deeper dive into service mesh fundamentals, why a service mesh is important, how it works, and the pros and cons of service mesh in Kubernetes.

The post Service Mesh And Ingress In Kubernetes: Lesson 3 – Service Mesh Fundamentals – Video appeared first on Packet Pushers.