Russ

Author Archives: Russ

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 to move to established. RFC 4271, around page 70, describes the process as—

If the local system receives a KEEPALIVE message (KeepAliveMsg (Event 26)), the local system:
 - restarts the HoldTimer and
 - changes its state to Established.

In response to any other event (Events 9, 12-13, 20, 27-28), the local system:
 - sends a NOTIFICATION with a code of Finite State Machine Error,
 - sets the ConnectRetryTimer to zero,
 - releases all BGP resources,
 - drops the TCP connection,
 - increments the ConnectRetryCounter by 1,
 - (optionally) performs peer oscillation damping if the DampPeerOscillations attribute is set to TRUE, and
 - changes its state to Idle.

For a bit of review (because this is running so long, you might forget how the state machine works), the way the snaproute code is written is as a state machine. The way the state machine works is Continue reading

The ever expanding menu…

A short note reminding the gentle readers who wander in to this site of the riches of information available in the main menu to the left of this post…

rule 11 reader takes you to a subscription form for the mailing list. The format and frequency of the mailing list is a little messed up right now, and I always mean to do more with it, but never seem to get around to it.

culture-eats-technologysixty books takes you to a list of books I’ve found particularly helpful or useful over the years. The title isn’t the number of books, strictly speaking, but rather a challenge to read sixty books this year. Not all of these are related to network engineering.

worth visiting is something of a blog role and interesting sites, not all related to network engineering.

author page takes you to a page listing all of my works. Right now this is on Amazon, but as not all my works are available on Amazon, I need to fix this. Yes, it’s already on my list of things to do.

network icons is a set of icons I use in public presentations not tied to a company, etc. These are Continue reading

Reaction: The Power of Unintended Consequences #49687

Warning, some philosophy may have unintentionally slipped into this post…

There are few things in life that ever really change; rather, we are held captive to what appears to be a surprisingly small set of rules that have lasted at least as long as writing seems to have been around, and—if the history of humanity described in writing is any guide—as long as humans have existed (regardless of your thoughts on that particular topic). One of them, for instance, is that there’s nothing truly new; take these few lines, for instance—

A generation goes, and a generation comes,
but the earth remains forever.
The sun rises, and the sun goes down,
and hastens to the place where it rises.
The wind blows to the south
and goes around to the north;
around and around goes the wind,
and on its circuits the wind returns.
All streams run to the sea,
but the sea is not full;
to the place where the streams flow,
there they flow again.
All things are full of weariness;
a man cannot utter it;
the eye is not satisfied with seeing,
nor the ear filled with hearing.
What has been is what will be,
and what Continue reading

Elephant Flows, Fabrics, and I2RS

The last post in this series on I2RS argues that this interface is designed to augment, rather than replace, the normal, distributed routing protocol. What sort of use case could we construct that would use I2RS in this way? What about elephant flows in data center fabrics? An earlier post considers how to solve the elephant flow using segment routing (SR); can elephant flows also be guided using I2RS? The network below will be used to consider this question.

benes-segment

Assume that A hashes a long lived elephant flow representing some 50% of the total bandwidth available on any single link in the fabric towards F. At the same time, A will hash other flows, represented by the red flow lines, onto each of the three links towards the core of the fabric in pretty much equal proportion. Smaller flows that are hashed onto the A->F link will likely suffer, while flows hashed onto the other two links will not.

This is a particularly bad problem in applications that have been decomposed into microservices, as the various components of the application tend to rely on fairly fixed delay and jitter budgets over the network to keep everything synchronized and running quickly. Continue reading