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

Reply via email to