SNMP protocol

[M a r c o]

(Ik weet niet of dit de juiste afdeling hiervoor is, maar het gaat niet over SNMP voor standaard netwerken of operating systems.)

Ik ben mij momenteel voor mijn werk wat aan het orienteren op het gebied van SNMP.
Ik moet bekennen dat ik er op dit moment nog erg weinig kennis van heb.

Ik wilde even wat van jullie inzichten op dit onderwerp.
Stel dat ik een custom product heb wat bij verschillende klanten in een private netwerk geplaatst wordt.
Dit product is geen router/switch/server of wat dan ook maar een specifiek apparaat met een netwerkaansluiting voor aansturing en SNMP mogelijkheden.
Dit apparaat is geconfigureerd voor monitoring en configuratie via SNMP. MIB file is ook gemaakt.

Ik ben nu eens aan het kijken naar de andere kant van de lijn.
Het NMS (Network management system).
Ik heb wel gezien dat hier honderden programma's voor beschikbaar zijn welke voor een groot deel alleen voor monitoring zijn, of alleen voor standaard apparaten welke automatisch gedetecteerd worden.

Voor wat zover ik heb bestudeerd zie ik de volgende mogelijkheden.
- Het volledig zelf (laten) coden van een management systeem geschikt voor het betreffende product.
- Het kiezen van een management systeem met SNMP ondersteuning voor de protocolafhandeling, en zelf een extensible (juiste term?) (laten) programmaren voor de functies van het betreffende product.
- Klanten met een eigen management systeem de MIB aanleveren en zelf een extensible laten maken. Ik ga er namelijk van uit dat je geen universeel stuk code kan schrijven dat in meerdere management systemen geimplementeerd kan worden.


Voordat ik een lading commentaar krijg dat ik de boel onderschat en dat ik niet weet waar ik aan begin:
Het is niet de bedoeling dat ik dit daarwerklijk zelf op korte termijn moet gaan uitvoeren.
Ik ben mij meer aan het verkennen in de mogelijkheden en ik wil zelf meer te weten komen over SNMP.
Er is de mogelijkheid dat ik met de tijd ook embedded software moet gaan maken met SNMP mogelijkheden.


Kan iemand trouwens nog een goed boek aanbevelen om mee te beginnen???
(Engels is geen probleem)

[jvanhambelgium]

Als jouw product nu volledig SNMP v1/2/3 compliant is, kan je toch zowel de monitoring als configuratie via SNMP doen ? Als jou MIB alle OID's bevat die jou product verstaat ben je toch vetrokken ?

Met een SNMP-SET kan je toch een scala aan instellingen fixen indien je dit wenst ?
Als je echter veel SNMP-SET gebruik moet je mischien wel naar de nodige security kijken, dus SNMPv3 gebruiken...

Of wil je meer kunnen doen dat je niet met SNMP kan ? Vb een "proprietary" management systeem opbouwen om ineens ook rapportjes te kunnen trekken van uw "device" etc ?
Het is een feit dat SNMP voornamelijk voor MONITORING/POLLING gebruikt is
Of zoek je een tool die dan alle config-statements als snmp-sets gaat uitspuwen richting jouw device ?

[M a r c o]

Het product is volledig SNMP compliant.
Ik begrijp dat alles inderdaad mogelijk is met get en set commando's.
Ik vroeg me meer af hoe dit in een bruikbare, overzichtelijke user interface gegoten kan worden voor gebruik in bijvoorbeeld een NOC (Network operation centre) waarin de SNMP zelf onderliggend is.

[jvanhambelgium]

Tja, ik werk als architect op engineering van een firma die een groot NSOC (dus ook security event analysis) heeft runnen.
In de praktijk gebruikt "onze tooling" zelden snmp-sets, ook vanwege security redenenen. (en ook wel betrouwbaarheid, udp enzo je weet wel, niet echt altijd robuust wat je met sommige config-statements of commando's echt wel wilt...)
Als jij inderdaad een GUI wil "aanleveren" (hetzij als fat-client, hetzij web/php based) zou je dit volledig met SNMP-sets kunnen doen, niets houd je tegen ;-)

Alle rapportage, monitoring etc is met snmp-get's en het verwerken van snmp-traps die we van toestel x of y krijgen.
Heel de zooi gaat in ons Netcool platform waarna de operatoren beneden dit effectief "op de console" gaan krijgen te zien en actie kunnen ondernemen.

Als echter jouw "device" zo een beetje speciaal is en slechts zelden voorkomend, dan doe je toch gewoon je zin ?
Of verwacht je dat klanten jouw device gaan integrere in hun eventuele nms ? (HP openview bijvoorbeeld)

[M a r c o]

Het product betreft een soort van QAM modulator die in een netwerk van kabelbedrijven / ISP's gebruikt gaat worden voor de distributie van tv zenders.
Het is niet enkel device wat bij enkele klanten sporadisch kan voorkomen.
Als een klant voor het systeem kiest, dan zal er een heel aantal exemplaren van in het distributie netwerk hangen.
Veel van deze bedrijven hebben zelf NOC's. Ik weet zo snel niet wat voor management systemen daar zoal gebruikt worden, en dat zal ook bij iedere weer anders zijn.
Daar zal ik ook eerst eens wat onderzoek naar moeten doen denk ik.

Het apparaat zal continu gemonitord moeten kunnen worden, en ook moeten er aanpassingen in de configuratie kunnen gebeuren. De vraag gaat dan zijn willen ze het integreren in hun eigen management system wat al draait, waarbij ze dan waarschijnlijk zelf de integratie zullen moeten regelen. Of willen ze een aangepaste GUI die ze naast hun eigen systeem hebben draaien.

[jvanhambelgium]

Tja, voor monitoring en reporting heb je de MIB hé. Als jij de MIB gaat aanleveren kan de klant deze volledig in zijn NMS opnemen en al een héél pak info extracten en monitoren.

Iets lastiger gaat worden voor config-operaties, maar gezien het soort netwerk dat jij daar aangeeft weet ik niet of je echt de snmp-set straat wilt ingaan en niet eerder met een aparte client gaat werken (vb JAVA-based zodat je 'em op zowel windhoos als unix dozen kan draaien)
In NOC's ga je nog veel Unix dozen tegenkomen (Solaris/Linux/HP-UX vb) dus je moet het dan wel ruimer zien als enkel een Win32 binary...

Dat is net waar wij rond werken, het feit dat meer en meer vendor hun "proprietary" systemen hebben. (vb secure webgui's of java/fat clients)
Dat is niet abnormaal hoor, eigenlijk ken ik geen enkele vendor aanraad of met iets komt aandraven dat via snmp-set de boel gaat configureren...security & schaalbaarheid zijn factoren van belang!

[M a r c o]

De apparaten worden ook voorzien van een embedded webserver waarop je kan inloggen en via een webpage ook settings wijzigen.
Het product is trouwens SNMP v2c compliant voor zo ver ik zo snel kan zien
Configuratie via webpage zal dan de voorkeur hebben boven configuratie via SNMP als ik het goed begrijp.
Het apparaat houd ook zelf in zijn eigen flash geheugen een log bij van system events en snmp traps.

In ieder geval al bedankt voor je input. Ik krijg al wat meer inzicht, en heb al wat aanknopingspunten om wat meer informatie te verzamelen. Ik ben geen IT'er maar een elektronicus, dus veel achtergrond kennis op dit gebied heb ik nog niet.

[ Voor 13% gewijzigd door M a r c o op 23-01-2008 16:47 ]

[jvanhambelgium]

Configuratie via web-gui is mooi MAAR soms kan het nuttig zijn om alternativen te zoeken indien je 1000'en devices tegelijk moet wijzigen met bepaalde parameters.
Ik zie de technische mensen echt niet gaan inloggen op waanzinnig veel units...dan kan je vb wel alternativen zoeken door via tftp/scp een nieuwe config-file door te pushen naar het device) OF via een snmp-set het device vragen een nieuwe config te komen afhalen ... hangt allemaal van de mogelijkheden van je device af.

Er zijn verschillende tools die dienen net voor config-management etc voor large-scale deployments (vb HP Opsware)
Kan je op het device ook inloggen met een SSH verbinding om zo in een command-line interface mode te komen ?

Met SNMPv2c moet je qua security toch oppassen , zeker als je niet out-of-band zit !!
Indien je volledig gescheiden zit van customer-traffiek (vb apart kanaal, aparte atm-pvc whatever) is het acceptabel ... anders niet !

[M a r c o]

dan kan je vb wel alternativen zoeken door via tftp/scp een nieuwe config-file door te pushen naar het device

TFTP/SCP ken ik niet, daar zal ik morgen eens naar kijken. Het apparaat ondersteunt wel firmware updates via FTP. Dus config files moeten misschien ook tot de mogelijkheid behoren. Dit zal ik nog uitzoeken

Kan je op het device ook inloggen met een SSH verbinding om zo in een command-line interface mode te komen ?

Ik denk niet dat dit tot de mogelijkheden behoort.

Met SNMPv2c moet je qua security toch oppassen , zeker als je niet out-of-band zit !!
Indien je volledig gescheiden zit van customer-traffiek (vb apart kanaal, aparte atm-pvc whatever) is het acceptabel ... anders niet !

De data is in principe aan de primaire kant in-band. Maar dit netwerk is volledig afgeschermd van de buitenwereld en wordt alleen gebruikt als distributiekanaal voor tv content. Het netwerk is ook bijna volledig fiber. De uitgang van het apparaat is een analoog signaal over coax.

[ Voor 18% gewijzigd door M a r c o op 23-01-2008 18:57 ]

[jvanhambelgium]

TFTP = Trivial FTP , een zwaar vereenvouigde versie van FTP om files te transferren , gaat over UDP en heeft een slechte security.
Die zie je dikwijls bij routers aanwezig op een nieuwe firmware te laden of config-files te tranfserren.

SCP = Secure Copy , om files te versassen over een versleutelde SSH verbinding.

FTP is toch al iets, alhoewel dat je ook weer met een security aspect zit indien out-of-band. Passwords etc zijn gewoon leesbaar over de kabel...

Maar indien je inderdaad out-of-band zit zit het wel snor.

In principe zijn MIB-files redelijk publiek, dus je mag me altijd wel eens een copietje bezorgen dat ik eens kan kijken hoe ie in elkaar zit.
Wie heeft de MIB geschreven ? Heb je zelf de software + mib in ontwikkeling genomen of is het aangeleverd ?

[M a r c o]

De MIB file heb ik zelf nog niet. De betreffende persoon was niet beschikbaar.

Ik denk niet dat ik de MIB file zomaar kan doorsturen. Het product is wereldwijd gepatenteerd en alle documentatie word onder NDA's beschikbaar gesteld.

De softwaren en de MIB zijn extern ontwikkeld. Ik zal volgende week eens een praatje met de programmeur gaan maken.

[Bl@ckbird]

Een paar aanbevelingen:
- Een web interface is handig voor initiële installatie, maar niet om veel units tegelijk te kunnen beheren.

- Baseline in security: Als je een feature niet nodig hebt --> zet het dan uit. Veel apparaten hebben standaard van allerlei services draaien. Deze worden vaak niet gebruikt en vormen alleen een security risico. Je kan er bijvoorbeeld voor kiezen om alleen SNMPv3 te implementeren en SNMPv1 / v2 niet.

Ook kan je er voor kiezen om SNMPv3 standaard uit te zetten; je klant moet het commando geven om SNMPv3 te gebruiken. Dus standaard uit --> tenzij...

Het mooiste is als je netwerkmanagement protocollen gebruikt die encrypt over de lijn gaan. (Zoals SSH i.p.v. telnet) Bij jouw apparaat, speelt dit minder, omdat het een gesloten netwerk betreft.

- SNMP wordt eigenlijk alleen gebruikt om informatie, met een interval, uit het apparaat te pollen. Reageert het apparaat niet, dan weet je dat er wat aan de hand is. Als de verbinding tussen het device en het NMS betrouwbaar is, kun je bijvoorbeeld SNMP traps / SNMP Informs (beter!) of Syslog gebruiken.

- Zorg voor een goede command line interface. ( CLI ) Als een engineer een probleem spot. (bekeken via het NMS via SNMP / syslog / enz.) logt hij vaak via het NMS op de box zelf in. Tekst commando's lijken oud, maar zijn erg krachtig.
Op de box zelf maar ook vanuit veel NMS systemen kun je commando's scripten. ( Eventueel voor duizenden apparaten tegelijk. )

Bij Cisco is CLI bijvoorbeeld standaard. (via seriële console kabel of remote via telnet of SSH.)

- Zorg dat elk apparaat een NTP cliënt heeft. Hiermee kan je er voor zorgen dat de tijd op alle devices gesynchroniseerd wordt. ( Ook op het NMS. ) Zo kan men de time stamps van logging info overal gelijk te trekken. Wanneer een foutmelding zich voor doet op device 1 om 12:03, is dit ook 12:03 op device 2 en 12:03 op het NMS systeem.

- Met een NMS beheer je meerdere devices ( soms duizenden ) en is vaak een 3rd party.
( HP Openview / IBM Tivoli )

Een EMS ( Element Management System ) wordt door de hardware fabrikant met een apparaat meegeleverd. (Of los erbij verkocht.) Met een EMS kan men een enkel apparaat, of slechts een paar apparaten beheren. (En slechts apparaten van één specifieke fabrikant.)

Bij een NMS ligt de nadruk meer op monitoring en globale configuratie.
Bij een EMS ligt de nadruk meer op configuratie.
( De fabrikant levert het EMS pakket mee en weet alle ins- en outs van zijn eigen hardware en kan zijn eigen EMS daar tegen aan programmeren.) Maar de grens EMS / NMS is redelijk vaag.

Het bedrijf Adventnet heeft een NMS / EMS systeem voor OEM partners.
Het standaard EMS/NMS platform staat en is geschreven in Java.
Een hardware fabrikant ( OEM ) kan hier zijn eigen software / plug-ins tegen aan programmeren en customizen. Ook de standaard logo's kunnen vervangen worden door het logo van de fabrikant.

- Een CLI via SSH / telnet is een must have. (Al is het maar voor de initiële configuratie of basic debugging. ) SNMPv3 is sterk aan te raden. Syslog is optioneel.
Je kan dus kiezen voor configuratie via een web interface, een customized EMS, of beiden.

[M a r c o]

- Zorg dat elk apparaat een NTP cliënt heeft.

Datasheet vermeld ondersteuning voor (S)NTP.
Dit is dus aanwezig.

[burne]

jvanhambelgium schreef op woensdag 23 januari 2008 @ 16:03:
eigenlijk ken ik geen enkele vendor aanraad of met iets komt aandraven dat via snmp-set de boel gaat configureren...security & schaalbaarheid zijn factoren van belang!

Cisco, Juniper, Extreme, Foundry, HP, IBM? HP Openview, CiscoWorks, Tivoli, OpenNMS, Tandberg NMS, Infinera?

Zo'n webinterface met een dikke java-applet schaalt natuurlijk heel mooi als je 220.000 nodes te onderhouden hebt in een netwerk wat heel Nederland omvat. Even drie bussen uitzendkrachten huren om een kleine aanpassing in de standaard-instellingen van je netwerk te verrichten, en dan nog drie dagen bezig zijn..

Juist als schaalbaarheid een punt is, is SNMP een prima oplossing, en op het niveau waar de 'echte jongens' spelen is het aanleggen van een dedicated management-netwerk geen punt. Het vezeltje naar Groningen kost toch al tonnen per maand, dus dat huurlijntje van een paar duizend euro per maand kan ook nog wel op de hoop, dat is een procent van de maandelijkse kosten.

[jvanhambelgium]

@burne,

Ik heb niet gezegd dat het technisch niet gaat, ik zeg dat ik niet denk dat veel NOCs het effectief op deze manier doen (het onze toch niet met zo'n 500.000 elementen) en ik geen producten ken die het vanuit hun "management tool" rechtstreeks zo doen

Vb.

Junipers (SSG's of IDP/IPS) beheren we met de NSM (Netscreen Security Manager) wegens schaalbaarheidsredenen.
Tussen de NSM en zijn "end-devices" in het veld zit een volledig versleutelde proprietary SSP (secure server protocol) TCP connectie waardoor alles gaat.
Als jij vanuit de NSM config-wijzigingen maakt op deze devices, gaat er uiteindelijk doorheen de SSP-flow vanuit de device-server "cli statements" ,


In het verleden heb ik ook wel via snmp-set mijn dagelijkse IOS configjes via TFTP gepushed van een device naar een centrale TFTP-server. Gewoon op FreeBSD met wat scriptjes dat via cron netjes in schedule liep.
Toch merkte ik soms dat bepaalde "set" statement niet altijd goed aankwamen :

- udp, dus spray & pray. niet echt de betrouwbaarste.
- snmp-agents hebben niet altijd de hoogte priority op een device en een drukke router of fw kan al eens wat milliseconden op zich laten wachten...waar door je some het "set" statement een 2e keer moet uitvoeren...In onze architecture gebruiken we een "node" op de klanten LAN die eigenlijk alle snmp-data reeds accepteerd en vervolgens binnen onze Netcool architectuur verder gaat verwerken over een VPN etc.De snmp gegevens zo door de (encrypted) WAN sturen is geen goed idee want dan gaan we wel eens een eventje missen vrees ik...

- tenzij je SNMPv3 gebruikt zit het met security behoorlijk mis. Op een dedicated out-of-band kan ik het nog accepteren.

Wat de large-scale deployments betreft. meest grote producten laten toe (multi-tier architecture, role-based) om bepaalde aanpassingen "in groep" te maken. Ook kan je simultaan met meerdere administrators werken.

(mijn) conclusie : voor device MONITORING/REPORTING is snmp zeer geschikt, voor CONFIG-MANAGEMENT zal je SNMP niet zoveel zien als primair protocol.
Het KAN technisch uiteraard meestal wel, maar als je tooling bekijkt als "HP Opsware" zie je dat ie dikwijls een cli-sessie openzet om statements te pushen/retrieven etc.

[ Voor 16% gewijzigd door jvanhambelgium op 25-01-2008 08:14 ]

[FireStarter]

Ik ben op dit moment me ook aan het orienteren op het gebied van SNMP. Met name SNMPv3.

We doen klantennetwerken monitoren deels inband deels out-of-band. Omdat we weinig aandacht hebben besteed aan beveiliging willen we gaan kijken wat de mogelijkheden zijn om SNMPv3 te gaan implementeren. Authenticatie en encryptie is wenselijk geworden.

Ben vooral nu geinteresseerd in wat voor effect SNMPv3 zal hebben. 2 van de 3 applicaties ondersteunen iig SNMPv3, voor de andere moet ik nog een oplossing zoeken.

Moet je nog met andere zaken rekening houden als SNMPv3 wordt geimplementeerd behalve de monitortools die je gebruikt?

[jvanhambelgium]

Bij SNMPv3 heb je voornamelijk een nieuwe "message processing module" die eigenlijk de SNMPv1/v2 PDU's gaat encapsuleren in een SNMPv3 pakket.
Zoals je weet zijn authenticatie en integriteit een feit.

Ik denk niet dat je met andere zaken moet rekening houden wat "puur" SNMP betreft. Je agent & manager relatie moet gewoon SNMPv3 compliant zijn.

Je hebt door de grotere granulariteit van SNMPv3 (USM , VACM) wel iets meer config werk op de end-devices, maar dat is niet echt verwonderlijk.

Voor applicatie die niet SNMPv3 compliant zijn zal je een oplossing moeten zoek, maar hoeveel SNMP managers heb je dan wel ? Of spreek je over de agent kant ?

[FireStarter]

jvanhambelgium schreef op dinsdag 19 februari 2008 @ 13:56:
Bij SNMPv3 heb je voornamelijk een nieuwe "message processing module" die eigenlijk de SNMPv1/v2 PDU's gaat encapsuleren in een SNMPv3 pakket.
Zoals je weet zijn authenticatie en integriteit een feit.

Ik denk niet dat je met andere zaken moet rekening houden wat "puur" SNMP betreft. Je agent & manager relatie moet gewoon SNMPv3 compliant zijn.

Je hebt door de grotere granulariteit van SNMPv3 (USM , VACM) wel iets meer config werk op de end-devices, maar dat is niet echt verwonderlijk.

Voor applicatie die niet SNMPv3 compliant zijn zal je een oplossing moeten zoek, maar hoeveel SNMP managers heb je dan wel ? Of spreek je over de agent kant ?

Sorry van het late bericht.

Nou ik ben nu aan het bekijken hoe SNMPv3 geimplementeerd zal moeten gaan worden met name dat USM en VCAM waar je het over had moet ik nog eens goed bestuderen.
Wat ik tegen kwam is Distributed SNMP Security Pack, te verkrijgen via snmp.com. Daar kan je via een java applicatie de security groepen enzo gaan aanmaken. Zou dit goed werken? Of zou je dit op een goedkopere manier kunnen doen?

Verder ben ik ook aan het onderzoeken hoe alles schaalbaar kan worden uitgerold. Met name paswoorden moeten goed te beheren zijn, niet dat je tig sleutels heb.

Het gaat om heel erg veel agents en verschillende managers.

Ben trouwens ook wel benieuwd naar het effect van de encryptie, hoezeer dit de managerkant zal gaan beïnvloeden kwa CPU kracht hiervoor nodig is.

Heb je trouwens al ervaring met het implementeren van SNMPv3?

[jvanhambelgium]

Wij gebruiken (voorlopig) geen SNMPv3, onze tooling is hier nog niet helemaal klaar voor.
Sowieso gebruiken we geen snmp-sets, dus wijzigingen laten we niet toe.
Verder natuurlijk loopt alles zoveel mogelijk over encrypted links waar we iets niet als "trusted" beschouwen, maar dat hangt per situatie af wat acceptabel is...

Ik ben niet echt een developer dus rond die SDK kan ik niets zinnigs zeggen.
Qua schaalbaarheid moet je gewoon deze info mee in een CMDB zetten, daar waar ook andere zaken instaan rond de configs van de elementen enzo. Bepaalde tools kunnen dan zaken uit deze Configuration Management DataBase halen om "dingen" te doen.