snaproute Go BGP Code Dive (2)

Now that you have a copy of BGP in Go on your machine—it’s tempting to jump right in to asking the code questions, but it’s important to get a sense of how things are structured. In essence, you need to build a mental map of how the functionality of the protocol you already know is related to specific files and structure, so you can start in the right place when finding out how things work. Interacting with an implementation from the initial stages of process bringup, building data structures, and the like isn’t all that profitable. Rather, asking questions of the code is an iterative/interactive process.

Take what you know, form an impression of where you might look to find the answer to a particular question, and, in the process of finding the answer, learn more about the protocol, which will help you find answers more quickly in the future.

So let’s poke around the directory structure a little, think about how BGP works, and think about what might be where. To begin, what might we call the basic functions of BGP? Let me take a shot at a list (if you see things you think should be on here, feel free to leave a comment—you might think of something I don’t, or we might have different ideas about what these should be, etc.):

• Handle peering sessions
• Receive updates
• Run bestpath
• Install routes into local tables
• Install routes into the Routing Information Base (RIB)

Each of these can be broken down in to a lot of other pieces and parts, but we don’t want to go too deep here for the moment—we’re really trying to guess how the basic functions of the protocol align with directories and files in the actual code. Essentially—If I want to know how this particular implementation of BGP handles peering, where would I look? Now, let’s glance at the actual contents of the SnapRoute’s Go BGP implementation, and see what we can figure out—can we match any functions to directories?

Some of the things here I can guess at just from experience, like (note I’m not going to verify this stuff, and I might be wrong in some cases, but that’s okay, we’re just taking a first stab at figuring out where things might be)—

• api—which means Application Programming Interface. Probably a set of files that declare function calls and the like into other applications.
• flexswitch—since FlexSwitch is the actual name of the project, this probably contains files related to the overall routing engine SnapRoute is creating/maintaining. I would expect to find interfaces and interprocess communication to other processes in the same project, or something like that.
• fsm—means Finite State Machine. A routing protocol can be described as a set of states, with specific events that cause the protocol to shift from one state to another. For instance, when a BGP peer shifts from active to idle,, this is a state change. The FSM would be considered the “heart” of the protocol in many ways.
• ovs—means Open Virtual Switch. This is probably interfaces to OVSDB, which allows this version of BGP to run the OpenSwitch project.
• rpc—means remote procedure call.

Another good place to look is in the /docs directory, which sometimes has useful information about how the code is structured. In this particular case, there is a diagram in the /docs directory that shows a basic overview of the code.

From this we can gather than the neighbor, FSM, and BGP RIB are considered three different modules in the code base. We can also infer there an external database that holds the BGP tables and configuration, accessed through the Thrift RPC. The server module is interesting; we’ll have to watch for this as we start asking the code specific questions, to figure out what this might be used for. I’ll give you hint up front, and say this is a pretty common structure for just about every piece of software that is driven by events.

That’s enough poking around for this post; we’ll look at some tools next, and then start into actually asking the code questions.