valamiért mégis az van, hogy ezt senki nem nagyon csinálja
Mivel én írtam olyan szoftvert, ami ezt csinálja, így el tudom mesélni a történet hátterét: azért nem csinálja szinte senki, mert egy kibaszott nagy szopás már maga az SNMP read is, de a write meg aztán pláne. Eleve értelmesen szinte semmit nem tudsz megcsinálni berendezés struktúra felderítés és cachelés nélkül, majdhogynem semmilyen berendezésen. Különösen nem, ha az eszköz bármilyen mértékben dinamikus struktúrájú tud lenni (ha cserélhető kártyák vannak benne, akkor eleve no-go a dolog, de ha csak vlan-okat, tunneleket, dinamikus subinterfészeket lehet létrehozni, már akkor is kell a struktúra). A legtöbbször azonban még egy fix konfigurációjú kicsi switch esetében sem kiszámíthatóak az interfészindexek (pl. sw verziót váltasz, és elmásznak az indexek). A következő szopatás, hogy a lehető legritkább esetben van akkora cpu az snmp agent mögött, ami bírja, ha nem esetileg, nagyritkán nyúlsz csak hozzá az eszközhöz, hanem folyamatosan basztatod. Nagyon sokszor nem is ütésálló az agent sw, ez fokozottan igaz, amennyiben nem csak a read, hanem a write is képbe jön. Pl. amikor az ügyfél 6500-as Ciscoja attól elcrashelt, mert átírtuk egy interfész description mezőjét SNMP-ből, hát nem voltak boldogok (erre még mi sem számítottunk, teljes főműsoridőben sikerült eljátszani). Egy rendes oprendszeren max. egy snmp daemon crashelne csak ilyen esetben, ugye. A read szemantika általában egyszerű (elküldöd a GET parancsot, és megkapod a választ), a write szemantika viszont sokszor nem ilyen egyszerű: még ha szimplán egy darab SET parancs elég is a kliens oldaláról, a berendezés maga sokszor több dolgot is csinál a háttérben (pl. a konfig sokszor szövegesen van tárolva). És vannak azok a műveletek, amik aszinkron módon hajtódnak végre: elküldöd a paramétereket, a SET elindítja a folyamatot, majd figyelni kell valami státusz mezőben, hogy hol tart a feldolgozás - ilyenkor az is egy gond, hogy egyszerre jellemzően egy folyamatot lehet végeztetni a géppel, külön oda kell figyelni, hogy nem küldheted be a következőt, amíg tart az előző feldolgozás.