On Fri, Mar 25, 2022 at 6:19 PM Amir Herzberg <amir.li...@gmail.com> wrote:
> Hi Matthew and NANOG, > > I don't want to defend prepending 255 times, and can understand filtering > of extra-prepended-announcements, but I think Matthew may not be correct > here: > >> Anyone that is prepending to do traffic engineering is >> doing *differential* prepending; that is, a longer number >> of prepends along one path, with a shorter set of prepends >> along a different path. >> >> So, dropping the inbound announcement with 255 prepends >> merely means your router will look for the advertisement with >> a shorter number of prepends on it. >> > > Right. But let's consider the (typical) case where someone is prepending > for traffic engineering. Now, if you're not very near to the origin of the > prepended announcement, and still received it (and not the shorter > alternative), then it is quite likely that you received it since the > alternate path failed - and the backup path was announced, instead (by > upstreams of the origin). So your router is quite likely not to receive the > shorter announcement. > > Note that as-path prepending only matters as a *differential* value. Choosing between 5 and 8 prepends, for example, gives you 3 levels of differentiation between the paths. Prepending 255 times is equivalent to setting MAXCOST in OSPF; it's an overload setting, saying "don't freaking use this path *EVER*". If you want to traffic engineer, you set your less preferred path with say 5 prepends, and your more preferred path with 3 prepends, and your really really preferred path with 1 prepend. If you're setting 255 prepends on a path, that's not traffic engineering, that's equivalent to setting the overload bit; it's the maximum metric equivalent in a link-state routing protocol. It's clearly a DO-NOT-USE indicator, in the same category as community 0xFFFFFF04 or 65535:0 In short--if someone sends me 255 prepends, it's going to be treated the same way as LSInfinity in OSPF. Matt > After all, if your router received both short and long announcements (from > same relationship, e.g., both from providers), then your router would > probably select the shorter path anyway, without need to filter out the > long one, right? > > So, filtering announcements with many prepends may cause you to lose > connectivity to these networks. Of course, you may not mind losing > connectivity to Kazakhstan :) ... > > best, Amir > >> >> >> -- > Amir Herzberg > > Comcast professor of Security Innovations, Computer Science and > Engineering, University of Connecticut > Homepage: https://sites.google.com/site/amirherzberg/home > `Applied Introduction to Cryptography' textbook and lectures: > https://sites.google.com/site/amirherzberg/applied-crypto-textbook > <https://sites.google.com/site/amirherzberg/applied-crypto-textbook> > > > > > On Fri, Mar 25, 2022 at 8:19 PM Matthew Petach <mpet...@netflight.com> > wrote: > >> >> >> On Fri, Mar 25, 2022 at 2:59 PM Adam Thompson <athomp...@merlin.mb.ca> >> wrote: >> >>> Tom, how exactly does someone “ride the 0/0” train in the DFZ? >>> >> >> It's not so much "ride the 0/0 train" as much as it is >> "treat excessive prepends as network-unreachable" >> >> Think of prepends beyond say 10 prepends as a way >> to signal "infinite" distance--essentially, "unreachable" >> for that prefix along that path. >> >> Anyone that is prepending to do traffic engineering is >> doing *differential* prepending; that is, a longer number >> of prepends along one path, with a shorter set of prepends >> along a different path. >> >> So, dropping the inbound announcement with 255 prepends >> merely means your router will look for the advertisement with >> a shorter number of prepends on it. >> >> If you're only announcing one path for your prefix, and it is >> prepended 255 times, you're fundamentally not understanding >> how BGP works, and the only way to get a clue-by-four might >> be to discover you've made your prefix invisible to a significant >> portion of the internet. >> >> >>> >>> >>> I’m connected to both commercial internet and NREN, and >>> unfortunately-long paths are not uncommon in this scenario, in order to do >>> traffic steering. If there’s another solution that affects global >>> *inbound* traffic distributions, I’d love to hear about it (and so >>> would a lot of my peers in edu). >>> >>> >>> >>> If there were a usable way to “dump” the excessively-long path only as >>> long as a better path was already known by at least one edge router, that >>> might be workable, but you’d have to keep track of it somewhere to >>> reinstall it if the primary route went away… at which point you may as well >>> have not dropped it in the first place. >>> >>> >> You dump the excessively-long path based on the assumption that >> the only reason for a long set of prepends out one path is to shift >> traffic >> away from that path to one that you're advertising out with a *shorter* >> set of prepends. >> >> The router doesn't need to 'look' for or 'keep track' of the different >> path; the human makes the decision that any sane BGP speaker >> would only prepend 255 times on a path if there was a shorter >> as-path advertisement they wanted people to use instead. >> >> So, drop the excessively long prepended path, and make use >> of the 'should be in the table somewhere' advertisement of the >> prefix with fewer prepends. >> >> Easy-peasy. >> >> >>> >>> >>> -Adam >>> >>> >>>
