Archive

Category Archives for "Russ White"

Hedge 89: Dana Iskoldski and A House Divided

Bluecat, in cooperation with an outside research consultant, jut finished a survey and study on the lack of communication and divisions between the cloud and networking teams in deployments to support business operations. Dana Iskoldski joins Tom Ammon and Russ White to discuss the findings of their study, and make some suggestions about how we can improve communication between the two teams.

Please find a copy of the study at http://bluecatnetworks.com/hedge.

download

The Hedge 88: Todd Palino and Getting Things Done

I often feel like I’m “behind” on what I need to get done. Being a bit metacognitive, however, I often find this feeling is more related to not organizing things well, which means I often feel like I have so much to do “right now” that I just don’t know what to do next—hence “processor thrashing on process scheduler.” Todd Palino joins this episode of the Hedge to talk about the “Getting Things Done” technique (or system) of, well … getting things done.

download

It’s Most Complicated than You Think

It’s not unusual in the life of a network engineer to go entire weeks, perhaps even months, without “getting anything done.” This might seem odd for those who do not work in and around the odd combination of layer 1, layer 3, layer 7, and layer 9 problems network engineers must span and understand, but it’s normal for those in the field. For instance, a simple request to support a new application might require the implementation of some feature, which in turn requires upgrading several thousand devices, leading to the discovery that some number of these devices simply do not support the new software version, requiring a purchase order and change management plan to be put in place to replace those devices, which results in … The chain of dominoes, once it begins, never seems to end.

Or, as those who have dealt with these problems many times might say, it is more complicated than you think. This is such a useful phrase, in fact, it has been codified as a standard rule of networking in RFC1925 (rule 8, to be precise).

Take, for instance, the problem of sending documents through electronic mail—in the real world, there are various Continue reading

The Hedge 87: Jordan Holand and nPrint

The network monitoring world is rife with formats for packets being measured—every tool has its own format. What would make things a lot better for network engineers is a standard data representation for packet analysis, no matter what format packets are captured in. Jordan Holland joins Russ White and Tom Ammon on this episode of the Hedge to discuss the problem and nprint, a standard packet analysis format and tools for converting from other formats.

You can find out more about nprint here.

download

The Hedge 86: TCPLS

TCP and QUIC are the two primary transport protocols in use on the Internet today—QUIC carries a large part of the HTTP traffic that makes the web work, while TCP carries most everything else that expects reliability. Why can’t we apply the lessons from QUIC to TCP so we can merge these two protocols, unifying Internet transport? TCPLS is just such an attempt at merging the most widely used reliable transport protocols.

You can read more about TCPLS here.

download

Illusory Correlation and Security

Fear sells. Fear of missing out, fear of being an imposter, fear of crime, fear of injury, fear of sickness … we can all think of times when people we know (or worse, a people in the throes of madness of crowds) have made really bad decisions because they were afraid of something. Bruce Schneier has documented this a number of times. For instance: “it’s smart politics to exaggerate terrorist threats”  and “fear makes people deferential, docile, and distrustful, and both politicians and marketers have learned to take advantage of this.” Here is a paper comparing the risk of death in a bathtub to death because of a terrorist attack—bathtubs win.

But while fear sells, the desire to appear unafraid also sells—and it conditions people’s behavior much more than we might think. For instance, we often say of surveillance “if you have done nothing wrong, you have nothing to hide”—a bit of meaningless bravado. What does this latter attitude—“I don’t have anything to worry about”—cause in terms of security?

Several attempts at researching this phenomenon have come to the same conclusion: average users will often intentionally not use things they see someone they perceive as paranoid using. Continue reading

Dennis Jennings and the History of NSFNET

The NSFNET followed the CSNET, connecting the campuses of several colleges and supercomputing systems with a 56K core in 1986. The NSFNET was the first large-scale implementation of Internet technologies in a complex environment of many independently operated networks, and forced the Internet community to iron out technical issues arising from the rapidly increasing number of computers and address many practical details of operations, management and conformance. The NSF eventually became the “seed” of the commercialized core of the Internet, playing an outsized role in the current design of routing, transport, and other Internet technologies.

In this episode of the History of Networking, Dennis Jennings joins Donald Sharp and Russ White to discuss the origins and operation of the NSFNET.

You can find out more about Dennis and the NSFNET in the following links.

https://internethalloffame.org/inductees/dennis-jennings
https://en.wikipedia.org/wiki/National_Science_Foundation_Network
https://www.nsf.gov/news/news_summ.jsp?cntn_id=103050
http://arvidc.weebly.com/nsfnet.html

download

Is it really the best just because its the most common?

I cannot count the number of times I’ve heard someone ask these two questions—

  • What are other people doing?
  • What is the best common practice?

While these questions have always bothered me, I could never really put my finger on why. I ran across a journal article recently that helped me understand a bit better. The root of the problem is this—what does best common mean, and how can following the best common produce a set of actions you can be confident will solve your problem?

Bellman and Oorschot say best common practice can mean this is widely implemented. The thinking seems to run something like this: the crowd’s collective wisdom will probably be better than my thinking… more sets of eyes will make for wiser or better decisions. Anyone who has studied the madness of crowds will immediately recognize the folly of this kind of state. Just because a lot of people agree it’s a good idea to jump off a cliff does not mean it is, in fact, a good idea to jump off a cliff.

Perhaps it means something closer to this is no worse than our competitors. If that’s the meaning, though, it’s a pretty cynical Continue reading

The Hedge 84: David Brown and the Root of Trust

Many engineers just assume that secure hardware boot is, in fact, secure. How does this security work, and just how secure is it, though? David Brown joins Tom Ammon, Eyvonne Sharp, and Russ White on this episode of the Hedge to discuss the secure boot loader in some detail. For more information on the secure boot loader and IoT, see David’s presentation at the Open Source Summit.

download

The Effectiveness of AS Path Prepending (2)

Last week I began discussing why AS Path Prepend doesn’t always affect traffic the way we think it will. Two other observations from the research paper I’m working off of are:

  • Adding two prepends will move more traffic than adding a single prepend
  • It’s not possible to move traffic incrementally by prepending; when it works, prepending will end up moving most of the traffic from one inbound path to another

A slightly more complex network will help explain these two observations.

Assume AS65000 would like to control the inbound path for 100::/64. I’ve added a link between AS65001 and 65002 here, but we will still find prepending a single AS to the path won’t make much difference in the path used to reach 100::/64. Why?

Because most providers will have a local policy configured—using local preference—that causes them to choose any available customer connection over other paths. AS65001, on receiving the route to 100::/64 from AS65000, will set the local preference so it will prefer this route over any other route, including the one learned from AS65002. So while the cause is a little different in this case than the situation covered in the first post, the result is the Continue reading

1 23 24 25 26 27 164