aus ANOther Wiki, der freien Wissensdatenbank

Inhaltsverzeichnis 1 Übersicht 1.1 Multicast Gruppen 1.1.1 Warum Multicast? 1.1.2 Vorteile von Multicast 1.1.3 Nachteile von Multicast 1.1.4 Arten von Multicast-Anwendungen 1.1.5 Anwendungsgebiete 1.2 IP-Multicast-Adressen 1.2.1 IP-Multicast Adressierung 1.2.2 Multicast-Sessions 2 IGMP und Layer2 2.1 Einführung IGMP2 2.1.1 Beitreten einer Gruppe 2.1.2 Verlassen einer Gruppe 2.2 IGMPv3 2.3 Bestimmen der IGMP-Version 2.4 Multicast, Layer-2-Switching 2.4.1 Schicht-2 Multicast Switchinglösungen 2.4.2 CGMP 2.4.3 IGMP snooping 3 Multicast-Routingprotokolle 3.1 Verwendete Protokolle 3.1.1 Multicast Protokolle: Grundlagen 3.1.2 Identifizierung von Multicast Distributiontrees 3.2 IP Multicast Routing 3.3 Einführung PIM 4 Multicast: Konfiguration und Überprüfung 4.1 Konfigurieren von PIM-SM und PIM Sparse-Dense-Mode an einem Interface 4.1.1 Überprüfen der Multicast-Routingtabelle 4.1.2 Finden von PIM-Nachbarn 4.1.3 Überprüfen von RP-Informationen 4.2 Überprüfen von IGMP-Gruppen und IGMP-Snooping 4.2.1 Überprüfen des Group-State 4.2.1.1 Konfigurieren eines Routers, um ein Member einer Gruppe oder ein Static Connected Member zu sein 4.2.2 Überprüfen von IGMP Snooping

Übersicht

Multicast Gruppen

Warum Multicast?

Multicast wird verwendet, wenn die selben Datenpakete verschiedenen Empfängern zugestellt werden sollen. Wird ein Paket zu Multicast-Empfängern gesendet, wird dies nicht für jeden Empfänger versendet, sondern als einzelner Stream. Dieser Sream wird von den Downlevel-Routern danach auf die jeweiligen Empfängern zugestellt. Der Stream wird also vervielfältigt, an den jeweils letzten Knoten vor der "Abzweigung". Dadurch wird einiges an Last von den Routern, der Leitung genommen, da nur ein einzelnes Paket von der Quelle ausgesendet werden muss.

Da erst die Downlevel-Router die Paketverteilung vornehmen, kann/muss der Sender die IP-Adresse des Empfängers nicht kennen.

Ein Anwendungsgebiet für Multicast sind Video/Audiostreams

Vorteile von Multicast

Annahme: Ein Netzwerk, 100 User. Diese 100 Userhören einen 16kbps-Audiostream. Das Netzwerk wird mit 16kbps belastet. Würde dieser Stream anstatt mit Multicast mit Unicast verbreitet, wird das Netz mit 100x16=1.6mbps belastet

Vorteile also:

• erhöhte Effizienz
• optimale Performance
• ideal für die Anwendungsverteilung

Video on Demand (VoD) wäre ohne Multicast nicht denkbar

Nachteile von Multicast

Multicast ist UDP-basierend, d.h. es kann durchaus passieren, dass Pakete verloren gehen. Ausserdem gilt eine UDP-Übertragung nicht als vertrauenswürdig.

Arten von Multicast-Anwendungen

• one-to-many: wird zb. bei Videostreams verwendet
• many-to-many: hier arbeiten zB. einige Empfänger auch als Sender

Weiters gibt es einige Anwendungen für many-to-one, wo zb. Hosts zum Zwecke einer Datensammlung an einen zentralen Empfänger schicken

Anwendungsgebiete

Neben Realtime-Anwendungen kann wird Multicast auch zb. für das Simultanaufsetzen von PCs verwendet

 

IP-Multicast-Adressen

IP-Multicast Adressierung

Multicast-Adressen nutzen die Klasse-D-Adressen (1110) Multicasts in dieser Range werden nur im lokalen Netz weitergeleitet. Die TTL liegt in der Regel auf 1.

Einige lokale Multicast-Adressen:

• 224.0.0.1 alle Hosts
• 224.0.0.2 alle Multicast-Router
• 224.0.0.4 alle DVMPR (Distance Vector Multicast Routing Protocol)-Router
• 224.0.0.5 alle OSPF-Router
• 224.0.0.6 alle OSPF- DR
• 224.0.0.9 alle RIPv2-Router
• 224.0.0.10 alle EIGRP-Router

Für Multicastanwendungen werden vorübergehende Adressen verwendet, die nach Gebrauch wieder verworfen werden. Man unterscheidet zwischen zwei Typen

• globale Adressen: 224.0.1.0 - 238.255.255.255. So ist zb. der Bereich 224.2.x.x für MBone (Multicast Backbone) reserviert
• administrative Adressen: 239.0.0.0 - 239.255.255.255, welche reserviert sind für private Domains

Der Administrative Bereich ist wiederum in zwei Bereiche unterteilt

• side-local: 239.255.0.0/16, 239.252.0.0/16, 239.254.0.0/16
• organisation-local: 239.192.0.0 - 239.251.255.255

Multicast-Sessions

Wenn eine Multicastanwendung auf einem Empfänger gestartet wird, muss die Anwendung wissen, welcher Multicast-Gruppe sie beitreten muss. Die Anwendung muss informationen über die verfügbaren Streams/Sessions lernen

Es gibt verschiedene Möglichkeiten für die Applikationen, diese Informationen zu lernen:

• die Anwendung verwendet bekannte, vordefinierte Gruppen
• ein Directory-Service ist verfügbar, über diesen die Anwendung die Infos erhält
• die Anwendung wird über einen Link gestartet. Auch ein via Mail verbreiteter Link ist möglich

Die Session-Directory-Application (sd) fungiert als Guide, welcher den Multicast-Content anzeigt. Eine Clientanwendung läuft am PC und informiert den User über den verfügbaren Content. Diese Verzeichnisanwendung verwendet entweder SDP (Session Description Protocol) oder SAP (Session Announcement Protocol), um über dn Content zu lernen. (SAP und SDP werden auch als SDR oder sdr bezeichnet)

IGMP und Layer2

Einführung IGMP2

IGMP ist ein Host-zu-Router-Protokoll, welches verwendet wird, wenn Hosts einer Multicastgruppe beitreten wollen. In IGMPv1 senden Router periodische Mitgliedschaftsabfragen an die Multicastadresse 224.0.0.1. Hosts senden die gewünschte Gruppe an die jeweilige Gruppen-Multicastadresse; Hosts verschwinden leise, still und heimlich aus den Gruppen

Aufgrund einiger Einschränkungen bei v1 wurde IGMPv2 entworfen. Die wichtigsten Unterschiede sind

• Gruppenspezifische Queries: nun können Router auch einzelne Gruppen abfragen
• Leave-Group-Message: die Hosts teilen dem Router das Verlassen der Gruppe mit. So wird die Last von einem Segment genommen, wenn der letzter Member aus der Gruppe ausgetreten ist

 

Beitreten einer Gruppe

Beim Betreten einer Gruppe muss ein Member nicht auf eine Query warten, es wird einfach das Interesse bekundet Mit show ip igmp group können einige Informationen die Gruppen betreffend abgefragt werden. So zb. der letzte beigetretene Host, sowie die Zeit des "Entstehens" und des "Auflösens" der Gruppe

Befinden sich zwei IGMP-Router im selben Ethernetsegment (Broadcast-Domain), wird der Router mit der höheren IP der designierte Querier

Verlassen einer Gruppe

In v1 verlässt der Host die Gruppe, ohne einen Hinweis auf das Verlassen zu hinterlassen. IGMPv2 hinterlässt einen solchen Hinweis

Wenn ein v2-Router eine Leave-Message erhält, antwortet er mit dem Senden einer gruppenspezifischen Anfrage. Damit kann der Router feststellen, ob noch Hosts in seinem Segment verbleiben

IGMPv3

Der Zweck für v3, welches den Antrag auf einen Standard gestellt hat, ist hauptsächlich, dass Hosts er erkennen geben können, von wem sie Traffic empfangen wollen

Bestimmen der IGMP-Version

Die Version wird mit

show ip igmp interface 

ausgegeben

Multicast, Layer-2-Switching

Für die meisten Switches bedeutet Multicast-Verkehr das selbe wie unbekannte MAC-Adressen: es wird gefloodet, an allen Ports, in allen VLANs

Eine Möglichkeit, wie Cisco-Catalysts dieses Problem angehen ist, dass der Administrator Multicast-Adressen verschiedenen Ports zuweist. So kann er die Ports 2, 3 und 8 so konfigurieren, dass nur diese den Multicast-Verkehr für die jeweilige Gruppe erhalten. Dies funktioniert, ist aer nicht skalierbar. IP-Multicast-Hosts betreten und verlassen Gruppen dynamisch, unter Verwendung von IGMP um den Multicast-Routern zu signalisieren. Dynamische Konfiguration der Forardingtables der Switches ist daher effizienter und spart administrative Arbeit

Auf Schicht-3 kann ein User auch mittels des PIM (Protocol-Independent Multicast) über das Internet multicasten. Dies ist eine Familie von Multicast Routing Protokollen, die one-to-many und many-to-many Datenverteilung über das Internet beherrschen. Der "protokollunabhängige" Teil beruht auf dem Fakt, dass PIM keinen eigenen topologieerforschenden Mechanismus hat, aber die Routinginformationen von traditionellen Routingprotokollen wie BGP verwendet

Schicht-2 Multicast Switchinglösungen

• CGMP: Cisco Group Management Protocol ist ein proprietäres Protokoll, welches zwischen einem Multicast-Router und einem Switch läuft.
• IGMP snooping: hier schnüffelt der Switch mit, und passt laufend seine MAC-Tabelle entsprechend an

CGMP

CGMP basiert auf einem Client/Servermodell, wobei dem Router die Server-, dem Switch die Clientrolle zugewiesen wird. Softwarekomponenten auf beiden Seiten wandeln IGMP in CGMP-Befehle um, mit denen dann die Forwardingtabellen des Switches gesteuert werden

Die Grundlage von CGMP ist, dass ein Multicastrouter alle IGMP-Pakete sieht, und daher den Switch informieren kann, wenn ein Host einer Gruppe beitritt oder eine Gruppe verlässt. Router verwenden bekannte CGMP-Multicast MAC-Adressen, um die CGMP-Steuerpakete zum Swtch zu senden. Der Switch verwendet diese Information dann, um seine Forwardingtabelle dementsprechend zu programmieren

Wenn ein Router ein IGMP-Steuerpaket sieht, erstellt er ein CGMPPaket, welches die Art des Requests beinhaltet (beitreten/verlassen), die L2-Multicast MAC-Adresse und die MAC-Adresse des Clients

Dieses Paket wird zur bekannten CGMP Multicast MAC-Adresse 0x0100.0cdd.dddd zu allen lauschenden Switches geschickt. Die CGMP-Steuernachricht wird interpretiert, und die Einträge werden im Swich-CAM (content-addressable memory) erstellt. So wird der Multicast-Verkehr für diese Gruppe eingeschränkt

IGMP snooping

Die zweite Möglichkeit ist das IGMP-Snooping. Wie der Name schon sagt, wird hier geschnüffelt, und zwar nach den IGMP-Membershp reports und den IGMP leaves.

Bei der Implementierung sollte vorsichig vorgegangen werden, denn wenn ein Switch alle L2-Multicast-Pakete überprüfen muss hat dies starke Auswirkungen auf die Leistung des Switch

Multicast-Routingprotokolle

Verwendete Protokolle

Multicast Protokolle: Grundlagen

Multicast Distribution Trees definieren den Pfad von der Quelle bis zum Empfänger, den der Multicasttraffic fließt

Es gibt zwei Typen von Multicast-Trees:

• source-routed tree
• shared tree

Beim Source-Routed-Tree wird ein separater Zweig für jede Quelle zu allen Mitgliedern dieser Gruppe gebaut. Da dieser Weg der direkte, der kürzeste ist, wird dieser Typ auch SPT, Short Path Tree, genannt

Shared Tree Protocols stützen sich beim Erstellen der Multicast-Forwardingpfade auf zentrale Knotenrouter, die einen Rendezvous-Punkt (RP) zwischen den Mulitcast-Quellen und Zielen bieten. Quellen senden erst die Mulicast-Pakete zum RP, welcher sie dann als shared-tree zu den jeweiligen Empfängern weiterleitet. Shared Tree ist weniger effizienter als SPT, aber schont Speicher und CPU

Grundsätzlich gibt es zwei Arten von Multicast-Routingprotokollen:

• dense mode protocols: sie flooden Multicasttraffic über das ganze Netzwerk und beschneiden ihn da, wo keine Clients dahinter sind. Hierfür wird ein periodischer flood-and-prune-Mechanismus verwendet

• sparse mode protocols: sie verwenden einen extrigen Auswahlmechanismus, bei dem die Verteilerbäume nur bei Bedarf aufgbaut werden. Dies passiert, wenn direkt angeschlossene Empfänger an den Routern eine Tree-Join-Message auslösen

Identifizierung von Multicast Distributiontrees

Die Multicast-Forwardungeinträge, die in einer Multicast-Forwardingtabelle aufscheinen, können wie folgt gelesen werden

• (S, G): Für die Quelle (S), welche an die Gruppe (G) sendet; diese Einträge zeigen in der Regen SPT, können aber auch zu einem Shared Tree gehören
• (*, G): Für jede Quelle (*), welche an die Gruppe G sendet; reflektieren für gewöhnlich Shared Trees, werden aber (in Cisco-Routern) auch für alle existierenden (S, G) einträge erstellt

SPT-Einträge benötigen mehr Router-Speicher, da für jedes Sender-Empfängerpaar ein eigener Eintrag existiert. Allerdings kann der Verkehr dann auch für jeden Empfänger direkt am besten Weg zugestellt werden. Dies minimiert das Delay

Shared Distribution Tree-Einträge hingegen benötigen wesentlich weniger Routermemory, allerdings können suboptimale Pfade zwischen Quelle und Ziel verwendet werden, mit allen verbundenen Nachteilen

 

IP Multicast Routing

Multicast Forwarding

Beim Unicastrouting trifft der Router die Entscheidung, wohin das Paket zu senden ist, anhand der Empfängeradresse im Paket. Beim Multicastrouting ist die Entscheidung hingegen von der Quelle abhängig

Multicastrouter müssen den Ursprung des Paketes kennen, was der Unterschied zum Unicast-Routing ist

Multicastrouting verwendet einen Mechanismus, Reverse Path Forwarding (RPF), um vor Loops zu schützen und sicherzustellen, dass der kürzeste Pfad zu den Empfängern verwendet wird.

Einführung PIM

Der PIM-dense mode (PIM-DM) initialisiert einen Multicasttraffic, der über alle Netzwerkteile gefloodet wird. PIM-DM initialisiert flood-traffic aus allen nicht-RPF-Interfaces, an denen ein weiterer PIM-DM Nachbar hängt, bzw ein direkt angeschlossenes Member der Gruppe

Multicast: Konfiguration und Überprüfung

Konfigurieren von PIM-SM und PIM Sparse-Dense-Mode an einem Interface

router(config)# ip multicast-routing

mit diesem Befehl wird Multcast-Routing auf einem Router aktiviert

router(config-if)# ip pim {sparse-mode | sparse-dense-mode}

ip pim sparse-mode

aktiviert die PIM-SM-Operation am gewählten Interface. Der Befehl

ip pim sparse-dense-mode

lässt das Interface im PIM-SM für sparse-mode-groups (die mit belannten Rendezvous points [RP]) und im dense-mode (für alle anderen Gruppen) operieren

 

router(config)# ip pim send-rp-announce {Interfacetyp} scope {ttl} group-ist {acl}

Das globale Kommando wird auf dem Router ausgeführt, der ein RP werden soll. Dieser Router sendet eine Auto-RP-Nachricht an 224.0.1.39, in der die Bereitschaft des Routers steht, als RP zu fungieren, für die Gruppen, die lt. Accesslists definiert sind

 

router(config)# ip pim send-rp-discovery {Interfacetyp} scope {ttl} 

Dieses globale Kommando konfiguriert einen Router als RP-Mapping-Agent.; er lauscht auf 224.0.1.39 und sendet eine RP-zu-Gruppen-Mappingsachricht nach 224.0.1.40. Andere PM router lauschen auf 224.0.1.40, und erkennen den RP so automatisch

router(config)# ip pim spt-threshold {rate | infinity}

kontrolliert den Switchover vom shared-distribution-tree zum SPT. "infinity" bedeutet, dieser Wechsel passiert nie

Überprüfen der Multicast-Routingtabelle

router# show ip mroute [group-adress] [summary] [count] [active kbps]

Der show ip mroute-Befehl ist das brauchbarste Kommando, um den Status von Multicastquellen und ~gruppen zu bestimmen, aus der Sicht des Routers, auf dem der efehl ausgeführt wir

Der Output dieses Befehls repräsentiert einen Teil des Multicast-Verteilerbaums, mit einem eingehenden und einer Liste von ausgehenden Interfaces. Die Optionen sind folgende:

• Summary: zeigt eine online, gekürzte Übersicht über jeden Eintrag in der IP-Multicast-Routingtabelle
• Count: liefert eine Statistik über Gruppen und Quellen, inklusive Paketanzahl, Pakete pro Sekunde, durchschnittliche Paketgröße und Bita pro Sekunde
• Active: zeigt, welche Quellen an welche Gruppen senden. Aktive Gruppen sind jene, die mit einer Rate oder mehr senden, die im kbps-Argument angegeben sind. Für dieses Argument liegt der Defaltwert bei 4 kbps

Finden von PIM-Nachbarn

router# show ip pim interface [type number] [count] zeigt Informationen über die für PIM konfigurierten Interfaces

router# show ip pim neighbor [typ number] listet die PIM-Nachbarn auf, die vom Cisco-IOS gefunden wurden

router# mrinfo [hostname | address] zeigt Informationen über Multicastrouter, die mit dem lokalen Router peeren

router# show ip pim interface

Dieser Befehl liefert folgende Informationen

• Address: IP-Adresse des Inerfaces
• Interface: Typ und Numemr des PIM-Interfaces
• Ver/Mode: konfigurierte PIM-Version (1/2) und der Modus (dense mode, sparse mode oder sparse-dense-mode)
• Nbr Count: Anzahl der Nachbarn an diesem Link
• Query Intvl: Frequenz, mit der PIM-Hellos und PIM-Queries gesendet werden (default ist 30 Sekunden)
• DR Prior: Priorität, sie wird für die Wahl des DR (designated router) verwendet. Wenn zwei Router an einem Link die selbe IP haben, gewinnt der mit der höheren IP
• DR: IP des DR. Bei Punkt-zu-Punkt-Verbindungen gibt es keinen DR, dies wird mit 0.0.0.0 dargestellt

router# show ip pim neighbor

Dieser Befekl zeigt Informationen über:

• Neighbor Address: IP-Adresse des PIM-Nachbarn
• Interface: das Interface, über das das PIM-Hello von dem Nachbarn empfangen wurde
• Uptime: Zeit, die der PIM-NAchbar aktiv ist
• Expires: Nach Ablauf dieser Zeit gilt der Nachbar nicht mehr aktiv. Ein neues PIM-Hello oder eine PIM-Query setzt den Counter wieder zurück
• Ver: PIM-Version des Nachbars, (1/2)
• DR Priority: wenn der Nachbar diese unterstützt wird die Priorität hier angezeigt. Wenn er es nicht unterstützt erscheint ein "none"

 

Überprüfen von RP-Informationen

router(config)# sh ip pim rp [group-name | group-address | mapping]

zeigt aktive RPs, die in den assiziierten Multicast-Routingeinträgen

mapping zeigt alle group-to-RP-Mappings des Routers

router(config)# sh ip rpf {address | name)

zeigt Informationen über Reverse Path Forwarding (RPF) für einen RP

router# show ip pim rp

Der Output des show ip pim rp Befehls listet alle altiven Gruppen und deren zugehörigen PPs auf. Dieser Befehl ist veraltet, denn er bietet nur eingeschränkte Informationen

Stattdessen wird meist der Befehl show ip pim rp mapping verwendet, er liefert einige Details über den aktuellen Inhalt der Gruppen-zu-RP-Mappings im Cache, wie folgendes:

• IP-Adressen eines Routers, der die Informationen verteilt oder lokal - wenn die Quelle der Informationen ein lokaler Router ist, der entweder eine manuelle RP-Konfiguration besitzt, oder eine Quelle einer automatisch verteilten Information ist.
• Mechanismus, mit dem die Informationen ermittelt werde - auto-RP, BSR oder statisch
• ob der Router ein Kanditat für RP, Mapping-Agent oder BSR ist

 

show ip rpf [IP]

Der Output dieses Befehls liefert RPF-Informationen in Verbindung mit den Quelladressen. Die spezifizierten Adressen müssen nicht zwangsläufig eine aktive Quelle sein. Es kann eine IP angegeben werden, auch die Adresse eines RPs. Das spezifizieren der IP des RPs ist sehr nützlich um die RPF-Informationen fpr den Shared Tree zu bestimmen.

"RPF interface" ist das Interface in Richtung Source (oder RP), während "RPF neighbor" die Adresse des next-hop-Routers in diese Richtung ist

"RPF-Type" weist auf die Quelle der Information. So weist zb. "unicast" darauf hin, dass die Information mittels einer Unicast-Routingtabelle zugestellt wurde, zb mit OSPF. Andere RPF-Typen inkludieren Distance Vector Multicast Routing Protokolle (DVMRP), Multiprotokcol Border Gateway Protocol (BGP)-Erweiterungen für IP oder staisch

RPF-Informationen sind unverzichtbar für Multicastrouting,

Überprüfen von IGMP-Gruppen und IGMP-Snooping

Überprüfen des Group-State

router# show ip igmp interface [type number]

zeigt die Multicast-Informationen zum zugehörigen Interface

 

router# show ip igmp groups [group-address  type number]

zeigt die Multicastgruppen, die direkt am Router angeschlossen sind und vie IGMP gelernt wurden

Konfigurieren eines Routers, um ein Member einer Gruppe oder ein Static Connected Member zu sein

Manchmal ist entweder kein Gruppenmitglied in einem Netzwerksegment oder ein Host kann seine Gruppenmitgliedschaft mittels IGMP reporten. Trotzdem soll Multicasttraffic in dieses Segment gelangen. Diese Befehle werden oft in Lab-Umgebungen verwendet, in denen kein Multicast-Server konfiguriert ist. Das folgende sind zwei Arten, Multicasttraffic in ein Netzwerksegment zu bringen:

• ip igmp join-group [group-address]
• ip igmp static group [goup-address]

sh ip igmp interface

Dieser Befehl zeigt die Multicastgruppen, die direkt an den Router angeschlossen sind und via IGMP gelernt wurden. Mit diesem Befehl erhält man folgende Informationen:

• Interfacekonfiguration für Milticast und IGMP
• Version, für welche das IGMP-Interface konfiguriert wurde
• IGMPv2-Querier des Multiaccessnetzwerk
• Multicast Designated Router (DR)
• beigetretenen Multicastgruppen des jeweiligen Routers

Überprüfen von IGMP Snooping

switch> show multicast gruop [igmp] [mac-addr] [vlan_id]

• zeigt Informationen über Multicastgruppen
• wenn das Schlüsselwort igmp benutzt wird, werden nur IGMP-gelernte Informationen gezeigt

switch> show multicast router [igmo] [mod_num/port_num] [vlan_id]

• zeigt Informationen über dynamisch gelernte und manuell konfigurierte Routerports
• wenn das Schlüsselwort igmp benutzt wird, werden nur IGMP-gelernte Informationen gezeigt

switch> show igmp statistics 10

Dieser Befehl liefert Informationen über das Vlan 10. Es wird die Anzahl der Gruppenspezifischen Queries und der generellen Queries gezeigt, weiters die Anzahl der Hostmitgliedschaften und der Group-Leavingmessages

Der Output ist geteilt zwischen gesendet und empfangen

show multicast router igmp

zeigt Informationen über das IGMP Routerport und die VLAN-Konfiguration auf einem Switch

show multicast group igmp

dieses Kommando listet Informationen über VLAN, Multicastgruppen und Ports, die Multicastgruppen auf einem Switch beigetreten sind auf

aus ANOther Wiki, der freien Wissensdatenbank

• Interior-Gateway-Protocol
• schnelle Konvergenz
• unterstützt VLSM
• ähnelt in einigen Punkten OSPF
• wurde in den 90ern totgesagt, erlebt aber eine Renaissance bei europäischen und US-amerikanischen ISPs
• unterstützt die meisten Charakteristiken von OSPF und EIGRP
• ist ein Teil der OSI-Protokollgruppe
• unterstützt verbindungslode Datenübertragung, CLSN für ConnectionLess Network Services
• das Schicht-3-Protokoll dazu heisst ConnectionLess Network Protocol, CLNP, welches ebenso wie IP eine Lösung für verbindungslose Datenübertragung ist

Inhaltsverzeichnis 1 Allgemein 1.1 Übersicht 1.2 Eigenschaften von IS-IS 1.3 LinkState-Ablauf 1.4 Integriertes IS-IS-Routing 1.4.1 Kernpunkte des Integrated IS-IS-Designs 1.4.2 Probleme bei Integrated IS-IS 1.5 ES-IS-Protokoll 1.6 OSI Routing Levels 1.6.1 Level 0 Routing 1.6.2 Level 1 Routing 1.6.3 Level 2 Routing 1.6.4 Level 3 Routing 1.6.5 Zusammenfassung 1.7 Vergleich zwischen IS-IS und OSPF 1.7.1 Unterschiede 1.8 Zusammenfassung 2 Ablauf des Routingvorganges 2.1 NSAP-Adressen 2.1.1 Integrated IS-IS NSAP Adressstruktur 2.1.2 Typische NSAP-Adressstruktur 2.1.3 Identifizieren von Systemen in IS-IS 2.1.3.1 Area-Adresse 2.1.3.2 System-ID 2.2 NET-Adressen 2.3 Subnetwork Point of Attachment (SNPA) und Circuit 2.3.1 SNPA 2.3.2 Circuit 2.3.3 Link 2.4 IS-IS Routing Levels 2.4.1 Level 1, Level 2 und Level1-2 Router 2.4.2 Intra und Interarea-Adressierung und Routing 2.4.3 OSI IS-IS Routinglogik 2.4.4 Route Leaking 2.4.5 IS-IS PDUs 2.4.6 LinkState Pakete (LSP) 2.4.6.1 LSP-Header 2.4.6.2 LSP TLV Beispiele 2.4.7 Implementierung von IS-IS in NBMA-Netzwerken 2.4.8 Netzwerktypen in NBMA implementieren 2.4.9 IS-IS in Broadcast-Netze implementieren 2.4.10 LSP repräsentiert Router: LAN-Repräsentation 2.4.11 LSP und IIH-Levels 2.4.11.1 Vergleich BC und PtP-Topologien 3 Konfiguration: Basic Integrated IS-IS 3.1 Integrieren von IS-IS in eine CLNS-Umgebung 3.2 Konfiguration: Integrated IS-IS 3.2.1 Beispiel 3.3 Optimierung von IS-IS 3.3.1 Ändern des Router-Levels 3.3.2 Ändern des Interface-Levels 3.3.3 Ändern der IS-IS-Metrik 3.4 Konfiguration von Route-Summarization in IS-IS 3.5 Überprüfen der IS-IS-Konfiguration 3.6 Überprüfen der CLNS IS-IS-Struktur 3.6.1 Troubleshooting Kommandos: CLNS 3.6.2 Troubleshooting Kommandos: CLNS und IS-IS

Allgemein

Übersicht

IS-IS arbeitet strikt nach CLNS-Bedingungen, integriertes IS-IS routet aber auch IP. CLNS-Adressen werden zur Konfiguration und zur Fehlersuche benötigt, auch wenn IP verwendet wird. IS-IS unterstützt verschiedene Data-Link-Umgebungen, wie Ethernet und Framerelay

Wie jedes Protokoll hat IS-IS Vor- und Nachteile, doch ist IS-IS eines der drei angemessenen, skalierbaren Routingprotokolle für große Netzwerke

Die Entwicklung von IS-IS begann vor der OSPFs. Große ISPs verwendeten IS-IS vor allem wegen der Konvergenz, der Stabilität und der Skalierbarkeit. Heute findet man eher Informationen und Fachartikel über OSPF als über IS-IS. Dennoch wird in einigen der weltweit grüßten Netzwerke IS-IS verwendet. Der Grund hierfür sind die oben genannten Fähigkeiten.

ISO definiert einen Router als Intermediate System, IS. Folglich ist IS-IS ein System, mit dem Router untereinander kommunizieren können

Die OSI-Protokollgruppe verwendet verbindungslose Netzwerkdienste (ConnectionLess Network Services, CLNS), um eine verbindungslose Datenübertragung zu gewährleisten, das verwendete Schicht-3-Protokoll heisst ConnectionLess Network Protocol (CLNP)

IS-IS verwendet CLNS-Adressen um Router zu identifizieren und die LSDb, die LinkState DataBase, aufzubauen. IS-IS ist ein Interior-Gateway-Protocol für CLNS

CLNP ist also eine Lösung für einen verbindungslosen, unzuverlässigen Datenaustausch, wie für IP

Eigenschaften von IS-IS

• IS-IS ist ein dynamisches Linkstate-Routingprotokoll für den OSI-Protokollstack. Es verteilt Routinginformationen, um CLNP-Daten in einer ISO-CLNS-Umgebung zu routen
• ISIS unterstützt VLSM
• Routingdomänen können ähnlich OSPF in Areas geteilt werden. IS-IS stellt Nachbarschaftsbeziehungen mittels Hello-Paketen her, und verwendet Link-State-Pakete (LSP), um die LinkState-Informationen auszutauschen, damit die LSDB gebaut werden kann
• Jeder Router wendet den Dijkstra-Algorithmus (SPF) an der LSDB an, um den besten Weg zu finden. Es werden nur wenige Informationen zwischen den Areas ausgetauscht, dies verringert die Last an den Routern, die dieses Protokoll unterstützen. Somit ist IS-IS effizient, was die Verwendung von Bandbreite, Speicher und Prozessorlast angeht
• Das IS-Is-Protokoll findet auf zwei Ebenen statt:

1. Ebene: Routing passiert in der IS-IS. Es erkennt die Lage der IS und der ES (End-Systems), und baut eine Routingtabelle, um jedes ES zu erreichen. Alle Geräte in einer Level-1-Routingarea haben die gleiche Area-Adresse. Das Routing in einer Area geschieht, indem die System-ID (auch Logical Significalt Adress Portion) betrachtet und der Weg mit den geringsten Kosten gesucht wird
2. Ebene: Die Router lernen die Lokationen aus den Level-1-Routingareas, und bauen eine Interarea-Routingtabelle. Alle IS in Level-2 verwenden die Adresse der Zielarea um den Verkehr über den Weg mit den geringsten Kosten ins Ziel zu lenken

LinkState-Ablauf

Um die beiden Ebenen zu ermöglichen, werden in IS-Is drei verschiedene Routertypen definiert:

• Level 1: Diese Router lernen die Pfade der Area, in der sie sich befinden (intra-area)
• Level 2: Diese Router lernen die Pfade zwischen den Areas (interarea)
• Level 1-2: Diese Art lernt sowohl die Pfade in den Areas als auch die dazwischen. Sie sind das Äquivalent zu den ABR in OSPF

Die Pfade, an denen L2 und L1-2-Router verbunden sind, werden Backbone genannt. Die Areas und der Backbone müssen verbunden sein

Integriertes IS-IS-Routing

Integrated IS-IS oder Dual-IS-IS ist eine Implementierung, um mehrere Netzwerkprotokolle zu unterstützen (IP, CLNSoder beide). Dies ist spezifiziert in http://www.faqs.org/rfcs/rfc1195.html">RFC 1195 und ISO 10589

Integrated IS-IS hängt CLNP-Routen Informationen über IP-Netzwerke und Subnets an. Es kombiniert ISO CLNS und IP-Routing zu einem Protokoll, so kann Integrated IS-IS für IP bzw. CLNS-Routing verwendet werden, oder einer Kombination aus beiden

Integrated IS-IS verwendet seine eigenen PDUs (Protocol-Data-Unit)um die Informationen zwischen den Routern, inklusive der IP-Erreichbarkeit, zu transportieren. IS-IS-Informationen werden nicht mit einem Netzwerklayer-Protokoll übertragen. Stattdessen werden diese Informationen direkt mittels Datalink-Frames versendet

Diese Protokollunabhängigkeit machen IS-IS äusserst erweiterbar. Es existiert auch eine Integrated IS-IS-Version, die IPv6 unterstützt

Da IS-IS CLNS-Adressen verwendet, um die Router zu identifizieren und die LSDB zu erstellen, ist es zwingend notwendig, das CLSN-Adressschema zu verstehen, wenn es konfiguriert oder debugged werden soll. Selbst wenn es nur für IP-Routing verwendet wird

Kernpunkte des Integrated IS-IS-Designs

Effektive Netzwerke sind gut geplant. Der erste und wichtigste Schritt beim Entwickeln einers skalierbaren Netzes ist der Entwurf eines Adressschemas, um das Zusammenfassen von Routen zu ermöglichen. Routesummarization ist nur in strikt hierarchischen Umgebungen möglich

Eine durchdachte Adressplanung bietet die Möglichkeit, die Router in Areas zu gliedern. Durch die Verwendung von Areas kann die Verbreitung von LSPs beschränkt werden, was Bandbreite einspart. L1-2-Router, die zwischen zwei Areas stehen, sind die logischen Punkte, um Summaries zu bilden

Probleme bei Integrated IS-IS

Ein Problem mit älteren Implementierungen ist die knappe Metrik, welche eine maximale Interfacemetrik von 63 (6 bit) und einer maximalen total-path-metric von 1023 (10 bit) bietet. Diese Metrik lässt wenig Spielraum.

Cisco-IOS ab 12.0 erlaubt eine 24bit Interface- und eine 32bit-Pfadmetrik. Per Default ist allerdings noch immer die kleine, knappe Metrik eingestellt. Probleme können dann entstehen, wenn mit älteren Routern bzw Routern unterschiedlicher Hersteller gearbeitet wird

Die Cisco-Implementierung von IS-IS misst nicht die Metrik der Interface, sondern legt sie auf 10 fest. Dieser Wert kann angepasst werden. Sollte dies nicht gemacht werden, verwendet IS-IS einfach eine Hopcount-Metrik, wie RIP

ES-IS-Protokoll

Das ES-IS-Protokoll erlaubt Routern und Hosts (ES), sich gegenseitig zu erkennen. Weiters können ES so auch ihre Network-Layer-Adresse lernen

ES-IS wickelt das Erforschen der Topologie bzw. den Austausch von Informationen zwischen den Routern (IS) und den Hosts (ES) ab.

Router senden End-System-Hellos (ESH) zu bekannten Adressen, um ihr Vorhandensein mitzuteilen. ES lauschen auf diese ESH und wählen einen zufälligen Routern an den sie ihre Pakete senden. Sollte ein ES ein Paket zu einem anderen ES senden wollen, geschieht dies ebenso über einen angeschlossenen IS.

Router hingegen senden IS-IS-Hellos (IIH), um Nachbarschaften herzustellen und aufrechtzuerhalten.

IP-Systeme verwenden kein ES-IS, denn IP hat seine eigenen Prozesse und Applikationen, um diese Funktionalität zu gewährleisten. Beispiele hierfür sind ICMP, DHCP oder ARP

Auch wenn IS-IS IP komplett unterstützt, werden zum Bilden von Nachbarschaften und zum Übertragen von Erreichbarkeitsinformationen IIHs verwendet

OSI Routing Levels

OSI kennt vier einzelne Routingoperationen, welche von 0 bis 3 nummeriert sind. IS-IS ist verantwortlich für Level 1 und Level 2 des OSI-Routings

Level 0 Routing

Das OSI-Routing beginnt mit ES-IS, wenn ein ES seinen nähesten IS auffinden will, durch das Lauschen nach ISH-Paketen

Wenn nun ein ES zu einem anderen ES ein Paket schicken will, sendet er dieses an seinen IS. Dies wird als Level-0-Routing bezeichnet

Level 1 Routing

Alle ES und IS befinden sich in einer bestimmten Area. Der Router begutachtet die Zieladresse, und leitet die Pakete auf die beste Route. Wenn sich das Ziel im selben Subnet befindet, was der Router ja aus den empfangenen ESH-Paketen weiss, forwardet er das Paket

Der IS kann eine Nachricht auch umleiten, wenn die Quelle einen direkteren Link kennt. Wenn sich das Ziel in einem anderen Subnet, aber in der gleichen Area befindet, identifiziert der Router anhand der System-ID den besten weg und leitet das Paket weiter

Level 2 Routing

Wenn sich das Ziel in einer anderen Area befindet, leitet der Router das Paket an den nächsten Level-1-2-IS weiter. Dieser Vorganng nennt sich Level-2-Routing. Die Paket wird weitergeleitet, bis es eine Level-1-2 Router bzw. einen Level-2-Router im Zielnetz erreicht. Innerhalb der Zielarea routet IS das Paket, basierend auf der System-ID, auf den besten Pfad

Level-2-Routing wird auch als Interarea-Routing bezeichnet

Level 3 Routing

Routing zwischen getrennten Domänen wird Level-3-Routing genannt. Das Level-3-Routing kann mit dem Border-Gateway-Protokoll, (BGP) verglichen werden. L3-Routing passiert zwischen verschiedenen AS, welche eine unterschiedliche Routinglogik verwenden und so unter Umständen Metrics haben, die nicht miteinander verglichen werden können. L3-OSI-Routing ist in Cisco-Routern nicht implementiert.

Zusammenfassung

• L0-Routing wird von ES-IS durchgeführt
• L1- und L2-Routing sind Funktionen von IS-IS
• IDRP führt das L3-Routing aus, wird von Cisco-Routern allerdings nicht unterstützt. IDRP ist ähnlich vielfältig wie BGP

Vergleich zwischen IS-IS und OSPF

Die beiden Protokolle sind relativ ähnlich. Beide Routingprotokolle haben folgende Merkmale:

• beide sind ein Open-Standard Link-State-Routingprotokoll
• beide unterstützen VLSM
• beide verwenden ähnliche Mechanismen (LSAs, Linkstate-Agingtimer und LSDB-Syncronisation) um die LSDB zu erhalten
• beide nutzen SPF, mit ähnlichen Update-, Entscheidungs- und Floodingprozellen
• beide werden erfolgreich in den größten und kompliziertesten Netzwerken eingesetzt (ISP)
• beide haben eine schnelle Konvergenz

Ein großer Unterschied zwischen den beiden Protokollen ist die Grenze anderen Areas. Während bei OSPF ein Router, der ABR, die Grenze darstellt, ist diese bei IS-IS der Link zwischen zwei L1-2-Routern. So kann bei IS-IS der Backbone erweitert werden, indem einfach weitere L2 und L1-2-Router hinzugefügt werden. Dadurch ist eine Erweiterung bei IS-IS wesentlich weniger komples als bei OSPF

Unterschiede

OSPF	Integrated IS-IS
Area-Grenze an den ABR	Area-Grenze an einem Link
Jeder Link nur in einer Area	Jeder Router nur in einer Area
Erweiterung des Backbones ist eher komplex	Einfache Erweiterung des Backbones
Gesendete LSA sind sehr klein	Es werden sehr wenige LSP gesendet
Läuft auf IP	Läuft auf dem DataLink-Layer
Benötigt IP-Adressen	Benötigt IP- und CLNS-Adressen
Die Defaultmetrik wird anhand der Interface-Bandbreite bestimmt	Die Defaultmetrik ist 10, für alle Interfaces
Knowhow und Equipment sind verfügbar	Knowhow und Equipment sind schwieriger zu finden

Zusammenfassung

• IS-IS ist ein unter ISPs populäres Routingprotokoll
• IS-IS ist ein stabiles IGP mit schneller Konvergenz, welches zum Routen von IPv4, IPv6 und CLNS verwendet wird
• Alle IS-IS-Interfaces haben per Default die Metrik von 10
• ES-IS (nur für CLNS-Routing) unterstützt das Bilden einer Nachbarschaft von Hosts und Routern mit Hello-Paketen. Hosts senden ESH, Router ISH
• OSI definiert vier Routinglevels, L0 bis L3. L0 deckt Routing zwischen ES und IS ab, L1 und L2 erledigen das Intradomainrouting, wobei L1 für Intra-, L2 für Interarearouting zuständig ist. L3 beinhaltet das Interdomainrouting
• OSPF und IS-IS sind Open-Standard-Routingprotokolle, die skalierbar sind, VLSM unterstützen und eine schnelle Konvergenz haben

 

Ablauf des Routingvorganges

Im Gegensatz zu IP-Adressen, wo die Adressen zu jeweiligen Interfaces gehören, werden CLNS-Adressen den jeweiligen Knoten zugeteilt. Da IS-IS ursprünglich für CLNS entwickelt wurde, benötigt IS-IS auch eine CLNS-Adresse, selbst wenn es nur für IP-Routing verwendet wird. CLNS-Adressen, die von Routern verwendet werden, bezeichnet man als Network Service Access Point(NSAP). Ein Teil einer NSAP-Adresse ist das NSAP-Sektor(NSEL)-Byte. Wenn ein NSAP eine NSEL von 0 besitzt, wird er Network Entry Title (NET) genannt.

NSAP-Adressen

• OSI-Networklayer-Adressierung ist mit NSAP-Adressen implementiert
• eine NSAP-Adresse identifiziert ein System im OSI-Netzwerk. Eine Adresse ist einem Knoten zugeordnet, nicht einem Interface
• verschiedene NSAP-Formate werden in verschiedenen Systemen verwendet
• NSAP-Adressen bestehen aus max. 20 Byte

1. Higher-Order-Bits für die Interarea-Struktur
2. Lower-Order-Bits für die Systeme in der Area

CLNS-Adressen, welche von Routern verwendet werden, werden NSAP-Adressen genannt. Anders als bei IP-Adressen werden NSAP-Adressen einem Gerät, nicht einem Interface zugeordnet

IP-IP Linkstate-Pakete (LSP) verwenden NSAP-Adressen, um die Router zu identifizieren und die Topologietabelle zuerstellen, die den Grundstock zum IS-IS-Routingbaum darstellt. Hierfür benötigt IS-IS NSAP-Adressen, selbst wenn IS-IS nir für IP-Routing verwendet wird. NSAP-Adressen beinhalten:

• die OSI-Adresse für das jeweilige Gerät
• den Link zum higher-layer-Prozess

Die NSAP-Adresse ist das Equivalent zu IP-Adresse und dem Upper-Layer-Protokoll im IP-Header

Es gibt verschiedene NSAP-Adressformate

 

Integrated IS-IS NSAP Adressstruktur

 

Die Cisco-Implementierung von Integrated IS-IS teilt die NSAP-Adresse in drei Felder: die Area-Adresse, die System-ID und das NSEL. ISO NSAP-Adressen bestehen aus

• der Authority and Format Identifier (AFI) und der Initial Domain Identifier (IDI) bilden den Initial Domain Part (IDP) der NSAP-Adresse. Dies entspricht in etwa einem classfull-Netzes in IP

• Das AFI-Byte spezifiziert das Format der Adresse. So entspricht ein Wert von 39 ISO-Data-Country-Code (DCC), 45 entspricht E.164, und 49 steht für lokal-administriert, also private Adressen
• Adressen, die mit AFI 49 starten, gelten als private Adressen, ähnlich http://www.faqs.org/rfcs/rfc1918.html">RFC 1918 bei IP. IS-IS routet diese Adressen, allerdings sollten sie nicht anderen CLNS mitgeteilt werden, da sie Ad-Hoc-Adressen sind.
• die IDI markiert die Subdomain unter der AFI. So ist zum Beispiel 47.0005 zivilen Einrichtungen der US-Regierung zugewiesen, 47.0006 dem DoD
• der Domain-Specific-Part (DSP) liefert das Routing in der IS-IS-Routingdomain. Der DSP enthält den High-Order-Domain-Specific-Part (HO-DSP), die System-ID, und die NSEL

• die HO-DSP teilt die Domain in Areas. Die HO-DSP ist mehr oder weniger mit dem Subneting in IP zu vergleichen
• die System-ID identifiziert das jeweilige OSI-Gerät.
• die NSEL steht für einen Prozess am Gerät, und ist grob mit Ports oder Sockets in IP vergleichbar. NSELs spielen bei Routenentscheidungen keine Rolle

Typische NSAP-Adressstruktur

Das einfachste IS-IS-Format, dann von den meisten IS-IS-verwendenden Firmen eingesetzt wird, ist folgendes:

• Areaadresse (mindestens 1 byte).

• AFI auf 49 gesetzt

• lokal administriert; dadurch können eigene Adressen verwendet werden

• Area-ID

• Die Oktette der Area-ID nach der AFI

• System-ID

• Cisco-Router benötigen eine 6-byte-System-ID

• NSEL

• bei Routern immer 0

Das NSAP wird NET genannt, wenn die NSEL gleich 0 ist. Router verwendern NET um sich selbst in den IS-IS-PDUs zu identifizieren

Als Beispiel kann die Adresse 49.0001.0000.0c12.3456.00 zugewiesen werden. Diese Adresse bedeutet:

• AFI 49
• Area-ID 0001
• System-ID 0000.0c12.3456, eine MAC-Adresse eines LAN-Interfaces
• die NSEL auf 0

In einigen Dokumentationen wird anstatt des Begriffes "Area-ID" das Synonym "Area-Adresse" verwendet

Identifizieren von Systemen in IS-IS

Area-Adresse

Der erste Teil der NSAP ist die Area-Adresse. Sie ist dem Routingprozess zugeordnet. Im Unterschied zum OSPF kann ein IS-IS-Router nur Mitglied einer Area sein

Alle Router in einer Area müssen die selbe Area-ID haben. Die Area-ID wird im L2-routing verwendet

End-Systems (ES) erkennen nur IS und andere ES im selben Subnetz, wenn sie die selbe Area-ID haben

System-ID

die 6-byte-NSAP-System-ID muss in einer Area einzigartig sein. Üblicherweise verwendet man eine MAC-Adresse des Routers, ider man wandelt eine IP-Adresse um (für Integrated IS-IS). Alle System-IDs in einer Domäne müssen die selbe Länge haben. Cisco erzwingt diese OSI-Direktive, indem immer 6 byte für die System-IDs vorausgesetzt werden.

L1 Intra-Area-Routing verwendet die System-ID. Daher müssen ES und IS einzigartige System-IDs haben

Alle L2-IS erkennen unter Umständen alle anderen IS im L2-Backbone. Daher müssen auch hier die System-IDs einzigartig sein

Folglich ist es ratsam, in einer Domain ausschließlich einzigartige System-ID-s zu verwenden, da so sie Probleme entstehen können, wenn z. B. ein Gerät in eine andere Area verlegt wird

NET-Adressen

• NSAP-Adressen beinhalten ein NSEL-Feld (Prozess- oder Portnummer)
• NET: NSAP mit einem NSEL-Feld 0

• gehört dem Gerät selber (wie die OSI-Schicht-3-Adresse des Gerätes)
• wird nur in Routern verwendet, denn nur Router sind in der Netzwerkschicht implementiert (die Basis für die SPF-Berechnung)

Subnetwork Point of Attachment (SNPA) und Circuit

Drei weitere Begriffe in IS-IS sind Subnetwork Point of Attachment, Circuit und Link

SNPA

Der SNPA ist der Punkt, der Subnetting ermöglicht. Der SNPA ist das Equivalent zur L2-Adresse, entspricht dem NET oder der NSAP-Adresse

Der SNPA eird wie folg bestimmt

• die MAC-Adresse eines LAN-Interfaces
• der Virtual Circuit-ID von X.25 oder ATM-Verbindungen, oder der Data-Link Connection Identifier (DLCI) einer Framerelay-Verbindung
• für High Level Data Link Control (HDLC) einfach HFLC

Circuit

Ein Circuit ist der IS-IS-Ausdruck für ein Interface. Da NSAP und NET das genamte Gerät bezeichnen, wird der Circuit verwendet, die einzelnen Interfaces zu unterscheiden. Der Router weist die Circuit-ID (ein Oktet) den Interfaces wie folgt zu:

• im Falle einer Punkt-zu-Punkt-Verbindung ist die SNPA die einzige Bezeichnung für einen Circuit. So ist zum Beispiel die Circuit-ID an einem HDLC Punkt-zu-Punkt-Link 0x00
• bei einem LAN-Interface wird die Circuid-ID mit der aus sechs Oktetten bestehenden System-ID eines designierten IS zu einer sieben-Oktett-LAN-ID verbunden. Ein Beispiel hiefür wäre 1921.6800.0001.01. Auf Cisco-Routern wird anstelle der System-ID der Hostname verwendet. Eine mögliche Circuit-ID könnte so ANOR01.01 sein

Link

Ein Link ist der Pfad zwischen zwei benachbarten IS. Der Status "up" ist definiert, wenn die Kommunikation zwischen den benachbaten SNPAs möglich ist

IS-IS Routing Levels

Level 1, Level 2 und Level1-2 Router

• Level 1 (entspräche OSPF interne Nicht-Backbone-Router)

• Intra-Area-Routing erlaubt es ES zu kommunizieren
• Level 1 Area ist eine Ansammlung von L1 und L1-2-Routern
• Level 1 IS haben eine Kopie der L1-Area-LSDB

• Level 1-2 (ähnlich en ABR in OSPF)

• Intra- und Interarea-Routing
• L1-2 IS hat für L1 und L2 je eine eigene LSDB, und bietet den L1 eine Default-Route

• Level 2 (wie OSPF-Backbone-Router)

• Interarea-Routing
• Level 2, der Backbone, ist eine zusammenhängende Reihe von L2- und L1-2-Routern
• L2 IS haben eine Kopie der L2-LSDB

Intra und Interarea-Adressierung und Routing

• die Area-Adresse wird für das Routing zwischen Areas verwendet. Die System-ID wird hier nicht berücksichtigt
• die System-ID wird für das Routing in der Area verwendet. Hier wird die Area-ID nicht berücksichtigt

 

Der Area-ID-Teil der NSAP-Adresse kann eine Länge von 1 - 13 bytes aufweisen, wie im ISO-Standard definiert. Daher ist eine NSAP-Adresse mindestens 8 byte lang. Um Flexibilität zu gewährleisten ist sie meist länger. Die Area-ID ist bei allen Geräten in einer Area gleich, und in allen Areas unterschiedlich. ES und IS haben, sofern sie sich in der gleichen Area befinden, die gleiche Area-ID

Routing in Areas hat zur Folge, dass alle System-IDs und Nachbarschaften aller IS und ES in der Area gesammelt werden, und mittels des SPF-Algorithmus der beste Pfad zwischen den Geräten bestimmt wird. L1-Router kennen nur die lokale Routingtable, die der eigenen Area. Sie leiten Traffic, der für eine andere Area bestimmt ist, an ihren nächsten L1-2-Router weiter.

Routing zwischen Areas basiert auf den Areaadressen. L2-Router der verschiedenen Areas tauschen die Areaadress-Informationen aus und nutzen den SFP-Algorithmus um den besten Pfad zwischen den Areas zu bestimmen.

 

OSI IS-IS Routinglogik

• L1-Router: für die weitere Vorgehensweise vergleichen sie die Areaadresse des Zielpaketes mit der der eigenen Area

• wenn sie gleich ist, verwenden L1-Router die System-ID um das Paket dem Ziel in der eigenen Area zuzustellen
• wenn sich die Area-IDs unterscheiden, werden die Pakete zu dem nächsten L1-2-Router weitergeleitet

• L1-2-Router: diese vergleichen ebenso die Area-ID

• ist sie gleich, verwenden sie für die Zustallung die L1-Datenbank und die System-ID für die Zustellung
• ist sie ungleich kommt die L2-Datenbank zum Tragen, und das Paket wird nach der Area-ID geroutet

 

Route Leaking

Dies ist ein seit den IOS 12.0 verfügbares Feature, welches L2-Routern erlaubt, Traffic zu einem L1-Router umzuleiten, um asymetrisches Routing zu verhindern.

Dieses Frature hilft, nicht obtimales Routing zu verbessern, indem es einen Mechanismus bietet, L2-Informationen in eine L1-Area einfließen zu lassen. Da L1-Router mehr Informationen bezüglich Intraarearouting haben, können diese gegebenenfalls einen besseren Weg in eine andere Area finden, indem sie einen anderen L1-2-Router verwenden

Route Leaking ist im http://www.faqs.org/rfcs/rfc2966.html">RFC 2966 definiert.

Beim implementieren von Route-Leaking wird ein up/down-Bit im TLV (Type, Length und Value, Tyte 128 und 130, IETF hat ebenso eine 135 definiert) gesetzt. Ist das bit auf "0", stammt die Route aus einer L1-Area

Ist das Bit allerdings auf "1", wurde die Route von L2 redistributiert. Dieser Mechanismus wird verwendet, um Routingloops vorzubeugen.

Diese Funktion sollte eher vorsichtig verwendet werden, da eine Topologieänderung in einer Area Auswirkungen auf viele andere Router, in anderen Areas haben könnte

 

IS-IS PDUs

Der OSI-Stack definiert eine Einheit aus Daten als PDU. OSI bezeichnet einen Frame als ein Data-Link-PDU und ein Paket als Network-PDU

In der Grafik sind drei PDU-Typen angeführt, alle drei mit der IEEE 802.2 Logical Linc Lontrol (LLC) Verkapselung. IS-IS und ES-IS PDUs sind direkt in ein Data-Link PDU verkapselt (frame); es bibt kein CLNP und keinen IP-Header. In andere Worten, IS-IS und ES-IS verpacken keine Routinginformationen in IP oder CLNP-Paketen, sie geben die Information direkt in einen Data-Link-Frame.

CLNP-Pakete beinhalten den ganzen CLNP-Header zwischen dem Data-Link-Header und den höheren CLSN-Informationen

IS-IS und ES-IS PDUs haben eine variable Feldlänge, abhängig von der Funktion des PDU. Jedes Feld beinhaltet einen Typencode, die Länge, und die diverse Werte (Values). Diese Informationen werden auch TLV genannt

IS-IS PDUs sind also direkt in einen OSI-DataLink-Frame verlkapselt. Es gibt weder einen CLNP noch einen IP-Header

IS-IS definiert vier PDU-Typen:

• Hello PDU (ESH, Intermediats System Hello [ISH], IS-IS-Hello[IIH]): sie werden verwendet, um Nachbarschaften herzustellen und aufrechtzuerhalten
• LSP: wird zum Verbreiten von LinkState-Informationen verwendet
• Partial Sequence Number PDU (PSNP): wird zur Bestätigung bzw. Neuanforderung verlorener Teile von LinkState-Informationen verwendet
• Complete Sequence Number PDU (CSNP): wird verwendet, um die kompletten LSPs in der LSDB eines Routers darzustellen

 

LinkState Pakete (LSP)

Ein Link-State-Paket repräsentiert einen Router. Ein Router beschreibt sich selbst mit einem LSP

In IS-IS wird die Charakteristik eines Routers mittels eines LSP definiert. Das LSP eines Routers besteht aus dem LSP-Header und den TLV-Feldern

• ein LSP-Header enthält folgendes

• den PDU-Typ und die Länge
• die LSP-ID
• die LSP-Sequenznummer, welche verwendet wird, um doppelte LSPs festzustellen und um sicherzustellen, dass nur die aktuellsten LSP-Informationen in der Topologietabelle gespeichert bleiben
• die verbleibende Lifetime des LSP

• TLV-Felder enthalten

• die Nachbar-IS des Routers, mit diesen wird eine Netzwerk-Karte erstellt.
• die benachbarten ES des Routers
• Authentikationsinformationen, um die Route-Updates abzusichern
• angeschlossene IP-Subnetze (optional für Integrated IS-IS)

LSP-Header

Im Header befindet sich eine Sequenznummer. Wird ein Router neu gestartet, steht die Sync-Nummer wieder auf "1". Nun empfängt der Router sein ursprüngliches LSP mit der Sequenznummer von vor dem Reload von seinen Nachbarn. Er nimmt das Paket auf und erhöht die Nummer wieder um "1". Durch dieses Verfahren wird sichergestellt, dass nur aktuelle LSPs im Umlauf sind

Ebenso befindet sich die Lifetime im Header. Dadurch verschwinden veraltete LSPs aus den Topologietabellen. Die Lifetime eines LSP beträgt 1200 Sekunden

 

LSP TLV Beispiele

TLV	Type	Längenfeld	veränderbare Länge
Area Adresse	1	Area-ID	Area
IS-Nachbarn	2	Nachbarcount+1	IS-Nachbarn
interne IP-Erreichbarkeit	128	Anzahl der verbundenen Präfixe	verbundene IP-Präfixe - 4byte metric, 4byte prefix, 4byte mask
externe IP-Erreichbarkeit	130	Anzahl der redistributierten Präfixe	redistributierteIP-Präfixe - 4byte metric, 4byte prefix, 4byte mask

Jeder Informationssatz, welcher "tuple" genannt wird, enthält einen Typencode, ein Längenfeld und die Länge

Jedes LSP enthält spezifische Informationen über das Netzwerk und die an einem Router angeschlossenen Geräte. Diese Informationen befinden sich in verschiedenen TLV-Feldern, hinter dem Header. Die TLV-Struktur ist eine flexible Art, Daten dem LSP hinzuzufügen, und ein einfacher mechanismus für zukünftige Erweiterungen

 

Genauere Dokumentation über wichtige TLV finden sich in ISO 10589 und http://www.faqs.org/rfcs/rfc1195.html">RFC 1195

 

Implementierung von IS-IS in NBMA-Netzwerken

Netzwerktopologien entsprechen im Allgemeinen einer von zwei Typen

• Punkt-zu-Punkt-Netzwerke: Point-to-Point-Links sind entweder permanent (leased line, permanent virtual circuit [PVC]) oder dynamisch (ISDN, switched virtual circuit [SVC])
• Broadcast-Netzwerke: Multipoint-WAN-Links oder LAN-Links wie Ethernet, FDDI oder Token Ring

IS-IS unterstützt

• Broadcast für LAN und Multiport-WAN-Links
• Point-to-Point für alle anderen Medien

IS-IS kann mit NBMA-Netzen nichts anfangen. Es sollte auf Point-to-Point-Links, wie ATM, Frame-Relay oder X.25 zurückgegriffen werden

Netzwerktypen in NBMA implementieren

IS-IS in Broadcast-Netze implementieren

• wird für LAN- und Multipoint-WAN-Interfaces verwendet
• Nachbarschaften werden mit "hello" hergestellt; es gibt eigene L1 und L2-Nachbarschaften
• Designiertes IS (DIS) erstellt einen Pseudonode und repräsentiert das LAN
• DIS dür L1 und L2 können sich unterscheiden
• DIS wird nach folgenden Kriterien bestimmt

• nur Router mit geeigneter Umgebung
• die höchste Interface-Priorität
• sollten mehrere geeignete Router überbleiben, entscheidet die SNPA (MAC), die höchste gewinnt

• es gibt kein Backup-DIS

Der BC-Mode ist nur für LAN-Interfaces empfehlenswert, ist allerdings auch bei den multiport-WANs per Default aktiviert.

LSP repräsentiert Router: LAN-Repräsentation

Bei IS-IS ist ein Broadcast-Link als Pseudonode dargestellt, an dem alle Router sternfärmig angeschlossen sind. Der DIS stellt den Pseudonode dar.

Router, auch der DIS, haben leichter eine einfache Nachbarschaft mit dem Pseudonode, als eine Nachbarschaft zu allen anderen Router im LAN. Ansonsten müsste jeder Router in einem Netzwerk mit n IS (n*(n-1)/2) nachbarschaftliche Verbindungen benötigen. Dies würde gewaltige Last bei der LSDB-Syncronisation nach sich ziehen

Der DIS generiert die Pseudonode-LSP. Ein Pseudonode-LSP detailiert nur die benachbarten IS (z.B. die im gleichen LAN). Es wird verwendet, um eine Netzwerkkarte zu erstellen und den SPF zu berechnen. Das PseudoLSP ist das Equivalent zum LinkState Advertisement (LSA) in OSPF

Bei IS-IS stellen Alle Router im LAN eine nachbarschaftliche Beziehung mit allen Routern inklusive dem DIS her. Daher kann, sollte der DIS ausfallen, ein anderer Router dessen Aufgabe schnell übernehmen, mit keinen oder nur geringen Auswirkungen auf die Toplogie des Netzes. Dies ist ein Unterschied zu OSPF, wo dem DR ein BDR zur Seite steht. Sollte der DR ausfallen, wird der BDR zum DR, und ein neuer DBR wird gewählt. In IS-IS ist dies nicht nötig.

LSP und IIH-Levels

• Da IS-IS aus zwei Levels besteht, werden auch zwei LSP-Typen benötigt: L1 und L2-LSPs
• Der DIS ist der "Beauftragte" des LAN:

• er sendet pseudo-L1 und pseudo-L2 für das LAN
• für L1 und L2 existieren eigene DIS

• LSP werden unicast in Punkt-zu-Punkt-Netzwerken gesendet
• In Broadcast-Netzen werden sie per Multicast gesendet
• In LAN werden eigene L1 und L2-IIHs versendet, per multicast
• Bei Punkt-zu-Punkt wird ein einfaches IIH-Format verwendet, per multicast versendet

Vergleich BC und PtP-Topologien

 

Konfiguration: Basic Integrated IS-IS

Selbst wenn IS-IS ausschließlich für IP verwendet wird, müssen die Router das OSI CLNS (ConnectionLess NetworkService) verwenden. Jeder Router benötigt einen Network Entity Title (NET), und die IS-IS-Pakete werden direkt am DataLink-Layer verkapselt

Die Konfugutarion von IS-IS unterscheidet sich leicht von der OSPFs und der von EIGRP. weiters sind die Defaulteinstellungen von IS-IS suboptimal, das heisst, so eingesetzt würden die vorhandenen Netzwerkressourcen nicht bestmöglich genutzt. Zwei Gründe, warum sich ein IS-IS-Admin mit der Materie genau beschäftigen muss...

Integrieren von IS-IS in eine CLNS-Umgebung

Eine NER-Adresse bezeichnet ein Gerät, nihct ein Interface. Dies ist ein wichtiger Unterschied zwischen NET- und IP-Adressen

Auch wenn nur IP geroutet werden soll muss jeder Router mit NET-Adressen bezeichnet werden, da IS-Is aus CLNS-Routing basiert

Die OSP-Protokolle (hello PDUs) werden verwendet, um die Nachbarschaftsbeziehungen herzustellen, die SPF-Berechnung passiert mittels NET-Adressen

Ein Gerät identifiziert ein anderes anhand der NET-Adresse. Daran erkennen die Geräte, dass sie miteinander kommunizieren können, entweder mit oder ohne einer Default-Route.

IS-IS verwendet eine OSI-Weiterleitungsdatenbank (die Routingtabelle) um den besten Pfad zum Ziel zu finden. Wenn die Datenbanken syncronisiert sind, verwenden Router die LSDB um den SPF-Baum zu den OSI-Zielen, den NETs, zu berechnen

L1 und L2-Router haben eigene LSDBs. Daher kann es sein, dass ein Router den SPF zweimal benutzen, einmal pro Level, und zwei SPF-Trees erstellen muss

Die Router legen die besten Pfade un der CLNS-Routingtabelle ab

Integrated IS-IS baut die IP-Informationen in die LinkState-Pakete (LPS) ein, und behandelt sie so wie ES-Informationen im SPF-Tree. Daher erfordert ein Update der IP-Erreichbarkeit, wie bei ES, nur eine Partial Route Calculation (PRC)

Die PRC generiert eine Auswahl an möglichen besten Routen, und leitet diese an die IP-Routingtable weiter, wo sie nach normalen IP-Routingtabellen-Regeln akzeptiert werden. So berücksichtigt der Router beim Vorhandensein mehrerer Routingprotokolle die Administrative Distanz. Wenn IS-IS-Routen in die IP-Routingtabelle einfließen, werden diese als L1 bzw L2 gezeigt, je nachdem was zutrifft

Durch die Trennung IP - Corenetz bietet Integrated IS-IS eine wesentlich bessere Skalierbarkeit als beispielsweise OSPF

 

Konfiguration: Integrated IS-IS

Die Grundkonfiguration von IS-IS lässt sich in vier Schritten zusammenfassen:

1. Bestimmen von Areas, vorbereiten des Adressplans (NETs) für Router, und bestimmen der Interfaces Es muss die Entscheidung fallen, wer L1, L2, L1-2-Router wird. Neben dem CLNS-Adressplan (NET) darf auch der IP-Adressplan nicht vergfessen werden. Hier sollte auf die Routesummarization nicht vergessen werden

2. IS-IS am Router aktivieren

router(config)# router isis [area-tag]

mit dem tag kann eine Prozessnummer vergeben werden, welche allerdings nur Einfluss auf den lokalen Router hat. Ein Cisco-IOS nimmt per Default eine "0" als tag an.

CLNS-Routing ist standardmäßig deaktiviert. Um es zu aktivieren muss das globale Kommando

clns routing

gesetzt werden, weiters muss das CLNS-Routing auf jedem betroffenem Interface aktiviert werden.

Per Default ist ein Cisco-Router ein L1-2-Router

3. NET konfigurieren Dies passiert mittels

net [network-entity-title]

Hier wird die Kombination aus Area-Nummer, der einzigartigen System-Identifizierungsnummer jedes einzelnen Routers und der NSEL 00 am Ende verwendet

Die Areanummer muss zwischen einem und 13 Bytes lang sein, bei Cisco ist die SystemID fix auf 6 bytes gesetzt.

4. Integrated IS-IS auf den auf den jeweiligen Interfaces aktivieren.

router(config-if)# ip router [area-tag]

Dies ist der letzte Schritt, es wird das Interface, auf welchem das IS-IS-Routing aktiviert werden soll.

Sollten mehrere IS-IS-Prozesse ausgeführt werden, muss der zugehörige Prozess mittels des area-tags angegeben werden

Auch hier gilt: Sollte CLNS-Routing aktiviert werden müssen, passiert dies mittels des Befehles

clns routing isis [area-tag]

Beispiel

interface Ethernet0/0
 ip address 192.168.1.1 255.255.255.0
 ip router isis
!
interface Serial1/1
 ip address 172.16.0.2 255.255.255.0
ip router isis
!
[gekürzt]
router isis
 net 49.0001.0000.0000.0002.00

Dies bedeitet

• 49.0001 ist die Area, eine "private"
• 0001.0000.0000.0002 ist die einzigartige SystemID
• IS-IS ist auf E0/0 und S1/1 aktiviert
• da nichts anderes konfiguriert ist, handelt es sich hier um einen L1-2-Router

Optimierung von IS-IS

Ändern des Router-Levels

router(config-router)# is-type [level-1 | level-1-2 | level-2-only]

Zwar würde das Netzwerk mit ausschließlich L1-2-Routern auch funktionieren, dies würde allerdings

• Speicherverschwendung (Jeder L1-2-Routrer hat eine LSDB von L1 und L2) und
• Bandbreitenverschwendung (Hellos und LSPs würden über alle Router/Netze laufen)

bedeuten

Ändern des Interface-Levels

router(config-if)# isis circuit-type [level-1 | level-1-2 | level-2-only]

Auch hier sind alle Interfaces standardmäßig auf L12 gesetzt. Unter Umständen können aber einzelne Interfaces L1 oder L2 zugewiesen werden, was wiederum Ressourcen spart

Ändern der IS-IS-Metrik

router(config-if)# isis metric metric [delay-metric [expanse-metric [error-metric]]] {level-1 | level-2}

Hiermit wird eine Metrik auf einem Interface konfiguriert, die Defaultmetrik ist 10. Die Metrik kann einen Wert zwischen 1 und 63 betragen

router(config-router)# metric [default-valute [level-1 | level-2]

Alternativ kann die Metrik global, für alle Interfaces angegeben werden. Dieser Befehl ist nur ab IOS >12.3(4)T verfügbar, und es wird nur die Cost-Metrik unterstützt

 

Konfiguration von Route-Summarization in IS-IS

router(config-router)# summary-adress adress mask [level-1 | level-2 | level-1-2] [tag Tagnummer] [metric Metriknummer]

So wird die Summarization erstellt. Default hierbei ist Level 2

Anbei ein Beispiel

router(config-router)# summary-adress 10.3.2.0 255.255.254.0 level-1-2

Hier wird eine Summarization von 10.3.2.0/23 in Level 1-2 erstellt.

 

Überprüfen der IS-IS-Konfiguration

Mit zwei einfachen, bekannten Befehlen kann die Konfiguration überprüft werden:

• show ip protocols: zeigt die aktiven IP-Routingprotokolle, die Interfaces, die am Routingprozess teilnehmen und die gerouteten Netzwerke
• sh ip route: zeigt die gesamte IP-Routingtabelle. Hier sind detailierte Angaben zu den Routen und den Protokollen zu finden

So würde

show ip route isis

zum Beispiel mittels '"i L2"' bekannt geben, dass es sich um eine I-ISIS-Toute aus Level 2 handelt. Weiters würde [115/20] für die Integrated-IS-IS-Distanz von 115 stehen, die IS-IS-Metrik würde hier auf 20 gestellt sein

Überprüfen der CLNS IS-IS-Struktur

Troubleshooting Kommandos: CLNS

router# show clns

zeigt generelle Informationen über das CLNS-Netzwerk

router# show clns [area-tag] protocol

zeigt Informationen über die spezifischen IS-IS-Prozesse am Router

router# show clns interface [type number]

zeigt Informationen über die Interfaces, auf denen CLNS läuft

router# show clns [area-tag] neighbors [type number] [detail]

zeigt, wenn vorhanden, IS und ES-Nachbarn.

Troubleshooting Kommandos: CLNS und IS-IS

router# show isis [area-tag] route

zeigt die L1-IS-IS-Routingtabelle, welche alle anderen SystemIDs der Area enthält. Ist nur verfügbar, wenn CLNS-Routing global und am Interface aktiviert ist

router# show clns route [nsap]

zeigt die L2-Routingtabelle, welche alle Routen zu allen bekannten Areas zeigt

router# show isis [area-tag] database

zeigt die IS-IS-LSDB. Um ein Refresh der LSDB zu erzwingen, kann clear isis * verwendet werden

router# show isis topology

zeigt die L1 und L2-Topologietabellen, in welchen die billigsten Pfade zu den jeweiligen IS beschrieben stehen

aus ANOther Wiki, der freien Wissensdatenbank

Cacti ist ein Tool, welches verschiedenste Zustände in einem Netzwerk graphisch darstellen kann. Es nutzt dabei die Funktionen des http://oss.oetiker.ch/rrdtool/">rrdtool

Inhaltsverzeichnis 1 Bezugsquellen 2 Voraussetzungen 3 Installation 4 Weitere Infos 5 Upgrading Cacti to latest version

Bezugsquellen

Cacti kann direkt von der http://www.cacti.net/download cacti.php">cacti-Homepage bezogen werden.

Voraussetzungen

Cacti benötigt ausserdem folgende Software:

1. RRDTool 1.0.48 oder höher
2. MySQL 3.23 oder höher, wobei höher als 4.0.20d empfohlen wird
3. PHP 4.1 oder höher, wobei höher als 4.3.6 empfohlen wird

http://www.debianhelp.co.uk/apacheinstall.htm">Apache mit php-Unterstützung wird ebenso vorausgesetzt

Installation

Unter Debian ist die Installation mit

# apt-get install cacti

denkbar einfach. So werden gleich die benötigten Pakete wie mysql und rrdtool mitinstalliert, sofern nötig

Nun müssen unter Umständen einige Zeilen geändert werden:

/etc/php4/apache/php.ini

extension=mysql.so

extension=gd.so

und

From /etc/apache2/apache2.conf

AddType application/x-httpd-php .php

Danach sollte ein cacti-User angelegt werden:

adduser cacti

Erstellen der MySQL-Datenbank

mysqladmin --user=root create cacti

Die default-Datenbank importieren:

gunzip /usr/share/doc/cacti/cacti.sql.gz
mysql cacti < /usr/share/doc/cacti/cacti.sql

Nun muss die /etc/cacti/debian.php angepasst werden:

$database_default = "cacti";
$database_hostname = "localhost";
$database_username = "cactiuser";
$database_password = "cacti";

Nun ein paar Rechte setzen

 chown -R cactiuser rra/ log/

wobei "cactiuser" ein gültiger user sein sollte

Nun noch einen Eintrag in die /etc/crontab

 */5 * * * * cactiuser php /usr/share/cacti/site/poller.php > /dev/null 2>&1

Wobei u.U. der User und der Pfad angepasst werden müssen

Nur noch vhost anpassen und fertig. Das erste Einloggen passiert mit admin/admin In den folgenden Seiten können einzelne Pfade noch einmal überprüft werden.

Weitere Infos

cacti-support-forum: http://forums.cacti.net/">http://forums.cacti.net/

off. Patches: http://www.cacti.net/download patches.php">http://www.cacti.net/download_patches.php

cacti-scripts: http://www.cacti.net/additional scripts.php">http://www.cacti.net/additional_scripts.php

screenshots: http://www.cacti.net/screenshots.php">http://www.cacti.net/screenshots.php

Upgrading Cacti to latest version

1. Backup the old Cacti database.

2. shell> mysqldump -l --add-drop-table cacti > mysql.cacti

Note: You will probably have to specify the -u and -p flags for the MySQL username and password. This user must have permission to read from Cacti's database or you will end up with an empty backup.

3. Backup the old Cacti directory.

4. shell> mv cacti cacti_old

5. Extract the distribution tarball.

6. shell> tar xzvf cacti-version.tar.gz

7. Rename the new Cacti directory to match the old one.

8. shell> mv cacti-version cacti

9. Edit include/config.php and specify the MySQL user, password and database for your Cacti configuration.

10. $database_default = "cacti";

11. $database_hostname = "localhost";

12. $database_username = "cactiuser";

13. $database_password = "cacti";

14. Copy the *.rrd files from the old Cacti directory.

15. shell> cp cacti_old/rra/* cacti/rra/

16. Copy any custom scripts from the old Cacti directory.

17. shell> cp cacti_old/scripts/* cacti/scripts/

18. Set the appropriate permissions on Cacti's directories for graph/log generation. You should execute these commands from inside Cacti's directory to change the permissions.

19. shell> chown -R cactiuser rra/ log/

(Enter a valid username for cactiuser, this user will also be used in the next step for data gathering.)

20. Point your web browser to: http://your-server/cacti/">http://your-server/cacti/>

If you need any help you can use cacti forums http://forums.cacti.net/">http://forums.cacti.net/