• 3 Posts
  • 25 Comments
Joined 1 year ago
cake
Cake day: July 9th, 2023

help-circle

  • Just updated and it looks like this one fixed the log spam:

    json_loads was called from hacs, this is a deprecated function which will be removed in HA Core 2025.8. 
    Use homeassistant.util.json.json_loads instead, please create a bug report at https://github.com/hacs/integration/issues
    

    It’s a little weird they don’t have a download update button on the new HACS dashboard for an individual repository, now you have to go to Settings > Updates. I also wish I could hide new and available repositories and only show the ones I have installed (you can’t seem to select Pending Restart, Pending Update, and Downloaded at the same time.)


  • There’s two main ways of doing geo-based load balancing:

    1. IP Any-casting - In this case, an IP address is “homed” in multiple spots and through the magic of IP routing, it arrives at the nearest location. This is exactly how 1.1.1.1 and 8.8.8.8 work. It works fine for stateless packets like DNS, however it has some risks for stateful traffic like HTTP.
    2. DNS based load balancing. A server receives a request for “google.com”, looks at the IP of the DNS server and/or the EDNS Client IP in the DNS query packet and returns an IP that’s near. The problem is that when you’re doing Wireguard, it goes phone -> pi-hole (source IP is some internal IP) -> the next hop (e.g. 1.1.1.1 or 8.8.8.8), which sees the packet is coming from your home/pi-hole’s public IP. Thus it gets confused and thinks you’re in a different location than you really are. Neither of these hops really knows your true location of your phone/mobile device.

    Of course, this doesn’t matter for companies that only have one data center.


  • Sorry, what do you mean route it directly? Maybe I didn’t clarify well enough.

    My DNS is routed over the VPN but Internet traffic is routed directly. The problem is the load balancing is done based on where the DNS server is so say Google even though the traffic egresses directly to the internet bypassing the VPN it still goes to a Google DC near my home. Not all websites do this so its not always an issue.



  • I have Wireguard and I forward DNS and my internal traffic from my phone over the VPN to my pi-hole at home. All other traffic goes directly over the Internet, not the VPN. So that means only DNS encounters higher latency.

    However, because a lot of companies do DNS based geo load balancing that means even if I’m on the east coast all my traffic gets sent to the West Coast because my DNS server is located there. That right there has the biggest impact on latency.

    It’s tolerable on the same continent, but once I start getting into other continents then it gets a bit slow.













  • One of the problems with the cloud-polling integrations is that they will frequently poll the back-end APIs to get the current status of that device. A normal user might only open up the app once or twice a day and call the APIs, but these integrations will go 24/7 every 10s-5m. That can add up to a non-trivial amount of traffic. If there’s 100 users opening it up once a day, that’s not a lot of traffic, but 10 users polling every 1 minute is equivalent to 15k people doing something once a day.

    I actually saw one of my integrations I used defaulted to updating every 10 seconds. I decreased that because I didn’t want to draw attention to it.

    A business will look at their usage and ask why there’s more than expected traffic. They could be running their server on a potato. They could go back and support Matter, that costs money, requires skilled engineers, and cuts into profit margins.

    While it sucks, that is something they could point to in a court about “economic harm”.






  • Will I still need to consider multicast DNS if my DNS server is on-prem (Pi-Hole + Unbound)

    Multicast DNS is separate from DNS, so even if you have Pi-Hole, you’d still have devices using mDNS. It’s possible to route mDNS across separate IP networks seeing as how there’s mDNS relays across VLANs which would suggest Wireguard could support Multicast. Other things use Broadcast (e.g. WoL) which is a bit more challenging to forward across IP networks.

    I’m not familiar with GRE so I couldn’t comment on whether it’s possible or not. I guess it all depends on how confident you are with your networking skills. If you get it working, you should definitely document it and share with others.

    I didn’t quite do what you did, but I ran HA in a Kubernetes cluster which was logically a separate IP network. I had to setup the container with multiple network interfaces and specially craft the route table to forward broadcasts + multicast traffic to the correct network.