January 20, 2020

ipSpace.net Blog (Ivan Pepelnjak)

Early Stages of Product Decline

One of the worst things that can happen to anyone selecting equipment for a new network infrastructure is to receive the End-of-Life notice a week after the gear has been deployed in a production network… or maybe it’s even worse to be stuck with a neglected piece of technology full of bugs that the vendor never fixes because they’re chasing other shinier squirrels.

If you’re careful and watch what the vendors are doing, you might be able to save the day and identify the early phases of product decline. Here they are (as seen from the outside) in approximate order:

End of promotion opportunities. In most corporations aggressive hunters fare better than meticulous farmers, and product development is no different. As a friend of mine working for a large corporation once said “The culture here rewards launches instead of steady improvements. Like in academia, publishing a paper is valued more than running ISS”.

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at January 20, 2020 07:09 AM

XKCD Comics

January 19, 2020

ipSpace.net Blog (Ivan Pepelnjak)

MacOS Catalina = Windows Vista

Remember the Windows version that was so security-focused that it broke everything, and needed a gazillion changes/updates/upgrades to get back to where you had a working computer? I think it was Vista, but maybe my memory is failing me. Anyway, Apple got its Vista moment with macOS Catalina.

I was stupid enough to upgrade just before New Year, and I’m still struggling with aftereffects and skeletons falling out of every cupboard I look at. I appreciate Apple trying to make their operating system ever more secure, but breaking stuff every time I upgrade it is borderline ridiculous.

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at January 19, 2020 07:29 AM

January 18, 2020

ipSpace.net Blog (Ivan Pepelnjak)

Worth Reading: Seven Deadly Sins of Predicting the Future of AI

The next time the sales system engineer working for your beloved $vendor drops by with a glitzy unicorn-based slide deck full of AI/ML goodies, read this article to get a slightly better understanding of where we are... from the perspective of someone who has actual experience doing that stuff.

by Ivan Pepelnjak (noreply@blogger.com) at January 18, 2020 09:30 AM

January 17, 2020

My Etherealmind
ipSpace.net Blog (Ivan Pepelnjak)

Video: Fallacies of Distributed Computing

What better way to start How Networks Really Work webinar than with fallacies of distributed computing… and that’s exactly what I did in late August 2019.

You need Free ipSpace.net Subscription to watch the video, and the Standard ipSpace.net Subscription to register for upcoming live sessions.

by Ivan Pepelnjak (noreply@blogger.com) at January 17, 2020 07:05 AM

XKCD Comics

January 16, 2020

The Networking Nerd

Why Do You Need NAT66?

It’s hard to believe that it’s been eight years since I wrote my most controversial post ever. I get all kinds of comments on my NAT66 post even to this day. I’ve been told I’m a moron, an elitist, and someone that doesn’t understand how the Internet works. I’ve also had some good comments that highlight a specific need for tools like NAT66. I wanted to catch up with everything and ask a very important question.

WHY?

Every Tool Has A Purpose

APNIC had a great post about NAT66 back in 2018. You should totally read it. I consider it a fair review of the questions surrounding NAT’s use in 2020. Again, NAT has a purpose and when used properly and sparingly for that purpose it works well. In the case of the article, Marco Cilloni (@MCilloni) lays out the need to use NAT66 to use IPv6 at his house due to ISP insanity and the latency overhead of using tunnels with Hurricane Electric. In this specific case, NAT66 was a good tool for him to use to translate his /128 address to something useable in his network.

If you’re brave, you should delve into the comments. A couple of my favorite passages:

People from your side completely fail to understand that while NAT was not designed for security, it did bring security, in particular for home users.

Either the IPv6 community sobers up and starts actively supporting NAT or you can kiss the IPv6 protocol goodbye. I’ve put many many hours into IPv6 integration and I’m starting to realize it’s a doomed protocol and should be scraped.

It’s obvious to me a decade later that there are two camps of people that discuss NAT66: Those that are using it for a specific purpose. And those that think it has to be enabled because they use it with IPv4 networks. An example of the former:

<script async="async" charset="utf-8" src="https://platform.twitter.com/widgets.js"></script>

Pieter knew what he needed to do to make it work and he did it. Not because it was something that he configured on his home router to make the Internet work. But he also knew this wasn’t the optimal solution. When you can’t change the ISP router to accept RAs you need a workaround. There are a ton of stories I get from people just like Pieter that involve a workaround or a specific thing like provider-independent address space not being available. These are the kinds of situations that tools like NAT were designed to solve.

X, Why, Z

Let’s get back to my earlier question: WHY?

For those that believe that NAT66 needs to be used everywhere, why? Is it because you’re used to using RFC1918 address space to conserve addresses? Maybe you don’t like the idea of your MAC address “leaking” onto the Internet? How about providing enhanced security, as the commenters above mentioned? There’s even a comment on my original post from late last year about using NAT to force redirects for DNS entries to avoid having Google overriding DNS on his Android phone. Why?

For me, this always comes back to the same answer I give again and again. NAT, used for a purpose, isn’t inherently evil or wrong. It’s when people start using it for things it wasn’t designed for and breaking every other thing that it becomes a crutch and a problem. And those problematic solutions always cause issues somewhere down the line.

NAT44 broke FTP. It broke end-to-end communications. It created the need for big, hungry middle boxes to track state of connections. It conflated addressing and firewall functions. Anyone that screams at me and tells me that NAT provides security by obscuring addresses usually has an edge firewall doing NAT for them. In a true one-to-one NAT configuration, accessing the public or global IP address of the host in question does nothing to halt the traffic from being passed through. People who talk to be about address obfuscation with NAT44 or NAT66 usually mean PAT, not NAT. They want one address masquerading as all the addresses in their organization to “hide” themselves from the Internet.

Why does NAT need to solve those problems? I get the complexity of using PI space internally and the need to configure BGP to avoid asymmetric routing. Especially if your upstream provider isn’t paying attention to communities or attributes you’re using to avoid creating a transit network or weight traffic to prefer one link over the other. NAT may be a good short-term solution for you in these cases. But do you really want to run NAT66 for the next decade because of a policy issue with your ISP? That, to me, is the ultimate in passive-aggressive configuration. Why not just jump through hoops instead of hammering out a real solution?

I may sound like a 5-year-old, but “WHY” is really the most important question you can ask. Why do you need NAT66? Why do you even need IPv6? Is it a requirement for a contract? Maybe you have to enable it to allow your application to be uploaded to the walled garden store for your mobile provider. Maybe you just want to play around with it and get an Hurricane Electric Sage t-shirt. But if you can’t answer “WHY” then all the other things you want aren’t going to make sense.

I don’t run my HE.net tunnel at home any longer. I didn’t have an advantage in running IPv6 and I had more than a few headaches that had to be addressed. There will come a day when I want to do more with IPv6, but that’s going to require more bandwidth than I have right now. I still listen to IPv6 podcasts all the time, like the excellent IPv6 Buzz featuring my friend Ed Horley. Even the experts are bullish about the adoption of IPv6 but not ignorant of the challenges. And these guys run a business doing IPv6.

For those of you that are already limbering up your fingers to leave me a comment, stop and ask yourself “WHY” first. Why do you need NAT66? Is it because you have a specific problem you can’t solve any other way? Or is it because you need NAT66 to be there just like ISDN dialer maps and reserved VLANs on switches? To me, even past my days in the trenches as an engineer, the days of needing NAT everywhere are long gone. The IPv4 Internet relies on NAT. We are hobbled by that fact. VPNs need NAT traversal. Game consoles and VoIP devices need to be NAT-aware, which increases complexity.

The IPv6 Internet doesn’t need to be like that. Let’s teach the “right” way to do things. You don’t need NAT66 for privacy. RFC 4941 exists for that. You don’t need to think NAT66 provides security. That’s what perimeter devices are for. Anything more complicated than those two “simple” cases is going to be an exercise in frustration. You don’t need to bellow from the rooftops that NAT is a necessary and mandatory piece of all Internet traffic. Instead, come back to “WHY”. Why do two devices need a middle box to translate for them and hold state information? Why can’t my ISP provide me the address space I want or the connectivity options that make this work easily? The more “WHY” questions you ask, the more the answers will come. If you just want to fold your arms together and claim that NAT is needed because “This is the way,” you may find yourself alone on the Island of NAT sooner than you think.


Tom’s Take

My identity as the “I Hate NAT” guy is pretty solid at this point in my life. It’s too late to change now. Sure, I don’t hate NAT completely. It’s like a vulture to me. It serves a specific purpose but having it everywhere is almost always problematic. By now, the only way I can work against the needless expansion of NAT is to ask hard questions. Ironically enough, the hard questions aren’t multi-part essays that require an open-book test to resolve. Often, the hardest questions can just be a single word that forces you to question what you need and why you need it.

by networkingnerd at January 16, 2020 06:58 PM

My Etherealmind
ipSpace.net Blog (Ivan Pepelnjak)

Automation Solution: Data Center Fabric with Tenant Connectivity

I always tell networking engineers attending our Building Network Automation Solutions online course to create minimalistic data models with (preferably) no redundant information. Not surprisingly, that’s a really hard task (see this article for an example) - using a simple automation tool like Ansible you end with either a messy and redundant data model or Jinja2 templates (or Ansible playbooks) full of hard-to-understand and impossible-to-maintain business logic.

Stephen Harding solved this problem the right way: his data center fabric deployment solution uses a dynamic inventory script that translates operator-friendly fabric description (data model) into template-friendly set of device variables.

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at January 16, 2020 07:01 AM

Potaroo blog

Addressing 2019

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.

January 16, 2020 01:40 AM

January 15, 2020

Honest Networker

Putting full tables in your 7609

<embed allowfullscreen="true" allowscriptaccess="always" height="520" id="v-KLrCtcBC-1-video" overstretch="true" seamlesstabbing="true" src="https://v0.wordpress.com/player.swf?v=1.04&amp;guid=KLrCtcBC&amp;isDynamicSeeking=true" title="Full Tables" type="application/x-shockwave-flash" width="908" wmode="direct"></embed>
Full Tables

by ohseuch4aeji4xar at January 15, 2020 11:08 PM

ShortestPathFirst

New Juniper Networks Videos Covering Segment Routing

Juniper recently posted some new videos on their YouTube channel covering Segment Routing. These videos feature my former colleague Ron Bonica as he provides a basic overview of Segment Routing (SR) including key concepts such as paths and segments before diving into how SR simplifies traffic engineering. I definitely recommend checking these out for anyone …

by Stefan Fouant at January 15, 2020 09:30 PM

My Etherealmind
ipSpace.net Blog (Ivan Pepelnjak)

EVPN Auto-RD and Duplicate MAC Addresses

Another EVPN reader question, this time focusing on auto-RD functionality and how it works with duplicate MAC addresses:

If set to Auto, RD generated will be different for the same VNI across the EVPN switches. If the same route (MAC and/or IP) is present under different leaves of the same L2VNI, since the RD is different there is no best path selection and both will be considered. It’s a misconfiguration and shouldn’t be allowed. How will the BGP deal with this?

If the above sentence sounded like Latin, go through short EVPN terminology first (and I would suggest watching the EVPN Technical Deep Dive webinar).
Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at January 15, 2020 07:29 AM

Potaroo blog

BGP in 2019 - Part 2

This second part of the report of BGP across 2019 will look at the profile of BGP updates across 2019 to assess whether the stability of the routing system, as measured by the level of BGP update activity, is changing.

January 15, 2020 12:40 AM

XKCD Comics

January 14, 2020

My Etherealmind
ipSpace.net Blog (Ivan Pepelnjak)

Public Cloud Networking Security is Different

If you’re running a typical (somewhat outdated) enterprise data center, you’re using tons of VLANs and firewalls, use VLANs as security zones, and push inter-VLAN traffic through firewalls for inspection. Security vendors love that approach - when inspecting traffic they can add no value to (like database- or backup sessions), the firewalls quickly become choke points that have to be upgraded.

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at January 14, 2020 07:23 AM

January 13, 2020

Potaroo blog

BGP in 2019 - Part 1

It has become a tradition each January for me to report on the behaviour of the inter-domain routing system over the past year, looking in some detail at some metrics from the routing system that can show the essential shape and behaviour of the underlying interconnection fabric of the Internet.

January 13, 2020 10:40 PM

Packet Pushers

Cisco’s New Certification Path – Packet Pushers Holiday Edition 2019 – Video

This excerpt from the Packet Pushers’ 2019 Holiday Livestream event addresses a viewer’s question about Cisco’s certification path, the value of certifications in IT, and other options that network engineers might want to consider. You’ll hear opinion and analysis from Russ White, Tommy McNicholas, Ned Bellavance, Ethan Banks, Greg Ferro, and Drew Conry-Murray. For more […]

The post Cisco’s New Certification Path – Packet Pushers Holiday Edition 2019 – Video appeared first on Packet Pushers.

by The Video Delivery at January 13, 2020 10:21 PM

My Etherealmind

Dictionary: Human Permafrost

What is Human Permafrost in IT Infrastructure ?

The post Dictionary: Human Permafrost appeared first on EtherealMind.

by Greg Ferro at January 13, 2020 12:51 PM

ipSpace.net Blog (Ivan Pepelnjak)

AWS Rarely Kills a Service. What About Your Vendor?

Here’s an interesting tidbit from “Last Week in AWS” blog:

From a philosophical point of view, AWS fundamentally considers an API to be a promise. Services that aren’t promoted anymore are still available […] Think about that for a second - a service launched 13 years ago is still actively supported to the point where you can use it today.

Compare that to Killed By Google graveyard, and you might understand why I’m a bit reluctant to cover GCP in my webinars.

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at January 13, 2020 06:46 AM

XKCD Comics

January 12, 2020

ipSpace.net Blog (Ivan Pepelnjak)

Must Read: Ironies of Automation

Stumbled upon a 35-year-old article describing the ironies of automation (HT: The Morning Paper). Here’s a teaser…

Unfortunately automatic control can ‘camouflage’ system failure by controlling against the variable changes, so that trends do not become apparent until they are beyond control.

In simpler words: when things fail, they fail really badly because the intermittent failures were kept hidden. Keep that in mind the next time someone tells you how wonderful software-defined AI-assisted networking is going to be.

by Ivan Pepelnjak (noreply@blogger.com) at January 12, 2020 02:17 PM

January 11, 2020

ipSpace.net Blog (Ivan Pepelnjak)

Another perspective on "engineering" in IT

Found a nice article about Margaret Hamilton, the lady who coined the term "software engineering".

Engineering—back in 1969 as well as here in 2020—carries a whole set of associated values with it, and one of the most important is the necessity of proofing for disaster before human usage. You don’t “fail fast” when building a bridge: You ensure the bridge works first.

Now be a good "networking engineer" and go and stretch another VLAN around the globe... ;)

by Ivan Pepelnjak (noreply@blogger.com) at January 11, 2020 05:52 PM

January 10, 2020

About Networks

Cisco NX-OS Graceful Insertion and Removal (GIR)

If you operate a data-center network with Cisco Nexus, you’ve probably already faced the problem of how to perform a maintenance on one of the two switches of a vPC pair, with minimum impact and risks for the production network. Cisco NX-OS contains a feature called “Graceful Insertion and Removal” or GIR to help you for that. Here is how it works. Scenario Let’s take the example below: (click on the image to see a larger version) We have two Nexus (in nx-os mode) in vPC. Doing layer-2 aggregation and …

The post Cisco NX-OS Graceful Insertion and Removal (GIR) appeared first on AboutNetworks.net.

by Jerome Tissieres at January 10, 2020 04:38 PM

ipSpace.net Blog (Ivan Pepelnjak)

NetDev 0x13 on Software Gone Wild

The last Software Gone Wild podcast recorded in 2019 focused on advances in Linux networking - in particular on interesting stuff presented at NetDev 0x13 conference in Prague. The guests (in alphabetical first name order) Jamal Hadi Salim, Shrijeet Mukherjee, Sowmini Varadhan, and Tom Herbert shared their favorite topics, and commented on the future of Linux networking.

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at January 10, 2020 04:18 PM

The Networking Nerd

The Art of Saying “No”

No.

It’s the shortest sentence in the English language. It requires no other parts of speech. It’s an answer, a statement, and a command all at once. It’s a phrase that some people have zero issues saying over and over again. And yet, some others have an extremely difficult time answering anything in the negative.

I had a fun discussion on twitter yesterday with some friends about the idea behind saying “no” to people. It started with this tweet:

<script async="async" charset="utf-8" src="https://platform.twitter.com/widgets.js"></script>

Coincidentally, I tweeted something very similar to what Bob Plankers had tweeted just hours before:

<script async="async" charset="utf-8" src="https://platform.twitter.com/widgets.js"></script>

The gist is the same though. Crazy features and other things that have been included in software and hardware because someone couldn’t tell another person “no”. Sadly, it’s something that happens a lot in the IT industry. As a bad as IT’s reputation for being the Department of NO is we often find ourselves backed into a corner when it comes to saying “yes” way too much. I wanted to examine a couple of specific situations when we really should be saying “no” to people instead of just agreeing to keep the conversation moving.

Whatever You Need, We Do

When I worked at a VAR, I did both pre- and post-sales. I would go out to the customer site with the account managers to discuss technologies and try to get the potential customer what they needed. One of the AMs I worked with loved to introduce me and infer my skill level by saying, “Tom is the guy that makes all my lies come true.” It was his favorite icebreaker. We would all chuckle and get the conversation started.

Sadly, that icebreaker was true more often than it should have been. Because he (and some other AMs) would very often tell the customer whatever they wanted to hear to close the sale. Promise we could install the whole system in three hours? Easy. Tell them it will fix all their crazy Internet speed problems? You got it. Even as bad as telling this this will make their applications run so much faster and keep them super secure the whole time. Whatever it takes to make you sign the check.

When I arrived on site with a pile of equipment and a list of things that I needed to configure, I was quite often stricken with frustration because of the way my AMs had fibbed to the customer about the capabilities of the solution. Maybe they sold the wrong licenses to keep the costs down. Or, in some cases, they sold a feature that was much harder to implement than others. I seriously couldn’t count on both hands and feet the number of times I was forced to go to the customer and ask them what they were expecting from the solution based on what was sold to them.

Sometimes, you have to say “no”. That’s a hard phrase to say when you work in sales. You want the customer to get your product or service instead of your competitors. You want to book revenue. You want to keep your boss happy and keep yourself employed. You want to meet your goals. But you also don’t want to burn your bridges when it comes to being a good resource instead of someone just looking to make a buck.

I always tried to position myself as someone that could off impartial advice about a subject. If the customer wanted something that I couldn’t deliver I would say, “That’s not a good idea” or “Have you thought about why you want that?” I wanted to make sure that the customer really did want the thing they were asking for. Anyone that’s ever had a CEO or CIO clamor to implement a thing they say in an airport ad after coming back from a conference trip will attest to the power of wanting cool, shiny things.

Being a truly trusted advisor to your client means you have to be honest. No, that open source project won’t get you what you’re looking for just because it’s free. No, you can’t make your old intercom system work with a new VoIP UC solution. No, you can’t just keep running this server another three years on Windows 2003 Server so you can avoid the upgrade fees for your new clients. Saying “no” isn’t just about making them avoid things they don’t want to do. It’s about helping them understand a strategy and vision for what they need to be doing. Customers don’t always need to be told what they want to hear. They really do need to be told what they need to hear though.

Managing Products, I Think

The other side of the equation comes from the vendor side with product managers. I’ll admit that I have a limited view here, but the people that I’ve talked to seem to back up my thoughts on the matter. As stated above, I’ve always wondered how crazy random features made it into a software product. My supposition is that someone wanted to close a million-dollar deal somewhere and that feature was one of the things that it took to make that happen.

I also know that crazy things like this happen more often than you might realize. For example, ever wonder why wireless access points come configured with 80 MHz channels out-of-the-box when everyone you know, vendors included, tell you to configure them for 20 MHz or even 40 MHz instead? Could it be that when testing companies pull the APs out of the box that they don’t reconfigure the channels? Or perhaps it’s because those APs with 80 MHz defaults seem “faster” on those same tests? It’s a silly default configuration but it wins contests and reports. That’s the kind of decision that gets made by a product manager that wants to win customers or awards.

I would hope that the people that make products understand that people don’t really need insane corner case features to make products work. Worse yet, having those crazy features involved to support a random solution that is likely going to be replaced in a few years anyway cuts into partner revenue. The vendor shouldn’t be the one making their equipment compatible with every piece of hardware under the sun. Microsoft doesn’t write all the drivers for hardware to work with Windows, for example. They just write the specs for interfacing with the OS and leave the driver software writing up to the people that make the webcams or Bluetooth coffee mugs.

Vendors need to let the integration work happen with the integrators. Maybe they get access to some kind of advanced API or toolkit that assists with writing the “glue” that ties systems together. But building in basic support for everything under the sun from the outset creates support nightmares and unforeseen interactions with things that you will own for the next decade. Take the easy way out and tell people “no” and that they need to find someone to help them instead of just begging to have that crazy feature request included in a one-off build. Or, worse yet, included in main release and enabled by default.


Tom’s Take

I will admit that I have a really hard time saying no to things. It increases my workload and makes me so distracted that I can barely see straight most of the time. But there are times that I know I need to respond in the negative to something. It’s usually when I see that the person making the request either doesn’t know what they’re asking for or will end up regretting it later on. The key is to help them understand that you have the experience they lack and the vision to see this isn’t going to work the way they are planning. Hopefully they’ll come around to your way of thinking. But if not, just remember that “No.” is a complete sentence.

by networkingnerd at January 10, 2020 03:46 PM

Honest Networker
XKCD Comics

January 09, 2020

ipSpace.net Blog (Ivan Pepelnjak)

Worth Reading: Apple II Had the Lowest Input Latency Ever

It's amazing how heaping layers of complexity (see also: SDN or intent-based whatever) manages to destroy performance faster than Moore's law delivers it. The computer with lowest keyboard-to-screen latency was (supposedly) Apple II built in 1983, with modern Linux having keyboard-to-screen RTT matching the transatlantic links.

No surprise there: Linux has been getting slower with every kernel release and it takes an enormous effort to fine-tune it (assuming you know what to tune). Keep that in mind the next time someone with a hefty PPT slide deck will tell you to build a "provider cloud" with packet forwarding done on Linux VMs. You can make that work, and smart people made that work, but you might not have the resources to replicate their feat.

by Ivan Pepelnjak (noreply@blogger.com) at January 09, 2020 08:11 AM

January 08, 2020

Packet Pushers

Netbox Demo Site (NetboxDemo.com)

By now you have likely heard of, what is quickly becoming, the defacto industry standard DCIM and “single source of truth” tool: Netbox. Netbox was created by Jeremy Stretch of Packetlife and is an excellent tool for managing your IP space, device inventory, device-to-device connections, rack elevations, and much more. It also happens to be […]

The post Netbox Demo Site (NetboxDemo.com) appeared first on Packet Pushers.

by John W Kerns at January 08, 2020 08:09 PM

Cisco’s Silicon One ASIC – Packet Pushers Holiday Edition 2019 – Video

Get opinions and insights on Cisco's new Silicon One ASIC in this excerpt from the Packet Pushers' 2019 Livestream YouTube conversation.

The post Cisco’s Silicon One ASIC – Packet Pushers Holiday Edition 2019 – Video appeared first on Packet Pushers.

by The Video Delivery at January 08, 2020 05:41 PM

Ethan Banks on Technology

Synology Running Out Of Space? Empty The Recycle Bin.

While performing end-of-year clean up on lab infrastructure, I discovered my 8 disk Synology array with about 22TB of usable storage was almost out of space. Really? What had I filled all that space with?

After a lot of digging around, I found that I had enabled the Recycle Bin on one or more Shared Folders, but had NOT created a Recycle Bin emptying schedule.

This means that over several years of shoving lots of data through the array, the various Recycle Bins attached to various Shared Folders had loaded up with cruft. I figured this out running a Storage Analyzer report.

To get my space back, the solution was to empty the Recycle Bin. One way to do that is to edit the properties of a Shared Folder and click “Empty Recycle Bin”. You’ll get a sense of relief as Storage Manager shows available space growing as the Synology removes however many million files you’ve been composting for however long.

However, I like to solve problems permanently. No one has time to manually empty recycle bins on a disk array in a distant rack. Manually. Like a savage. Yuck.

Automating a recycle bin task on a Synology box is done via the Task Scheduler found in the Control Panel. Simply create a “Recycle Bin” Scheduled Task.

The configuration of the task from there is straightforward. Give the task a useful name, set the schedule, and then the policy. There’s plenty of power and granularity in the Task Settings–look at the screenshot below. The appropriate policy will vary by personal and/or business requirements, so I won’t bother talking you through all of that. It depends!™ 😆

by Ethan Banks at January 08, 2020 04:10 PM

ipSpace.net Blog (Ivan Pepelnjak)

Do We Need Math in Networking?

I should have known better, but I couldn’t resist being pulled into a Twitter spat around the question “whether networking engineers need to know something about math” a long while ago.

Before going into the details, let’s start with Wikipedia definition: “Engineering is the use of scientific principles to design and build machines, structures, and other things” including “specific emphasis on particular areas of applied mathematics, applied science, and types of application”.

So feel free to believe that you don’t need any math or other science (because there’s very little science behind what we do in networking) in your job, in which case you might want to stop reading… but then at least please think twice about your job title.

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at January 08, 2020 07:18 AM

XKCD Comics

January 07, 2020

Packet Pushers

What Makes A Good IT Leader?

This post originally appeared in Human Infrastructure, a free weekly newsletter from the Packet Pushers. You can subscribe and see every back issue here. A Packet Pushers listener recently reached out through our FU (Follow Up) link with a question: “I hear Greg complain a lot about IT leadership, and I think it’s largely justified, […]

The post What Makes A Good IT Leader? appeared first on Packet Pushers.

by Drew Conry-Murray at January 07, 2020 09:19 PM

ipSpace.net Blog (Ivan Pepelnjak)

There Is no Layer-2 in Public Cloud

The amount of layer-2 tricks we use to make enterprise networking work never ceases to amaze me - from shared IP addresses used by various clustering solutions (because it’s too hard to read the manuals and configure DNS) to shared MAC addresses used by first-hop router redundancy protocols (because it would be really hard to send a Gratuitous ARP message on failover) and all sorts of shenanigans we’re forced to engage in to enable running servers to be moved willy-nilly around the Earth.

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at January 07, 2020 07:20 AM

Honest Networker

January 06, 2020

Packet Pushers

SDN and Distributed systems world community questions

Working with multiple customers on Software-Defined Network (SDN) Solutions for years (first original NSX-MH, then NSX-V, and then Avi Networks (now NSX Advanced) load-balancer) – I came up to the realization that there are several interesting angles with the industry switch from a traditional single box to a distributed system solution. Before we start, let’s […]

The post SDN and Distributed systems world community questions appeared first on Packet Pushers.

by Petr McAllister at January 06, 2020 11:14 PM

ipSpace.net Blog (Ivan Pepelnjak)

Review: Webinars in 2019

A year ago I wrote about ipSpace.net plans for 2019. While we created over 50 hours of webinar content and over 20 hours of course content in 2019, let’s see how well we delivered on my promises.

Following AWS Networking webinar, we’ll do a similar one on Azure (in early autumn 2019) and GCP (late 2019 or early 2020)

Azure: done. GCP: postponed. Let’s see how serious Google is about that particular project.

Read more ...

by Ivan Pepelnjak (noreply@blogger.com) at January 06, 2020 06:54 AM

XKCD Comics

January 04, 2020

ipSpace.net Blog (Ivan Pepelnjak)

Worth Reading: Understanding Scale Computing HC3 Edge Fabric

A long while ago someone told me about a "great" idea of using multi-port server NICs to build ad-hoc (or hypercube or whatever) server-only networks. It's pretty easy to prove that the approach doesn't make sense if you try to build generic any-to-any-connectivity infrastructure... but it makes perfect sense in a small environment.

One can only hope Scale Computing keeps their marketing closer to reality than some major vendors (that I will not name because I'm sick-and-tired of emails from their employees telling me how I'm unjustly picking on the stupidities their marketing is evangelizing) and will not start selling this approach as save-the-world panacea... but we can be pretty sure there will be people out there using it in way-too-large environments, and then blame everything else but their own ignorance or stubbornness when the whole thing explodes into their faces.

by Ivan Pepelnjak (noreply@blogger.com) at January 04, 2020 07:55 AM

January 03, 2020

ipSpace.net Blog (Ivan Pepelnjak)

Worth Reading: Why Doctors Think They're the Best

Another great article by Scott Alexander, this time explaining the consequences of selection bias. The applicability to network engineering (and continuous use of shaky solutions) is left as an exercise for the reader.

by Ivan Pepelnjak (noreply@blogger.com) at January 03, 2020 07:47 AM

XKCD Comics

January 02, 2020

The Networking Nerd

Time For Improvement

Welcome to 2020! First and foremost, no posts from me involving vision or eyesight or any other optometrist puns for this year. I promise 366 days free of anything having to do with eyeballs. That does mean a whole world of other puns that I’m going to be focusing on!

Now, let’s look back at 2019. The word that I could use to describe it was “hectic”. It felt like everything was in overdrive all year long. There were several times that I got to the end of the week and realized that I didn’t have any kind of post ready to go. I’m the kind of person that likes to write when the inspiration hits me. And instead I found myself scrambling to write up some thoughts. And that was something I told myself that I was going to get away from. So we’re going to call that one a miss and get back to trying to post on a day other than Friday.

That also means that, given all the other content that I’ve been working on with Gestalt IT that I’m going to have to schedule some time actually working on that content instead of hoping that some idea is going to fly out of the blue at 11:30pm the night before I’m supposed to put a post up. The good news is that also means that I’m going to be upping the amount of content that I’m consuming for inspiration. Since I spent a good chunk of they year going on a morning walk it meant that I had a lot more time to consume podcast episodes and wash those ideas around. I’m sure that means that I’m going to find the time and the motivation to keep turning out content.

Part of the reason for that is because of something that Stephen Foskett (@SFoskett) told me during a call this past year. He said that I’ve been consistently turning out content for the last 9 years on a weekly basis. I’m proud of that fact. Sure, there’s been a couple of times in the last year or two when I’ve missed and had to publish something on a Saturday or the Monday after. But overall I’m happy with the amount of content that I’ve been writing here. And because you all keep on reading it I’m going to keep writing it. There’s a lot of value in what I do here and I hope you all continue to value it too.

IA Writing

Last January I switched over to using IA Writer for my posts on my iPad. I wrote primarily on that platform all year long. I can say that It’s very handy to be able to grab your mobile device and hammer out a post. Given that I can do split screen and reference my hand-written notes from briefings it’s a huge advantage to keeping my thoughts organized and ready to put down on paper.

Between IA Writer for writing, Notability for taking notes during briefings, and Things to keep me on track for the posts that I need to cover I’ve gotten my workflow down to something that works for me. I’m going to keep tweaking it for sure but I’m happy that I can get information to a place where I can refer to it later and have reminders about what I need to cover. It makes everything seamless and consistent. There are still some things that I need to use Microsoft Word to write, but those are long-form projects. Overall, I’m going to keep refining my process to make it better and more appropriate for me.

Ultimately, that’s a big goal for me in 2020 and something that I’ve finally realized that I do regularly without conscious thought. If you’ve read any books on process or project management you’ve probably heard of kaizen, the Japanese concept of continuous improvement of processes. It’s something that drives companies like Toyota to get better at everything they do and never accept anything as “complete”.

I’ve read about kaizen before but I never really understood that it could mean any improvement before. I had it in my head that the process was about change all the time. It wasn’t until I sat down this year and analyzed what I was doing to find that I’m always trying to optimize what I do. It’s not about finding shortcuts for the sake of saving time. It’s about optimizing what I do to save effort and the investment of time. For me it’s not about spending 8 hours to write a script that will automate a one-time 30-minute task. It’s about breaking down the task and figuring out how many times I’ll do it and how I need to optimize the process to spend less time on it. If the answer is a script or an automation routine then I’m all for it. But the key is recognizing the kaizen process and putting a name to my behavior.


Tom’s Take

2020 is going to be busy. Tech Field Day is going to be busy. I’m going to be at a lot of events checking out what’s going on and how to make new things happen. I’m also going to be writing a lot. And when you factor in my roles outside of work with Wood Badge and a trip to Philmont, NM with my son for a high adventure trip with his scout troop you can see I’m going to be quite occupied even when I’m not writing. But I’m not going to remove anything from my process. As I said above, I’m going to kaizen everything and fit it all in. That might mean having a couple of posts queued up when I’m in the back country or taking some extra time after dinner to write. But 2020 is going to be a big year of optimizing my workflows and improving in every way.

by networkingnerd at January 02, 2020 05:15 PM

Keeping It Classless

Returning to First Principles

I feel very strongly (and have for some time) that fundamentals are really important in a technical career. I didn’t start my career with a traditional CS degree, and while there were some fundamental knowledge to be picked up along the way, much of my education and early work experience bypassed a lot of the lower-level fundamentals and placed heavy emphasis on operating technology. This feeling of pulling levers and pushing buttons, rather than actually building things, in large part was responsible for me shifting back into software development full-time.

January 02, 2020 12:00 AM

January 01, 2020

XKCD Comics

December 30, 2019

XKCD Comics