Excellent thread from Nick on this topic! A big point I'm a fan of:
"...most juniors don't have an immediately accessible lab on their laptops or cloud environment, because they don't spend much time labbing. Most mid-levels can spin up a topology on demand."
Labbing something does not have to be a arduous, time-intensive process. Being familiar with lab resources available to you and knowing how to efficiently use them is paramount to getting definitive answers to questions quickly.
For example, let's say somebody asks me whether changing the MTU on Layer 3 interfaces between two routers causes an OSPF adjacency between both routers to immediately flap.
I don't know the answer to that off the top of my head. But I *do* know where two unused boxes in my lab are. I can quickly SSH into both, set up a Layer 3 interface and OSPF adjacency between the two, and get a definitive answer to the question within minutes.
Another important aspect of labbing to answer questions is knowing which aspects of a question are and are not important to an accurate lab.
If I'm testing OSPF adjacency changes due to MTU, the BGP configuration on the same devices *probably* doesn't matter. Don't waste time trying to stand up and troubleshoot technologies that aren't relevant to the question at hand!
Obviously, this same advice doesn't necessarily apply when you're studying for a certification or trying to learn a technology. This advice applies when you're trying to answer a specific question or validate a specific set of behavior in the lab.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
A #network administrator's worst nightmare can be intermittent network congestion - it's impossible to predict, short-lived, and has major impact. Can #Python help us find and fix it?
A case I've seen in TAC is where customers observe intermittently incrementing input discard counters on interfaces of a Nexus 5500 switch. This is usually followed by reports of connectivity issues, packet loss, or application latency for traffic flows traversing the switch.
Oftentimes, this issue is highly intermittent and unpredictable. Once every few hours (or sometimes even days), the input discards will increment over the course of a few dozen seconds, then stop.
A common misunderstanding engineers have about Equal-Cost Multi-Pathing (ECMP) and port-channels is that they increase the bandwidth that can be used between two network devices. This *can* be true, but isn't *always* true.
Curious why? 🧵
First, let's review our topology. Three Cisco Nexus switches are connected in series. Traffic generators are connected to Switch-1 and Switch-2 through physical interface Ethernet1/36. Switch-1 and Switch-2 connect to Router through Layer 2 port-channels.
As the names suggest, Switch-1 and Switch-2 are purely Layer 2 switches. Router is a router that routes between two networks - 192.168.1.0/24, and 192.168.2.0/24. The traffic generator mimics four hosts - two in 192.168.1.0/24, two in 192.168.2.0/24.
"I see a lot of packet loss when I ping my switch" 🚩🚩🚩🚩🚩🚩🚩🚩🚩🚩🚩🚩
Wait, why is this a red flag? Let's dig into this behavior in a bit more detail... 🧵
First, let's take a look at our topology. We have two hosts in different subnets that connect to a Cisco Nexus 9000. One host connects via Ethernet1/1, and the other connects via Ethernet1/2. Ethernet1/1 has an IP of 192.168.10.1, while Ethernet1/2 owns 192.168.20.1.
The architecture of most network devices has three "planes" - a data plane, a control plane, and a management plane. We'll focus on the first two. The data plane handles traffic going *through* the device, while the control plane handles traffic going *to* the device.
On Cisco Nexus switches in production environments, avoid working within a configuration context on the CLI unless you're actively configuring the switch. Otherwise, you might accidentally cause an outage by trying to run a show command.
Curious how that's possible? 🧵
Cisco IOS and IOS-XE require you to prepend show commands with the "do" keyword to execute them within a configuration context.
NX-OS does not require you to do this - you can run a show command within any configuration context without the "do" keyword.
Discovered an interesting issue at home today - when I ping a Nexus 9000v running in CML from an Ubuntu host, I see duplicate replies.
At first glance, you might think the Nexus is duplicating replies. Meaning, a single ICMP Echo Request packet enters the switch, and the Nexus sends two ICMP Echo Reply packets.
However, that's not the case - if you run Ethanalyzer on the mgmt0 interface of the Nexus, the Nexus sees two ICMP Echo Request packet enters with the same sequence number. Therefore, it generates two ICMP Echo Reply packets.
The Nexus is a victim of the problem, not the cause.