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