Comment by geocar
4 days ago
> Please let me know of the scenario where route A is preferred, undesirable, long-path route B is advertised/leaked, and as a result traffic flows over route C.
> ... I'm really curious what you're thinking
That the actor actually wanted the traffic to flow over route C.
> You know what's really toxic? Not explaining what you mean and just sending some introductory lab documentation about what the other person has already clearly shown they understand.
I think perhaps you and I have different ideas of what is "clear", for example when you said something that is totally covered in introductory lab documentation, I thought it was clear that you did not understand.
> I don't even know what you mean by a lot of these things
That is clear! But confusing! How can you clearly understand but not know what I mean?
> Peering means to give your own routes (and your transit customers' routes) to someone else.
That's exactly what's happening here: Not every transit customer peers with every other transit customer.
> > Please let me know of the scenario where route A is preferred, undesirable, long-path route B is advertised/leaked, and as a result traffic flows over route C.
Yes, but how does advertising undesirable route B make traffic go over route C? This is why I think you're confused.
> That's exactly what's happening here: Not every transit customer peers with every other transit customer.
I am not understanding what you're saying at all. You said:
> > > > 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.
This is the thing you are supposed to never do as a peer, and the thing that I have a whole bunch of filtering to prevent my peers from inadvertently doing.
Are you misusing the word "peer"? It's hard to talk about BGP and routing policy without using these words correctly.
I think I'm going to give up here.
> This is why I think you're confused.
I think you're confused.
> I am not understanding what you're saying at all.
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.
> This is the thing you are supposed to never do as a peer
So you say, but that's what I did when back in the early 2000s, and that's what the parties in the news were doing, and if you're not totally lying to me, you know this because it's the default in BGP, that's why you would say you need to:
> I have a whole bunch of filtering to prevent my peers from inadvertently doing.
because that's how BGP works. Duh.
> It's hard to talk about BGP without using these words correctly.
and I am flabbergasted you continue to persist at it, when I have even offered you "introductory lab documentation" to help.
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.
2 replies →