Using SNMP to control switches to set VLANS

[SahilTikale]

We should have a better way to set VLANS programmatically than using pexpect due to the problems discussed in #744. @pjd-nu gave us super overview of how SNMP works and what troubles we may encounter (like it is good for reading stuff from hardware, but writing to hardware can be tedious at times)

I, @henn, @naved001, @pjd-nu agree that this can be a good internship project.
Explore, understand SNMP and come up with a solution to set VLANS using it.

[ianballou]

I'm going to start working on this one. Right now I've gotten python-easysnmp setup locally on my machine to get up to speed with SNMP queries. I'll talk with @naved001 later about getting access to our switches.

[ianballou]

For the PowerConnect, so far I've discovered that updating Access mode VLANs is easy using SNMP OID 1.3.6.1.4.1.89.48.62.1.1.<port#>. I haven't yet found a way for accessing/editing the Trunk mode VLANs. On a side note, I did discover that it's pretty easy to deal with VLANs on ports set to General mode.

[zenhack]

Cool, keep up the good work.

The reason we wrote the telnet drivers in the first place was that @pjd-nu had spent about a day fighting with the powerconnect's MiB, and we decided it was best to just get something working so we could unblock things. So it might take a bit of digging to work everything out; keep us posted.

Happy hacking.

[SahilTikale]

Best of luck @Izhmash. I am curious to know the outcome. Keep us posted.

[ianballou]

In exploring the options with SNMP so far I have a good feeling that it will be usable in our switch drivers. However, the drivers will still need to be unique for different switch models. For example, the Dell switches have different SNMP MIBs than the Cisco switches, so a unified driver wouldn't be possible.

Is it an issue for anyone that the drivers wouldn't be unified? I understand that Pexpect and Telnet was a workaround, but I'm not sure how strongly we feel collectively about moving away from it.

[zenhack]

That was my expectation.

Fine to start with one driver for now; they're independent, so no need to do them all at once.

[henn]

After an extended conversation with myself, @pjd-nu @naved001 and @Izhmash, we decided that SNMP doesn't make sense. Reasons included:

[Quotes are from RFC 3535]

• The future for switch configuration seems to be the NetConf API, which has advantages like:
  • transaction support, which could facilitate scaling the operations queue.
  • more standardized for writing config across switches
• At least one vendor is deprecating SNMP in new products (Windows). For others, the sense we had is that SNMP is in maintenance mode rather than adding-features mode.
• The somewhat standard MIBs for SNMP, as far as we can tell, only include the ability to manage with vlan-centric commands that take bitmasks for the ports. This could mean race conditions in cases when some of the ports were managed by another HIL instance or manually. It could also mean difficulty in cases where we wanted to check or set a complete list of VLANs a particular port was connected to, like we do in revert_port().

• The SNMP transactional model and the protocol constraints make it more complex to implement MIBs, as compared to the implementation of commands of a command line interface interpreter. A logical operation on a MIB can turn into a sequence of SNMP interaction where the implementation has to maintain state until the operation is complete, or until a failure has been determined. In case of a failure, a robust implementation must be smart enough to roll the device back into a consistent state.

• For switch-specific operations like enabling jumbo frames or DHCP/ARP snooping, we would have to delve into switch-specific MIBs rather than being able to use standard things.
• If we're going to introduce another tool that requires a large background like SNMP or NetConf, we should ensure it's something that's going to help us going forward. SNMP can vary quite a bit between vendors. NetConf seems to be the future.
• SNMP is typically used for getting/monitoring, rather than setting config info.

o Standardized MIB modules often lack writable MIB objects which can be used for configuration, and this leads to a situation where the interesting writable objects exist in proprietary MIB modules.

• SNMP does have better error handling than our pexpect, but so does NetConf.
• Our Cisco switch in Kaizen supports netconf.

[zenhack]

Works for me. FWIW, the points about "most SNMP implementations" and "newer hardware will support this" don't necessarily preclude having drivers for specific switches be SNMP based if it makes sense for that particular switch -- the beauty of having a well-factored driver API. But I'm totally find just deferring until we've got a more modern technology to switch over to.

…

-Ian

[zenhack]

(Also, thank you guys for recording the points made like this; this is much better re: paper trail than we've mostly been).