Author Archives: Russ
Author Archives: Russ
The post Worth Reading: The spillover effect appeared first on 'net work.
The post Worth Reading: Information paralysis appeared first on 'net work.
The post Worth Reading: Ransom by spreading the infection appeared first on 'net work.
The post Worth Reading: The canary appeared first on 'net work.
The argument around learning to code, it seems, always runs something like this:
We don’t need network engineers any longer, or we won’t in five years. Everything is going to be automated. All we’ll really need is coders who can write a python script to make it all work. Forget those expert level certifications. Just go to a coding boot camp, or get a good solid degree in coding, and you’ll be set for the rest of your life!
It certainly seems plausible on the surface. The market is pretty clearly splitting into definite camps—cloud, disaggregated, and hyperconverged—and this split is certainly going to drive a lot of change in what network engineers do every day. But is this idea of abandoning network engineering skills and replacing them wholesale with coding skills really viable?
To think this question through, it’s best to start with another one. Assume everyone in the world decides to become a coder tomorrow. Every automotive engineer and mechanic, every civil engineer and architect, every chef, and every grocer moves into coding. The question that should rise just at this moment is: what is it that’s being coded? Back end coders code database systems and business logic. Continue reading
The post Worth Reading: The economic model of Marai appeared first on 'net work.
The post Worth Reading: The bandwidth paradox appeared first on 'net work.
The post Worth Reading: Broadcom’s two ASIC lines appeared first on 'net work.
The post Worth Reading: The new security normal appeared first on 'net work.
The post Worth Reading: Sledgehammer DDoS appeared first on 'net work.
The post Worth Reading: The private path to censorship appeared first on 'net work.
The post On the ‘net: Looking at Openflow appeared first on 'net work.
The post Worth Reading: DevOps and what’s in a name appeared first on 'net work.
The post Worth Reading: Hype driven development appeared first on 'net work.
I ran into an interesting paper on the wide variety of options for assigning addresses, and providing DNS information, in IPv6, over at ERNW. As always, with this sort of thing, it started me thinking about the power of unintended consequences, particularly in the world of standardization. The authors of this paper noticed there are a lot of different options available in the realm of assigning addresses, and providing DNS information, through IPv6.
Alongside these various options, there are a number of different flags that are supposed to tell the host which of these options should, and which shouldn’t, be used, prioritized, etc. The problem is, of course, that many of these flags, and many of the options, are, well, optional, which means they may or may not be implemented across different versions of code and vendor products. Hence, combining various flags with various bits of information can have a seemingly random impact on the IPv6 addresses and DNS information different hosts actually use. Perhaps the most illustrative chart is this one—
Each operating system tested seems to act somewhat differently when presented with all possible flags, and all possible sources of information. As the paper notes, this can cause Continue reading
The post Worth Reading: W3C at the crossroads appeared first on 'net work.
The post Worth Reading: Network Time Protocol appeared first on 'net work.
In the last post on this topic, we found the tail of the update chain. The actual event appears to be processed here—
case BGPEventUpdateMsg:
st.fsm.StartHoldTimer()
bgpMsg := data.(*packet.BGPMessage)
st.fsm.ProcessUpdateMessage(bgpMsg)
—which is found around line 734 of fsm.go. The second line of code in this snippet is interesting; it’s a little difficult to understand what it’s actually doing. There are three crucial elements to figuring out what is going on here—
:=
, in go, is a way of appending the information in a data structure with more information. So, for instance, if you do something like this—
a-string = "this is a"
a-string := " string"
The result, in a-string
, is this is a string
. Whatever else this snippet is doing, then, it is taking something out of the data
structure, and appending it to the bgpMsg
structure. What, precisely, is it taking from the data
structure?
The *
(asterisk) is a way to reference a pointer within a structure. We’ve not talked about pointers before, so it’s worth spending just a moment with them. The illustration below will help a bit.
Each letter in the string “this is a string” Continue reading