The Internet is a mesh of connected computers. The equipment that connected these devices are made of chips. But, in the end, how does data move from one chip to another? I was about to learn.
​

The first generation network chip was configured as a local area network. The new version had more memory and logic. We could use it as a router and that meant we could connect it to other networks in more complex ways.
​

However before we could do that, because it was a new generation, we had to rewrite part of our existing code. I continued to work on the software that I had started earlier. Once the chip was correctly initialized, I implemented each network feature one after another. Controlling the ports, the VLANs, MAC address support, FDB support and lastly, network security rules. For each of these features, choices had to be made on how much memory of the chip we used and which settings we would set.
​

Implementing these was quite interesting because the way a chip works with data is completely different than the way you work with it in software. In the software world there are conditions and loops. In the chip world, it was byte masks and byte replacement.
​

Quickly after that we wrote the software to configure routes on the chip but it was cumbersome to use. Support had to be coded in the information system of both the baremetal team and the cloud team. That would require a lot of work. Isn't there an existing standard to manage routes? There is! It’s called BGP! It’s a protocol to exchange route information between peers.

​

Unlike for the TCP stack I had written, here we could reuse software. I didn't want to rewrite everything. A few software existed and worked on linux, the operating system we used. These software all used an internal operating system protocol. What if we implemented it?
​

So I started to type in the code in my editor. I had the operating system source code and a few other tool’s source code as guides. I could not directly use the code but by looking at the memory of the device and comparing state to state, data to data, I could understand the protocol and implement the features we needed. As the number of lines of code grew, the logic of the code was more and more sound.
​

First testing crafting individual requests by hand, then testing more and more complex workflows. Finally I tested each tool and checked that each action I performed had the result I expected.
​

This was an amazing achievement for me. It was amazing because I had found a way to make the hardware act like a standard linux. I had done this by implementing a not very documented protocol. In a sense, I had broken a mental wall. If we were smart enough with a small amount of work, we could leverage a disproportionate amount of existing tools. By mimicking an abstraction we would enable the team to make the switch to our hardware faster.
​

​

If you have missed it, you can read the previous episode here​

​

​

To pair with :

• Bastion - Cloud Boat
• Foundation by Isaac Asimov