January 21, 2020

ipSpace.net Blog (Ivan Pepelnjak)

Public Cloud Cannot Change the Laws of Physics

Listening to public cloud evangelists and marketing departments of vendors selling over-the-cloud networking solutions or multi-cloud orchestration systems, you could start to believe that migrating your workload to a public cloud would solve all your problems… and if you’re gullible enough to listen to them, you’ll get the results you deserve.

Unfortunately, nothing can change the fundamental laws of physics, networking, or application architectures:

Read more ...

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

January 20, 2020

Packet Pushers

Kubernetes And Multi-Cloud – Packet Pushers Holiday Edition 2019 – Video

This excerpt from the Packet Pushers’ 2019 Holiday Livestream event addresses a viewer’s question whether a common platform will emerge for multi-cloud environments. Naturally, this lead to a conversation about Kubernetes and its potential. 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 Kubernetes And Multi-Cloud – Packet Pushers Holiday Edition 2019 – Video appeared first on Packet Pushers.

by The Video Delivery at January 20, 2020 08:38 PM

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.


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 provider independent (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 20, 2020 02:51 PM

My Etherealmind
Network Design and Architecture

GPON vs. Traditional Ethernet Architecture

GPON (Gigabit Passive Optical Network) is used to reduce the number of active switching nodes in the network design. Network Design Best practice in Campus networks and many Datacenter networks (Not Massively Scale Datacenters), is to use Three-Tier; Access, Distribution and Core network design. Although the design decision depends on the scalability requirements in the Campus and DC, two layer; Access and Collapsed Distribution/Core design can be used. Below figure depicts common three tier Access, Distribution and Core design.


This post was first published on “Service Provider Networks Design and Architecture by Orhan Ergun” book. 


GPON vs Active Ethernet

Figure – GPON vs. Traditional Ethernet Architecture, Source: cisco.com


In Three-tier Traditional campus networks, there are active Ethernet devices used in each tier. Active means, nodes require electricity. Active Ethernet switches forward traffic based on forwarding rules. If it’s a Layer 2 network, traffic is forwarded based on Layer 2 information, if it is a Layer 3 design, traffic is forwarded based on routing protocol information.

GPON in the campus network replaces traditional three-tier design with two-tier optical network, by removing the Active access and distribution layer Ethernet switches with the ONT, Splitter and OLT devices. Although ONT requires power, the power requirement of ONT, compared to ActiveEthernet switch is much less and the Splitter doesn’t require power at all. Splitter is purely a non- Active device.

Analysis show that using GPON in the Campus network, instead of Active devices, reduces power requirement significantly.

Many capabilities which are provided by Active Ethernet switches, such as Vlan awareness, Security features, Quality of service, Multicast, Redundancy, loop prevention etc. are provided with GPON design as well.

In design, there is no best solution. Every solution has its advantages and the disadvantages. This is also true for the comparison between GPON vs. Active Ethernet.

So far, it has been given that GPON has many advantages. On the other side, GPON has its bandwidth limitation as a technology. 2.5Gbps Download, 1.25Gbps Upload limitation. Although with the newer generation of PON solution, it can provide more Download and Upload bandwidth.

When we compare GPON with Traditional Active Ethernet, it is true that the Download bandwidth is 2.5Gbps and Upload bandwidth is 1.25Gbps, which is less than what traditional Ethernet can provide.

Depending on the Split ratio on the Splitter, 2.5Gbps bandwidth might be shared with 32, 64 or even with 128 different end points. Thus, it is true to say that when there is more bandwidth requirement per end point, Active Ethernet architecture can provide more bandwidth, probably with a better cost.

Cost analysis should be made carefully, as there might be different Fiber optic cable and transceiver requirements for each solution.

The post GPON vs. Traditional Ethernet Architecture appeared first on orhanergun.net.

by Orhan Ergun at January 20, 2020 01:02 PM

Edge Computing Providers

Edge computing is a networking philosophy focused on bringing computing as close to the source of data as possible, in order to reduce latency and bandwidth usage. In a simpler term, edge computing means running fewer processes in the cloud and moving those processes to local places, such as on a user’s computer, an IoT device, or an edge server.


This post was first published in ‘ Service Provider Networks Design and Architecture by Orhan Ergun ‘ book.

Bringing computation to the network’s edge minimizes the amount of long-distance communication that has to happen between a client and server.

For Internet devices, the network edge is where the device, or the local network containing the device, communicates with the Internet. The edge may not be a clear term; for example, a user’s computer or the processor inside of an IoT camera can be considered the network edge, while the user’s router, ISP, or local edge servers are also considered the edge.


It is important to understand that the edge of the network is geographically close to the device, unlike origin servers and cloud servers, which can be very far from the devices they communicate with.


Cloud computing offers significant amount of resources (e.g., processing, memory and storage resources) for the computation requirement of mobile applications. However, gathering all the computation resources in a distant cloud environment started to cause issues for applications that are latency sensitive and bandwidth hungry. The underlying reason is that network traffic has to travel through several routers managed by Internet Service Providers (ISPs), operating at varying tiers. All these routers significantly increase the Round-Trip Time (RTT) that latency-sensitive applications face.


In addition to this, end-to-end routing path delays can change very dynamically due to ISPs and network conditions.


Akamai, CloudFront, CloudFlare and many other Edge Computing Providers provide edge services like WAF, Edge Applications, Serverless Computing, DDos Protection, Edge Firewall etc.


edge computing

Figure Applications of Cloud and Edge Computing (source: www.NTT.com)

In the above figure, common use cases of Cloud and Edge Computing Services are shown. Many emerging technologies will require Edge computing.

The post Edge Computing Providers appeared first on orhanergun.net.

by Orhan Ergun at January 20, 2020 12:44 PM

Segment Routing Workbook by Orhan Ergun

Recently I published a new book on Segment Routing.

Segment Routing have been deployed by many networks (Both Enterprises and Service Providers ) for many different use cases such as Traffic Engineering, Fast Reroute , Monitoring and so on and I believe Segment Routing will be even more popular in near future. Thus, I believe this book should be read by anyone who are interested in networking.

You can get the sample copy of the book and purchase it from here. 

This book covers both Theory and Practical aspect of Segment Routing.

Segment Routing is a technology that is gaining popularity as a way to simplify MPLS networks. It has the benefit of interfacing with Software Defined Networks and works based on Source Routing.

This Workbook will be useful for those who want to understand, deploy,  verify and troubleshoot Segment Routing Networks. This Workbook will be useful for the  CCIE and CCDE certification exams.

Book Content:

  • Segment routing fundamental and concepts
    • Segment routing introductions
    • SR and MPLS data plane
    • Segment routing global block
  • Segment routing in IGP
    • SR Control Plane overview
    • SR in OSPF
    • SR in ISIS
    • Configuration lab and troubleshooting tips
    • Segment Routing and LDP
      • SR and LDP coexistence
      • SR Mapping Server
      • SR and LDP internetworking
      • Migration strategies
      • Configuration lab and troubleshooting tips
    • Segment routing and BGP
      • BGP prefix-SID
      • BGP based Datacenters
      • Configuration lab and troubleshooting tips
  •        Single domain SR Traffic Engineering
        • Introduction
        • Anycast and binding SID overview
        • SR Policy (Dynamic and explicit path)
        • Traffic Steering
        • On-demand Next hop (ODN)
        • IGP Flexible algorithm
        • Configuration lab and troubleshooting tips
  • Multi domain SR Traffic Engineering
          • PCE Protocol overview and architecture
          • BGP Label Unicast
          • BGP link state
          • Egress peer engineering (EPE)
          • Multi domain scenarios
          • Configuration lab and troubleshooting tips

The post Segment Routing Workbook by Orhan Ergun appeared first on orhanergun.net.

by Orhan Ergun at January 20, 2020 12:02 PM

Different wordings for the same definition/meaning in Networking

In computer network engineering almost always we use different definitions/wordings to explain same thing. In this post, I will give you some examples, please add whatever else you remember in the comment box below , we can discuss them there.


All below keywords explain the same thing. 


Let’s start with MPLS Cases :

  1. Tunnel Label , Transport Label , Transport Label , Outer Label , Topmost Label , Outmost Label : They all define PE to PE reachability in MPLS network.
  2. Ingress PE , Source PE , Headend PE , Ingress LSR , Edge LSR : Either in MPLS VPN or MPLS Traffic Engineering cases, you can see these keywords and they all define the same thing.
  3. Inner Label, VPN Label , VC (Virtual Circuit) Label , Service Label : They all define same thing which is Layer 2 VPN customer service information.

Inter Domain Routing Cases :

  1. IX (Internet Exchange) , IXP (Internet Exchange Point) , Internet Exchange , Peering Point , Exchange Point
  2. Public Peering Exchange , MLPE (Multi Lateral Peering Exchange) , Public Exchange

IOT Case:

  1. Smart Device, Smart Object , Sensors , Intelligent Object , Smart Things

Routing :

ASBR , IGW (Internet Gateway) , Edge Router , Border Router , Border Gateway, BGP Gateway , Transit Router , They all define the same thing which is a router connecting the AS to the Internet.

As I said , there are so many other examples and let’s discuss them over the comment section.

The post Different wordings for the same definition/meaning in Networking appeared first on orhanergun.net.

by Orhan Ergun at January 20, 2020 11:55 AM

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

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


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”


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