On Wed, 21 Jun 2017, Saku Ytti wrote:
Hey,
Uou're saying, you drop long AS_PATH, to improve customer observed latency? Implication being, because you dropped the long AS_PATH prefixes, you're now selecting shorter AS_PATH prefixes to the FIB?
Absent of this policy, in which scenario would you have inserted the filtered longer AS_PATH prefix to the FIB? I assume only scenario where this happens is where there is larger aggregate route, which is lower latency than the more specific route with longer as_path.
You do have to wonder, what was the thought process that resulted in 35 being the right number of prepends "accomplish" whatever TE they were shooting for? AS path: 10026 9498 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 55644 45271 I don't mean to single out 55644. It's just the first/most obnoxiously long as-path I found when looking for long ones. I seriously doubt provider/customer/customer-of-customer relationships ever get much deeper than a handful or so of ASNs...so if prepending a few times doesn't get it done, 10-20-30 prepends are unlikely to help. In the above case, that long path is actually our best path. We localpref peering above transit. So, it doesn't matter how many prepends, they add, we're never going to not use this path if its available. We have transit paths to these routes that are only a single handful of ASNs long. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________