Conversation

Notices

1. Embed this notice
   Erin 💽✨ (erincandescent@akko.erincandescent.net)'s status on Saturday, 27-Apr-2024 03:12:49 JST Erin 💽✨

   • disarray
   @disarray oh yeah that's how I learned my first IXP port had been turned on
   
   I managed to beat them to sending the peering request for the second port though >:)
   • Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Erin 💽✨ (erincandescent@akko.erincandescent.net)'s status on Saturday, 27-Apr-2024 03:15:41 JST Erin 💽✨

     in reply to

     • disarray
     • Stanford
     @tfunken @disarray peering with them is fine, I'd rather send traffic over my IXP port rather than my transit providers IXP port
     
     But their transit is very much a double edged sword and I carefully traffic engineer things so they're mostly a backup
     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Stanford (tfunken@social.lyratris.com)'s status on Saturday, 27-Apr-2024 03:15:42 JST Stanford

     in reply to

     • disarray

     @erincandescent @disarray I am still not sure if peering with HE is a good or bad thing tho :neocat_laugh_nervous:

     Dealing with their network is kinda a pain :neocat_sad:

   • Embed this notice
     Erin 💽✨ (erincandescent@akko.erincandescent.net)'s status on Saturday, 27-Apr-2024 04:01:45 JST Erin 💽✨

     in reply to

     • disarray
     • Stanford
     @tfunken @disarray of course you can do traffic engineering, just your options are a lot more crude
     
     They only get a /44 covering prefix on the transit session. They pick up some more specifics as peering routed from the IXP route servers. I depref their outbound transit routes as applicable because their network especially here isn't very good
     
     So the end result is that traffic mostly goes by them to or from their customers
     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Stanford (tfunken@social.lyratris.com)'s status on Saturday, 27-Apr-2024 04:01:48 JST Stanford

     in reply to

     • disarray

     @erincandescent @disarray Well, that's the thing.
     You can't do traffic engineering with them at all.

     That might not matter if you just have one single location, but as soon as you have multiple and wanna do something like anycast or something, HE is such a pain because they just run one dumb, flat network worldwide.
     No communities, no geo balancing no noting.

     Lets say I have a PoP in DE and one in US.
     Both with a tier 2 transit.

     I do peer with He.net in DE.
     Now all the US traffic flows to DE, because HE thinks this is the best route.

     Now lets say your transit in US is buying transit form HE.net.
     Now all the traffic, including the one form DE is going to the US.
     You might think traffic form DE should go via your DE peering, because this is obviously the shorter way, geographically and also virtually (AS path), but transit routes have a lower metric in the HE network, so the route HE.net learned in the US has a higher priority, even in DE, where you peer with them.

     Soo.. the only way to do "traffic engineering" (if you wanna call it that) with them is either by peer with them at all location you are present, no exceptions, or by avoiding exporting any route to them as a transit route (directly or trough your transits) so HE.net is forced to route via a different tier1 which allows you to do proper traffic engineering, via for example action communities.