ben-bradley
commented
7 years ago Hi Michael,
You're right. Leonidas needs to be running on a router in the network path between the polling host and the polled device in order to be of any use. Whether all traffic is passed through the host that Leonidas is running on or whether it's just SNMP traffic is an implementation detail. The important part is that iptables is able to process the packets.
If the architecture of the network is such that the poller and polled device are on the same subnet, then there isn't a clean solution that I'm aware of that doesn't involve making changes to the subnetting. The degree to which the proxying/caching is "transparent" is intended to be viewed from the perspective of the polling application, not the network. One of the requirements in designing Leonidas was that polling applications need not be modified or configured in any way. Since many polling applications already live in VMs or containers, it seems not too complex an operation to adjust their routing tables to have the traffic transit the host running Leonidas.
Horizontal scaling is possible, but, again, there needs to be some intelligence in the network routing in order to have traffic pass through the routers hosting Leonidas in a way that makes sense. Given the limitations of SNMP as a protocol, this is the best option that I could come up with.
The techniques that are being employed to enable Leonidas to perform the operation of proxying and caching SNMP requests in a way that is transparent to the polling application aren't optimal, but they do work. Implementing the optimal solutions would require a significant amount of time and energy that would likely not produce a worthwhile return on investment. To paraphrase General Patton: "A good plan now is better than a perfect plan next week."
I saw your post on Reddit and I was a bit too lazy to sign up for an account to add my comments there -- so I'm adding them here.
If I am reading your code correctly, you need to run Leonidas on a router that is in the path between your SNMP Poller and SNMP Device, correct?
That's great if you have the two separated by a router -- but what happens when you have the SNMP Poller sitting on the same network segment as the SNMP Device? The target device is going to get the request, and (depending on interface settings) the Proxy would see the request but can't stop the target device from receiving the request.
If you want to run truly transparently, your options are:
Option #1 requires no changes on your part. You just run somewhere in the network and you have implemented policy routing rules throughout the network that force Source/Destination pairs that don't involve your proxy to punt the packets over to a proxy instance. You're going to run into issues with knowing where the request originated from though. HTTP "solves" this by injecting extra information within the request.
Option #2 Means you physically need to be between the poller and the target. Classic example here is an inline firewall. This option sucks because if your poller dies, then traffic stops flowing. Things also get messy when you start introducing virtual machines or containers. Again, if you live on the same network segment then you're SOL if you're a VM.
Option #3 is what you're doing. You're assuming the poller and the target live on different segments. Normal traffic passes through as-is, and SNMP traffic is proxied.
The problem you are trying to solve is identical to the problem of Web Caching. HTTP has one thing SNMP doesn't: native support for proxies. In addition to Option #2 and Option #3, you can program host endpoints to route HTTP requests directly to Web Caches.
Arguably, the native HTTP support for proxying is the ideal solution. You're pushing intelligence down to the endpoints (keeping the network as a simple transport) and letting the host figure out where to send traffic (Proxy learned via DHCP options, WPAD, etc).
In short, I guess my long winded thought here is that it's a great idea in principle, but you're going to be severely limited in your deployment options. You MUST have a router between the Poller and Device that can run your software. Transparent bridging isn't that much different, but is worse IMO due to bandwidth requirements. You can't easily scale horizontally with bridging -- routing you can spin up more instances and ECMP across them