<div dir="auto">I think the key difference here is that I really just wanted HE to treat my routes no differently no matter how they learned them.   I wanted them to apply normal BGP routing rules to them..  that is, pick the path with the shortest AS path.   <div dir="auto"><br></div><div dir="auto">From a strictly technical basis, its silly to prefer a path of AS6939-ASxxxx-A4043 to a path of AS6969‐AS4043.    I understand the business reasons of wanting to send traffic down circuits where you get paid, but how many intermediate ASNs do there need to be in the middle before it makes sense to ignore the business reasons for doing so?    I guess once you get paid for pushing the traffic one doesn't really care, but at some point one has to look at the network efficiencies here.</div><div dir="auto"><br></div><div dir="auto">In this case, we were purchasing a DSL aggregation service from another regional provider after our DSL customer base reached the point where it no longer made sense for us to maintain our own infrastructure.  What we really needed was a peering connection with them but they were technically unable to make this happen, so it ended up being transit which we found out after the agreement was signed.  </div><div dir="auto"><br></div><div dir="auto">I vaguely remember them giving some reason why they couldn't do a no export on our routes inside their network (maybe running multiple networks under different ASNs due to acquisitions or some technical shortcomings of their network, don't remember for sure).  But one way or another they ended up announcing our routes to HE and couldn't or wouldn't stop doing so. </div><div dir="auto"><br></div><div dir="auto">This basically bit us in the rear with HE which is why I was griping.   HE has such a big footprint that that connection attracted a large percentage of our overall traffic. I would have been happy with any of several common community strings that people use.    Set localpref. Don't export.  And so on.  Just send us traffic literally any other way other than this one.   Or less traffic.  Ideally, setting the localpref to the same value as a peering customer would have been ideal, because then the path length would have been taken as the selection criteria.  I would have been fine if no-export came along for the ride as a side effect. </div><div dir="auto"><br></div><div dir="auto">What ended up happening instead is that the only way we could fix this is that we did the evil things that you discussed and split all of our prefixes in half and announced them everywhere else both ways.    The regional ISP for whatever reason didn't learn the smaller prefixes so the peering worked fine (I suspect they may not have been taking a full table)    And, since we now appeared as a customer of HE we ended up getting transit from them for free across our IX link, although in realty the amount of extra traffic was minimal (except during a couple of network events) .</div><div dir="auto"><br></div><div dir="auto">I really would have rather been able to tell Hurricane to just ignore this route or treat it as a peer or something like that.   </div><div dir="auto"><br></div>This whole service has been disconnected for some time now, so it doesn't really matter much to me other than it still frustrates me that we had to go down the other path to fix this when a commonly implemented community string may have eliminated the need to do so. <br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Mon, Jul 25, 2022, 4:51 PM Tony Wicks <<a href="mailto:tony@wicks.co.nz">tony@wicks.co.nz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">><br>
> I do understand the reasoning behind preferring customer routes.<br>
> However in the case where a customer of a customer also connects to <br>
> you directly via peering doesn't it make sense to prefer the direct <br>
> connection?  or at least not prefer the customer learned routes.<br>
<br>
So from my experience of working at transit providers over more years than I care to contemplate I can assure you what may seem to make sense as a customer does not necessarily translate to how IP routing works. IP has no concept of Customer or Peer it is simply designed to hand the packet to a valid next hop as determined by policies. As such routes are normally divided into customer, peer or further upstream transit if you are not one of the tier 1 providers. A peer provides you no income, a customer (a customer of a customer is largely the same thing as being a direct customer). Take the example of the customer buying a transit service on a 95th percentile basis. So as a transit provider I get paid based on how much traffic I hand to that port(s) and in turn I provide connectivity to all my peers, customers and upstream transits all over the world. I can't do this for free as then I can't pay for my network and I am a company not a charity. Customer X advertises his lets say a /22 to me, all good. But then customer X advertises his /22 and some disaggregated /24's to a local peering exchange that I am also connected to. If I do not both prioritise customer X's customer port routes AND drop any more specific routes learnt from customer X then I will end up handing all customer X's outgoing traffic to them over the peering instead of the revenue generating port. I have seen customers do this both through innocent and malicious intent. Sure, there are a lot of complex policies that I might apply to accept local traffic in one area and hand other traffic via the transit port but why on earth would I do that and likely cause all sorts of other potential routing issues while reducing the revenue I am entitled to?<br>
<br><br>
</blockquote></div></div>