On Mon, 25 Jul 2022 at 17:19, Brian Turnbow via NANOG <nanog@nanog.org> wrote:
Hi,
I do understand the reasoning behind preferring customer routes. However in the case where a customer of a customer also connects to you directly via peering doesn't it make sense to prefer the direct connection? or at >least not prefer the customer learned routes.
Business not technical. Fill up the bandwidth and they will buy more!!
In our situation, we were buying transit, heavily prepended, from a provider on a tiny circuit. The purpose of the transit was related to another service we were acquiring from that provider and wasn't about the transit, but >the transit was needed for the service to work reliably. Unfortunately this provider was also a HE customer and so we now had all of the HE traffic coming down this tiny link, since all of our other transit providers and >ourselves only peered with HE.
I don't remember why, but we couldn't have the transit provider not announce our routes toward HE, so we ended up doing the announce more specifics everywhere else thing. Which I hate doing on so many levels.
Thus the desire for a community to tell HE that although they learned this route from a customer, it is not a customer route.
You can use communities to set the local preference with HE. This should do the trick 6730:0008 set local pref to 64 (lowest they have afaik)
Google has let you down, 6730 (sunrise) is not 6939 (HE) ;) Afaik HE does not provide TE communities. Lukas