At the most basic level, there are only three BGP policies: pushing traffic through a specific exit point; pulling traffic through a specific entry point; preventing a remote AS (more than one AS hop away) from transiting your AS to reach a specific destination. In this series I’m going to discuss different reasons for these kinds of policies, and different ways to implement them in interdomain BGP.
In this post I’m going to cover local preference via communities, longer prefix match, and conditional advertisement from the perspective of AS65001 in the following network—
Communities an Local Preference
As noted above, MED is the tool “designed into” BGP for selecting an entrance point into the local AS for specific reachable destinations. MED is not very effective, however, because a route’s preference will always win over MED, and because it is not carried between autonomous systems.
Some operators provide an alternate for MED in the form of communities that set a route’s preference within the AS. For instance, assume 100::/64 is geographically closer to the [65001,65003] link than either of the [65001,65002] links, so AS65001 would prefer traffic destined to 100::/64 enter through AS65003.
In this case, AS65001 can advertise 100::/64 with Continue reading
Russ White’s BGP series continues with a discussion of building loop-free paths with the Border Gateway Protocol (BGP). Topics include AS (Autonomous System) paths, loop prevention, why loop checks are inbound, and more on IBGP and EBGP. Russ White is a network architect, author, and instructor. You can subscribe to the Packet Pushers’ YouTube channel […]
The post Learning BGP Module 1 Lesson 2: How BGP Builds Loop-Free Paths – Video appeared first on Packet Pushers.
Russ White kicks off a ten-video series on the Border Gateway Protocol (BGP). The series is divided into two modules, with short lessons within each module. This first video covers a brief history of BGP and then gets into the purpose of BPG, reachability vs. a route, Autonomous System (AS) rules, problems that BGP solves, […]
The post Learning BGP Module 1 Lesson 1: Why BGP? – Video appeared first on Packet Pushers.
My third article on privacy and networking is up over at Packet Pushers—
Does an IP address need to be treated like other Personally Indentifiable Information (PII)?
The post Privacy And Networking Part 3: Is An IP Address Protected Information For Privacy? appeared first on Packet Pushers.
At the most basic level, there are only three BGP policies: pushing traffic through a specific exit point; pulling traffic through a specific entry point; preventing a remote AS (more than one AS hop away) from transiting your AS to reach a specific destination. In this series I’m going to discuss different reasons for these kinds of policies, and different ways to implement them in interdomain BGP.
In this post I’m going to cover AS Path Prepending from the perspective of AS65001 in the following network—
Since the length of the AS Path plays a role in choosing which path to use when forwarding traffic towards a given reachable destination, many (if not most) operators prepend the AS Path when advertising routes to a peer. Thus an AS Path of [65001], when advertised towards AS65003, can become [65001,65001] by adding one prepend, [65001,65001,65001] by adding two prepends, etc. Most BGP implementations allow an operator to prepend as many times as they would like, so it is possible to see twenty, thirty, or even higher numbers of prepends.
Note: The usefulness of prepending is generally restricted to around two or three, as the average length of an AS Path in the Continue reading
The US Federal Communications Commission recently asked for comments on securing Internet routing. While I worked on the responses offered by various organizations, I also put in my own response as an individual, which I’ve included below.
I am not providing this answer as a representative of any organization, but rather as an individual with long experience in the global standards and operations communities surrounding the Internet, and with long experience in routing and routing security.
I completely agree with the Notice of Inquiry that “networks are essential to the daily functioning of critical infrastructure [yet they] can be vulnerable to attack” due to insecurities in the BGP protocol. While proposed solutions exist that would increase the security of the BGP routing system, only some of these mechanisms are being widely deployed. This response will consider some of the reasons existing proposals are not deployed and suggest some avenues the Commission might explore to aid the community in developing and deploying solutions.
9: Measuring BGP Security.
At this point, I only know of the systems mentioned in the query for measuring BGP routing security incidents. There have been attempts to build other systems, but none of these systems have been Continue reading
The FR Routing project is a fully featured open-source routing stack, including BGP, OSPF, and IS-Is (among others), supported by a community including NVDIA, Orange, VMWare, and many others. On today’s episode of the Hedge, Tom Ammon and Russ White are joined by Donald Sharp, Alistair Woodman, and Quentin Young to update listeners on projects completed and underway in FR Routing.
My second post on privacy for network engineers is up over at Packet Pushers—
Given the arguments from the first article in this series, if privacy should be and is essential—what does the average network engineer do with this information? How does privacy impact network design and operations? To answer this question, we need to look at two other questions. First, what is private information, precisely? The network carries […]
The post Privacy And Networking Part 2: Legal And Ethical Privacy appeared first on Packet Pushers.
ISDN, while an old technology, is still around in many parts of the world. When will it go away? George Michaelson joins Tom Ammon and Russ White to discuss the end of ISDN. The conversation then veers into old networking technologies, and the importance of ISDN in setting the terms and ideas we use today—ISDN is one of the key technologies around which network engineers built their mental maps of how to build and maintain networks.
I’m teaching a three-hour webinar on troubleshooting on the 22nd of April:
This training focuses on the half-split system of troubleshooting, which is widely used in the electronic and civil engineering domains. The importance of tracing the path of the signal, using models to put the system in context, and the use of a simple troubleshooting “loop” to focus on asking how, what, and why are added to the half-split method to create a complete theory of troubleshooting. Other concepts covered in this course are the difference between permanent and temporary fixes and a review of measuring reliability. The final third of the course contains several practical examples of working through problems to help in applying the theory covered in the first two sections to the real world.
This is offered on Safari Books Online through Pearson. I think that if you register for the course, you can watch a recording later.
You can register for my network troubleshooting course here.
Information about the IEEE Network Softwarification Conference can be found here.
Our upcoming episodes for this month are George Michaelson on the death of ISDN and old networks; an update on the FR Routing project; and Rick Graziani on college and network engineering. Thanks for listening to the Hedge!
DC fabric design is more of an art than a science—a lot of factors come into play, such as future growth, lifecycle management, security, and costs. How can network engineers balance these various factors—how do they even know what questions to ask? Brooks Westrbook joins Tom Ammon and Russ White to discuss three- and five-stage DC fabric design, OPEX, CAPEX, and other topics on this episode of the Hedge.
At the most basic level, there are only three BGP policies: pushing traffic through a specific exit point; pulling traffic through a specific entry point; preventing a remote AS (more than one AS hop away) from transiting your AS to reach a specific destination. In this series I’m going to discuss different reasons for these kinds of policies, and different ways to implement them in interdomain BGP.
In this post, I’ll cover the first of a few ways to give surrounding autonomous systems a hint about where traffic should enter a network. Note this is one of the most vexing problems in BGP policy, so there will be a lot of notes across the next several posts about why some solutions don’t work all that well, or when they will and won’t work.
There are at least three reasons an operator may want to control the point at which traffic enters their network, including: