On Fri, Nov 4, 2011 at 4:11 AM, Randy Bush <[email protected]> wrote: > could someone post a clear technical explanation of WHAT a route leak > is,
I'll bite. It requires carefully a constructed definition, first: "Customer" - A is a customer of B iff A has an arrangement with B which explicitly allows B to announce A's routes to any third party, and for B to announce B's entire routing table to A. Customer is a technical arrangement, regardless of how or why that arrangement was arrived at, e.g. paying money. If A is a customer of B, A is allowed to announce A's own routes (and by extension A's customer's routes) to B. A _may_ (or may not, at A's discretion) signal to B that A wishes B to forward all (or a subset) of A's (and A's customers) routes to third parties. A is not _required_ to do so, and A may further signal that B should only send those prefixes to a subset of third parties with whom B peers. (Observe: B may always announce A's routes to B's other customers.) A route leak occurs, when B announces non-customer routes to non-customers. (Those would be routes for which B has not been given explicit _blanket_ permission to announce to third parties.) If A (a customer of B) signals to B to not announce a subset of routes to B's non-customers, but B does so anyways, that would _not_ constitute a true route-leak as such. (It would, however, be a contractual and technical issue that would normally be resolved between A and B.) If it helps, I've tried to illustrate the leak/no-leak distinction below... Brian Examples - in the following, I'll use "->" or "<-" to indicate customer relationships, and "-" to indicate non-customer (peer) relationships. The route traverses the AS's left-to-right. A is the originating ASN, and the highest letter is the receiving ASN. The following are non-route-leak paths from announcer to receiver: A - B (A peers with B) A -> B (A is a customer of B) A <- B (B is a customer of A) A -> B <- C A <- B <- C A -> B -> C A -> B -> C - D A -> B - C <- D A - B <- C <- D A -> B -> C - D <- E <- F (and so on) (There can be only one "-", and all the arrows must point towards the "-" in the ASCII stick diagram.) Any of these would be route leaks: A - B - C A <- B -> C A - B -> C A <- B - C A -> B - C -> D A <- B <- C -> D -> E (This is one of the most common sources of route-leaks. It is one of the easiest mistakes for a network engineer to do.) A -> B -> C - D <- E <- F -> G -> H (This is how the previous example usually is seen in the wild) A -> B -> C - D <- E - F <- G (Here E is accidentally providing transit to F) The special case of mutual customers (mutual transit) would be represented as: A <-> B Mutual transit/customer arrangements can legitimately do the following: A -> B <-> C -> D A <- B <-> C <- D A - B <-> C <- D A -> B <-> C - D Basically, on any given prefix announcement, "<->" can be treated as either "<-" or "->" in order to fit the "allowed" rules. If neither of those substitutions fits an existing "allowed" rule, then the result would be a route leak. Examples of mutual-transit leaks: A - B <-> C - D A <- B <-> C -> D A - B <-> C -> D _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
