Underhanded Code and Automation

12 October 2020 | Comments Off on Underhanded Code and Automation

So, software is eating the world—and you thought this was going to make things simpler, right? If you haven’t found the tradeoffs, you haven’t looked hard enough. I should trademark that or something! 🙂 While a lot of folks are thinking about code quality and supply chain are common concerns, there are a lot of little “side trails” organizations do not tend to think about. One such was recently covered in a paper on underhanded code, which is code designed to pass a standard review which be used to harm the system later on.

Everyone Must Learn to Code

14 September 2020 |

The word on the street is that everyone—especially network engineers—must learn to code. A conversation with a friend and an article passing through my RSS reader brought this to mind once again—so once more into the breach. Part of the problem here is that we seem to have a knack for asking the wrong question. When we look at network engineer skill sets, we often think about the ability to configure a protocol or set of features, and then the ability to quickly troubleshoot those protocols or features using a set of commands or techniques.

The Hedge 18: Programming Fundamentals for Network Engineers

15 January 2020 | Comments Off on The Hedge 18: Programming Fundamentals for Network Engineers

Network engineers do not need to become full-time coders to succeed—but some coding skills are really useful. In this episode of the Hedge, David Barrosso (you can find David’s github repositories here), Phill Simmonds, and Russ White discuss which programming skills are useful for network engineers.

Lessons Learned from the Robustness Principle

29 July 2019 | Comments Off on Lessons Learned from the Robustness Principle

The Internet, and networking protocols more broadly, were grounded in a few simple principles. For instance, there is the end-to-end principle, which argues the network should be a simple fat pipe that does not modify data in transit. Many of these principles have tradeoffs—if you haven’t found the tradeoffs, you haven’t looked hard enough—and not looking for them can result in massive failures at the network and protocol level.

Another principle networking is grounded in is the Robustness Principle, which states: “Be liberal in what you accept, and conservative in what you send.” In protocol design and implementation, this means you should accept the widest range of inputs possible without negative consequences. A recent draft, however, challenges the robustness principle—draft-iab-protocol-maintenance.

According to the authors, the basic premise of the robustness principle lies in the problem of updating older software for new features or fixes at the scale of an Internet sized network. The general idea is a protocol designer can set aside some “reserved bits,” using them in a later version of the protocol, and not worry about older implementations misinterpreting them—new meanings of old reserved bits will be silently ignored. In a world where even a very old operating system, such as Windows XP, is still widely used, and people complain endlessly about forced updates, it seems like the robustness principle is on solid ground in this regard.

Exaggerating the End of NetEng

19 December 2016 |

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…

snaproute Go BGP Code Dive (14): First Steps in Processing an Update

12 December 2016 | Comments Off on snaproute Go BGP Code Dive (14): First Steps in Processing an Update

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…

snaproute Go BGP Code Dive (13): Finding the tail of the update chain

31 October 2016 | Comments Off on snaproute Go BGP Code Dive (13): Finding the tail of the update chain

Just in time for Hallo’ween, the lucky thirteenth post in the BGP code dive series. In this series, we’re working through the Snaproute Go implementation of BGP just to see how a production, open source BGP implementation really works. Along the way, we’re learning something about how larger, more complex projects are structured, and also…

snaproute Go BGP Code Dive (12): Moving to Established

10 October 2016 | Comments Off on snaproute Go BGP Code Dive (12): Moving to Established

In last week’s post, the new BGP peer we’re tracing through the snaproute BGP code moved from open to openconfirmed by receiving, and processing, the open message. In processing the open message, the list of AFIs this peer will support was built, the hold timer set, and the hold timer started. The next step is…

snaproute Go BGP Code Dive (11): Moving to Open Confirm

26 September 2016 | Comments Off on snaproute Go BGP Code Dive (11): Moving to Open Confirm

In the last post in this series, we began considering the bgp code that handles the open message that begins moving a new peer to open confirmed state. This is the particular bit of code of interest— case BGPEventBGPOpen: st.fsm.StopConnectRetryTimer() bgpMsg := data.(*packet.BGPMessage) if st.fsm.ProcessOpenMessage(bgpMsg) { st.fsm.sendKeepAliveMessage() st.fsm.StartHoldTimer() st.fsm.ChangeState(NewOpenConfirmState(st.fsm)) } We looked at how this…

snaproute Go BGP Code Dive (10): Moving to Open Confirm

12 September 2016 | Comments Off on snaproute Go BGP Code Dive (10): Moving to Open Confirm

In the last post on this topic, we traced how snaproute’s BGP code moved to the open state. At the end of that post, the speaker encodes an open message using packet, _ := bgpOpenMsg.Encode(), and then sends it. What we should be expecting next is for an open message from the new peer to…