Datenkommunikation – VI. Netzw. Management Netzwerkmanagemen t Skript + Computernetze Peterson & Davie, Kapitel 2.3, 3.1.2, 3.3, 7.1, 7.1.2 ASN.1 Ziel:

Präsentation zum Thema: "Datenkommunikation – VI. Netzw. Management Netzwerkmanagemen t Skript + Computernetze Peterson & Davie, Kapitel 2.3, 3.1.2, 3.3, 7.1, 7.1.2 ASN.1 Ziel:"—  Präsentation transkript:

1 Datenkommunikation – VI. Netzw. Management Netzwerkmanagemen t Skript + Computernetze Peterson & Davie, Kapitel 2.3, 3.1.2, 3.3, 7.1, 7.1.2 ASN.1 Ziel: flexible und einfache Anpa ssung des Netzes an veränderte Anforderungen effiziente Nutzung der vorhandenen Netzressourcen Gewährleistung einer konstant hohen Dienstgüte des Netzes Realisierung: Überwachung und Steuerung aller Netzkomponenten physische Ressourcen (Bridges, Router etc.) und logische Ressourcen (OSI Layers, Verbindungen) Softwarekomponenten Austausch von Infos zwischen Management System und logischen Ressourcen 1

2 Datenkommunikation – VI. Netzw. Management Funktionen des Netzwerkmanagements Konfigurations-Management: Test, Diagnose, Fehlerkorrektur Konfiguration, Initialisierung, Beenden, Kontrolle, Namensvergabe, Versionierung Fehler-Management: Versenden von Fehlermeldungen, Überwachung von Fehlerzählern, Test, Diagnose, Fehlerkorrektur Performance-Management: Überwachung des Durchsatzes, der Dienstqualität, des Antwortzeitverhaltens, Analyse der Auslastung Sicherheits-Management: Zugriffsschutz, Zugangskontrolle, Überwachen von Zugriffen auf Netzkomponenten, Datenschutz Abrechnungs-Management: Benutzerverwaltung, Kosten und Rechnungsstellung, Nutzungsbeschränkung, Abrechungsbereiche, Austausch von Kosteninformationen zwischen verschiedenen Bereichen Netzdokumentation 2

3 Datenkommunikation – VI. Netzw. Management Managementsystem ist selbst ein Netzwerkknoten Protokoll: Kommandos und Meldungen an Ressourcen Reaktion sind Zustands- oder Alarmmeldungen Unabhängig vom Kommunikationsverfahren Outband/Inband Management 3

4 Datenkommunikation – VI. Netzw. Management Agenten Protokoll komplex, daher Protokollabwicklung als separate Instanz in einer Komponente vorhanden realisiert in Software oder Hardware Netzwerkkomponente mit Agent = "Probe" Agent auch für mehrere Komponenten möglich 4

5 Datenkommunikation – VI. Netzw. Management Handhabbare Objekte ( managed objects ) nur interessante Eigenschaften einer Ressource sollen verwaltet werden können in Struktur und Eigenschaften sehr verschieden sein Modell / Protokoll: Attribute Kommandos Reaktionen spontane Meldungen (Status, Alarm -> dringlich) fest definiert, falsche Bedienung wird zurückgewiesen Attribut: Namen Zugriffsrecht Wert 5

6 Datenkommunikation – VI. Netzw. Management Operationen auf Objekte 3 Gruppen von Operationen: auf Objekt per se (Erzeugen, Vernichten einer Instanz) auf Attribute (Auslesen, Verändern, Aktionen) vom Objekt initierte Meldungen Operation: Anforderung Rückantwort Reaktionen (bestätigte Operation) spontane Meldungen Parameter: Operationstyp Name des Objekts Attributliste opt. Operationskennung ("Seriennummer") opt. Adresse opt. Berechtigung 6

7 Datenkommunikation – VI. Netzw. Management Management Protokoll und Dienste Protokoll Daten Einheit (PDU) PDU's + Dienst = Management Protokoll Bsp. SNMP Managementdienst abstrahiert vom darunterliegenden Management Protokoll stellt Benutzer Funktionalität zur Verfügung, welche in eintsprechende PDUs umgesetzt wird 7

8 Datenkommunikation – VI. Netzw. Management Management Architektur 8

9 Datenkommunikation – VI. Netzw. Management Rollen eines Managementprozesses Manager & Agentensystem unterscheiden sich durch Ihre Rolle Management Prozess kann seinerseits wieder Agent sein 9

10 Datenkommunikation – VI. Netzw. Management Management Informationen und MIB transparent bzgl. PDU Struktur PDU in ASN.1 Notation MIB: Management Information Base Datenmodell des Netzverwaltungssystems, Summe aller im System bekannten Objektklassen und der Instanzen es können keine neuen Objektklassen angelegt werden MIB Kopie auf Management System und auf Agent MIB ist ein Baum 10

11 Datenkommunikation – VI. Netzw. Management Namen von Objektklassen OID - Object Identifier aus ASN.1 Basis ist von ISO / CCITT (heute ITU) festgelegter Baum Adressierung: 1.3.6.2.1.1... 11

12 Datenkommunikation – VI. Netzw. Management SNMP - Simple Network Management Protokol Standard verbindungslos, UDP Freie SNMP Tools: Unix: - scotty (commandline Tools) - tkinetd (mächtiges, aber unintuitives GUI Tool) - cheops(-ng) (GTK Interface) - gxsnmp - NET-SNMP (daemon, tools) Windows: - Getif Kommerziell: Tivoli HP OpenView CiscoWorks 12

13 Datenkommunikation – VI. Netzw. Management SNMP - Simple Network Management Protokol Nachricht enthällt: SNMP Version Community Name PDU SNMP Nachrichten werden ohne Absprache versendet Request -> Response - asynchron! Synchronization über Auftragskennung Nachrichten können verloren gehen -> Sache der Applikation Massnahmen zu treffen SNMP Komponente ist Probe, Agent und Manager in einem 13

14 Datenkommunikation – VI. Netzw. Management Arbeitsweise der Protokolleinheit Senden: Applikation -> Auftrag an Protokolleinheit Protokolleinheit -> PDU in ASN.1 Notation mit Community Namen, Quell und Zieladresse an Authentifizierungsdienst Auth.dienst -> Validation -> Verschlüsselung -> SNMP Nachricht -> Transportdienst Empfang: Paket empfangen, dekodieren SNMP Nummer vergleichen Community Namen, Nachricht & Adresse validieren (evtl. Alarm) Operation durchführen tritt bei einem Fehler etwas unerwartetes auf, wird die Nachricht verworfen 14

15 Datenkommunikation – VI. Netzw. Management PDUs bzw. Grundoperationen 5 Grundoperationen: GET ein oder mehrere Objekte abfragen. Objekt Kennung wird in PDU angegeben. Wird mit get-Response beantwortet. GET-NEXT - für's Abfragen von MIB-Tabellen und Listen -> vermeiden von Fehler-Nachrichten bei get-Request - holt lexikographisch nächsten Eintrag aus dem Baum -> dadurch Durchqueren des Baums möglich, ohne dass man ihn kennt (MIB des Geräts nicht verfügbar) RESPONSE (für GET, GET-NEXT, SET) Resultat oder Fehler Rückgabe. Enthällt die (ggF. ausgefüllte) Anfrage. Bei Fehler, zusätzlich Fehlerstatus und -index. 15

16 Datenkommunikation – VI. Netzw. Management PDUs bzw. Grundoperationen SET Setzen von Werten. Bei Fehler wie oben. Ohne Fehler -> Kopie der Anfrage plus Fehlerindex = 0 TRAP Wird spontan von Agent an Management Station gesendet. Keine Response-PDU. 16

17 Datenkommunikation – VI. Netzw. Management SNMPv1 Operationen 17 ManagerAgent Get GetNext Set Response ManagerAgent Trap

18 Datenkommunikation – VI. Netzw. Management Auslösen von Traps Traps werden ausgelöst durch: Verbindungsabbruch, -neustart, Initialisierung oder Neustart des Agenten, Fehler bei der Identifikation 18

19 Datenkommunikation – VI. Netzw. Management Zugriff auf Objektinstanzen Bearbeitung einer Nachricht: Authentifikation über Community-Name, üblicherweise Community-Names für's Lesen und Schreiben. Community-Name wird in jeder Nachricht mitgeschickt. Identifikation der betroffenen Objektinstanz Prüfung der Berechtigung zur Ausführung der Aktion: not-accessible, read-only, read-write 19

20 Datenkommunikation – VI. Netzw. Management Transport der Nachricht Transport über verbindungsloses Protokoll - bisher nur UDP standartisiert: IP Header | UDP Header | SNMP-Header | SNMP-PDU SNMP: Port 161, SNMP Trap: Port 162 20

21 Datenkommunikation – VI. Netzw. Management Management Information Base II Beschreibung entsprechend dem RFC 1157 Standard-MIB in RFC 1213 kann erweitert werden, auch um private MIBs Registrierung vom MIBs bei Internet Assigned Numbers Authority Ziel bei Entwurf der MIB II waren: schrittweise Erweiterbarkeit verbesserte Unterstützung von Multiprotokoll Geräten Überarbeitung der MIB I Spez. Aufwärtskompatibel mit den SNMP Spez. 21

22 Datenkommunikation – VI. Netzw. Management Der MIB II Teilbaum alle MIB II Objekte im MIB II Teilbaum unter 1.3.6.1.2.1 bzw. {mgmt 1}: 1.3.6.1.2.1 1.iso Objekte der ISO.3.org Objekte anderer int. Organisationen.6.dod Objekte des Department of Defense.1.internet Objekte im Internet.2.mgmt Objekte des IAB.1mib-2 Objekte der MIB II 22

23 Datenkommunikation – VI. Netzw. Management Gruppen des MIB II Teilbaums Die Objekttypen der MIB II sind in folgende 12 Gruppen angeordnet, die jeweils wieder eigene Teilbäume besitzen:  system{mib-2 1}  interface{mib-2 2}  at{mib-2 3}  ip{mib-2 4}  icmp{mib-2 5}  tcp{mib-2 6}  udp{mib-2 7}  egp{mib-2 8}  cmot{mib-2 9}  transmission{mib-2 10}  snmp{mib-2 11}  rmon { mib-2 16} Aufteilung in Gruppen zwecks höherer Flexibilität bei der Implementierung. Nicht benutzte Gruppen müssen nicht implementiert sein. 23

24 Datenkommunikation – VI. Netzw. Management MIB II Gruppen System Group Info zum Agenten aus administrativer Sicht: Beschreibung, Kontakt, Uptime, bereitgestellte Dienste etc. Interface Group Parameter der Netzwerkanschlüsse. Andere Anschlüsse -> eigene MIBs. IfNumber, IfTable sind die einzigen Elemente. IfTable ist noch weiter unterteilt. Adress Translation Group Umsetzung der medienspezifischen Adresse in Netzadressen. Wird nicht mehr benutzt. -> ipToMediaTable IP Group IP Aktivitäten und Konfigurationen eines Netzknotens: - ipAddrTable - ipRouteTable - ipToMediaTable -> Siehe Dokumentation MIB II (Auszug aus MIB Definition) 24

25 Datenkommunikation – VI. Netzw. Management MIB II Gruppen ICMP Group Fehler, nicht erreichbare Adressen etc. TCP Group empfangene TCP Pakete, existierende TCP Connections und Statistiken dazu. -> tcpConnTable UDP Group entsprechend TCP Group EGP Group wird nicht mehr verwendet (ersetzt durch BGP, RFC 1163) Transmission Group beschreiben das Übertragungsmedium. Noch leer, da entsprechende MIBs noch im Entwurfsstadium sind. SNMP Group Statistiken plus Schalter für Erzeugung von Traps bei unauthorisiertem Zugriff. 25

26 Datenkommunikation – VI. Netzw. Management Interfaces Gruppe Interfaces(2) ifNumber(1)ifTable(2) ifEntry(1)ifEntry(2)... 26 ifIndex(1) ifDescr(2) ifIndex(1) ifDescr(2) ifType(3) ifMtu(4) ifSpeed(5) ifPhysAddress(6) ifAdminStatus(7) ifOperStatus(8) ifLastChange(9) ifInOctets(10) ifInUcastPkts(11) ifInNUcastPkts(12) ifInDiscards(13) ifInErrors(14) ifInUnknownProtos(15) ifOutOctets(16) ifOutUcastPkts(17) ifOutNUcastPkts(18) ifOutDiscards(19) ifOutErrors(20) ifOutQLen(21) ifSpecific(22)

27 Datenkommunikation – VI. Netzw. Management RMON MIB und LAN Monitore definiert RFC 1271 LANs werden komplexer, enthalten mehr Geräte üblicherweise hat's mehr auf Layer 1 und 2 arbeitende Komponenten als Hubs, welche oft "dümmer" sind als Geräte der höheren Ebenen speziell für Verwaltung von LANs mit deren Hubs, Repeatern und Bridges soll Funktionalität von LAN Monitoren abdecken Funktionalität von LAN-Monitoren/Analysatoren: Layer 2 untersuchen angeschlossene Geräte identifizieren grafische Darstellung der Netzbelastung Datenverkersaufkommen von Station ermitteln und darstellen einzelne Stationen beobachten Tests durchführen und besondere Ereignisse (Kollisionen, Broadcasts,...) erfassen höhere Protokolle statistisch erfassen implementiert in Software 27

28 Datenkommunikation – VI. Netzw. Management RMON Gruppen Gruppen der RMON-MIB: statistics history alarm hosts hostTopN matrix filter capture event Implementierung der RMON Gruppen ist optional 28

29 Datenkommunikation – VI. Netzw. Management Statistics Group Auslastungs- und Fehlerstatistiken zu einzelnen Netzwerkanschlüssen (Ethernet, Tokenring) RmonetherStatsTable etherStatsEntry StatisticsetherStatsEntryetherStatsIndex...etherStatsDataSource...etherStatsDropEvents...etherStatsOctets etherStatsEntryetherStatsPkts etherStatsBroadcastPkts etherStatsMulticastPkts etherStatsCRCAlignErrors etherStatsUndersizePkts etherStatsOversizePkts etherStatsFragments etherStatsJabbers etherStatsCollisions etherStatsPkts64Octets etherStatsPkts65to127Octets etherStatsPkts128to255Octets etherStatsPkts256to511Octets etherStatsPkts512to1023Octets etherStatsPkts1024to1518Octets etherStatsOwner etherStatsStatus 29

30 Datenkommunikation – VI. Netzw. Management Konfiguration von Rmon Messungen 1. tabelleStatus auf createRequest setzen -> Ressourcen werden von Agent reserviert 2. Agent setzt gruppeStatsStatus auf underCreation 3. Management Station konfiguriert danach den Eintrag ( tabelleEntry) indem sie z.B. tabelleDataSource setzt. tabelleDataSource ist immer “read-create”, d.h. der Wert kann nur einmal während der Konfiguration geschrieben und später nur noch ausgelesen werden. 4. sobald Konfiguration abgeschlossen ist, setzt Management Station tabelleStatus auf valid. Nun fängt der Agent mit Messungen an. 5. die Management Station kann tabelleStatus auf invalid setzen, wodurch der Agent die Ressource freigibt und diese für andere Messungen konfiguriert werden kann -> Konfigurations-Transaktion – allerdings nur single User. 30

31 Datenkommunikation – VI. Netzw. Management History Group periodisch Werte aus Statistics Gruppe in Ringbuffer kopieren Zeitintervall muss angegeben werden Tabellen medienspezifisch, jedoch nur Ethernet spezifiziert RmonhistoryControlTablehistoryControlEntry History historyControlEntry historyControlIndex...historyControlDataSource...historyControlBucketsRequested...historyControlBucketsGranted historyControlEntry historyControlInterval historyControlOwner historyControlStatus etherHistoryTableetherHistoryEntry etherHisoryEntryetherHistoryIndex...etherHistorySampleIndex...etherHistoryIntervalStart...etherHistoryDropEvents etherHisoryEntryetherHistoryOctets etherHistoryPkts etherHistoryBroadcastPkts etherHistoryMulticastPkts etherHistoryCRCAlignErrors etherHistoryUndersizePkts etherHistoryOversizePkts etherHistoryFragments etherHistoryCollisions etherHistoryJabbers etherHistoryUtilization 31

32 Datenkommunikation – VI. Netzw. Management Alarm Group Auslösen eines Alarms bei der Über/Unterschreitung eines Schwellenwerts verknüpft mit Event in Eventgroup alarmVariable entspricht OID RmonalarmTablealarmTableEntry AlarmalarmTable Entry alarmIndex alarmInterval alarmVariable alarmSampleType alarmValue alarmStartupAlarm alarmRisingThreshold alarmFallingThreshold alarmRisingEventIndex alarmFallingEventIndex alarmOwner alarmStatus 32

33 Datenkommunikation – VI. Netzw. Management Event Group Ereignisse und Aktionen, welche beim Eintreffen eines Ereignisses durchgeführt werden sollen Aktionen (eventType): keine Log-Eintrag Trap beides RmoneventTableeventEntry eventevent EntryeventIndex...eventDescription...eventType event EntryeventCommunity eventLastTimeSent eventOwner eventStatus logTablelogEntry logEntrylogEventIndex logIndex logTime logDescription 33

34 Datenkommunikation – VI. Netzw. Management Hosts Group Zuordnung von beobachtetem Verkehr zu MAC Adressen hostControlTable hat Eintrag pro konfigurierten Netzanschluss hostTimeTable sortiert nach Zeit -> einfache Erkennung von neuen Stationen RmonhostControlTablehostControlTableEntry hostshostControlTable Entry hostControlIndex....hostControlDataSource...hostControlTableSize hostControlTable Entry hostControlLastDeleteTime hostControlOwner hostControlStatus hostTablehostEntry hostAddress hostCreationOrder hostIndex hostInPkts hostOutPkts hostInOctets hostOutOctets hostOutError hostOutBroadcastPkts hostOutMulticastPkts hostTimeTablehostTimeEntry 34

35 Datenkommunikation – VI. Netzw. Management HostsTopN Group wie Hosts Group, ausser dass die Tabellen nach einem konfigurierbaren Schlüssel sortiert sind optional RmonhostTopNControlTablehostTopNControlTableEntry hostTopNhostTopNControlTable Entry hostTopNControlIndex...hostTopNHostIndex...hostTopNRateBase hostTopNControlTable Entry hostTopNTimeRemaining hostTopNDuration hostTopNRequestedSize hostTopNGrantedSize hostTopNStartTime hostTopNOwner hostTopNStatus hostTopNTablehostTopNEntry hostTopNReport hostTopNIndex hostTopNAddress hostTopNRate hostTopNRateBase:hostTopNInPkts(1),hostTopNOutErrors(5), hostTopNOutPkts(2),hostTopNOutBroadcastPkts(6), hostTopNInOctets(3),hostTopNOutMulticastPkts(7) hostTopNOutOctets(4), 35

36 Datenkommunikation – VI. Netzw. Management Matrix Group Verkehrsaufkommen zwischen zwei beliebigen MAC Adressen optional DS gleich wie SD aber nach Destination sortiert RmonmatrixControlTablematrixControlEntry matrix matrixControlEntry matrixControlIndex...matrixControlDataSource...matrixControlTableSize...matrixControlLastDeleteTime matrixControlEntry matrixControlOwner matrixControlStatus matrixSDTablematrixSDEntry matrixSDEntrymatrixSDSourceAddress...matrixSDDestAddress...matrixSDIndex matrixSDEntrymatrixSDPkts matrixSDOctets matrixSDErrors matrixDSTablematrixDSEntry... 36

37 Datenkommunikation – VI. Netzw. Management Filter Group Definition von Filtern, gemäss welchen Pakete ausgelesen werden ein Strom von durchgelassenen Paketen wird Channel genannt Channel kann durch mehrere ODER-verknüpfte Filter gebildet werden Filterausdruck wird durch Bitmaske definiert welche auf Pakete angewendet werden Filter zählen Pakete nur. Verarbeitung wird durch Paket Capture Group abgedeckt RmonfilterlTablefilterEntry filter filterEntry filterIndex...filterChannelIndex...filterPktDataOffset filterEntry filterPktData filterPktDataMask filterPktDataNotMask filterPktStatus filterPktStatusMask filterPktStatusNotMask filterOwner filterStatus channelTablechannelEntry... 37

38 Datenkommunikation – VI. Netzw. Management Filter Group RmonfilterlTablefilterEntry filter filterlEntry...... channelTablechannelEntry channelEntrychannelIndex channelIfIndex channelAcceptType channelDataControl channelTurnOnEventIndex channelTurnOffEventIndex channelEventIndex channelEventStatus channelMatches channelDescription channelOwner channelStatus channelAcceptType:acceptMatched(1), acceptFailed(2) channelDataControl:on(1), off(2) channelEventStatus:eventReady(1), eventFired(2), eventAlwaysReady(3) 38

39 Datenkommunikation – VI. Netzw. Management Packet Capture Group speichert Pakete, welche die in der Filter Group definierten Kanäle passiert haben in Puffern diese können von der Managementstation abgerufen werden komplette Pakete oder nur n Bytes Trace Anwendungen auf der Managementstation RmonbufferControlTablebufferControlEntry capture bufferControlEntrybufferControlIndex...bufferControlChannelIndex...bufferControlFullStatus bufferControlEntrybufferControlFullAction bufferControlCaptureSliceSize bufferControlDownloadSliceSize bufferControlDownloadOffset bufferControlMaxOctetsRequested bufferControlMaxOctetsGranted bufferControlCapturedPackets bufferControlTurnOnTime bufferControlOwner bufferControlStatus captureBufferTablecaptureBufferEntry... 39

40 Datenkommunikation – VI. Netzw. Management Packet Capture Group bufferControlFullStatus gibt an, ob die Probe noch Platz für weitere Pakete hat mit bufferControlFullAction kann angegeben werden, was passiert, wenn der Buffer voll ist mit bufferControlMaxOctetsRequested kann der für Pakete zur Verfügung stehende Platz konfiguriert werden bufferControlTurnOnTime : wann wurde Buffer angeschaltet RmonbufferControlTablebufferControlEntry capture bufferControlEntry... captureBufferTablecaptureBufferEntry captureBufferEntrycaptureBufferControlIndex...captureBufferIndex...captureBufferPacketID captureBufferEntrycaptureBufferPacketData captureBufferPacketLength captureBufferPacketTime captureBufferPacketStatus 40

41 Datenkommunikation – VI. Netzw. Management SNMPv3 Unterstützung von sicheren Schreiboperationen (Transaktionen) Definition eines langlebigen (?!), modularen Architekturmodels, welches einfachere Weiterentwicklung erlaubt unterstützung von billigen, einfachen aber auch von teueren, komplexen Implementationen möglichst aufwärtskompatibel und einfach open source UCD-snmp -> NET-snmp rel. kleine Verbreitung siehe Schönwälder s151ff 41

42 Datenkommunikation – VI. Netzw. Management Features von SNMPv3 Sicherheit: verschlüsselte Nachrichten (DES) (aufwendig) security Modell kann gewählt werden Zeitstempel Authentifizierung Prüfsummen Sicherung gegen Wiederholung verfeinerte Zugriffskontrolle auf einzelne Views Transaktionen: msgID erlaubt Zuweisung von Frage zu Antwort bestätigte Traps (Inform) getBulk erlaubt Wiederholungen von einzelnen get Befehlen: hole OIDs 1.2.3.4, 1.3.7.8 und dann die 4 nächsten ab 1.3.1.5.7 detailliertere Fehlermeldungen Views (Unterbäume können definiert und adressiert werden) 42

43 Datenkommunikation – VI. Netzw. Management Features von SNMPv3 Architektur: einzelne Teile einer SNMP Engine sind auswechselbar und direkt adressierbar subAgenten (AgentX), Proxy Agenten, Registrierung von OID Subbäumen erweiterte Möglichkeiten im Bezug auf Verwaltung und Manipulation von Tabellen 43

44 Datenkommunikation – VI. Netzw. Management Probleme von SNMP MIBs hinken Gerätefeatures hinterdrein SNMP wird für Überwachung verwendet, selten für Konfiguration -> Admins verwenden oft proprietäre CLIs keine Versionierung oder Konfigurationsvarianten auf Agenten kein Commit / Rollback / Retransmit SNMP ineffizient bzgl. Bandbreitenausnützung - Polling wenig effizient (je nach MIB Traps/Events, die ausgelöst werden können) - Trap Mechanismus ohne Performance Garantien - bie hoher Netzlast: - Trap Nachrichten können verloren gehen - es kann zu Trap Stürmen kommen -> Verschlimmerung der Lage Netzlast -> je nach Anwendung viel zu hohe Netzauslastung Master->Slave, d.h. kein Push! unzuverlässig, keine Fehlertoleranz Protokoll zustandslos: keine automatische Bestätigung mehrere Management Stationen können gleichzeitig Zustand eines Agenten ändern 44

45 Datenkommunikation – VI. Netzw. Management Netconf Neues Protokol in Entwicklung Siehe: Homepage: http://www.ops.ietf.org/netconf/ Bsp: http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-eof- netconf.pdf http://www.ops.ietf.org/netconf/ http://www.ripe.net/ripe/meetings/ripe-47/presentations/ripe47-eof- netconf.pdf Basiert auf XML 4-Schichtenmodel: Konfigurations-Möglichkeiten / Content | |,, Operationen,, |, | RemoteProcedureCalls,, |, | sicherer TransportSSH, SOAP oder BEEP 45

46 Datenkommunikation – VI. Netzw. Management Netconf verschiedene Konfigurationen können auf dem Agenten liegen (,...) Adressierung der einzelnen Managed Objects per URI: http://ietf.org/netconf/base/1.0#name http://authority/protocol/category/version#name sollte einfacher scriptbar/parsbar sein als SNMP sollten im Stande sein Capabilities miteinander auszuhandeln Standard befindet sich in der Diskussionsphase – manches kann noch ändern 46