Peering means "give our downstream customers' routes plus our own routes; receive the same from them".

Transit means "give our entire table, receive their routes plus their downstream customers routes".

You don't give one peer's routes to another. You filter to make sure you are not doing this. They hopefully filter (using data from RIRs) to make sure you're not doing it. If both parties screw up the filtering, you "leak routes" like we're discussing here.

This has been standard practice for peering since at least 1997. It is codified, among other places, in RFC7454.

> And that is why; You seem to have a very strong opinion about something that you don't understand "at all" and frankly I cannot understand how that can work.

Do you operate an AS? Are you a peering contact? I mean, I only do it mostly for funsies now but for quite awhile that was part of my job. :P

Also, still seeking an answer to this question:

> > > Yes, but how does advertising undesirable route B make traffic go over route C [that previously went over route A]? This is why I think you're confused.

▲

geocar 20 hours ago | parent [-]

> Do you operate an AS? Are you a peering contact?

> I mean, I only do it mostly for funsies now but for quite awhile that was part of my job. :P

I'm retired now. I wrote some about my experiences on HN a long time ago:

https://news.ycombinator.com/item?id=18535518

https://news.ycombinator.com/item?id=2727993

I set up multihoming in the US (going through ARIN assignment for ASN and PI) in the early 2000s and for another larger company in the UK (doing the same same but different) in the early 2010s.

> Also, still seeking an answer to this question:

Not sure what to tell you. I've answered this within the context of the news article, if you're asking specifically what kinds of configurations do that they're the kinds that are in that "introductory lab documentation" and if you're not overstating your credentials you should be able to understand.

	▲	mlyle 10 hours ago \| parent [-]
		OK, so you've never actually been involved in peering between providers. That explains things. If you are buying transit for multihomed site, you just mostly need to worry about advertising your few local routes and receiving a table. These words mean specific things in a provider environment. Peering between providers is not transitive. You should not give a peer's routes to another peer-- else you are offering to provide transit to that peer. None of the three parties involved (the peer the route came from, the peer the route would go to, or you), generally, want this. > As soon as I peer with two big sites that don't peer directly with each-other, they both gotta let me forward announcements unfiltered across them. So -- this is true for neither scenario. If you buy transit from two people, you don't want to "forward" routes between them. Likewise for two peers. You only want to pass on your own routes, plus routes for your downstream customers or to your downstream customers. The other topic that caused confusion: leaking a route to somewhere won't change where traffic goes unless that new leaked route wins. If it wins, the traffic will come to you (regardless of AS path). If it doesn't win, the existing route will still be used. I'm retired-ish now, too (now I'm mostly a high school teacher for the funsies). But if you find yourself with BGP infrastructure in HE.NET Fremont, or somewhere that can peer with FREMIX, or somewhere that can access KCIX, feel free to send me a peering request. I currently have 2 direct upstream transit providers and 55 peers across 3 sites and export 6 prefixes plus 2 downstream prefixes :P