A (long) time ago, a reader asked me about RFC4456, section 10, which says:
Care should be taken to make sure that none of the BGP path attributes defined above can be modified through configuration when exchanging internal routing information between RRs and Clients and Non-Clients. Their modification could potentially result in routing loops. In addition, when a RR reflects a route, it SHOULD NOT modify the following path attributes: NEXT_HOP, AS_PATH, LOCAL_PREF, and MED. Their modification could potentially result in routing loops.
On first reading, this seems a little strange—how could modifying the next hop, Local Preference, or MED at a route reflector cause a routing loop? While contrived, the following network illustrates the principle.
Note the best path, from an IGP perspective, from C to E is through B, and the best path, from an IGP perspective, from B to D is through C. In this case, a route is advertised over eBGP from F towards E and D. These two eBGP speakers, in turn, advertise the route to their iBGP neighbors, B and C. Both B and C are route reflectors, so they both reflect the route on to A, which advertises the route to some other Continue reading
I’ve reorganized the menu on the left just a little, combining some items under “reading,” and adding a new item called “topics.” Under this new item, you’ll find collections of articles on specific topics from other sources, starting with the ‘net neutrality page and the meltdown and spectre post reformatted as a page, with some new additions. I’m always trying to find new ways to organize the information here, making it easier to find things; hopefully this is a useful change.
In a recent comment, Dave Raney asked:
Russ, I read your latest blog post on BGP. I have been curious about another development. Specifically is there still any work related to using BGP Flowspec in a similar fashion to RFC1998. In which a customer of a provider will be able to ask a provider to discard traffic using a flowspec rule at the provider edge. I saw that these were in development and are similar but both appear defunct. BGP Flowspec-ORF https://www.ietf.org/proceedings/93/slides/slides-93-idr-19.pdf BGP Flowspec Redirect https://tools.ietf.org/html/draft-ietf-idr-flowspec-redirect-ip-02.
This is a good question—to which there are two answers. The first is this service does exist. While its not widely publicized, a number of transit providers do, in fact, offer the ability to send them a flowspec community which will cause them to set a filter on their end of the link. This kind of service is immensely useful for countering Distributed Denial of Service (DDoS) attacks, of course. The problem is such services are expensive. The one provider I have personal experience with charges per prefix, and the cost is high enough to make it much less attractive.
Why would the cost be so high? The same Continue reading
Just a friendly reminder that I keep the ‘net Neutrality page up to date with a selection of articles I find from all sorts of different viewpoints. I am trying to avoid the “this is what you can do,” and “the fight is not over” sorts of articles, and focus on arguments making points in either one direction or the other, or some perspective I have not seen before.
I just added three more articles today.
While many have already seen something on these two, this is the best set of articles I’ve found on these vulnerabilities and the ramifications.
You don’t have to worry if you patch. If you download the Continue reading
Another installment in the History of Networking over at the Network Collective. This time we continue the conversation with Alistair Woodman on the history of Voice over IP.
Network Engineering and coding, like many other things in the information technology world, share overlapping concepts—even if we don’t often recognize the overlap because we are too busy making up new names to describe the same thing. For this week’s video, I turn my attention to the Application Programming Interface, or the API.
I won’t be publishing anything here from the 25th through the 29th, so the next post here will be next year, in 2018.