Hacker News Reader

Comment by yardstick | Hacker News Reader

The problem with talking to a telco, is you have to talk with not just one but any your customer may use. And if at the customer location there’s multiple routers in between the cameras and that telco router, it’s a shitshow trying to configure anything.

Much easier to drop some router on site that is telco neutral and connect back to your telco neutral dc/hq.

View on HN

The Metro Ethernet Forum standardized a lot of services telcos can offer, many years ago

No good when the upstream is some wifi connection provided by the building management, rather than a telco themselves.

May as well pick a single solution that works across all Internet connections and weird setups, be an expert in that, vs having to manage varying network approaches based on telco presence, local network equipment, operating country, etc.

That's all true, but you can also, you know, like, talk to people without buying your whole solution from them :)

(btw, have you actually read past the first 7 words? I'm much more interested what people think about the latter parts.)

On the later parts, VRF in my scenarios won’t scale.

Need to provide support access to 10k-50k locations all with the same subnet (industry standard equipment where the vendor mandates specific IP addressing, for better or worse). They are always feeding in data into the core too.

Much easier to just VPN+NAT.

That is a valid point. Though I would probably check first what the scaling limits on VRFs actually are; there was some netdev work a while back to fix scaling with 100k to 1M devices (a VRF is a device, though also a bit more than that). It's only the server ("technician") that needs to have all of these (depends on the setup if that helps or not), intermediate devices just need to forward without looking at the tags, and the VPN entry point only cares about its own subset of customers.

I'd probably use the IPv6 + NAT64 setup in your situation.

Reply on news.ycombinator.com